QCAD.org Forum

Hello all,
I create rather complex files where generating offset tool CAM paths (postprocessor GRBL offs mm) may take upwards of 35 minutes.
I'm running ubuntu 22.04, QCAD 3.30; my CPU is a 12th gen core i7 .

I checked on resource manager (htop) and the QCAD application seems only using 1 of the available 12 cores.
Any future intentions to multithread the tool path generation to speed up computation?

Thank you
newyd_cnc

Hi,

A good benchmark is to know how many text lines there are in the exported G-Code file.
Can you provide such a count?

I have a CAM that supports pocketing and that may easily export 100k G-moves for a single contour.
In under a minutes or so per contour.
With pocketing every next path is basically an offset to the former.

Multi-threading is not always a solution.
For one, it is impossible to predict where a next segment must start unless you know where the former ended.
And then G-Code relies on the last reached position.
I can envision a toolpath per thread and then a TSP (Traveling Salesman Problem) routine to connect the starts and ends.

QCAD uses Multi-threading to render data on screen.
At that instance that is static data, nothing really depends on the outcome from another core.
Still, there are cases that forcing 1 core is better (see forum).


One source of a vast amount of arc segments are splines.
Splines are approximated by a polyline with tangentially connected bulging segments what is then exploded to individual arcs (and lines).
Arcs (lines) can be exported as G2/3 (G1).

As stated several times before, this conversion is not per definition a mathematical closed format.
Bulging segments have 2 endpoints, the 2 associated polyline vertices, arcs have no endpoints, they have end-angles.
It may that two consecutive bulging segments don't have an endpoint in common as arcs.
Especially with tangentially connected that may be a problem, some arcs will never touch or cross.
It tend to get worse for the offsets of these.
This is usually solved allowing for a connect tolerance with a really small but fixed value.
Not that you can mold an arc so that it fits ... Like relocating and endpoint of a line segment.
But All is OK until your arcs lengths and/or radii come close to this minute value.


Have a look at your CAM Configuration dialog.
A typical spline interpolation tolerance is 0.01 and that is in units.
Most configurable tolerances in QCAD are NOT drawing unit related.
0.01 would be fine using inches when the design is tens to hundreds of inches.

You have to ask yourself the question "How correct must a spline approximation be?"
Do you really need a path accuracy of 0,01mm for a design in decimeters to meters?
Is the repeatability of your setup that precise?

A less strict approximation tolerance generates fewer and larger, longer arc segments.

My personal answers on both counts are YES, rather 0,001mm, but then my designs are mostly not larger than coin-size.
To avoid other floating point number issues I stepped down in drawing units to microns.
The values are simply 1000 times larger, but the build in tolerances remain the same.

Regards,
CVH

Dear CVH,

my gode file has 106k lines.

Now please note that the profiles as drawn in the dxf files do not include splines to be converted at gcode processing stage. All the profiles are already converted into polylines and I do apply a reasonable resolution scale-down via the "OS" command in order to limit the number of vertices in the polyline profile.

Converting the dxf file to gcode machine program takes about 45 minutes. I noticed however that if I create an individual toolpath per each profile instead of selecting all the profiles and creating a profile toolpath for everything selected, the gcode processing time is considerably shorter. I don't quite see the reason why

kind regards

newyd_cnc wrote: ↑

Tue Oct 08, 2024 11:05 am

I noticed however that if I create an individual toolpath per each profile instead of selecting all the profiles and creating a profile toolpath for everything selected, the gcode processing time is considerably shorter. I don't quite see the reason why

The only thing I can think of is piece in piece detection and TSP.
When you create 'one' toolpath of several contours then QCAD connect the end and start using a TSP algorithm.
It will also cut the inner most contours before others.
Piece in piece detection evaluates every segment in regards with every other contour.
106k G-Code lines can mean something of 100k segments, fill in the number of contours yourself.

Creating a toolpath for each contour is typically in the order of creation but that can be rearranged.
Connecting the previous end with the next start is then nothing else than retract and an already well defined G0 motion.

There are probably other tasks that suffer from a high segment count.
And then I hope that the export includes G2/3 moves, interpolating arcs with line segments is only required by ancient CNC-drivers.
Using G2/3 moves for Splines results in a continuous motion because there are no hard corners where the FEED requires adaptation.


With an example file we would be able to reproduce at least something.
See above rules ... Just trying to help you more efficiently.


What I don't understand of your reply is:

newyd_cnc wrote: ↑

Tue Oct 08, 2024 11:05 am

All the profiles are already converted into polylines and I do apply a reasonable resolution scale-down via the "OS" command

Or you use the QCAD GUI and explode Splines into Polylines with tangentially connected Arc shaped segments with XP...
... With the related settings configured in the Application Preferences.
Or you let QCAD/CAM convert them using the preferences in the CAM Configuration Dialog.
I am not aware of OS Command Line Tools for initiating QCAD/CAM related tasks.

Regards,
CVH

Dear CVH

thank you for your helpful clarification.
I cannot unfortunately publicly share the document as it prtoected by company copyright.

Concerning your question:
"
Or you use the QCAD GUI and explode Splines into Polylines with tangentially connected Arc shaped segments with XP...
... With the related settings configured in the Application Preferences."
yes that's what I do ... *followed by the OS command* to reduce the number of vertices (i.e. lower the resulting resolution of the previous spline -> polyline conversion) to something that is eyeballed as correct. OS being polyline simplify command

Any insight is always welcome

Kind regards

newyd_cnc wrote: ↑

Wed Oct 09, 2024 8:33 am

OS being polyline simplify command

This is a GUI tool or command.
OS commands are those you can execute from the OS Command Line ... QCAD Command Line Tools

It is not addressed in the reference: Draw > Polyline > Simplify (OS)
But Simplify (OS) is intended for polygons and doesn't simplify polylines with bulging segments (aka 'Arc'-segments)
Meaning that it doesn't merges bulging segments to one bulging segment.
It may however convert tiny 'Arc'-segments into straight segments.

Bad practice.
You get hard corners at the nodes where the CNC controller has to decelerate and accelerate afterwards to reach FEED again.
Look at it as a car that must round a corner. It is best that you decelerate the mass in motion to do that.
Cutting speed is less steady this way and that has an influence on surface finish, tool wear and other related.
With Laser/Plasma you get excessive burning by the reduced traveling speed with the same power.


A Spline and an Ellipse shape are by standard seldom supported by a CNC-driver.
They can be approximated by connected Arc shapes within some tolerance.
Polylines support straight and bulging segments, a bulging segment is sometimes called an Arc but that is basically wrong.
Bulging segments can be converted to Arcs but the relationship is not really 1:1.
Most CNC-drivers support G1 or straight motion and G2/3 or circular motion ... CW or CCW.


Your goal is thus to approximate a Spline by nicely tangentially connected Arc shapes.
Tangentially connected also means that the FEED doesn't have to change. (Unless your acceleration parameters are that strict)
Or use the QCAD XP tool or let QCAD/CAM do that for you.
XP its parameters are found in the Application Preferences.
How QCAD/CAM virtually explodes your splines is directly configurable on the CAM Configuration Dialog.

Do not Interpolate Arc shapes with yet more tiny straight line segments when that is not absolutely required. (QCAD/CAM dialog)
Or, do not explode Splines to polylines with line segments. (QCAD XP preference)

I assure you that it can't get any better than tangentially connected Arc shapes.
Although the algorithm could benefit from optimized Bi-Arcs.

On the approximation tolerance you must be very reasonable.
Let's agree that 1 unit per 100 is already tight.
For a shape that is 1000 units across, a tolerance of 0.01 can be considered as overkill (=10ppm).

For what it is worth.
I keep the original Spline on a dedicated layer, the way back after XP is almost impossible in a later session.
I then preform XP on a duplicate (DP), when both are visible in a different color the approximation is quite clear.
Start with a less strict tolerance, the tighter, the more 'Arc'-segments are required.

newyd_cnc wrote: ↑

Wed Oct 09, 2024 8:33 am

I cannot unfortunately publicly share the document as it prtoected by company copyright.

You can always attach your file (or a snippet) to a Private Message (PM).
I assure you that the content is handled with the utmost confidentiality, any copy is deleted afterwards.
It is not the content or what it represents that interest me.
In this case I need the Spline(s).
To send a PM, the easiest way is to click on the user name and take it from there.

Regards,
CVH