search

domoszlai / juicy-gcode

A lightweight SVG to GCode converter for maximal curve fitting
https://hackage.haskell.org/package/juicy-gcode
MIT License
110 stars 7 forks source link

Getting NaN values in arc commands #6

Closed einarkurbitur closed 4 years ago

einarkurbitur commented 4 years ago

Hello I have been trying out your tool with relatively good success. However, I have noticed that some curves in the SVG image return a NaN value for coordinates in the GCode. I've attached both the svg and the output from JuicyGcode as a text file (polytest_2 is the svg). I've tried this on multiple files and I always get this value somewhere in the GCode.

NaN_Values.txt polytest_2.txt

domoszlai commented 4 years ago

I think I know what the problem is; there are some beziers that start- and endpoints are the same. It is an intersting edge case, I added an exception for that in the prototype, https://github.com/domoszlai/bezier2biarc/commit/f598cbb488f38edf26c2ffc97bdebe76a7e696a6. Let's see how it works out in general.

einarkurbitur commented 4 years ago

Great! it has happened to me on more drawings I have tried so if you need more sample images let me know. Other than this issue, this tool is fantastic. By far the simplest and best tool to convert svg to gcode I have found so far.

domoszlai commented 4 years ago

Could you try the fix-nan branch, please? Seemingly it solved the NaN problems. It might not completely perfect though, I think I also need to change how the error is estimated. The current method is quite naive, I think it accepts some really bad approximations if the start- and endpoints are very close.

einarkurbitur commented 4 years ago

I tried the fix-nan branch and while it did fix the issue for the original svg it is stalling out on some other svg's. As in, I try to run the program and it eats up all my ram and cpu until I kill it. It outputs some gcode to the file but I guess it stalls on some case. These files had only one or two lines with NaN on the master branch version of Juicy-Gcode.

I've attached the two files I tried

Doggo_crosshatch_opt.txt Duck_plot.txt

domoszlai commented 4 years ago

I added one more patch that solves most of the issues. There were many beziers where P1==C1 or P2==C2. In these cases due to floating point inaccuracy, the algorithm falsly detected an inflexion point, and split the bezier into two where one of them was very tiny. The approximation of this tiny bezier then never converged because of numerical instability... There is one more issue with the doggo example I need to investigate.

domoszlai commented 4 years ago

There were so many strange edge cases... Could you give it a try again, please?

einarkurbitur commented 4 years ago

I just tried it out and plotted it and it seems to work as intended now. I'll be doing some more drawings a plotting them during this week so if I run into another error I'll let you know.

Another feature I was wondering about is if it's possible to add a flag so it outputs G0, G1, G2 and G3 commands instead of the G01, G02, G03 and G04. The firmware I'm using now for my plotter doesn't understand the command with the extra 0 so I've modified the GCode.hs file to output the commands in my format, but could be nice if this would just be a flag you could toggle. However, I don't know if anyone else than me really needs this feature so it might not be desirable to implement.

domoszlai commented 4 years ago

Great! First thing first, I think it is good enough to release.

domoszlai commented 4 years ago

As for the other request, it would be easy just to remove the extra zeros. I'm afraid though that it wouldn't work with some other firmware...

domoszlai commented 4 years ago

The fix has been released. If you find any other problems, please open a new ticket.