I’m seeing a random behavior occurring when cutting - the machine is calibrated fine and usually cuts well, but I’ve started to see this behaviour when cutting a couple of shapes. I’ve done a bit of searching in the forums here, but haven’t found anything quite like what I’m seeing, but maybe i’m just missing something obvious.
Here is a video showing the behaviour - at 13 seconds the white crosshair jumps and the sled drags to catch it and buggers up the cut. The weird thing is that the behavior repeats with each pass. - I’d post an image, but the forum software won’t let me enter more than 2 links as this is my first post… will post in a comment perhaps
I thought it was something screwy in the gcode, but it seems to check out in the simulators i’ve used verify. here is the nc file.
Running on win 10 on a surface pro 4 (8GB ram)
Firmware - 1.10
GroundControl - 1.10 Portable
Any thoughts on what is happening here would be welcome - I’m a real novice with this, but have been having some good success until this started to occur.
Is this repeatable? The fact that you’ve got a video of it makes it seem like you are able to repeat the issue, that’s good. Do you know which lines in the .nc file are involved? Do you have the log.txt file that includes that session? One thing I see is that the gcode uses 13 digits after the decimal point.
There was a fix to the firmware GroundControl that will be released next Wednesday that addresses a problem with gcode that has more than 5 digits past the decimal point. You could download the development version from here and try it to see if it resolves your issue. If you do that, please report back!
Edit - the PR was a change to GroundControl, not the firmware. Sorry for my confusion…
Guys,. I know I am new here … And don’t know to much about gcode yet, but I believe you said it occurs at the same place each pass. My thoughts when you set up the gcode, you tagged a line twice or have a line in your original cad hidden on top of another.
Take this thought with a grain of salt… LikevI said I am new to this as well
@chopsrob, another thing to think about when creating a gcode file is the tolerance specification used to generate the gcodes. MakerCam in metric mode uses a default of .00254mm for a tolerance. That results in coordinates with many more decimal places than the Maslow is capable of adhering to. I think the target accuracy for the Maslow is in the range of .5mm, so a tolerance of .01mm is a reasonable value to use. In MakerCam, Edit/MachiningTolerances is the place to make the adjustment. After making the change and doing the calculate step, the exported gcode parameters will still have that crazy 16 digit mantissa, but most of the digits will be 0’s or 99999999 which won’t matter when truncated.
This isn’t the first time we’ve seen this problem with a MakerCam file in metric mode, and I’m hoping that the PR to GroundControl will help.
thanks for the reply @blurfl - yes this is repeatable - the jumps seem to be identical on each pass - here is a picture of a cut piece which shows the random output at either end of the piece.
It is also repeatable when I reconstruct the .nc file (the nc file I linked in the original post was not the one in the video - is was a second attempt as I assumed there was just something whacky about the generated code, but it seems the problem persists even when I remake the gcode - always in the same spot on each of these pieces.
Here is a video of what the cutting head is doing when the cross hairs jump
I don’t have the log file, but could capture it next time i run the job if you would find it useful. I’ll find out the line too - I realized after the fact that I didn’t have this info and that it would have been helpful. Unfortunately I won’t be able to test the dev version for a day or two as I have set the maslow up in the workshop at work which I don’t have access to over the weekend. - But should be able to have a go early next week.
If you’re willing to try things, but unable to download and use the dev version of GroundControl I linked to, you could go into MakerCam and change the tolerance value under Edit/Tolerance from the default of .00254 to .01 (it looks like you’re working in metric, these tolerance values are metric). The calculate and export and see if this file jumps. Let us know if you try that, inquiring minds…
@blurfl - that feels like what is going on - I’ve been using makercam and it works pretty well for generating the code - I’ll tweak these settings and see if that fixes things up - more things to try and test! thanks again.
thanks for your reply @Stephen_Slagle - i thought that too initially, but when i recreated the gcode, tested without issue in a simulator and yet the problem persisted on the maslow, I ruled that out. @blurfl has made some great and insightful suggestions for me to try - I think the issue is likely with the gcode makercam generates in some circumstances not being entirely compatible with what groundcontrol can handle - seems like the most likely scenario - thanks again for responding
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.
. 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.