Using Pocket in part design workbench

[jriegel]

If the sketch is closed (with all coincident constraints at the points) it should always create a solid.
Holes you can do later with a Pocket feature.

[wmayer]

So my question is, would the developers find it helpful for me to start my sketcher design again from scratch and carefully and accurately note the issues, and submit a bug report (reports), or would it be better if I leave it for a while and try again when sketch is in a later stage of development?

From my point of view it's OK to report bugs as early as possible.

[yorik]

2) if I tried to use the upgrade arrow to go from lines to wire to closed shape ..... It would get confused. It looked like it was not recognising the arcs.

That's indeed a problem with the upgrade tool, some things like arcs are still not very well handled

[jriegel]

Mostly I think all PartDesign features need a check for the sketch quality. If the
sketch doesn't allow a proper solid (there are lot of things in a sketch which prevent that) the
user needs to be informed and the feature must fail.

[jmaustpc]

If the sketch is closed (with all coincident constraints at the points) it should always create a solid.
Holes you can do later with a Pocket feature.

'Morning all

I may not have had coincident constraints at all appropriate places, that day's version was crashing so often in sketcher that it was hard to keep up with where I was at.

To "save" one has to exit the "sketch editor dialogue box thingy", so the old "save early and save often" was not so convenient.

Also my layout was closed with curves in places, so perhaps it could have been related to the handling of arcs in some manner or other.

Anyway I have just now updated from the daily PPA again, so I will do some simple sketches and systematically test some sketcher features.

For example
one with just lines,
one with "wires?" (multi-point lines)
one with arcs

etc.


I will report back here later with the results.

Jim

[jmaustpc]

So my question is, would the developers find it helpful for me to start my sketcher design again from scratch and carefully and accurately note the issues, and submit a bug report (reports), or would it be better if I leave it for a while and try again when sketch is in a later stage of development?

From my point of view it's OK to report bugs as early as possible.

G'day again everyone

Is this sort of information useful?

Sketcher "bugs?", limitations.

I have made three simple sketch based projects, then "padded" by 20mm, not attached to a face, all on the xy plane. Files attached for your reference.
1) simple shape made from lines
2) same simple shape but made from a single "wire?" (multi point line)
3) same as 1) i.e. made from single lines but with two arcs

a) general issues with all files
a)1) on the "small sketcher" tool bar there is two buttons "create new sketch" and "close the editing of the sketch". The second button "close editing of the sketch" is not ever highlighted and does not ever seem to do anything.
a)2) with all three projects, if you open them up, double click or right click and select edit sketch in the combi view box, then select a part of the sketch with the mouse from the picture and drag it around with the mouse, freecad will freeze up. Project 1 (plain lines) seems to be able to be moved around heaps before it locks up, the project 2 "wire" locks up quickly, and project 3 (lines and arcs) locks up immediately. So presumably the more complicated the project the more quickly it locks up?
a)3) Once the coincident constraint has been used on two points, that new combined point is no longer selectable with the mouse. For example I made the top left hand points coincident and then wanted to define the horizontal distance between the point and another point on the diagram, but one can't.

b) functionality per project file (not including things already mentioned in part a) above)
b)1) project 1 simple lines. This seemed to work well, pad made a solid, constraints all seemed to work properly.
b)2) project 2 wires. This seemed to work well both with constraints and pad, but Freecad did crash and close once, at what seemed a random event (not repeatable as far as I can tell at this time)
b)3) project 3 simple lines with two arcs. Mostly constraints seemed to work, there was an "arc diameter limitation" (see below), Pad function produced a "tube" with narrow (presumably 0) wall thickness. Freecad crashed once when I selected and tried to drag an arc, which I had initially place in the wrong spot.
b)4) "arc diameter limitation". (I imagine this point is probably a low priority, if an issue at all) I noticed that with the arc on the bottom right corner I could not change the diameter constraint from 2.5mm (the radius), without getting an error message, (I had constrained the start and finish points of the arc with a coincidence constraint with the end of two horizontally constrained, and position constrained lines). So as I see it, the solver seems to be assuming that I want a 180 degree arc in this case? Normally I think most people would want the vertical distance (5mm in my file) between the end of the two horizontal lines to be equal to the radius of the arc to join then around their ends. But I thought one should be able to specify a larger diameter (smaller would not make sense but larger could) which would "solve" by reducing the degrees of the arc shown and moving the "centre position" accordingly. When I change the radius constraint the "Distance constraint" error box pops up saying "Datum 5.5 of constraint with index 18 is invalid". I assume this is referring to my 18th constraint in my list, which is a distance constraint for the start point of the upper short line which the arc joins to the other end of with a coincidence constraint. To put this another way, if I have a start and finish point for an arc, and I then define a radius that is half the distance between those points or larger, then those two points together with the radius, will determine how many degrees of the arc will be required and the location of the centre of the arc.

Freecad 4415 daily PPA on Kubuntu 11.04 with kde 4.7.

sketcher_singlelines.fcstd.zip

(4.71 KiB) Downloaded 44 times

sketcher_wirelines1.fcstd.zip

(5.39 KiB) Downloaded 41 times

sketcher_singlelines_and_arcs.fcstd.zip

(8.99 KiB) Downloaded 42 times

Jim

[wmayer]

To "save" one has to exit the "sketch editor dialogue box thingy", so the old "save early and save often" was not so convenient.

The Save button will now still be active while editing a sketch.

a1 -- is fixed
a2 -- should also be fixed now. There was an error in loading the project files so they should still be valid
a3 -- that is something very annoying and I have to dig into what the problem is

b1 -- OK
b2 -- Don't know why it crashed. Since it's not repeatable I don't see a chance to fix -- in case the crash was really caused by this.
b3 -- in the source code there are still too many assert() (this is a C-function and halts the application if the passed boolean expression is false). So, the chance is high that you met such an assert. (Maybe it's the same as in b2.)
The pad object lacks of its two lids and for any reason the internal shape is broken. We have this issue with other sketches where arcs are used. I think this is a problem with the cad kernel and we have to search for a workaround for it.
b4 -- the solver engine is still evolving and will be improved step by step. So, those things should be tested with a later version if they work as you expect them.

[jriegel]

b2 -- Don't know why it crashed. Since it's repeatable I don't see a chance to fix -- in case the crash was really caused by this.
b3 -- in the source code there are still too many assert() (this is a C-function and halts the application if the passed boolean expression is false). So, the chance is high that you met such an assert. (Maybe it's the same as in b2.)

Mhh, the asserts don't work any more as expected. In VS hitting an assert leafs a completely messed up stack and the debugger can not
see the point where the assert was.
Maybe its the catching of signals or the throwing exceptions on all kind of errors. I did not investigate yet.
Normally the user which hit a assert should get a appropriated massage with reason and source code line, so the
developer know what went wrong. If the standard C assert stop to work we can implement a alternative which work on
all platforms..

I personally like asserts to check if a api is used right and certain assumptions I made for a interface are meat...

[wmayer]

Mhh, the asserts don't work any more as expected. In VS hitting an assert leafs a completely messed up stack and the debugger can not
see the point where the assert was.
Maybe its the catching of signals or the throwing exceptions on all kind of errors. I did not investigate yet.

For me the asserts still work. In case you encounter one the debug application says which file and line. In release mode with VC an assert is be completely ignored but not necessarily on Linux with gcc. There it is very common to build an application in debug mode and when making a package the strip tool is used to remove all the debug symbols again. This means that asserts are still active and usually leads to an abnormal program termination if it fails.

Normally the user which hit a assert should get a appropriated massage with reason and source code line, so the
developer know what went wrong.

No, IMO that's completely wrong. A user should never ever worry about an assert() (which under Windows doesn't work anyway as mentioned above and also because __FILE__ and __LINE__ are only defined in debug mode). An assert() is only for the developer to test an API or algorithm but must not be used to check user input.

I personally like asserts to check if a api is used right and certain assumptions I made for a interface are meat...

But as said above they must not be used to check if user input is valid. And in the sketcher there are/were a lot of asserts which failed because of invalid user input, e.g. from python side.

[jriegel]

No, IMO that's completely wrong. A user should never ever worry about an assert() (which under Windows doesn't work anyway as mentioned above and also because __FILE__ and __LINE__ are only defined in debug mode). An assert() is only for the developer to test an API or algorithm but must not be used to check user input.

That would be true in a normal case. But here we have user which use basically code in development and debug it for us.
If on Linux a assert cause a program termination its the worse it can happen! The user loose the whole project and we have no info what happens and where.
It would be better in this case to throw an exception. There we have at least the change to recover and log.
For me on Windows the assert give me a Dialog box with line and file but even in the debugger the app is screwed.
In Release builds they left out, so I never will see if the user caused a special condition in some of the APIs...

So maybe we should do the following:

Write our own assert which break in debug, which throw an exception in unstable release builds and is non existent in
real releases.

Werner, what do you think?