Hmm… The G2 / G3 not being supported on fluidNC seems like it could be the culprit.
I have generated some linear gcode from FreeCAD which can be done without messing with the postprocessor using the flag “split arcs” for path/CAM operations (not that anyone seems keen on FreeCAD, fair enough).
That has no G2 or G3 codes in and I can try it next weekend. Here is the linear code in case anyone has the time to verify we are bumping into that sheet1.ngc (411.9 KB)
If this turns out to fix the issue I don’t know if what I have been seeing would be a separate one to what @bar is working on, or if it just is the issue and others have not had such a pathological case of it.
Side note, with fixed point numbers on 24bit integer for the uController, we should have sub micrometer precision for a 24’ working area (12’+/-). Are arcs that sensitive in gcode?
@md8n ahh, well FreeCAD does throw a lot of curve balls so the wacky gcode you saw sounds on brand. Thanks for showing the ncviewer and helping with looking through the code, I had not seen your update until after messing with FreeCAD.
Hmm… The G2 / G3 not being supported on fluidNC seems like it could be the culprit.
There are at least two variations of the arc codes.
when you go through the CAM step, what type of machine do you tell it that you
have? you should look for GRBL if it’s there.
I have generated some linear gcode from FreeCAD which can be done without messing with the postprocessor using the flag “split arcs” for path/CAM operations (not that anyone seems keen on FreeCAD, fair enough).
That has no G2 or G3 codes in and I can try it next weekend. Here is the linear code in case anyone has the time to verify we are bumping into that sheet1.ngc (411.9 KB)
If this turns out to fix the issue I don’t know if what I have been seeing would be a separate one to what @bar is working on, or if it just is the issue and others have not had such a pathological case of it.
Side note, with fixed point numbers on 24bit integer for the uController, we should have sub micrometer precision for a 24’ working area (12’+/-). Are arcs that sensitive in gcode?
I don’t think it does fixed point numbers, I’m pretty sure it does double
precision floating point.
and yes, arc can be that sensitive (among other things, if the start and end are
the “same point”, the gcode specs say that you are asking to cut a full circle,
if they are off by enough for it to notice, you but a very tiny arc instead.
Too many CAM programs create a TON of little tiny movements. This is one of the
things that gcodeclean looks for and cleans up.
4 Simplified job with arc orientation mirrored, G2 and G3 removed: does not crash sheet1.ngc (115.8 KB)
@bar, @dlang If there is some known problem with version 0.7X firmware crashing, pretty sure that 1 and 2 will reproduce it quickly. Only conclusion I can draw right now is that the arc in my jobs can be cut depending on orientation / location, which is very weird.
@bar, @anna, I’m going to need you guys to take a look at this as it is not solved with the latest 0.78.1 release.
As you have asked in your video update, this is an extremely easy to reproduce issue and I suspect it will take 5 minutes for you to root cause.
What I have tried:
Different stepdowns 1,2,10mm (issue is consistent)
2 diffierent postprocessors (issue is consistent)
Offseting job by 1mm in x axis. Issue goes away.
What I think:
My job is offset by 4’ in x, and 2’ in y so that I don’t have to mess with the machine home position when cutting a 4’ x 8’ sheet. I guess that this causes something wacky to occur as my machine coordinate system shows what I assume to be a 4’ x 8’ rectangle in an impossible coordinate system by default (the machine would crash if it tried cutting from the default home without adding my offsets).
Can you please confirm that sheet1.ngc (91.1 KB)
crashes on one of your machines and sheet1_1mmoff.ngc (91.0 KB)
does not?
If neither crash, my alternate hypothesis is that there is a bad spot in my callibration coincident with the arc change of direction where compensation mathematics for the anchor geometry is resulting in a singularity.
So, if neither files crash for you on the first arc I can send you my config.yaml and you could try it to see if you get the crash then. If my second guess at the issue is right, that would squash a very nasty bug IMO.
@bar, @anna I can confirm this issue is specific to calibration. I am 99% sure this is a firmware bug caused by bad calibration correction maths as I mentioned previously.
I determined this by running the failing files after re-calibrating my maslow4 for thinner stock (I did not care to mess with z offsets for stock thickness and wanted to test my theory also).
Please confirm by running any of the failing files with This original failing config maslow.yaml (5.2 KB)
, and then the second recalibrated config maslow.yaml (5.2 KB)
, which works.
This issue has been open a while now and I expect you will likely fix the issue others are finding with arc cuts by addressing the problem, so could you please push it higher in the priority queue?
Testing now. I will let you know if I see anything odd. First thing I noticed though is that the speed is really slow. Was that intentional? At this speed you may be wearing out bits pretty fast.
Ok here is what happened. I had to run the GCode you sent with my own yaml file because the yaml contains the calibration info which is specific to your anchor location. Sheet1.ngc crashed about 20 min in. So I reconnected and ran Sheet1_1mmoff.ngc which did not crash. On a hunch I went back and ran Sheet1.ngc again and it succeeded. I used the same XY home each time I ran the file, but I had to set the home up and to the right before starting because the cut would have run off of the sheet of plywood. Did the issue re-appear after you recalibrated?
There are a few interesting things on your findings I’d like to discuss
1, home position. Is the work area fixed at 8’ × 4’? I have been able to jog the machine (accidentally) outside 8’ × 4’ so assume this would not cause the crash I am seeing
2, calibration. To reproduce the issue reliably you would need to use my calibration file. I assumed you could override the firmware’s 15mm accuracy check after tensioning belts in a debug build. If this is non-trivial, best hack I can think of for manual anchor point fettling is some unistrut bolted to the floor upside down with the tracks as hypotenuse in the frame rectangle, and beaurau hinge like guides on the far edge.
3, speed. I actually dont understand this well. I thought i set the maslow to cut at full pelt and i have seen my bits wearing out really fast! If you can give me your recommended settings for a 5mm step down with a 1/4 bit or point me at forum thread, that would be fantastic.
@bar, can you help @anna with a debug firmware build? She cant use the supplied config files without one. Or maybe you have a means for her to simulate tension from the motor controllers which would be even easier.
At the end of the day she just needs to be able to have the ESP32 run the gcode with that config so you can check the program counter for the motion controller process when the machine becomes unresponsive at the end of the first curve. My hunch is whatever happens after div0.
No, there are no software constraints on where the machine can go (although maybe there should be).
I think Anna meant that on our machine it would fall off of the spoil board if it went further
This is the hard part. We can override that check in software, but we still need to find a way to keep the belts mechanically tight. The easiest option would be to just hold them, but since each test takes about two hours that’s a lot of holding . Do you know what part of the file has the issue? Maybe we can make a smaller version with just a few lines of gcode where it crashes which would make testing much more doable
We usually run everything at about 1800mm/min which I think is about 3x faster than that file is cutting. Counterintuitively router bits actually last longer when they cut faster
How long into the file is this? If we can make it 5 minutes in is that enough to say if we are seeing the issue or not?
With the crashing calibration, between 5 and 7 minutes. It does a straight down vertical of about 30", a 90 deg left, a straight left horizontal about 22", 90 deg right, straight up 6" or so and then you are at the arc. It fails at the end of the arc.
@bar, what would be needed to remove the manual tensioning requirement? Is it a super heavy lift software development wise?
The need to manually tension it is more of a hardware thing than a software thing, the belts just need something pulling against them to be able to unspool properly, but maybe the solution is to just run it with no motors at all. I can turn off the alarms for the motors not being connected and run the file with your config without the machine even needing to move to test. If the issue is purely math it should happen even without the motors turning.
. Do you know what part of the file has the issue? Maybe we can make a smaller version with just a few lines of gcode where it crashes which would make testing much more doable
