Circle representation

[gerdvogel]

Circle representation
did a small test, because a circle is not displayed completely in GRBLlaser. The NC file contains only one circle and consists of three segments. The circle is truncated in the representation, this happens whenever a circle is the largest element.

(Projekt circle test)
(Erstellt mit Estlcam Version 11 Build 11,117)
(Laufzeit ca. 00:05:52 Stunden)

(Benoetigte Werkzeuge:)
(Laser)
G21
G90
G94
M04 S1000

(Nr. 144: Gravur 4)
G00 X31.9510 Y0.1645
G02 X-16.0938 Y-27.6812 I-32.0607 J-0.0535 F900
G02 X-16.1865 Y27.8496 I15.9840 J27.7922
G02 X31.9510 Y0.1645 I16.0767 J-27.7386

G00 X0.0000 Y0.0000

M05
M30

Regards Gerd

[arkypita]

Hi Gerd. You are right, but this is a known issue.

The way LaserGRBL use to compute the size boundaries is to compute the X-Max / X-Min and Y-Max / Y-Min by using the X/Y values in each GCode lines.

This is good for G1 linear movement, but it is not ok for G2/G3 arcs where X/Y only represent the target point of movement, not really the farest/nearest point reached by the arc.

This cause a very small error when tracing big images rich of small segments/arcs, so it is not an issue in those cases (only a good approximation) but gives a big error when using small sequence of GCode with big arcs segments.

I can use more complex math (sin/cos/tan etc) to compute the right values when processing G2/G3
but i am not sure that the result is worth the effort.

[gerdvogel]

Hi, I once wrote a small program in Visual Studio 2017 to read and scale Gcode files. I laser outlines on wood and then saw them out, because the pieces of wood don't always have the right size and I don't always have the files to re-create I wrote this program. In this program I also determine the Max X and Y values as well as the Min X and Y values without sin, cos or tan. If you want to have the program, I have to translate the comments into english first. I could also translate the last version of GRBLlaser to German. Can I send the files to this email address or do YOU have another one? With friendly greetings from near Munich Gerd Vogel Ps: during my studies I learned Fortran 2, then later Fortran 4, Basic, Pascal, C and the other languages that are available to program microcontrollers, also I wrote some CAD programs for schematics and layout creation, as well as some postprocessors for the manufacturing. Translated with www.DeepL.com/Translator Von: arkypita <notifications@github.com> Gesendet: Sonntag, 3. November 2019 17:12 An: arkypita/LaserGRBL <LaserGRBL@noreply.github.com> Cc: gerdvogel <gerd_vogel@gmx.de>; Author <author@noreply.github.com> Betreff: Re: [arkypita/LaserGRBL] Circle representation (#760) Hi Gerd. You are right, but this is a known issue. The way LaserGRBL use to compute the size boundaries is to trace the X-Max / X-Min and Y-Max / Y-Min by using the X/Y values in each GCode lines. This is good for G1 linear movement, but it is not ok for G2/G3 arcs where X/Y only represent the target point of movement, not really the farest/nearest point reached by the arc. This cause a very small error when tracing big images rich of small segments/arcs, so it is not an issue in those cases (only a good approximation) but gives a big error when using small sequence of GCode with big arcs segments. I can use more complex math (sin/cos/tan etc) to compute the right values when processing G2/G3 but i am not sure that the result is worth the effort. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#760?email_source=notifications&email_token=AHOB6WPS6QRJJFVLNOL7RQ3QR3Z3TA5CNFSM4JILZ2N2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5WQMQ#issuecomment-549152818> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHOB6WKASXMFYD27TLL7743QR3Z3TANCNFSM4JILZ2NQ> . <https://github.com/notifications/beacon/AHOB6WLLEAUTRQFFPB5AH5LQR3Z3TA5CNFSM4JILZ2N2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5WQMQ.gif>