Markus wrote:
Calibration Grid (work area) is 1200mm x 1000mm9x9 points
can you tell us about your frame and anchors? a fitness of 3 is fantastic if it
holds up for a full calibration.
David Lang
@bar I just noticed that the center point deviation calculations do not use the new measurementToXYPlane() function, so I created a PR to have them do so.
1 Like
created PR to allow for calibration to take place without Z all the way down
note that I have installed platformIO so I now can say that these compile, but I don’t have a setup to test them. This is one reason I am sticking to small, “obviously correct” changes 
1 Like
@bar looking in MotorUnit.h I see the line
double _mmPerRevolution = 43.975; //If the amount of belt extended is too long, this number needs to be bigger
This seems incorrect to me, one revolution of the encoder is an integer number of teeth, whatever the diameter is, it’s always going to end with the teeth in the same position.
now, the difference between 44 and 43.975 is not much ~0.057% but it seems like a mistake.
It may be that we need to add a belt stretch factor in, but it would be better to do that separately (and it may need to scale both on the amount of belt fed out and on the belt tension)
1 Like
I think I’m seeing an inconsistancy with position recording (x/y position and belth length/encoder readings), it seems like sometimes float is used and sometimes double is used. Am I mistaken? is there no difference on this chip (if so, I think we still should be consistent)
when saving the Z position, there is a line that says
if (ret == ESP_ERR_NVS_NOT_FOUND || currentZPos != fi.i) { // Only write if the value has changed
this seems wrong, why are you saving only if there is an error rather than if it reports ok?
edit, never mind, this is saying save if there isn’t a value there or if it has changed, it’s the key not found, not the storage not found.
1 Like
1 Like
are the belt anchors raised or at the back of the wasteboard? (it looks like they are raised)
Assuming that the fitness score stands up after the full calibration, can you do some accuracy testing for us? That is a very stiff frame, so it’s very possible that you now have the most accurate maslow 4 yet built 
1 Like
I made a stab at making the maslow save the belt lengths while idle (to avoid the rehang dance), the PR is
this will conflict with the work that @md8n submitted in PR# 163, but it should be straightforward to change this code to match his improvements once they are accepted.
2 Likes
And I haven’t finished the other half of that work yet - which is in ESP3D-WebUI
1 Like
This is intensional, the tooth spacing on the belt is in theory exactly 2mm so for 22 teeth we should move exactly 44mm, but weve found that in practice 43.975 is actually more precise
Bar wrote:
This is intensional, the tooth spacing on the belt is in theory exactly 2mm so for 22 teeth we should move exactly 44mm, but weve found that in practice 43.975 is actually more precise
This difference seems similar to the scaling factor that was mentioned by a
tester above
does this vary from belt to belt?
David Lang
1 Like
It seems quite consistent, but since that number is found experimentally we should probably test again after making changes to the calibration process
Would this behavior impact the ability to jog to very specific reference location for the purpose aligning to a workpeice feature where you would want to set the origin at a new location accurately?
Does not work at all for me. I get 15mm error after calibration. I am using the JST connector encoders. Not sure if this is the problem or not as I have not tried any other firmware.
Have tried calibrating twice with the same result.
Totally. Frustrated.
1 Like
Check the video I posted earlier in this thread, it only dips like 1-2mm maybe. You should be fine.
1 Like
I should say, calibration is fine with fitness around .5. But it seems the machine cant cut any gcode. Ive done this dance a few times with the @dlang’s branch and the 0.85 firmware.im super confused because i thought 15mm errors were typically associated with encoder read failure, but I have the JST connectors
This is actually a different error message that also has the number 15 in it. I will change that one to 12mm now to avoid the confusion.
That error message indicates that there is something funky with the calibration values. Basically when you press “Apply Tension” the machine takes a single measurement and checks to see if that measurement aligns with it’s past calibration.
What it’s telling you there is that the measurement it just took doesn’t match up with the values stored from calibration.
To make sure I am being clear, the error occurs during a job. The machine starts barfing out error messages when moving to the start of a cut before semi crashing at the first plunge. I say semi crash because the UI shows the machine moving still along the cut path, and the z axis continues to go up and down whilst the sled remains static.
Do you have any suggestions for a path forward? The old hardware did not have this issue on the same frame, but I had not tried the 0.85 firmware with it. Ive run calibration many times with the same results on the JST encoder hardware and 0.85 firmware. I could try an earlier revision of firmware perhaps?
1 Like
Trying an earlier version of the firmware is a great idea, although I just tested the latest firmware here and I couldn’t get that issue to happen which to me points to something hardware specific.
I think that the first thing that I would try is to unplug and re-plug the encoder wires on both ends. That comes to mind because in the past issues like this were encoder wire related so that’s the place it seems logical to start.