After taking 12 precise triple-checked measurements in mm, i realized that they are entered in inch.
Can someone please decode this for me ( RunHoleyCalibration.py line 25)
(47.+5./8.)-(9.+11./16.)
2 Likes
It is a measurement in inches. It is the 2nd position on the tape, minus the 1st.
Also, today, I just finished some work debugging the GUI update. I was able to go through the calibration within the GUI. You might want to give that a try. It is in a different repository.
- Ground Control: https://github.com/schmittjoshc/GroundControl
- Firmware: https://github.com/schmittjoshc/Firmware
2 Likes
I’m not well versed in github and I’m trying to understand what “base” code (“tree”?) you used for each repository. I looked through the readme files but didn’t see anything pertaining to where the code was forked from, although I’m probably looking in the wrong place. This latest GUI work; what “version” FW and GC was it built off of?
I appreciate your time and good work.
1 Like
Ok, think I got it. So entering a number like 38.0315 (966mm in inch) would also work, right?
confirming that these are still the latest instructions Holey Triangular Calibration
could you edit the first post and put a link to them? (and then update the link if the instructions change)
There is quite a bit of information I haven’t provided. I will do my best.
This was confusing for me, as well. So, when I originally created the Ground Control and Firmware branches, I did something wrong; they were not real forks in GitHub. Because of this mistake, when I tried to create a test pull-request, I couldn’t. To correct this, I had to go through this whole thing, where I re-forked (correctly, this time) GC and the Firmware, and then merged from my incorrectly forked repos, into the correctly forked repos.
Yeah. It is just the measurement. It is a list of measurements, 1 through 12.
Yeah. I can do this, at some point. However, (tagging @Gero so he reads it) I realized the home position dropped significantly (1500 mm) when I finished the (new version of the) calibration process. So, there may still be an issue that needs to be resolved. This is just an FYI.
1 Like
Looks like i got good calibrated for my first attempt.
The point that stopped me was that i’m counting 11 here in py /GroundControlUpdate
Edit 1: 
wait for edit 2
“Do not drink and script!” - Linus Torvalds
2 Likes
Right. That is a good observation. The 12th one is different because it is measured to the top of the work piece. The top of the work piece does not have a hole number. That measurement is done after, on the Measurements.append(… line, that is after the loop.
I was on the wrong py-script
Optimized Errors
Index : 0
Points Span : 1 to 2
Measured Distance : 966.0001
Calibrated Distance: 932.782509423
Distance Error : 33.2175905772
Index : 1
Points Span : 2 to 3
Measured Distance : 964.99934
Calibrated Distance: 973.454454822
Distance Error : -8.45511482166
Index : 2
Points Span : 4 to 5
Measured Distance : 964.00112
Calibrated Distance: 932.528364597
Distance Error : 31.4727554027
Index : 3
Points Span : 5 to 6
Measured Distance : 963.00036
Calibrated Distance: 970.275709594
Distance Error : -7.27534959424
Index : 4
Points Span : 1 to 4
Measured Distance : 964.00112
Calibrated Distance: 805.511920922
Distance Error : 158.489199078
Index : 5
Points Span : 2 to 5
Measured Distance : 710.00112
Calibrated Distance: 772.134944167
Distance Error : -62.1338241667
Index : 6
Points Span : 3 to 6
Measured Distance : 710.00112
Calibrated Distance: 710.276626635
Distance Error : -0.275506634913
Index : 7
Points Span : 2 to 4
Measured Distance : 1197.0004
Calibrated Distance: 1192.07081007
Distance Error : 4.9295899298
Index : 8
Points Span : 1 to 5
Measured Distance : 1200.00014
Calibrated Distance: 1250.03420628
Distance Error : -50.0340662797
Index : 9
Points Span : 3 to 5
Measured Distance : 1197.99862
Calibrated Distance: 1165.37957551
Distance Error : 32.6190444899
Index : 10
Points Span : 2 to 6
Measured Distance : 1195.63896
Calibrated Distance: 1275.84908375
Distance Error : -80.2101237466
Distance Between Motors:
3621.28354785
Motor Y Offset:
431.936559116
Left Chain Tolerance:
4.5884952892
Right Chain Tolerance:
-2.77555229331
Something wrong here, will try fresh 
1 Like
Yeah. Something seems off.
- I would look at Measurement 1-4. It is 964, but it should be more around 710, like 5 and 6.
1 Like
Fixed it and it worked! Thanks so much. Cutting need to wait 
2 Likes
Observations for the GUI version:
- sled weight is not asked
motorspacingx = 3495.27578505
motoroffsety = 531.923557145
triggers
Message: Unable to find valid machine position for chain lengths 2032.00, 2032.00 . Please set the chains to a known length (Actions → Set Chain Lengths)
Solved by setting:
motorspacingx = 3495.28
motoroffsety = 531.92
-
error report for an image in the terminal when reaching this page
-
strange images and no descriptive text (thank for the metric, a hint would be nice, although turns red when trying inch) on this page
1 Like
I can see in the repo, in GitHub, that image is present. I am trying to think of some potential root-causes.
- Maybe you cloned from a different repository than me. Could you provide the url of the repository you cloned?
This one is consistent with what I get much of the time. I am pretty sure I know the root-cause. I it is because the _verifyValidTarget doesn’t let a kinematics::forward result in a number that is off the board. Once all the calibration parameters are written to the Arduino, this error goes away. I propose we bypass the _verifyValidTarget diagnostics step when doing the kinematics::forward calculation. What are your thoughts about that?
I was unaware of this. I would like to check if this works for me, too.
Yeah. That one needs to be fixed.
1 Like
1 Like
I had to create a new fork, to enable the eventual pull-request.
In terms of the GUI implementation, the most up-to-date one is here (Note the missing “Update”. Not GroundControlUpdate):
2 Likes
I believe to have done 2 (GUI / non-GUI) out of 3?
I am reading incredible results in the Forum and always behind, but think it deserves:
-
- a updated place in the WIKI to follow
-
- a place for the brave to report back
4 Likes
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
I’m looking to use the WebControl interface, is it possible to use this with the
holey triangular firmware? (assuming I use the external program to do the
calibration)?
David Lang
2 Likes
That is a question to ask @madgrizzle. I have attempted to write this in such a way that it can be easily ported over to a different GUI; I minimized the amount of content that is specific to Kivy. So, the only content that needs to be reproduced is the GUI part.
I think so. I don’t think @madgrizzle has changed the Firmware. We’d have to check. The changes I have made should merge into any branch, as long as they are not too different.
yeah. this is always an option. Even without a GUI, you can use the script to run the calibration.
1 Like
Webcontrol can be made to work with whatever. It supports stock firmware as well as mine with optical calibration support. Im confident it can be made to work with holey calibration firmware.
5 Likes