Problems with Tag Dressup

[herbk]

Hi,
Today i run in a problem at using the TagDressup at a complex Contour Path.

Aggain i have to cut out some profiles. To get a path for 14 elemets with one click i combine this elements, use Contour Path for the initial path, and add a Dogbone and a Holding Tag Dressup.
At FC everything works and i can export a Gcode file. If i load the file in LinuxCNC i get a error message:

emc_error.jpg (311.41 KiB) Viewed 1758 times

If i delete the Tag Dressup, the path works.

I don't get this error if i create the milling path from surfaces or a edges and add the dressups. Also not if i create a Path Array and add the dressups.

I attached the file wich produces the error at LinucCNC, it's made with:

OS: openSUSE Leap 15.1 (KDE//usr/share/xsessions/plasma5)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19285 (Git) AppImage
Build type: Release
Branch: master
Hash: 8b2e318f15ee6304e8d89f48b2ac45af3bf61aed
Python version: 3.8.1
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.4.0
Locale: German/Germany (de_DE)

[mlampert]

I can confirm this. I do get different errors though indicating that rounding/precision errors do play a role here. That doesn't seem to explain everything that is going on though. Looking at the g-code this is the section in question on the second level around (note that the first level has identical parameters except for Z=25):

Code: Select all

G2 X472.516 Y343.932 Z9.000 I226.063 J-8.328 F800.000
G2 X476.667 Y361.398 Z9.000 I119.013 J-19.055 F800.000
G2 X481.823 Y373.334 Z9.000 I60.525 J-19.064 F800.000

and this is the same piece on the third level with the holding tag:

Code: Select all

G2 X472.516 Y343.932 Z0.000 I226.063 J-8.328 F800.000
G2 X473.913 Y351.215 Z0.000 I119.013 J-19.055 F800.000
G1 X474.852 Y355.104 Z4.000
G2 X476.477 Y360.796 Z4.000 I116.677 J-30.226 F800.000
G1 X476.667 Y361.398 Z3.369
G1 X477.764 Y364.585 Z0.000
G2 X481.823 Y373.334 Z0.000 I59.427 J-22.251 F800.000

The offending code is the G2 command immediately following the completion of the holding tag. The starting position does not line up with your screenshot which is probably the result of LCNC's path smoothing. It only exasperates the issue though. Even if LCNC would follow the path to the dot there is still an error in the center offset.

Code: Select all

OS: Debian GNU/Linux bullseye/sid (LXQt//usr/share/xsessions/lxqt)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19325 (Git)
Build type: Unknown
Branch: feature/v-carve
Hash: 6364d4f2611dde4ba7e10cb6df907641e5979ab1
Python version: 3.7.6
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: C/Default (C)

[mlampert]

Actually, I take that back, the problem is here:

Code: Select all

G2 X506.138 Y376.030 Z9.000 I-15.152 J-23.462 F800.000
G2 X511.718 Y366.864 Z9.000 I-40.053 J-30.667 F800.000
G2 X516.792 Y352.144 Z9.000 I-75.755 J-34.345 F800.000
G2 X519.955 Y333.598 Z9.000 I-145.671 J-34.387 F800.000

vs.

Code: Select all

G2 X506.138 Y376.030 Z0.000 I-15.152 J-23.462 F800.000
G2 X509.947 Y370.279 Z0.000 I-40.053 J-30.667 F800.000
G2 X516.792 Y352.144 Z0.000 I-79.351 J-24.934 F800.000
G2 X519.955 Y333.598 Z0.000 I-145.671 J-34.387 F800.000

The latter is wrong, there should be an entire tag in there. What is there is (by FC) rendered as:

Capture.PNG (1.78 KiB) Viewed 1650 times

Capture1.PNG (1.06 KiB) Viewed 1650 times

The top view (bottom picture) clearly shows the misalignment.

[herbk]

Hi Markus,
did you anything find out about this problem?
Today i have had had it at a simple circel, so it seams not to be related only with B-Splines. And i have it only if i have several parts to mill out at once. - And, to make it more mysterious, a few hour's later i can add the tags and get a valid path...

One other prob have had today to: Two times FC AppImage crashes as i tryd to move one of the holding tags. Not at each, only some tags of one of the parts are not to move.


OS: openSUSE Leap 15.1 (KDE//usr/share/xsessions/plasma5)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19405 (Git) AppImage
Build type: Release
Branch: master
Hash: d2b943e8b7d8fe2673a4e20671b6cb0f8180fdbd
Python version: 3.8.1
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: German/Germany (de_DE)

[mlampert]

... - And, to make it more mysterious, a few hour's later i can add the tags and get a valid path...

PR-2997 (I wonder what PR-3000 will be about )

I think I found it. I eventually were able to reproduce the issue by moving one tag around - and then there was a position where it fails. The issue was indeed precision. Splitting an arc into two pieces could end up moving the center of the arc - and if you do that two times in a row (splitting the already split arc again) the resulting arc could be so off that the algorithm fails and just inserts the mangled remaining arc. I changed the arc splitting algorithm to always use the original circle making precision and reproducability much better. Please let me know if it still causes problems.

[jcf]

I had the same problem now with a very simple thing: just a cylinder with tags as a test object.
LinuxCNC complained for the radius error, while bCNC accepted the G code, and I tried also an online simulator that did not complain.
So I had the idea that the problem was in the LinuxCNC part. But after reading the above posts this seems not to be true?

[chrisb]

It may be helpful if you add your FreeCAD infos and the file.

[herbk]

Hi Marcus,

Please let me know if it still causes problems.

Thank you!
I'l let you know if the prob again appers, i have to cut out a few hundreds of this profiles with different sizes at the next weeks...
I found a few more Path related bugs with this work, but need a bit more time to create exaple files which i can upload here.

BTW: is there some way to look "is a PR merged to the AppImage or is it not" ?

[chrisb]

is there some way to look "is a PR merged to the AppImage or is it not" ?

"some way" yes, but not easy, I'm afraid. See https://www.freecadweb.org/wiki/Source_ ... mit_number.

[jcf]

The FreeCAD file of my test cylinder is too big to post, it can be found here:
http://staff.ltam.lu/feljc/software/cnc ... r_01.FCStd
It is only a cylinder with tags. The cylinder works fine, but the tags do the misery.

Here is a screenshot:


Indeed this does not look to me like a cylindrical path, so LinuxCNC is right to complain!

The error seems to lie in the path generation of the tags in FreeCAD.

My FreeCAD version is:
OS: Linux Mint 19
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.4.
Build type: Release
Python version: 3.6.8
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)