I am doing some work on Holey Calibration, which will hopefully be an update to how the calibration routine. One issue that has come up, which I do not believe to be isolated to Holey Calibration, is when Firmware cannot perform a Kinematics::forward calculation.
The Kinematics::forward is a function in the Firmware that is numeric and iterative. The Kinematics::_verifyValidTarget function checks if the position is on the worksurface, and if not, replaces it with a point that is on the worksurface. Because of this, the Kinematics::forward function will not converge when it calculates a position that is off the worksurface, and an error is issued.
The calibration parameters are written to the Firmware one parameter at a time. The intermediate-state that is present in the Firmware before all the parameters have been written can result in a position that is not on the worksurface, even if the full calibration is valid. This can cause a failure with valid calibration parameters.
I would like to change the code such that Kinematics::_verifyValidTarget is not called from Kinematics::forward. Which will enable the Kinematics::forward function to converge when the position is not on the worksurface.
I want to ask the question: is there any reason to not do this?
The purpose of Kinematics::_verifyValidTarget within the Kinematics.inverse function is to prevent the system from commanding a position which causes the sled to fall off the worksurface. It is a diagnostics check. However, I cannot think of a reason it needs to be called from the Kinematics::forward function.
Seems logical to conclude it’s not needed to me as well, but under what situation does this come up? Is this an issue only during calibration? I wouldn’t think it would happen under normal circumstances since the verifyValidTarget check should keep the sled from moving outside the valid range.
I believe it to only come into play when the calibration is syncing with the Firmware. During this transition phase, there is the potential to have a “mixed” calibration, which is part old and part new. It is also possible to have a “mixed” calibration that is part new and part default.
Yes, I agree with that assessment. I think its more of a nuisance error in that situation, but again, I tend to agree there’s no need to check for valid target on forwards.
It’s also a bit of a safety thing. Without checking to see if the machine is within the work surface we were having issues where people would accidentally tell their machines to move “up 100 inches” or open a mm gcode file in inches, and then the whole machine would tear itself apart.
I don’t know that we need to call it there, but I think we do want to keep a safety check to make sure we don’t leave the work area
I agree that we need to have limits, but I don’t think they should be in the
kinematics functions, they should be in the g-code interpretation sections.
If someone is manually manipulating the chain lengths (or manually running the
motors), you are in expert mode and should not do any checks.
during calibration, we should not be doing these checks.
Thanks everyone for the input. I think the proposal of removing it from the Kinematics::forward function does not conflict with any of the stated needs.
The Kinematics::forward function is the function which translates chain-lengths into an x,y coordinate. This is actually hardly ever used in the Firmware, except when changing the calibration. Therefore, it shouldn’t impact the diagnostics functionality as mentioned by @bar. The limits will still be in place.