I’ve been running your slats.nc file and I see the jumping, even with the new version of GroundControl, starting around line 39 (it shows up as line 40 in GC/View because of the way GC handles the first line of the file as a comment):
G2 X90.40609137055837 Y266.71065989847716 I-868075.4517766497 J-4540330.784263959
The I and J parameters are pretty large…. That I value is more than half a mile! So don’t wast time trying the dev. version of GroundControl, but do try dialing back the tolerance value. I’ll be anxious to hear how that goes.
Edit - if you want to post the revised tolerance .nc file I can run it in simulation mode and won’t need to spoil any plywood…
Well I’ve run the file on the machine, but the result was the same - always with that section of each slat - between the first and second notch from either end. I also skipped through the file (not shown in the video) to see what it did at when it reached those parts of the other slats - with the 3 that I looked at, the behaviour was the same - random jumping between the first and second notches from either end.
In both your file and the one in the issue above, the gcode processor is creating parameters that require more precision than is available.
In your case, I think that MakerCam’s metric mode is causing the problem. Once you’ve loaded your SVG into MakerCam, use the Inch/MM button in the upper right corner to put MakerCam into Inch units, then calculate and export. I think that the file will run correctly then.
Have had another go at this one following @blurfl 's advice and switched to imperial. Unfortunately the problem persists even when the calculations are done in makercam in inches - you can see the outcome here: https://youtu.be/paKKO21RD2E (from ~8sec)
There are still this huge radius for I and J that throw GC off the path. The switching from mm to inch in makercam help for the 16 digits behind the decimal point, but not for the huge number you have for I and J.
How is the file created? Instead of an gigantic arc, a straight line might do.
Did you mention somewhere that the file was being converted to a .jpg file somewhere along the process or was that someone else? I think the issue may be that the file is actually not made up of smooth lines, MakerCAM is having a hard time finding the edges of the file and so it is trying to use MASSIVE arcs to approximate the edges which is creating numbers which are too large to fit precisely in the Arduino’s memory so it is unable to do accurate calculations.
How does the file go from the design to the .svg file?
@chopsrob, I’m sorry that this is posing such a problem. Thanks for posting the SVG file, that helps a lot. That looks like an elegant chair, I’m asxious to see it built!
I’m not an expert in MakerCam, I had hoped that there were settings that would keep it from calculating arcs with radii measured in miles, beyond the precision available in the math on an Arduino. I haven’t found any settings that do this. I’ve been working on a patch to the firmware to identify the issue, but that is taking time, and we all want to see that chair cut and assembled!
I can tell you that I took the SVG into Easel and generated a file there that runs without error. It doesn’t have your vaues for material thickness or bit size or cut settings, so it won’t help you, but it means that you could use that way to generate your .nc file and cut without running into this issue.
@chopsrob, we have made some headway in identifying and working around the problem that has plagued this file. The firmware fix in PR#430 works to run the generated nc file as you posted it. With luck that PR will be merged in time for the release next week.
The file was made using a piece of software I backed on kickstarter in 2011 - sketchchair - so there was no JPG to SVG conversion - straight up vector file.
It was a cool project which seemed to die while still in beta - a shame as it is the perfect companion to a maslow cnc IMO.
I’ve just seen @blurfl’s post re the firmware fix - maybe that will resolve what is happening - I was planning to redraw the file in something else, but I’m 2/3 through this cut and matching the pieces would have been a bit of a muck around - would be good to get working as it is - strange how makercam interprets that line… it’s no different to any of the others
Diatom.cc has started other projects, Piccolo for example, and dropped them mid- development.
Sketchchair’s official forum gets a server error, it’s blog is an undefined link, neither a good sign. I’d considered supporting their Kickstarter, but my CNC router at the time would have been good for dollhouse furniture. Piccolo was exciting (would have bought one) but never materialized. Diatom hasn’t proved very reliable, alas
I have tried on linux to have a separate (old)java to at least get it running for a start.
I failed mainly because I could not install it in the productive environment without risk.
VM’s might be a start point here but I could not determine how far I need to go back to see it once. Requires Java 1.5 or above
is sadly not true for the above part
Sketchchair is pretty awesome - I have a working beta version which is a little flakey, but can still be used. The simple way you can design bespoke furniture (and test it with a dummy) for cutting on a CNC make it ideal for maslow users. Would be cool if it could export gcode directly - perhaps even a skew specifically tailored to the needs of ground control would be good - rather than having to import into makercam (or similar) and then export the gcode.
@Gero - not sure it would be of use to you, but I can get you a linux beta which, if like the windows version, works ok