Holding tags on circular path does not work

[reox]

I have a similar problem to https://forum.freecadweb.org/viewtopic. ... 9&p=169227 but I can generate the holding tags without any problem - they just don't work.

To test it, I created a cylinder and added a contour path with default settings and holding tags with default setting. The resulting gcode can not be executed:

2017-08-23-114445_306x104_scrot.png (8.73 KiB) Viewed 2100 times

You can also see in the preview inside FreeCad that something is messed up:

path2.jpeg (84.07 KiB) Viewed 2100 times

path.jpeg (44.67 KiB) Viewed 2100 times

Attached are also the generated G-Code with the linuxcnc postprocessor and the test file.

I also tested it on a rectangular workpiece, which worked fine.

Code: Select all

OS: Debian GNU/Linux testing (buster)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11904 (Git)
Build type: None
Branch: master
Hash: 88e2b6de9a256896de2069fe1b55c66296b75ee1
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: German/Austria (de_AT)

[mlampert]

confirmed, I'll have a look tonight.

[mlampert]

This is a very interesting case, it seems when a step down path just brazes a cone shaped tag - things go horribly wrong. The simplest reproduction is the same shape and a step down of 5:

tag-broken.png (54.56 KiB) Viewed 2061 times

changing the step down to a value that does not end up with a path along the top face of the tag has no issues:

tag-fine.png (65.83 KiB) Viewed 2061 times

I don't have a root cause yet but I suspect it's another one of those rounding/float precision issues. I should have a fix for this soon - in the meantime, please change your tag height or step down so they don't align.

[reox]

Thanks for looking into it and for finding a workaround I can confirm the workaround works for me!

[reox]

I just found some other problematic inputs: If you define a radius which is exactly half the width and the angle is set to 45 degrees, you will get the same issue. If you then define the width as +0.01mm everything is fine again.
Also if an angle is in such a way, that the ends would intersect (like define width=8, height=4.8, angle=30 degrees, radius=0) you get interessting effects.
One tag got disabled but the remaining three stay but have the same issue again.

There might be more

[mlampert]

There might be more

This is great - please keep them coming - holding tags is fragile and the more edge cases we have to harden it the better!

[nahshon]

This is great - please keep them coming - holding tags is fragile and the more edge cases we have to harden it the better!

There is redundancy in these files. Which ones are relevant?

Code: Select all

-rw-rw-r--. 1 itai itai 41696 Aug  5 19:49 PathDressupHoldingTags.py
-rw-rw-r--. 1 itai itai 25947 Aug  5 19:49 PathDressupTagGui.py
-rw-rw-r--. 1 itai itai  4759 Aug  5 19:49 PathDressupTagPreferences.py
-rw-rw-r--. 1 itai itai 10421 Aug 22 21:06 PathDressupTag.py

Some problems:
When I add tags to a path, the path appears twice in the tree view (under the job and under "TagDressup"). The unmodified original path is still active and visible.
When I delete the TagDressup the orig path is still there but it is not in the tree view.

Deleting a job moves its children to the parent document. I do not expect to see tool controllers and paths directly under the document (even when a gcode file is opened/imported, create a job for it!).

[mlampert]

There is redundancy in these files. Which ones are relevant?

Code: Select all

-rw-rw-r--. 1 itai itai 41696 Aug  5 19:49 PathDressupHoldingTags.py
-rw-rw-r--. 1 itai itai 25947 Aug  5 19:49 PathDressupTagGui.py
-rw-rw-r--. 1 itai itai  4759 Aug  5 19:49 PathDressupTagPreferences.py
-rw-rw-r--. 1 itai itai 10421 Aug 22 21:06 PathDressupTag.py

PathDressupTag.py was an start to rewrite holding tags - I probably should have removed it, it's not active right now. I factored the tag preferences into PathDressupTagPreferences.py and the Gui (for both implementations) is in PathDressupTagGui.py. The actual implementation is still the original - quite fragile - in PathDressupHoldingTags.py.

In case you want to experiment that is the currently active code. If you would like to take over the re-implementation I would recommend looking at PathDressupTag.py.

Some problems:
When I add tags to a path, the path appears twice in the tree view (under the job and under "TagDressup"). The unmodified original path is still active and visible.

This should not happen. Is there a chance you get an error? Could you share a file where this happens?

When I delete the TagDressup the orig path is still there but it is not in the tree view.

Again, this shouldn't happen. When you delete a dressup the base path should be moved back into the Job. A test file where this happens would be great.

Deleting a job moves its children to the parent document. I do not expect to see tool controllers and paths directly under the document (even when a gcode file is opened/imported, create a job for it!).

Agreed, this has been annoying me as well. I started implementing this in a branch I currently work on, when a job is deleted it will also delete all its dependent children. There is no point in keeping any of them around, the only thing one can do with them is delete them anyway.

[nahshon]

I found my problem. I did not have swig installed. After installing swig and recompiling things work much better.

[mlampert]

I found my problem. I did not have swig installed. After installing swig and recompiling things work much better.

phew - glad you found the glitch and it works for you now!