Holey Triangular Calibration

Technical Details
301

Update

I have been working on this for a while, and I thought an update is in order.

@jimr had some difficulty when he tried to do this, where he got the message “Please reset the chain-lengths”. I was able re-produce this issue, and came up with a multitude of potential root-causes.

  • First issue: the Firmware does not support the use of scientific notation for the calibration parameters. However, GC produces values in scientific notation for large or small numbers. The Firmware uses the NutsAndBolts.cpp, readFloat function. There is an alternative, String.toFloat, which does support scientific notation, and is used elsewhere in the Firmware to parse the gcode. The use of readFloat (no support for scientific notation) vs. String.toFloat (support for scientific notation) is inconsistent within the Firmware.
  • Second issue: the message, “Unable to find valid machine position for chain lengths …”, which pops up, does not provide sufficient information to debug whatever problem that caused the system to fail to converge. In my case, the Advanced Settings Chain Length was set to something like 177 mm. Because this was so short, every time I updated the calibration, I got this message. There was no information that the System Settings Chain Length was so short. I have updated this to report a diagnostics message with more resolution.
  • Third issue: the parameter values in GC don’t always align with the parameter values in the Firmware. This is a problem in the procedure that is executed when GC connects with the Firmware.
    When a connection is established between GC and the Firmware, GC requests all the parameters to be reported from the Firmware. The Firmware then communicates the values to GC. However, when GC receives these parameter values, if there is a difference between a parameter value in GC and the Firmware, GC writes it back to the Firmware; no change in GC and no change in the Firmware. So, the Firmware parameter value gets updated to the same value it was, and the value in GC is unchanged. This makes no sense, and is likely not the intended modus operandi. This particularly makes things difficult when debugging issues, because the parameter values you see in GC are not necessarily the parameter values that are in the Firmware. There really aren’t any other times when the parameter values attempt to sync between GC and the Firmware, so this can go on for a long time.
  • Fourth, the function, Kinematics::forward always makes a call to the function, Kinetics._verifyValidTarget. This is unnecessary diagnostics, and is a nuisance. I changed this in my Holey Calibration clone, and asked to update it in this thread. I think this is OK to make this change, and should make it into the main software at some point.

I believe I have fixed these two.

I have not yet fixed this one.

Next Steps:

  • Commit changes to the GitHub Firmware branch.
    • More diagnostics information related to “Unable to find valid machine position for chain lengths …” error message
  • Add Sled Weight somewhere into the calibration process

Not Planning to Do:

  • Address all the issues related to syncing the parameters between GC and the Firmware. I don’t see this as a huge activity, but I don’t see it as necessary to make Holey Calibration functional. Just know that the functionality to sync GC parameter values with the Firmware does not work. It doesn’t work in the Main Fork or the Holey Calibration fork. So, be skeptical. The best way to check this is, in GC, change the parameter value, and then change it back.
2 Likes