G-Code generation bug

[nealexey]

Hello everybody!

I'm completely beginner here.

First of all, I want to say a huge thank to the entire community, especially, of course, the developers for the program. I just found it for myself, but I already understand that it is great for my hobby tasks.

I looked for a similar error on the forum, but didn't really find anything, so I opened here a new topic.

I use the following configuration:
OS: Ubuntu Core 20 (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Unknown
Branch: releases/FreeCAD-0-19
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.5
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.5.0
Locale: English/United States (en_US)

After G-code generation in the G-code there are some wrong lines, correspond to the same places in the trajectory, but located in different layers strictly one above the other.

In my model the problematic places are located in the following area:

The problematic area is shown on model

Area_with_wrong_commands.png (114.58 KiB) Viewed 2367 times

And more detailed:

Error places

Zoomed.png (112.83 KiB) Viewed 2367 times

The error lines are exactly the same.
I attached the G-code file. The wrong lines are 929, 1125, 1214, 1413, 1609, 1694. All lines are identical.

Bug_lines_929_1125_1214_1413_1609_1694.txt

G-code

(49.2 KiB) Downloaded 38 times

As you can see above, the wrong commands are not visible on the render, but the path-simulator freezes when it gets to this point. The print-screen of froozen FreeCAD with path-simulator is shown here:

Stacked path-generator

Screenshot from 2021-06-30 22-34-33.png (37.31 KiB) Viewed 2367 times

FCStd-file is also attached here:

Bug_Part.FCStd

The modell

(368.76 KiB) Downloaded 33 times

I just deleted these wrong lines from G-code and my part was machined completely properly.

Thank you very much!

[chrisb]

Hi and welcome to the forum!

Can you reduce this to a single Path operation?

And by the way, why do you use 3D pocket instead of the normal pocket?

[GeneFC]

After G-code generation in the G-code there are some wrong lines, correspond to the same places in the trajectory, but located in different layers strictly one above the other.

Those lines are not errors. They are very short arcs with essentially infinite radius.Therefore they act as short straight lines.

The Pocket 3D operation is quite complex, and it tries to fit the shapes it finds using either arcs or straight lines. Tolerances allow either to be correct.

To a human it sometimes seems silly to have a short straight line in the middle of arcs or a short arc in the middle of straight lines, but they do not usually cause any noticable effects.

I had no problem simulating the complete shape, so I do not know what you saw that did not look right.

I did notice that the FCStd file is rather strange. There is a second body that contains some elements of a Job, but not a complete Job. Did you create something and then try to delete it or drag it in the tree?

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of FreeCAD: 64-bit
Version: 0.20.25157 (Git)
Build type: Release
Branch: Master
Hash: 257cdd8f423f1530b8df6f53e242de629fee4e85
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

Gene

[bmsaus4ax]

Hello everybody!

The error lines are exactly the same.
I attached the G-code file. The wrong lines are 929, 1125, 1214, 1413, 1609, 1694. All lines are identical.

As Gene has pointed out the short segment is an arc with a massive centre point relative X dimension.

I am using a relatively slow processor PC and I do get the freeze . Inspecting the system Resource Monitor for the processor I can see that the CPU is working on resolving the path, so a fast machine may not show the pause.

When run individually Pocket_3D003 is the only one that causes any problem because of this radius being present.

But there may still be something like a bug in the 3D Pocket Operation. If I toggle any of the 3D Pocket Ops "Toggle Active State of the Operation" from Inactive to Active this creates a fault per the trace back report

Code: Select all

Traceback (most recent call last):
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathUtils.py", line 60, in new_function
    res = function(*args, **kwargs)
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathOp.py", line 552, in execute
    result = self.opExecute(obj)  # pylint: disable=assignment-from-no-return
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathAreaOp.py", line 347, in opExecute
    for shape, isHole, sub in shapes:
<class 'ValueError'>: too many values to unpack (expected 3)
Traceback (most recent call last):
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathUtils.py", line 60, in new_function
    res = function(*args, **kwargs)
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathOp.py", line 552, in execute
    result = self.opExecute(obj)  # pylint: disable=assignment-from-no-return
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathAreaOp.py", line 347, in opExecute
    for shape, isHole, sub in shapes:
<class 'ValueError'>: too many values to unpack (expected 3)

If run first before making inactive the operations run ok. Toggling it renders it inoperable from then on.
.
OS: Ubuntu 20.04.2 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.25157 (Git) AppImage
Build type: Release
Branch: master
Hash: 257cdd8f423f1530b8df6f53e242de629fee4e85
Python version: 3.9.5
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: English/Australia (en_AU)

[Russ4262]

...
But there may still be something like a bug in the 3D Pocket Operation. If I toggle any of the 3D Pocket Ops "Toggle Active State of the Operation" from Inactive to Active this creates a fault per the trace back report

Code: Select all

...
  File "/tmp/.mount_FreeCAVviZjB/usr/Mod/Path/PathScripts/PathAreaOp.py", line 347, in opExecute
    for shape, isHole, sub in shapes:
<class 'ValueError'>: too many values to unpack (expected 3)

If run first before making inactive the operations run ok. Toggling it renders it inoperable from then on.
...

Thanks for the feedback. This error is due to return values that did not get adjusted with the recent rotational purge.
PR #4901 [Path] Fix 3D Pocket tuple lengths in return values is active with the fix.

Russell

[nealexey]

Hi and welcome to the forum!

Can you reduce this to a single Path operation?

And by the way, why do you use 3D pocket instead of the normal pocket?

Hello chrisb.

Thank you very much for the answer. I'm positively surprised, how many answers I have received!

I tried to make it with single operation, but it calculates than only to the depth with a nearest horizontal surface (locates at depth -2,2mm from stock top surface).

So it looks:

Screenshot from 2021-07-01 20-05-33.png (73.36 KiB) Viewed 2229 times

The model is attached:

only_one_3D-Pocket_operation.FCStd

(163.43 KiB) Downloaded 34 times

Tu cut further I make new operation with the start depth below -2,2 mm and with the chosen geometry below this depth only. So it calculates till next horizontal surfaces, and so on. Thus, in this model, I did 3 operations of 3D-Pocket.

With normal pocket I also tried, but received the following complexity:

Screenshot from 2021-07-01 20-30-13.png (29.31 KiB) Viewed 2229 times

and

Screenshot from 2021-07-01 20-28-15.png (123.81 KiB) Viewed 2229 times

As you see, there are not machined areas (are marked on the pictures above), and I have no idea how to proceed with normal pocket operation.

The model is also attached to the post:

Pocket_operation.FCStd

(184.91 KiB) Downloaded 41 times

With best regards,
Alexey

[nealexey]

After G-code generation in the G-code there are some wrong lines, correspond to the same places in the trajectory, but located in different layers strictly one above the other.

Those lines are not errors. They are very short arcs with essentially infinite radius.Therefore they act as short straight lines.

The Pocket 3D operation is quite complex, and it tries to fit the shapes it finds using either arcs or straight lines. Tolerances allow either to be correct.

To a human it sometimes seems silly to have a short straight line in the middle of arcs or a short arc in the middle of straight lines, but they do not usually cause any noticable effects.

I had no problem simulating the complete shape, so I do not know what you saw that did not look right.

I did notice that the FCStd file is rather strange. There is a second body that contains some elements of a Job, but not a complete Job. Did you create something and then try to delete it or drag it in the tree?

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of FreeCAD: 64-bit
Version: 0.20.25157 (Git)
Build type: Release
Branch: Master
Hash: 257cdd8f423f1530b8df6f53e242de629fee4e85
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

Gene

Hello Gene!

Thank you for your answer and comments.

Yes, I noticed, that in principle this arc is as a little straight line. In principle, deleting of these lines is giving exactly a straight line instead of arc.

May be it calculates on your computer correctly due to another system and configuration, but on my computer it stacks exactly on this moment. And as bmsaus4ax wrote, at his computer as well.

About the infinitely large radius, maybe, of course, I have an old post processor. I am using a quite old LinuxCNC with my CNC-mashine, but before that there were no problems with it. And here it shows a huge circle, i.e. he drows not an arc, but an almost full circle, with a very small gap. So it also draws an arc, but a larger segment of the circle, not a smaller one.

Thanks for the remark with duplicate operations. I don't know how they were added, I guess I accidentally did something wrong. I removed them, making the project tree neat. But this will not affect the creation of the trajectory.

[chrisb]

I understand why you used more than one operation. I wanted you to reduce it just for demonstrating the issue, but I think that Gene has already explained where it comes from.

[nealexey]

And I have two more questions. I don’t know whether to create a new topic for each question, or ask in an existing one, so I ask here first.

Question 1

I cannot figure out what I am doing wrong in this file.

For some reason the trajectory (and cut material, if exists) is displayed with a shift relative to the part. But when I select either the stock or an operation in the project tree, the display becomes correct:

Project tree components are inactive:

Screenshot from 2021-07-01 22-53-41.png (76.16 KiB) Viewed 2167 times

Either the stock or an operation is active in the project tree:

Screenshot from 2021-07-01 23-31-28.png (120.15 KiB) Viewed 2167 times

The model file is the following:

Plate.FCStd

(119.56 KiB) Downloaded 33 times

Question 2

In path simulation it shows bigger hole, as shall be. Seems, like it uses for cut material calculation not a cut edge diameter of a bit, but its shank diameter.

Screenshot from 2021-07-01 23-36-56.png (69.83 KiB) Viewed 2167 times

The same thing I have in both models, from this and previous posts.

There is also similar topic here: https://forum.freecadweb.org/viewtopic.php?f=15&t=59645
But in my case path self is correct, I already cut both parts, and they are absolutely OK, in my case it is only a visualization issue in path simulation.

[chrisb]

For some reason the trajectory (and cut material, if exists) is displayed with a shift relative to the part.

On Job creation a clone is created, in your case "Model-Body001". You have moved this clone, and path generation is taken out on the new position.

In path simulation it shows bigger hole, as shall be. Seems, like it uses for cut material calculation not a cut edge diameter of a bit, but its shank diameter.

This is probably a bug, probably in the simulator.