QCAD.org Forum

Hello QCAD/CAM team, I'm new at this forum.

I created DXF files with only lines to cut, then I export file using LinuxCNC postprocesor.
I would like to reduce cut time, I mean reduce rapid movement lenth between points.


Question 1
I use LinuxCNC Postprocesor to create path. It works fine.
I see that QCAD use always start point of the line as first point to cut.
Is possible to change that default settings to use end point of the line
as first point to cut?
Or use nearest line point (start or end) to set as start cut point?
I ask because this idea can make shorter total cutting time.

Diagonal is longer than straight line
See my screenshots. In green new view



Thank you!

Welcome to the QCAD forum.

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

I would like to reduce cut time, I mean reduce rapid movement lenth between points.

I think this is not automated.
It may be that QCAD/CAM optimizes rapid moves to the nearest cutting start position, but I am not sure about that.
QCAD/CAM will reverse entities that are part of a closed path if those have the opposite direction.
It is then possible that it doesn't reverse entities to optimize rapid moves when they are not part of closed path.

Have you tried reversing the orientation of every second next entity?

Regards,
CVH

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

I see that QCAD use always start point of the line as first point to cut.

Correct and that is what you can use for a better path strategy.

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

Is possible to change that default settings to use end point of the line
as first point to cut?

No but you can reverse the orientation (start becomes end and end becomes start) of the line with Menu / Modify / Reverse (RV).

Your example modified to an alternating direction of those lines looks like this (red = start, blue = end point)


A path can then be created with a more optimized outcome ...


BTW: I also reduced the Overcut in the tool definition. I don't know what works best for you ...

CVH wrote: ↑

Wed May 31, 2023 4:44 pm

Welcome to the QCAD forum.

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

I would like to reduce cut time, I mean reduce rapid movement lenth between points.

I think this is not automated.
It may be that QCAD/CAM optimizes rapid moves to the nearest cutting start position, but I am not sure about that.
QCAD/CAM will reverse entities that are part of a closed path if those have the opposite direction.
It is then possible that it doesn't reverse entities to optimize rapid moves when they are not part of closed path.

Have you tried reversing the orientation of every second next entity?

Regards,
CVH

Hi CVH,

Thank you for warm welcome & Thank you for fast reply.

In my example I have 193 lines to cut. This lenth I can't reduce. My idea was to reduce only rapid movement distance between each cutted line.
Diagonal line for movement is longer than straight line.
Sure QCAD optimize rapid moves to the nearest start position but I think it can be more time efficent when script can start with nearest (end or start for next line)

I try to reverse but I need to do it manually & I think best is when is made by equation inside CAM script.
Me as a human can make mistake (reverse not proprer) but mathematic can calculate faster (find nearest point to cut)

Parallel I check at other software how change total lenth of path. I made a two exports, both automatic.
Difference is my opinion BIG
I add also Gcodes

0.7 meter less 10% less

My problem is that this software can't export to LinuX CNC, which I need. I got only Gcode.

So maybe is possible to use QCAD and load gcode and convert to Linux CNC format?

BTW is possible to get from QCAD total lenth of path?
Total lenth of path = cutting lines + rapid movement.

Regards Wojciech

Hi Husky,

Thanks for your reply.

Husky wrote: ↑

Wed May 31, 2023 10:47 pm

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

I see that QCAD use always start point of the line as first point to cut.

Correct and that is what you can use for a better path strategy.

I understand this strategy., thank you

ha4n wrote: ↑

Wed May 31, 2023 2:24 pm

Is possible to change that default settings to use end point of the line
as first point to cut?

No but you can reverse the orientation (start becomes end and end becomes start) of the line with Menu / Modify / Reverse (RV).

Your example modified to an alternating direction of those lines looks like this (red = start, blue = end point)

This is ok, but this is only my adjustment with no mathematic proof that this help to make rapid movement shorter.


Husky-2023.05.31-01.png


A path can then be created with a more optimized outcome ...

That is fine, thank you for info. My optimalization focus is only shorter time of rapid movement



QCADCAM reduce cut time.gif

BTW: I also reduced the Overcut in the tool definition. I don't know what works best for you ...

My optimalization focus is only shorter time of rapid movement

Can you explain more how you do it?
You use "0"in yellow parameters?

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

Sure QCAD optimize rapid moves to the nearest start position but I think it can be more time efficent when script can start with nearest (end or start for next line)

For some reason QCAD doesn't reverse entities to see if there is a shorter route.
This may even be intended behavior.

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

My problem is that this software can't export to LinuX CNC, which I need. I got only Gcode.

To my knowledge there are LinuX CNC postprocessors.
And yes they export G-Code.
You need to feed this G-Code into LinuX CNC what is a CNC controller that executes G-code.

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

BTW is possible to get from QCAD total lenth of path?

Not sure, I know of a long way.

Regards,
CVH

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

Parallel I check at other software how change total lenth of path. I made a two exports, both automatic.
Difference is my opinion BIG
I add also Gcodes

0.7 meter less 10% less

My problem is that this software can't export to LinuX CNC, which I need. I got only Gcode.

I compared my manually in QCADCAM optimized path to your cnc files. QCADCAM path is 4319 mm what would be ~2 m or 38.44% less then your ~7016 mm path. Sounds already better to me then the 10% (actually 8.9%) optimization ...

However - it is only comparable if all parameter are absolute identical in all scenarios!

BTW: The cut lengths is ~1086 mm - simple math to calculate the actual rapid lengths.

Husky wrote: ↑

Fri Jun 02, 2023 9:37 am

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

Parallel I check at other software how change total lenth of path. I made a two exports, both automatic.
Difference is my opinion BIG
I add also Gcodes

0.7 meter less 10% less

My problem is that this software can't export to LinuX CNC, which I need. I got only Gcode.

I compared my manually in QCADCAM optimized path to your cnc files. QCADCAM path is 4319 mm what would be ~2 m or 38.44% less then your ~7016 mm path. Sounds already better to me then the 10% (actually 8.9%) optimization ...

However - it is only comparable if all parameter are absolute identical in all scenarios!

BTW: The cut lengths is ~1086 mm - simple math to calculate the actual rapid lengths.

Hi Husky,
Thank you for reply

The cut lengths is ~1086 mm, fine I can do it with my calculator but how you calculate total patch 4319 mm?
You use command :IS:?

ha4n wrote: ↑

Fri Jun 02, 2023 3:55 pm

The cut lengths is ~1086 mm, fine I can do it with my calculator but how you calculate total patch 4319 mm?
You use command :IS:?

Cut lengths in QCAD? Select the entities and read the total lengths in the Property Editor.

Total path / rapid path? In QCAD currently difficult to do! I used like you a third party program to get the number of 4319 mm. I consider my approach of an optimal path has still room for improvements!


Plain rapid move? Would be total path (4319 mm) minus cutting paths (1086 mm) = 3233 mm rapid (x,y,z) - no rocked science ....

Command IS? Don't know what that is ...

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

Me as a human can make mistake (reverse not proprer) but mathematic can calculate faster (find nearest point to cut)

That isn't that simple! I agree to disagree! How will mathematic decide that the nearest point is the correct / logical and common sense strategy? I can imaging a lot of scenarios where your approach would destroy the workpiece what means even mathematics can make mistakes ...
Well, it is actually NOT a mistake but it still goes south and the workpiece ends up in a garbage can ...

Husky wrote: ↑

Fri Jun 02, 2023 8:13 pm

Total path / rapid path? In QCAD currently difficult to do!

Aren't rapid paths not simply on a dedicated layer after a toolpath is created ... ?
They are in 3D but that is summed just the same.

CVH wrote: ↑

Thu Jun 01, 2023 8:52 pm

Not sure, I know of a long way.

If the G-Code is basic enough to import: menu CAM .. G-Code import...
Cutting and traversing are on separate layers.

Rounded to two digits.
wycinanie frezem 44.cnc: traversing in 193 moves with a total length of 1446.38mm.
planowanie 44.cnc: traversing in 193 moves with a total length of 817.33mm.
Both cut 193 paths with a total length of 1086.58mm at FEED 60.

Traversing paths are reduced to 56.51% for the second file.
Remember that traversing is done in G0 mode or with the highest X/Y FEED available.
Diagonal this even exceed these FEEDs because for example Fmax1000 in X and in Y is about F1414 along the trajectory.

This doesn't account for plunge down and retract.
For this we need to investigate the G-Code:
It retracts 193 times in G0 mode from Z-1.6 to Z10 or 193*11.6mm = 2238.80mm.
And it plunges 193 times in two steps, first to Z0.08 in G0 and then further down to Z-1.6 in G1 F600, again 2238.80mm.

If allowable the most gain in travel that can be made is in plunging down and retracting.
If the cutter doesn't collide with anything at lets say Z3.0 the vertical movements can be reduced to 1775.60mm instead of 4477.60mm.
The gain is here much more pronounced then with optimizing Start/End.


I think that most machinist and businesses are interested in the estimated cutting time and not in the traveled distance.
This is even harder to estimate because we need to account for acceleration and deceleration time.


@ ha4n: May I remark that the plunging FEED is 10 times the actual cutting FEED.
In the end this will kill your cutter as it is slamming in full cut on your workpiece at 600mm/min.
Usually it is reversed: cutting FEED 600, plunging gently at FEED 60.
This kind of aggressive entry strategy may be required for surface hardened materials ... For the first handful of microns.

Regards,
CVH

Husky wrote: ↑

Fri Jun 02, 2023 8:13 pm

Command IS? Don't know what that is ...

menu Info .. Total Length of Selection (IS).
Similar as Property Editor .. Total Length if and only if the selected entities are of the same type.

Regards,
CVH

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

My problem is that this software can't export to LinuX CNC, which I need. I got only Gcode.

wycinanie frezem 44.cnc
planowanie 44.cnc

Can you explain M2048 P0, M2048 P519 ... M2048 P711 in these files?

Regards,
CVH

CVH wrote: ↑

Sat Jun 03, 2023 4:42 am

Husky wrote: ↑

Fri Jun 02, 2023 8:13 pm

Command IS? Don't know what that is ...

menu Info .. Total Length of Selection (IS).
Similar as Property Editor .. Total Length if and only if the selected entities are of the same type.

Thanks - almost forgot about that one. Haven't used it since ages ...

CVH wrote: ↑

Sat Jun 03, 2023 4:01 am

I think that most machinist and businesses are interested in the estimated cutting time and not in the traveled distance.
This is even harder to estimate because we need to account for acceleration and deceleration time.

In perspective, with infinite accelerations (... what is not of this world )

Cutting: 1086.58mm at FEED 60 >>> 18min 6.58sec
Traversing: 1446.38mm at FEED 1414 >>> Less then 1.5min (Assuming all at 45° with Fmax1000 in X & Y)
Traversing: 817.33mm at Fmax1000 >> Less then 1min (Assuming Fmax1000 in X or in Y)

Retracting to Z10: 2238.80mm assuming Fmax1000 >>> About 2.2min
Retracting to Z3: 887.80mm assuming Fmax1000 >>> Less then 1min
Plunging: Somewhat slower depending the pierce FEED for the last 2.4mm.

It takes more time to optimize G0 motions or write about it compared to the gain in fabrication time.
Still, optimizing is good practice when you need hundreds or more pieces.
Remark that I used moderate traversing FEEDs, my CNC engraver works fine with Fmax5000 reaching top FEEDs up to F7000.

Regards,
CVH

Hi Husky,
thank you for your reply

Husky wrote: ↑

Fri Jun 02, 2023 8:13 pm

ha4n wrote: ↑

Fri Jun 02, 2023 3:55 pm

The cut lengths is ~1086 mm, fine I can do it with my calculator but how you calculate total patch 4319 mm?
You use command :IS:?

Cut lengths in QCAD? Select the entities and read the total lengths in the Property Editor.

Thank you for info


Husky-2023.06.02-01.png

Total path / rapid path? In QCAD currently difficult to do! I used like you a third party program to get the number of 4319 mm. I consider my approach of an optimal path has still room for improvements!


Husky-2023.06.01-02.png


Plain rapid move? Would be total path (4319 mm) minus cutting paths (1086 mm) = 3233 mm rapid (x,y,z) - no rocked science ....

Command IS? Don't know what that is ...

ha4n wrote: ↑

Thu Jun 01, 2023 8:26 pm

Me as a human can make mistake (reverse not proprer) but mathematic can calculate faster (find nearest point to cut)

That isn't that simple! I agree to disagree! How will mathematic decide that the nearest point is the correct / logical and common sense strategy? I can imaging a lot of scenarios where your approach would destroy the workpiece what means even mathematics can make mistakes ...
Well, it is actually NOT a mistake but it still goes south and the workpiece ends up in a garbage can ...

Hi Husky, Maybe I not explained well. In my project I'm focused to get the shortest total patch because my router will engrave multiple times the same path (only lines). My goal is to reduce rapid movement beacuse cuting path is constant. In this case we see that QCAD automated generated total path for project is/ can be 2 x times longer than updated with "reverse" change. This update "reverse" path I need do it manually with my experience. I try few times to "reverse" lines but not always help it to get shorter rapid movement way. And in this point I think that mathematic can do it better than me. Sometimes next line end is closer than next line start. This equation can be done faster by math (algorythm) then by me trying to find it few times

I also understand that main 'time consumig" is cutting path, that is true, but why not reduce rapid movement?

Anyway many thanks for help and I will back with new project to ask how to make it faster