Arcs as Lines for Lasercutter

[mechatronic]

Hi,

So the machine controller I'm working with has been having issues with arcs; specifically it slows down the velocity dramatically, and it's proportional to the arc diameter too (number of chords etc). I've been looking at fixing this, but having reviewed the sample files I have, they don't appear to use any arc functions whatsoever. Instead, it appears that it's just line instructions used for arcs.


A big issue I have, is that I can't really generate sample files to figure out what's happening, as the drivers and software are ancient and it's a struggle to get working. I'm relying upon samples I have from others that have reverse engineered the driver output in the past. And I've just noticed, that even though they're HPGL compliant, they don't use arcs (ie AA/AR commands), but just use the "pen down" linear command.

Soooo, how can I render circles/arcs as just their chord lines? I don't even know how objects are coerced into a path type, nor how they're parsed - so far I've given arc commands for arcs, and get a centre XY, arc start XY and sweep. I'm hoping there's already something I can use that can output chord paths instead?

Thank

[mechatronic]

I've since found that the "Interpolate Arcs with Line Segments" config option is supposed to do this, but it doesn't appear to work...

Do I need to remove arc variables or something, or will it just feed them to the line CAM instead, and work without modifying post processors?

Ref: https://qcad.org/rsforum/viewtopic.php?t=8765

[mechatronic]

Okay, mashing every setting until I get a result, it would appear that paths have to be offset, so outside or inside, and on path doesn't work.

[CVH]

it would appear that paths have to be offset, so outside or inside, and on path doesn't work.

Wasn't aware of this shortcoming.
And it explain why once so often users ask for an arc discretization GUI tool so they can do this process upfront.

mechatronic,
Andrew stated that not offsetting whole the circle with small line segments was a bug and the workaround was:

Code: Select all

Grbl_EASEL_MM.prototype.getArcInterpolation = function() {
    return Grbl.prototype.getArcInterpolation.call(this) && (
    (this.checkContext("CamOffset") && this.outputOffsetPath) || 
    (!this.checkContext("CamOffset") && !this.outputOffsetPath));
};

Unsure what was meant in 2021 with 'This fix will also be included in the next QCAD/CAM release.'
The Grbl_EASEL_MM (not yet included) or the workaround itself at exporter level or a fix that doesn't require the workaround ...

When exporting an arc shape to a toolpath block it checks this.getArcInterpolation()===true
When true it will chop up the arc with approximateWithLines(this.getArcSegmentLength() and export a bunch of line segments.
Otherwise it will export an arc shape.

getArcInterpolation(this) returns a global option as boolean or falls back on this.arcInterpolation.

It should then be simply setting this.arcInterpolation = true; in your custom postprocessor. (Without the workaround, when fixed)

One might assume this is related to CamArcInterpolation of the CAM config dialog: https://qcad.org/rsforum/viewtopic.php? ... 427#p42687
But it is not ...
The dialog pops up without "Interpolate Arcs with Line Segments" checked using Grbl_EASEL_MM.js by Andrew including the setting.

Then assuming "Interpolate Arcs with Line Segments" is parsed to a global by the dialog and the getArcInterpolation() does not need to fall back on this.arcInterpolation at all.

Further found that the counterpart of context "CamOffset" is "CamNotOffset" but unsure this means exporting 'On shape'.

And the same as you ... Whatever I do I get G2/G3 moves when 'milling on shape' ...
The 6 arcs from a single circle have no custom property for example 'CamOffset' = 0 compared with the offset line segments where this is 1.
Even then one would expect the last pair of tests to return true instructing arc interpolation.


Sorry to be of no help.
Regards,
CVH

[CVH]

As stated in my PM I have filed a feature request:
https://qcad.org/bugtracker/index.php?d ... sk_id=2506

What is not, is not and thus basically it is not a bug.
You could vote for it.

Regards,
CVH

[mechatronic]

Voted!

[CVH]

Hi, again.

I have some luck with fooling it a bit.
Included this.outputOffsetPath = true; not using cutter compensation (G40, G41, G42)
And offset the required shapes by half the so said tool radius diameter.
Also opted for a certain offset side of course and to interpolate arc's.

In fact, any laser beam has a minute size ... Isn't it?
High power industrial lasers cutting thicker metal account for that so the piece has the about exact end dimensions.
A plasma cut has also a certain width depending power and substrate thickness.

On export (to G-code) I get arc's represented by segments. Obvious
Almost replicating 'OnShape' but then including arc interpolation.

There is a catch to it ...
An offset to an offset is not entirely the same original shape.
Beneficial for lasers there it includes rounded corners at some (but not all) hard corners what overcomes:
- Decreasing Feed to dead stop at hard corners
- Trothling up Feed after each such corner.
Feed changes at hard corners may scorch the substrate there your laser power is not Feed relative.

And then again you could do without offset shapes.
Just think of your laser beam as having a physical diameter ... As a micro mill.
Then you never need to 'mill' on shape.

Regards,
CVH

[mechatronic]

Hi,

Thanks for your thoughts.

I fully agree - and had this thought whilst playing with some sample paths. I need HPGL (kind of like G code with some very nice refinements and capabilities, but originally for HP pen plotters), so inbuilt compensation is something *not* within the realm of HPGL.

As you point out, the laser is minute, BUT, it is actually much thicker than you'd think! Depending on the focal lens, and thickness of material, compensation actually becomes quite important. The Beamo config uses 0.3mm from memory - it's not far off probably for 3mm of MDF. When I calibrate the axis, I cut a 100mm x 10mm square. I have to measure both the inside cut out and outside of the cut part, to determine the cut size to account for it.

But for me, this comes back to Toolpaths by Layer!!! I don't mind setting compensation, when I can easily isolate inside and outside cuts. I might have 5-6 layers that need different tools (ie diff power for cutting vs engraving) and with cutting compensation, that nearly doubles the layers. Again, I'm fine with that. But when artwork may be an SVG imported, with a billion segments, it takes long enough to coerce into layers, to then have to manually select everything for each layer. And then you cut, find stuff needs fixing, and then have to remember to re-add replaced segments etc etc.

I've hard-coded interpolation into the post processor now, so part of calibration is to figure out the cut width. As I build data on materials and thicknesses, I might find this is variable, so the tool library may grow!

[mechatronic]

Actually, having a think, it does pose an issue for engraving... Especially score marks on cardboard etc to lineup with edge cuts, or artwork being engraved internally which needs to be on the line. Text a good example. I suspect tools for engraving with a 0.0 diameter is the solution there.

[CVH]

Seems to be included in the next release.
See Changelog, planned for after 3.28.2
https://www.ribbonsoft.com/en/documentation/changelog

The only thing that remains is closing the feature request: https://qcad.org/bugtracker/index.php?d ... sk_id=2506

Regards,
CVH