not only [Sketch] - FC becomes unresponsive while performing calculations

[uwestoehr]

By using a PD Pattern, if that meets your needs. Here, others will be able to advise you better.

This does not help me since I have to create cut paths for a laser cutter. At the moment I take a sketch and export its elements as a single DXF and the laser cutter can directly use them.

Maybe using the Draft WB is an alternative?

For deletion, it may be possible to do group deletion. I think the code is already there in SketchObject. I can look into this.

Thanks.

In such straightforward case, while for you it is evident the result (substract 4 DoF from the previous rank), it is not obvious for the software and it needs to calculate it. When it comes to a more serious delete, it is generally the case that you will have a very hard time to calculate the actual DoF, redundant constraints and so on. The software still does it (provided enough time is provided)...

OK. I understand.

So for Sketcher there is not much room for improvement, but for FC. I unfortunately don't have any knowledge regarding the calculation distribution over different CPU kernels. But I have e.g. 8 CPU kernels and it is sad to see that FC only uses one of it.

Then I often read that some calculations are fast on the GPU, so maybe this could be an option. Does anybody knows more about calculating on the GPU?

[abdullah]

This does not help me since I have to create cut paths for a laser cutter. At the moment I take a sketch and export its elements as a single DXF and the laser cutter can directly use them.

Maybe using the Draft WB is an alternative?

I see.

I am not sure if one can do clones or draft arrays of sketches.

Hopefully somebody else has already run that road and can help.

So for Sketcher there is not much room for improvement, but for FC. I unfortunately don't have any knowledge regarding the calculation distribution over different CPU kernels. But I have e.g. 8 CPU kernels and it is sad to see that FC only uses one of it.

Then I often read that some calculations are fast on the GPU, so maybe this could be an option. Does anybody knows more about calculating on the GPU?

Please feel my sympathy. It was great for me to see two kernels running for the parallel QRs.

SparseSuite can use the GPU in some of its algorithms. I am unsure how much work it could be to provide support for it. But it will never be part of FC LGPL as we know it. It may be a personally compiled version for yourself that you could only distribute under the GPL.

[user1234]

This is the reason why i am strictly against of any kind implementation of a array in the sketcher.

- it overloads the solver (CAD beginners will used that incorrect)
- the workflow does no profit from it, very rare exceptions excluded, but then there an easy workaround
- the tree is more intransparent (you do not see in the first look, where the arrays are "hidden", since you have an array but no feature for it)
- you can array any feature or sketch based geometries in PD, but not vis-à-vis --> inconsistency
- commercial CAD with sketch based solver also do not do that

This does not help me since I have to create cut paths for a laser cutter.

One of the rare exceptions:
- pad a sheet
- make the array based sketch
- pocket it
- array it feature based (since this have no solver and OCCT use tbb, which allows multicore calculations, it is pretty fast)
- DraftWB
- Top view of the sheet
- mark face
- shape 2D view (see webm)
- export it
- tschüss, next!

Or you just array the sketch alone, fusion it and export it.

Greetings
user1234

edit: blue

[M4x]

[...] since I have to create cut paths for a laser cutter. At the moment I take a sketch and export its elements as a single DXF and the laser cutter can directly use them. [...]

What about paddding / pocketing the sketches and export the body via TechDraw instead of the Sketches? Would you get the same result but with the possibility to use PD patterns?

[uwestoehr]

Or you just array the sketch alone, fusion it and export it.

many thanks. You inspired me to the solution that is so easy that I am a bit ashamed I did not find it earlier :
- create a sketch with a single rounded rectangle
- create a draft array of the sketch
- select the array in the tree and export it as DXF

that was it

[user1234]

Hello!

- create a draft array of the sketch

If you do not need the boundaries of the sheet, then this is the absolutely fastest way.

Greetings
user1234

[chrisb]

that was it

Glad to see you finally found a way to get your huge sketches back to a "recommended normal" size. It is often helpful, if you show the whole picture to the community, so that better help ius possible.
If you have irregular sketches, where no arraying is possible, you can still split into several sketches and export them all together into a single dxf.

[abdullah]

If you have irregular sketches, where no arraying is possible, you can still split into several sketches and export them all together into a single dxf.

I have been thinking about this particular case lately. There could be an "option" to use a "block" constraint alike concept here. Such geometry does not contribute in terms of DoF to the parameters or constraints. Therefore, it could be an option to patiently wait 1 minute once for creation, then "freeze" what won't be touched, so that solve times are handable again, if modifications are necessary, unfreezing part,... some kind of "modular" approach to handling very big sketches.

Do you think this would be useful?

There is some feature request in the tracker about improving the block constraint or providing something different from what we ended up last December. I will try to think about it then (if you want, you may link this post to help my failing memory ).

[user1234]

I think the sketcher is top notch! Also the block and lock function are very fine as they are, at least i think so. B-splines with pole constraints, then the sketcher is really imba.

Thank you for your hard work!

Greetings
user1234

[chrisb]

There is some feature request in the tracker about improving the block constraint or providing something different from what we ended up last December. I will try to think about it then (if you want, you may link this post to help my failing memory ).

Do you mean issue #4695? There was also a discussion about such a "this part of the sketch is ready"-block feature. I couldn't find it, perhaps the author (Uwe Stoehr?) is watching here.

Do you think this would be useful?

Sort of, but with more no than yes, because it may invite to inferior sketching. Sketching is not only applying a tool, it is an art. Good sketching leads to naturally constrained and easy understandable sketches. Creating huge sketches defeats this.

Among others I have learned much here from two highly professional modelers, one is NormandC and the other is Wilfried, AKA freecad-heini-1. There is no need to talk much about Normand, Wilfried was an educator of Pro/E. Both have the ability to create easily comprehensible models, and both propagate to keep sketches simple.
drmacro was also an educator of CAD systems and recommends too to keep the sketches simple.

In the old days Pro/E propagated the 7-7-7 rule, saying a sketch should
- either have no more than 7 elements
- or have no more than 7 dimensions
- or take no longer than 7 minutes.

Normand recommended a maximum number of 100 constraints.

Sketches are the core of many models, and most time is invested in creating them. If you have the sketches and nothing else you don't need too much time to rebuild a model. (That's how we migrated many models from 0.16 to higher versions.)

So the question is: Should we have a powerful tool, but rather recommend not to use it, or should we have a tool which rather enforces certain limits because we would recommend anyway to stay within them? To put it differently: is it worth investing time to implement something which we recommend not to use?