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.
EDIT #1:
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?
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.
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.
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.
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.