GCode Export

[jb55]

PROBLEM: I created a rectangle with some letters and small boxes within the rectangle. The idea was to export the Gcode for engraving on a CNC machine. I reordered the boxes and exported the Gcode. When I opened the GCode in Mach3 and viewed the tool path, it was all over the place. Not that it wasn't correct, it would engrave the lettering and boxes okay, but the order was crazy. It would do one letter, then a randome box or two, back to another letter in a different word, another box, etc.

QUESTION: Is there a way to designate in a QCADCAM drawing the order in which elements will be engraved when exporting the GCode?


Win11-64
QCADCAM 3.32.4.0 (3.32.4)

[CVH]

QUESTION: Is there a way to designate in a QCADCAM drawing the order in which elements will be engraved when exporting the GCode?

Probably not.
You can opt to process inner tool paths first or it is already the default.

In the same Profile it will kinda attempt to optimize the traversing between sub tool paths.
Typically a Traveling salesman problem.
Here one of finding the shorted routes connecting tool paths endings with other tool paths starting positions.

Then I suspect that QCAD/CAM exploits some kind of 'Nearest neighbour' algorithm.
Never guaranteed to be optimal and in rare cases it might even result in the worst route.
After exploding text entities, with 44 paths, the number of all possible permutations is astronomical (2.65e+54).
That may be reduced somewhat accounting for already connected paths.
At some point, finding the optimal route may simply take longer (years) than using a not so optimal route.

It may start to matter for more than hundreds or thousands copies of the same job.
A better and novel candidate would be some 'Ant colony optimization' algorithm.


The solution for a more logical organization lies in dividing your job into several Profiles:
- Profile 1 - Boxes
- Profile 2 - Text entities
- Profile 3 - Outer contour
The order of profiles is configurable.


Remark that:
- QCAD/CAM has no method for pocketing.
- TTF text is exploded to outer contours.
- Engraving 'On path' will produce open glyphs that are 1 tool radius larger in all directions and smaller for voids.
I would then advice an inward offset for Profile 2 by defining side and milling method.
It will never be exactly the same as the filled areas with sharp corners.
For certain fonts or in isolated cases the Glyphs can be distorted too much.

Regards,
CVH

[jb55]

Thanks for the detailed description. I guess I'll continue to do what I did for this one and simply edit the GCode in a text editor using cut and paste to set the order of operation.

Cheers.

[CVH]

I guess I'll continue to do what I did for this one and simply edit the GCode in a text editor using cut and paste to set the order of operation.

Really ... Dividing the job up in Profiles is the more common approach.
Think of hundreds to thousands of closed tool paths or open motion chains instead of only 40 or so.

Select those things belonging to one Profile and generate the CAM-entities (KP).
Select another group for a second Profile, and so on.

Perhaps you could organize the source in layers.
Then you can select all from one layer to initiate a Profile (KP) per layer content.


Not that I don't edit the exported G-Code myself ...
Typically to prefix a fast plunge to somewhat above the bottom of the last pass.

For an engraving point it is mandatory that the plunge FEED-rate is slow and gentle.
... We are talking about engraving tips in the sub 0.1mm range on brass, steel or even stainless.
Plunging whole the way down at this rate while there is nothing than a void left by a previous pass is very time consuming.
Especially when pocketing TTF text using a V-carving technique with many traversing at Zsafe.

BTW: Not every milling tool is capable/intended of/for plunging straight down like a drill.

But that are global find/replace instructions.
Like when depth Z-1.20 is already processed:

Code: Select all

G1 Z-1.25 F100  >>>  G1 Z-1.15 F1500\r\nG1 Z-1.25 F100\r\nF600\r\n   (0.106s instead of 0.75s per plunge)

An even better approach would be ramping down at an angle so that there is a forward motion.
Or a helical entry if there is room for it but these are hard to find textually without a tag.

Regards,
CVH