I knew of chain wrap before posting. That was addressed mechanically in parallelogram chain by using fixed sprockets on the sled instead of point mounts so that wind/unwind would cancel eliminating that error. Chain sag is another issue I was already aware of. https://github.com/MaslowCNC/Firmware/pull/369 Variable chain tension requiring varying current for same speed is yet another. Fun with Numbers - Calculating Motor Load Force Also, play in the chain links accumulates for long chains. Are there others?
The thing that all of these sources of error have in common is that
- They are each in their own right systematic and computationally expensive to model and compensate with an inverse model.
- Because the magnitude and sign of each error source (along the chain vectors) can ultimately be expressed as a function of position, they can all be combined and eliminated together using a robust (enhanced tbd)calibration routine and a precomputed lookup table(s) of correction values for each position.
There is no need to model each minor systematic effect, just observe the combined effect once, at grid locations, during (enhanced tbd)calibration, then each time a move starts in one of those grid squares, apply the appropriate correction.
leftChainLength = computeLeftHypotenuse(commandedX, commandedY);
rightChainLength = computeRightHypotenuse(commandedX, commandedY);
leftChainLength += errorCorrectLeft(commandedX, commandedY);
rightChainLength += errorCorrectRight(commandedX, commandedY);
In order to always be applying the best correction, any moves larger than 1 grid square should be broken into smaller moves. Off the top of my head a grid pitch near 7" sounds about right so that a 6" test square can be cut with only a single correction factor.
Non systematic error sources like linkage slop, loose motor mounts , will not be affected by this approach. The (enhanced tbd)calibration routine could be a IR led, or retroreflector mounted on top of the router over the bit, watched by webcam using machine vision techniques. Or it could use the method I described previously, or they could be combined.
To be clear, these techniques are NOT intended for immediate implementation. This is a pie in the sky wishlist that might go towards creating a requirements specification for a hypothetical future major version.
As such, objections such as “no time”, “too much work”, “that is not how it currently works”, “you aren’t qualified” do not apply.
Objections that Do apply are “We tried X once, but reverted because of Y”, or “We considered X, but chose Y because …”, also “X wont work because of Y.” Preferably Y comes with a link or explanation.
Are there any existing software requirement specification documents? If so, that could serve as the high level overview I have been after.