There is the machine’s origin (X,Y each at the machine’s homed minimums), and there is also a workspace origin, which can be different. Commands to go to the X,Y “0,0” will go to the workspace origin. You control where this origin is. You can position where you want, and zero a given axis. This includes Z too, but usually the Z has to be probed after homing. Technically speaking, each time you probe Z to the top of the material, when it sets the new 0 for Z, that’s a workspace origin being set.
This is normal for X – negative is to the left of 0 and positive to the right.
Normal for Y is negative is toward the front of the table (closer to you) and positive is toward the back, farther from you. Assuming you are at the front.
Yes I am using Estlcam. I did put in that start gcode and it works and ran the operation fine.
Thanks for the kind words. After seeing Doug’s post I think I know what happened. I guess the G92 persists across power cycles. I am also guessing that the reported position in the FluidNC terminal is the actual position and not the relative position (to the origin). I was trying to move the position of the machine after a power cycle to the position I had read previously from the terminal after a dry run.
I rebooted everything, zeroed it and ran G92 X0 Y0 Z0 and everything works as I would expect.
Now to figure out why my strut is 1.81mm too wide. I measured a few of the screw slots and some of those were bang on 5mm with a few others being 5.11mm. Not sure why the outside would be off so much though. I did 3mm DOC, 15mm/s speed and 24000 rpm. I also did a 0.5mm finishing pass. Before I did the job I did the XY ruler drawing and did 150mm ruler each way and it was spot on after a few small adjustments to the steps/mm.
Any thoughts on why I’m almost 2mm off on the outsides?
I went and measured the length of the cut strut and I’m at 1475mm when according to the Estlcam grid and the generated drawing it should be 1450mm. Something’s not right. I’ll have to dig around tomorrow.
99% sure this is the issue. I increased the x and y steps per mm by 1. That would explain why Y is such a big difference and X is less. I’ll have to change that back tomorrow and re-run.
I’m with @jeyeager on thinking that is likely the issue. Adjusting the steps usually should only take teensy small adjustments. “1” sounds like a big leap. The test for it should be the biggest distance you can do for a given axis. I think there is a Teaching Tech calibration website that has a built in calculator (made for printers but that can be used for this) where you enter the distance you programmed for, the measurement of how far it actually traveled, and your current steps, and it tells you what the new value should be. It’s not the kind of thing to guess at. There’s a formula for it, but why not use the calculator!
I reset the steps per mm back to 50 and started the cut. Halfway through the 8th triangle cutout my endmill snapped. My best guess is that it came loose, and slipped down, drilling deeper on the plunge. When it tried to move it was too deep and snapped.
At this point it was cutting in air so I paused the cut job trying to figure out how to recover. I couldn’t manually move it while paused so I cancelled the job by pushing the red reset button right next to the pause. I then manually moved the machine, swapped the bit out and homed. I did not reboot hoping it maintained the origin. I then went to estlcam and made new g-code, removing the g92 x0 y0 from the start script and deleted the first 7 cutouts so it would continue a bit before where it snapped. I started the program and probed and it’s first movement was driving to the middle of the table away from the actual part and driving the bit into the table. I quickly unplugged it and reset everything. This time I put the g92 x0 y0 back in the code and manually drove it to my previous origin that I wrote down before. This time it correctly went to the right spot but seemed like the cut was maybe 1mm off as it didn’t quite line up perfectly. I wasnt sure if the previous cut was truly accurate so I decided to let it finish the job just to see. The new strut dimensions are better but still slightly off. The x is half a mm short and the y is 3/32" too short. I’ve ordered a metric tape measure to not have to keep converting these long measurements.
My thought right now is to create a test square that’s say 100mm x 100mm and cut that out using estlcam and measure with my digital caliper then adjust the steps per mm based on that. Once that is done, recut the square and check again. If that looks good, cut the strut and see if that’s good. Adjust if needed but hopefully not at this point
I’m still baffled why the origin appears to be moving and creating these unexpected movements. Is that red reset button that is next to the pause button somehow resetting it? The coordinates in the console window all make sense so why would the G0 behave sometimes and not other times?
Don’t feel bad. We’ve all been through multiple rounds of this. The more you do it, the more you learn, and the better it gets.
Loose grub screws (set screws) can cause this. Also, loose end stops, or loose end stop switches. Also, skipped steps can result in a cut that’s not properly aligned with the work origin.
With a Jackpot, I know that the “zeroed” work origin survives even after a reboot!
This is the right approach, but two things: The larger you can make the test, the better. Also, it need not be cut, can be drawn with a pen.
I think I may not have been clear. I’m referring to the machine driving to the middle of the board when it should have been going back to the workpiece. This was certainly not caused by grub screws or improper alignment.
Once I set everything and manually zeroed and set the origin and got if cutting again, then yes I see loose grub screws or something like that causing a slight shift.
I had considered that too but I think the accuracy of a 100mm piece with a digital caliper is better than a larger piece with a tape measure. The error should scale with the size of the piece, but the accuracy of the measurement technique decreases which may even things out. When doing 3D printer calibration tests you only extrude 100mm of filament and check for adjusting those microsteps.
To your second point, I can more accurately cut a piece than draw with a pen. I tried drawing a test ruler using a pen with light pressure. I was even using the V3.1 of your tool less pen holder and had wobbly lines. At least with cutting the piece I can also account for any runout. Arguably that should probably be accounted for with the tool settings in Estlcam…
This is a good point also. My concept was that a fine point pen, marking corners on a full size LowRider, and measured with a decent tape measure, should be pretty accurate. But a decent size pocketed cut, measured with calipers, is also good.
If the program ran on in the background when it started getting caught and skipping steps, the controller might have thought it was somewhere else entirely. Could that be it?
I suppose I could do both. Cut the 100mm and then recheck with another cut and also try the pen method.
I did home it after that which I thought would fix any of that. Unless the origin is not referenced from the machine home. Like if the machine home is 0,0,0 and the origin is 130,170, -50 with respect to that. If the origin then drifts shouldn’t it match back up after homing?
Two ways I can think of that it would not match right (other than loose grub screws) is if the first cut effort suffered skipped steps, or the homing is not repeatably accurate.
Of those two, the former (something probably not good in the gcode / feeds & speeds) is probably preferable to the latter, which means something ain’t right in the machine.
I’m not sure what the issue is. I feel like the machine shouldn’t be driving off to the middle of the table when sending simple move commands.
It almost seems like its getting G90 commands when it shouldn’t or switching between relative and absolute positioning unexpectedly. I think I just need to try and reproduce the issue and work back from there. Just take off the router and make sure nothing collides and try and send small movements. I don’t suppose there is a query to figure out where the machine thinks its origin is?
Perhaps someone can help me get my terminology right. I believe the “origin” is set by the G92 command and that should be the point the machine sees as X0, Y0 and Z0 when executing G code and using G0 commands right? So what is the position called where the machine homes to using the endstops/limit switches? I’ve been calling it Machine Zero but is there a correct term for it?
Crown has ran fine twice and I’ve cut two (incorrectly sized due to calibration mentioned earlier) struts so far so I don’t think it’s necessarily g-code.
