Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Program End Sequence is not exactly same in exported GCODE #23

Closed
matopeto opened this issue Oct 22, 2021 · 7 comments
Closed

Program End Sequence is not exactly same in exported GCODE #23

matopeto opened this issue Oct 22, 2021 · 7 comments

Comments

@matopeto
Copy link

matopeto commented Oct 22, 2021

I am using web interface

I set "Program End Sequence" to

M05 S0
G1 F3500
G1 X0 Y0
M30

but it generates:

M5 S0
G1 F3500
G1 X0 Y0.0000009999999974752427
M30
M2

It is practicaly the same, but i expect to be exactly same as i write to the settings

@sameer
Copy link
Owner

sameer commented Oct 27, 2021

M05 => M5 is expected, conversion does not preserve leading zeros.

M2 signals program end and is always appended, did you want to exclude that?

For the second G1: it is definitely strange that the coordinates are off, would you be able to share the SVG you used?

@matopeto
Copy link
Author

Hi

My svg is:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="99.999992mm"
   height="100mm"
   viewBox="0 0 99.999995 99.999999"
   version="1.1"
   id="svg8"
   inkscape:version="0.92.1 r15371"
   sodipodi:docname="drawing-test.svg">
  <defs
     id="defs2" />
  <sodipodi:namedview
     id="base"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscape:pageopacity="0.0"
     inkscape:pageshadow="2"
     inkscape:zoom="0.35"
     inkscape:cx="343.35714"
     inkscape:cy="45.714271"
     inkscape:document-units="mm"
     inkscape:current-layer="layer1"
     showgrid="false"
     inkscape:window-width="1920"
     inkscape:window-height="976"
     inkscape:window-x="-8"
     inkscape:window-y="-8"
     inkscape:window-maximized="1" />
  <metadata
     id="metadata5">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title></dc:title>
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Layer 1"
     inkscape:groupmode="layer"
     id="layer1"
     transform="translate(-14.986755,-60.92857)">
    <path
       style="fill:none;stroke:#000000;stroke-width:0.23873515px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
       d="m 15.106123,160.92857 v -100"
       id="path3680"
       inkscape:connector-curvature="0" />
    <path
       style="fill:none;stroke:#000000;stroke-width:0.23873515px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
       d="M 114.86738,62.253075 V 108.61069 H 70.607112"
       id="path3682"
       inkscape:connector-curvature="0" />
  </g>
</svg>

web interface generates:

G21
G90
M5 S0;svg#svg8 > g#layer1 > path#path3680
M5 S0
G0 X0.11936799641895846 Y0
M3
G1 Z0 S30
G1 X0.11936799641895668 Y100.00000100000003 F3500;svg#svg8 > g#layer1 > path#path3682
M5 S0
G0 X99.88062200358111 Y98.67549598675495
M3
G1 Z0 S30
G1 X99.88062200358111 Y52.317880523178786 F3500
G1 X55.62035533138921 Y52.3178805231788 F3500
M5 S0
M5 S0
G1 F3500
G1 X0 Y0.0000009999999974752427
M30
M2

Web interface settings:

Tolerance: 0.002
Feedrate: 3500
Origin X/Y:0
DPI: 96
Tool On Sequence:

M03 G1Z0 S30

Tool Off Sequence:

M05 S0

Program Begin Sequence:

M05 S0

Program End Sequence:

M05 S0
G1 F3500
G1 X0 Y0
M30

@matopeto
Copy link
Author

M05 => M5 is expected, conversion does not preserve leading zeros.

Ok, make sense

M2 signals program end and is always appended, did you want to exclude that?

OK, i think M2 is good at the end

For the second G1: it is definitely strange that the coordinates are off, would you be able to share the SVG you used?

Yes this is strange, i have other svg: (it is too big so i attatching link: https://1drv.ms/u/s!Aom0_RHBpL-hl_B7ITjfAD2YXWkcVg?e=zVQ8m2

And it generates:

M5 S0
M5 S0
G1 F3500
G1 X0 Y1
M30
M2

At the end:

1 instead of 0 !!!!

this is full generated gcode: https://1drv.ms/u/s!Aom0_RHBpL-hl_YAUE25vFivn8D4-Q?e=4Wza52

@sameer
Copy link
Owner

sameer commented Nov 1, 2021

Hi matopeto,

Sharing an update after I looked into this further. It is related to svg2gcode's origin option which is applied in a post-processing step after the g-code is generated.

For your first SVG, the code without any post-processing would've been:

G21
G90;svg#svg8 > g#layer1 > path#path3680
G0 X0.11936799641895846 Y-0.0000009999999974752427
G1 X0.11936799641895668 Y100.00000000000003 F300;svg#svg8 > g#layer1 > path#path3682
G0 X99.88062200358111 Y98.67549498675496
G1 X99.88062200358111 Y52.31787952317879 F300
G1 X55.62035533138921 Y52.3178795231788 F300
G1 X0 Y0
M2

The first G0 move would go negative. This is avoided by translating all the move commands. And that happens to include any inserted custom g-code sequences like program end.

The same issue occurs with your second SVG.

This behavior feels a bit unintuitive, you would expect the sequence to be identical in the output. I am thinking of chaning origin handling to only apply to the SVG (no postprocessing step). What do you think?

@matopeto
Copy link
Author

matopeto commented Nov 1, 2021

This behavior feels a bit unintuitive, you would expect the sequence to be identical in the output. I am thinking of chaning origin handling to only apply to the SVG (no postprocessing step). What do you think?

Hm.. this is very ineresting. Thanks for explenation.

I am thinking that posprocessing should be applyed only to SVG only not begin/end sequences, because (I think) that is very good to some before and after steps independend of the SVG. E.g. in my case pen up and return to the zero/home position. But don't know how this change will affect other users using your program. But for me it would be expected behaviour.

@sameer sameer closed this as completed in 1713876 Nov 21, 2021
@sameer
Copy link
Owner

sameer commented Nov 21, 2021

Hey matopeto,

I've pushed some changes which should resolve this and confirmed they work with your SVG. Let me know if you run into any other problems!

@matopeto
Copy link
Author

@sameer thank you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants