Just finished running it and no issues with the gcode itself 
(Video is uploading)
Other than a couple of slightly weird z-axis moves it seems totally normal.
What am I doing wrong then? To recap the events.
- ran homing (retract x2, extend all, fully, put pins in, take slack)
- jogged to all 4 corners confirming belts were tight throughout.
- jogged to bottom left.
- Load File.
- Click on Z, DEFINE HOME.
- Click on Define Home.
- Click play.
Thatās a 9 degree spiral ramp into the work piece.
So itās not the gcode that is the issue (gcode shouldnāt really be able to do that anyway)ā¦and also Iām not really seeing anything in the print statements that seems like a clear red flag. The position error being 15mm and it halting is telling us that something is wrong, but itās clearly pulling way way too hard which seems like a bigger issue than that.
Nothing, you did everything exactly right. Thatās 100% the same set of steps that I took.
When it went up to the top of the board like that, what was it showing on the screen like this?
It looks to me like it goes further than it would need to move to get to where the pattern starts.
Edit: Like did the machine seem to think that it had not moved far enough or something? Iām sort of grasping at straws here, but I donāt have a good theory so any information helps
I donāt remember. I never really looked at the layout, just at the xyz coordinates. Which when I clicked the home went to all zeroes as expected.
1 Like
Iām positive that you arenāt doing something wrong. Whatever is wrong itās a bug in the software. There is no combination of buttons or gcode that should make it possible to break a beltā¦Iām just not sure where that bug isā¦
When you click home, does that set the G54 WCS to zero? Iām assuming the machine position is wherever the router is in space after take slack.
On all the other GRBL machines homing would be what you call retract and extend all.
That is exactly right. We might want to come up with better names for those.
Clicking up here will pull up standard FluidNC interface which shows the machine position and WCO more clearly.
1 Like
One thing that is for sure an issue (but probably not your issue right now) is that the stop button doesnāt work right.
Iām going to fix that right now and hopefully learn something along the way.
1 Like
Just out of interest, the 4000mA alarm setting on the motors seemed to get triggered yesterday for me even when I had set it to 2500mA. Are we sure FluidNC is reading the yaml correctly and is it clear as to when you need to restart FluidNC, the machine or bothā¦?
1 Like
Yes, the alarm is triggered when we the motor current goes above the threshold which I think can still happen under any circumstances.
When the machine moves to a new location it uses two belts to pull itself there and the other two are slack. The thing is that one of those belts usually finishes pulling first (especially on sideways moves it seems like) which can lead to the second āpullingā belt going slack. Then when we start to take a measurement the opposing belt to the one which is a little slack pulls tight and the slack belt pulls really hard to fight it.
I think that might be what you are seeing. Itās only an issue in the horizontal mode I think.
The solution might be to automatically take up that slack a bit at the end of the move.
Updated to 0.66.9 and ran a 4 point calibration. The results were in line with what we were seeing before.
CLBM:[{bl:2295.11, br:2412.76, tr:2316.78, tl:2184.68},{bl:2032.89, br:2014.52, tr:2661.79, tl:2653.90},{bl:1215.83, br:3063.70, tr:3441.27, tl:1973.52},{bl:2139.56, br:3498.21, tr:2984.26, tl:1112.66},{bl:3403.12, br:2054.87, tr:1237.41, tl:2980.35},{bl:2964.41, br:1203.74, tr:2117.14, tl:3409.68},]
Fitness: 0.04677634341601715 in 2700 cycles
WARNING FITNESS TOO LOW. DO NOT USE THESE CALIBRATION VALUES!
Calibration complete
Calibration values:
Maslow_tlX: -40.0
Maslow_tlY: 2173.3
Maslow_trX: 3983.8
Maslow_trY: 2328.0
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 4014.6
Maslow_brY: 0.0
1 Like
How do the numbers produced line up with what you expect your frames measurements to be?
I think that your idea of maybe trying a different set of anchor points is a good idea.
Off, measuring it was 2700x3800 I believe. I did print 2 more anchors, but need to buy some construction adhesive. Itās also too cold here so need to get some propane. Earliest those will be good to go is tomorrow night.
1 Like
I might be getting my threads mixed up in my head, but did you have a chance to try doing extend all with
And comparing the measured values to the values printed in the console?
(Itās a slightly updated version of the one that I sent you before)
Yes I did, the bottom left was off on the first, but matched the second and third measure.
1 Like
Thatās right. Darn.
Iām putting all my eggs in the āthere is something weird about the anchor point spacing which is breaking the mathā basket. Itās an insane basket to bet on, but weāve eliminated everything else that I could think of.
I crunched the numbers on these and a couple of your other runs and I havenāt really learned anything 
It seems like the results get steadily worse the long that I run it which is unique, but I donāt totally understand what Iām looking at.
To try to understand better I plugged the numbers into OnShape as a CAD model and let it solve them. The first 3 sets of measurements give use the estimated values for the anchor point locations and then after that we can use the model to predict what some of the other values will be and compare them to our measured values.
On the left we have the measured values and on the right we have the values predicted by OnShape for those measurements.
1973.52 ā 1957.15
2984.26 ā 2977.68
1112.66 ā 1108.79
1237.41 ā 1237.85
2980.35 ā 2983.07
2117.14 ā 2107.84
3409.68 ā 3415.56
What did we learn? Not much. Just that some of them are pretty spot on and others are pretty far offā¦That doesnāt seem unreasonable given that the corner locations are only based on the first three sets of measurements which wonāt give us that good of an estimate.
There doesnāt seem to be much of a trendā¦ie they arenāt getting worse with time or something like that.
I drew the first 3 points in 3d in F360, assuming the anchor points are in the spoilboard plane, and the heights are my guesses of the heights of each arm. the last joint constraint would not fit, here was a dfference of about 16mm
The main objective of the callibration is getting to know where the anchorpoints are, relative to each other. What if we let the machine measure just that? In a routine like this:
retract all belts ā hook the machine on the BR anchor with the BR belt->extend the TL (opposite from the BR) belt so you can hook it onto the TR anchor ā let the machine take the slack and measure with a set tension ā repeat for the other two anchors ā repeat the whole thing starting from the TL anchor. This way the anchor points are known in 6 steps (or 5).
I realise this is a lot of work, and not the workflow that we are looking for in the future (especially as the M4 wants to fall off the frame), but for now, to know things for certain, this might help.
Good luck with the troubleshooting,
Arjen
1 Like