QCAD Bugtracker

Hi,

First:
Several controllers that I know of don't accept a G41/42 compensation move given a circular entry motion. For example a circular Lead-In. A gradual offset to circular would be some odd spiral motion and most controllers can not cope with that.

The first motion must always be a linear move.
Such can easily be compensated to end in an offset position.
Said to be fixed somehow.

You did fall back on interpolating arcs as (very) short line segments.
A better solution would be to not use G40/41/42 compensation.
And to let QCAD/CAM generate the offset path itself, instead of relying on the controller.

Typically a post-processor with 'offset' in the display name.
Or the specific script includes:

this.outputOffsetPath = true;

Perhaps you can attempt that first.

For the rest it is unclear what went wrong.
With a CAM drawing example Andrew could try to replicate the issue under Qt6.

I think that the large memory usage has more to do with the vast amount of interpolated segments. The garbage collector only acts on intermediate values and/or objects that are no longer in use.

Regards,
CVH

Thank you very much for your comment, CVH.

Besides being quite old, in a sense I’m a newbie, and your explanation is like a foreign language I can’t cope! I didn’t choose the compensation, CAM did, I think… PlanetCNC did not complain about the previous G41, only about G40. Of course, a huge number of segments are being generated since I choose short ones to get more precision, so a corresponding amount of memory should be needed… or does it not? I don’t know how and why the data is being used this way, (holy ignorance! ), but is it needed to keep all the data in memory, all the time and till the end of the program? The g-code generated is only 348KB, the program for this project 340MB, but during the export rises to more than 6GB!Why the green cursor starts and ends with 50% instead of showing the progress of the process? Why the Abort button closes the little window but do not stop the process? When the “slowing” start, it is possible to close the program window, but after some time, I have to kill the program to close it.This is to be used in a little CNC that I built, with only a 500W Spindle, so I’m using 12 passes for the project. Is it needed to keep all the data, all the time and even after the generation of the g-code, to the end of the program? Seems peculiar… As you well wrote,” The garbage collector only acts on intermediate values and/or objects that are no longer in use”.

Please don’t get me wrong, this is one of the most spectacular pieces of software I found, and I dig a lot, there’s more, a license that allow me to run the program in all the Oss and computers I want, it’s unique! This is not only Technique, this is Art!

Best Regards,
Mgoodboy

Hi,
You didn't specified the used post-processor.
I am about sure there exist a calculated 'Offset' variant.
This is selected by the user at the far left in the QCAD/CAM toolbar, typically just above the drawing panel.
Before anything else if you have only one type of machine at your disposal.
QCAD/CAM allows you to generate profiles for different machines in the same file.

At best you attach a minimal CAM drawing file to replicate the issue under Qt6.

What counts for the entry compensation move (G41/42) is also true for the exit compensation move (G40). Both are typically limited to linear.

QCAD/CAM works in several steps:
- On adding a profile it first generates CAM-entities for the given source entities and stores these in the project drawing file. An Arc entity in the source can thus be stored as thousands of short straight CAM-entities or lines in 3D.
In memory and later in the drawing file.
12 passes are 12 times the same CAM-entities at a different Z levels.
- On export it converts these CAM-entities to your textual G-code dialect.
A CAM-Line from A to B is then translated to a G1 to position Bx-By in your case …
… When the last know position was indeed Ax-Ay-Az.
There are many G-code dialects and QCAD/CAM has also post-processors for other export formats.

If you choose to re-generate the CAM-entities on export, the first step is repeated for all existent and already created profiles.

12 passes has probably to do with the limited power, the material, the cutter size.
Even then.
It is common for a cutter to process 10-200% of its diameter in depth in a single pass.
12 passes is rare and probably only used for very deep grooving.
In addition to a CAM program, an operator must also rely on a good tool that calculates things such as optimal feed/speed, chip rate, and required power.
There are indeed a few rough rules of thumb and experience with your own machine is especially important.

The 50% progress is probably some default and can be based on an educated guess.
For example: In a certain custom tool I specified that at some early point in the process I set the Progress Bar at 10% without really knowing if the following steps will take abut 9 times as long.
Even then, when I update the Progress Bar frequently it may still trail or not show any further progress at all until finished.
Then I also discovered that it must be at least 5% more than the last value to actually update the bar.
And finally I found out that overdoing slows everything a lot more than you might expect from a simple bar widget.

Bottom line:
The Progress Bar is not a factual thing.
It is partially based on what is not yet done without really knowing.
Stalling may indicate various things. It can be an endless loop, a program stall, an unexpected vast amount of work in a next step, … Or simply not updated.

Regards,
CVH