Closed alastaira closed 3 years ago
It seems likely that this shares the same cause as #1248
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
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 .
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.
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
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.
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.
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
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
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):