the problem is that once you change the calibration correction values, 1651mm of
chain is not an integer number of teeth.
the problem is that once you change the calibration correction values, 1651mm of
But it needs to be…
if one chain is 6.35mm per link and the other is 6.3501mm per link, they can’t
both extend to 1651mm with an integer number of tooth moves.
add in chain sag, which varies based on the amount of chain fed, and the tension
on the chain and it’s even uglier.
This is why I say that fixing this would require some deep changes in the
IMHO, this would be
- track position by encoder steps, not mm
1b. this requires a lot of conversion from mm to encoder position
add B commands that move by encoder steps (the current ones move by mm)
change the ‘home’/‘chain reset’ position to allow for different lengths of
chain on each side
change the initial ‘extend chains’ step in calibration to instead be
‘feed/retract 1 tooth from each side’ (with the option to just feed/retract 1
tooth from one side) repeatedly, even if this means that the resulting sled
position is not exactly in the center)
Here is a link to the post I mentioned before:
That makes sense. Gcode is in mm though, so it must be converted whether it is done at the chain or at the encoder. I guess my point is that the conversion location in firmware can be moved, but it still has to take place. It remains unclear to me if that conversion would be more accurate if it were moved.
Ok, so my takeaway here is that this is a known problem but everyone has this problem and apparently has had it from the very beginning. The root cause has been determined but implementing the fix is the next hurdle. In the meantime, it doesn’t appear to cause any noticeable accuracy issues possibly owing to a relatively sophisticated calibration routine. It does present a problem when resetting chains however.
So reset your chains before you calibrate
The trick is that for positioning the ‘reset chains’ point, we want to
move/define the location in terms of encoder steps and then record the mm
position that this ends up in.
with the current system, we move in mm and don’t know where we will end up in
encoder steps (and therefor sprocket position)
I could be having tunnel vision here and be missing something, but at the very
least, the default 1651mm clain length will have to be broken up into separate
left and right chain lengths to ccount for differences in the chains
the process of calibration will change the effective chain lengths for the same
in practice, this is something people just live with and ignore.
an error of 5 degrees in the sprocket translates to 0.88mm in chain length,
which can be up to 2mm of position (worst cases)
Ok this makes more sense. The makerverse calibration routine gets more attractive to me now because it addresses these or attempts to works around them. Does the cain length extension take into account that we use the second to the last pin on the chain to attach rather than the last one?
All, just an update. I have now performed the extend chains exercise 10 times this morning. In all instances, my sprockets are returning to the 12 o’clock position. I’ve verified through measurment that the chains are indeed extending 6.35 mm per revolution and 1651 mm +/- .25mm per extension exercise. In other words, this problem isnt a problem for me anymore.
Prior to this mornings testing (where I obtained the above results). I did notice that Web Control was spiking my CPU usage to 98%. I have an RPI-4 with 8GB memory. I’m running it headless, with RPIOS Lite. It is a pure web server. The only change I made was to Settings->WebControl Settings-> Computed Sled Position. This had been enabled for some reason. I disabled it and load dropped to 24%.
After that I did my testing and obtained the above results. It looks like my “problem” has been resolved. Not sure if RPI load should affect the arduino operation, the code is a black box to me. I just wanted to report the only variable I changed.
I ran Holey Calibration five (5) times. My first calibration error was around 1.35. the latest one was 1.19. I’m not sure what the units are but I assume its %. Also, where does this number compare to the expected? How does it compare to others?
Thanks for sharing.
I have been operation under the understanding that less than 3 was really good and that was based on an earlier forum discussion. Obviously lower is better, so congrats on a good calibration. At some point the uncertainty in measurement becomes more of the issue.
I admit I don’t pay close attention to things here, so maybe I am mis-interpreting things. But I saw what look like a bunch of wrong assumptions that should clear up.
If you are talking about the Maslow Firmware, it most certainly tracks and saves the axis position using integer encoder steps. See Settings.cpp:148
If this is still done using the same method originally designed in the firmware, B08, they will always return to the exact same encoder position. The underlying function does not use any chain stretch or adjustments here, it just converts the originalChainLength in mm from Settings to encoder steps. See Gcode.cpp:218
Again, as long as whatever front end you are using is still using command B08, there is no error introduced.
Your issue does sound like it was related to this problem. It was only an appearance issue, the firmware still accurately tracked the encoder counts, it just failed to use the brakes to stop at the correct position. This pull request fixes that, if it was merged into the firmware you are using you won’t see that issue anymore. Fix Error in Calibrate Chain Lengths Function. by krkeegan · Pull Request #8 · WebControlCNC/Firmware · GitHub
Anyways, good luck everyone, sorry if I misunderstood anything.
krkeegan , Thanks for the clarifications.
Orob , That makes sense. For reference I am using a 1/16" mortising bit in my router to make as small of a hole as possible. I’m using a Starret mm scaled, steel measuring tape, recently lab calibrated. It’s as accurate and reasonable a measuring device as can be used for this. However, you are correct. I am still having to eyeball the centers of the holes. I am also having to eyeball 10th’s of a mm in my measurments. The end result is diminishing returns on successive calibrations.
For example, I am currently stuck in a loop of achieving .65 and .45 calibration errors between Holey calibration exercises. I don’t think I’m going to be able to get much more of an improvement using these measuring methods. Besides, I noticed my top beam flexing by a couple of mm’s which may be introducing some more error.
you may want to take a look at the vernier measurement approach I talked about
note that the design goal of the machine was toget to ~0.5mm so you are close to
the limit (also look up the ‘sources of errors’ thread about all the possible
things that could contribute to the errors)
right now, you are at the limit of what that calibration method can do, that
doesn’t mean you are going to be that accurate everywhere, so if it really
matters, do a test cut and check the results.
dlang , Thanks for the suggestions. Your scale idea is a good one, someone should run with it. My only thought is to make it a holder that the user can clamp an actual vernier scale ruler into rather than try to make the scale a part of the tool. You can eliminate the inacuracy introduced by the 3d printing.
FYI, I ran three more calibration cycles. This time I picked the dimensions using the hole edges and not trying to estimate the centers. This made a noticeable difference. My last run resulted in an error of .1288. Like you said though, I need to move on to test cuts at this point. I’m going to have to stiffen the beam and re-run the calibration again anyway so everything done so far is a wash.
Thanks again for the input.
I got the idea from an image someone posted that took a traditional vernier
caliper, removed the moving jaw and used a tape measure of the same width.
the advantage of the 3d printed part is that it includes a post to put in the
hole, so there is no estimating the center of the hole.
I had a set printed on a resin printer, and they didn’t clear the liquid out of
the slots before curing it, so that didn’t work well. But I think that resin
printed parts have pretty good dimensional accuracy.
when trying to measure to the edge of the hole, put a snug fitting pin in the
hole and measure against that.
All, as my original problem hasn’t re-occurred im going to assume that it is no longer one. I have done many extend chains since and have not seen this issue occur again. It sounds like maybe the brakes needed some exercising before they could fully do their job. The motors im using are new and haven’t really been broken in yet. Thanks everyone for your help.