Path from ShapeString fails : bug in master c. sept 2019

[Syres]

This is of course a better solution. Are you going to make a pull request as well?

For the sake of a few hours I was going to hang fire for the chance of a proper fix to include @mlampert's input. If he's busy then I'll get a PR together for the reversal of just the

Code: Select all

edges = copy.copy(PathOpTools.orientWire(offset).Edges)

back to

Code: Select all

edges = copy.copy(offset.Edges)

I'm a little conscious of being a bull in a pottery shop but I'm still working to understand how the PathOpTools.orientWire works!!

[freman]

Very commendable prudence. I'm not sure all those submitting PR are that careful !

I have just tried your file with a model containing three shapeStrings on a block , it seems that the first one works fine but subsequent attempts to use the other strings are resulting in multiple paths based on the first string.

I thought it was me being careless at first but I've repeated it a couple of times and only get that same result.

Can you check that?

[Syres]

Very commendable prudence.

That's my past role as a Technical Problem Manager coming out in me!! Just to make sure we are following the same steps, I've attached a file with 3 Shapestrings done in one Engrave operation using the same PathEngraveBase.py as you are using with build 0.19.18760.

Let me know if you can't get it to work but please just note down the steps from creating the Job onwards as this may also assist the other work I'm doing around the error handling and screen feedback to user.

Edit: Updated attachment to include an extrusion which is used as the Stock for the Job

[freman]

thanks, I'll check that in a little while. I need to concentrate on one thing at a time. I have managed to get three shapeStrings with a path. I have not checked paths in detail but looks OK. Three paths in one hit, one job would be nice.

One ancillary problem is that I don't seem to be able to set z=0 to the top of the block as normally is possible. I shift it up in Setup but it seems to revert.

I padded up instead of down when making the block but this should normally be correctable in setup.

[freman]

Just for the record, I changed the pad to negative 10mm , edited all the paths to cut 1mm engraving and looked at it in CAD sim. The brown blocks of stock are all still up at z=10mm while the tool correctly follows the new cut in z=0 . Gcode is good. Just the sim has not updated where stock is.

Opening up Setup and hitting reset does not correct it.
I had to delete the whole job to correct where stock is going.

[freman]

Edit: Updated attachment to include an extrusion which is used as the Stock for the Job

Thanks, just opened this, created a new job ( with my template ) added 3 strings in one path. Gcode and sim looks good.

[chrisb]

freman, would you mind changing the subject of the first post (i.e. th etitle of the topic) to something more descriptive? As time went by, we discovered that the culprit was not between your ears .

[freman]

done

[Syres]

PR Submitted (I've titled as temporary because I'm sure there can be a proper fix implemented in the future) https://github.com/FreeCAD/FreeCAD/pull/2725

[vocx]

I'll just add one more bit of info that may assist, the letters of the Shapestring had visible faces certainly up to and including build 0.19.18284 (approx 24/9/2019) which could be changed using the Shape Color field and those faces disappeared in build 0.19.18351 (approx 28/9/2019). Could that account for the 'Item Is Not a Shape' error?

Ignore my above post regarding the missing faces it's just that the default view is set to Wireframe instead of Flat Faces which happened around the same time as two commits were made to src\Mod\Path\PathScripts\PathEngraveBase.py around the end of September.
...

[ Bug ] Initial Display Mode for Draft wires is Wireframe

In Draft, we did notice that the default "DisplayMode" of Draft objects changed from "FlatLines" to "Wireframe".

Up to this point it didn't seem to cause a problem, so we didn't investigate further. It is just a bit annoying. In Draft, certainly "FlatLines" is preferred as default.

It seems that the internal C++ code sets up "Wireframe" by default because that is preferred for Sketches (both Sketches and Draft objects are based on Part_Part2DObject). Presumably in Draft some code set the DisplayMode to "FlatLines", but now it seems it inherits the original "Wireframe" mode, and we aren't sure why.