arkypita / LaserGRBL

Laser optimized GUI for GRBL
http://lasergrbl.com
Other
1.26k stars 497 forks source link

Nasty bug in G3 arc coordinates created from vectorisation of PNG file - possible safety hazard! #1594

Closed alastaira closed 3 years ago

alastaira commented 3 years ago

Selecting the Vectorize function for a particular PNG image (attached) generates a set of instructions containing a G3 command with extreme I and J parameters that cause the laser to move massively out of range (while burning!). That instruction is not shown in the preview window and there is no indication of a problem until LaserGRBL tries to execute that command.

To Reproduce

  1. File Open the attached file "wym_animalcipher.png"
  2. Choose settings as shown in "LaserGRBL_Bug.png" screenshot - vectorize, mid-level brightness/contrast/white clip, B&W, spot removal 2.0, Smoothing 1.0 Optimize 0.2, No filling.
  3. On Target Image dialog, choose Autosize to select 300 DPI (I'm using border speed 1800, if it matters)
  4. Note that, in the preview window, there is a slight break on one side of the letter "n"
  5. Start the job. After only a few seconds executing, the command highlighted in "LaserGRBL_Bug2.png" will be executed, causing the laser to move to extreme positive y value (I don't know the exact distance as I killed the job as soon as it started!)

Expected behavior Correct vectorisation of the image (and/or correct visualisation of the preview of the commands generated, so at least the error would become apparent before starting the job)

Hardware and software configuration (please complete the following information):

alastaira commented 3 years ago

It seems likely that this shares the same cause as #1248

arkypita commented 3 years ago

Hi, can you share the original wym_animalcipher.png file put inside a .zip? The file attacched in github is compressed. And if possible, also an exported .nc gcode

alastaira commented 3 years ago

Sure. Please find attached (lines highlighted on above screenshot occur on Lines 161-162 of the .nc file) wym_animalcipher.zip wym_animalcipher.nc..zip .

arkypita commented 3 years ago

Hi, I tried to send the code to my engraver and I confirm the wrong (and dangerous) behavior.

However, the code generated by LaserGRBL is not entirely wrong. The I and J values are the offset values of the center point of the arc, relative to the starting point of the circle. It is completely normal that I and J are outside the work area and it is also normal that they can assume quite large values when working with short and almost straight arcs.

image

If you load the gcode file you sent into a simulation program like CAMotics you can see that a PC has no problem simulating this path.

I believe that the issue is inside the grbl firmware instead, that could be not able to handle this numbers (hardware limit). See: https://github.com/gnea/grbl/issues/901

arkypita commented 3 years ago

Since an arc of circumference with a very distant center is actually approximable with a straight line, I think I will try to intercept these cases and transform them into straight lines.

alastaira commented 3 years ago

Thankyou for your attention. I agree - it seems likely that this is caused by the GRBL issue you referenced concerning large I/J values parsed as single precision floats. It would be nice if the underlying cause were addressed (i.e. GRBL itself sanitised any inputs) but, as an immediate fix, I think your suggestion of creating straight line segments instead of arcs when the deviation is so minor is a good alternative.

arkypita commented 3 years ago

Implemented in v4.6.0 currently pre-release, can be downloaded here for test: https://github.com/arkypita/LaserGRBL/releases/download/v4.6.0/install.exe