What was the number in GC and the FW when you ran the cut?
Also, have you updated your FW and GC since the change to the Chain Tolerance calculation?
Here is the script to run it.
RunHoleyCalibration_jimr.py (1.0 KB)
Here are the results.
CalResults_jimr (2.6 KB)
I looked at the results. It looked like one measurement might have been off, because the calibration was 15 mm off on that measurement. It was the vertical measurement on the right side, from point 5 to point 6. I used the kinematics from before we inverted the chain-tolerance calculation. This is the revision.
Update
I have done some work in preparation of a pull request. Unfortunately, git is new to me, and it hasn’t been as easy as I would have liked. Apparently I created a new repository, rather than forked the MaslowCNC repositories, which has made it more difficult than if I had known what I was doing. Further, there were conflicts in the Firmware Kinematics.cpp file.
I have created two new repositories in github under my username:
They are currently only used for preparation of a pull-request. They have not been tested, and should only be used if you wish to be the first to test it. If you would like a more tested version, the links in this post, 176 are the ones to use.
At this point, all the conflicts have been handled, and a pull-request is possible. I would like to compile everything and run it before actually doing that. That will not happen this weekend or the next, since I will be going to see the in-laws next weekend.
4 Likes
In frame carpentry, this is called “burning an inch”
I would think this would only be relevant within a few inches of the pivot point, anything beyond will quickly approach a non measureable deviation.
@WoodCutter4, thanks for doing this.
Because there are 12 measurements and only 4 parameters, there is quite a bit of information in the errors within the calibration. You would expect for the benchmark cut to be similar to the calibrated errors in the 12 measurements. I would expect the benchmark errors to be around 1 mm, and that is statistically supported by the fact that there is more data (12 measurements) than is necessary (4 measurements). Because you are seeing a difference between the accuracy from the benchmark and the accuracy between the calibration leads me to believe the machine is calibrated differently from the calibration inputs (and therefore outputs).
I would guess there is something misaligned between your machine setup and your initial calibration definition within the RunHoleyCalibration.py script (cal.SP_D, cal.SP_motorOffsetY, cal.SP_rotationDiskRadius, cal.SP_sledWeight, cal.SP_leftChainTolerance, cal.SP_rightChainTolerance, cal.SP_chainOverSprocket). The machine calibration in the RunHoleyCalibration.py script needs to match the calibration in Ground Control when the cut was run. You need to manage that yourself. To make it more confusing, the Firmware doesn’t always sync with the Ground Control settings when you think it should.
So, there are several things that we can do. First, could you explain what you entered into the initial machine parameters in the RunHoleyCalibration.py script? What were the machine parameters when you ran the calibration cut? Is there any possibility the Firmware didn’t sync with Ground Control before running the calibration cut?
If you are confident in all those numbers, then we’ll just have to wait for the GUI implementation. This should reduce the potential for differences between the Firmware and Ground Control.
Hey @Joshua I’m happy to offer my services as Git wrangler if that’d be helpful 
Shoot me a message if there are any questions you have or if there’s anything you need assistance with
2 Likes
Thanks for the offer 
. I think I have mostly worked through my git issues. I now have exercised git commands from the terminal on my Ubuntu machine, merged all the conflicts, and pushed the changes back to a legitimate fork on GitHub. Ideally, the only thing I need to do is validate the functionality. If nothing goes wrong, I can create the pull-request, which I now know how to do.
What GUI do you recommend for git on Ubuntu? I used ‘gitg’, but the functionality was sparse. Also, I used ‘kdiff3’ to merge the conflicts, but it wasn’t great.
1 Like
I can’t make any recommendations as I’ve only used the command line tool
I tried gitkraken, but the learning curve is to steep for an old man like me. It looks cool though.
1 Like
Any idea when/if this will be implemented into the main stream?
1 Like
My guess is that the more testers with positive feedback, the faster a pull-request can be generated. 
(hoping to try this weekend but i’m planing that for weeks 
)
I’d like to try it too. A walkthrough of installation and setup would be nice though!
1 Like
It’s allot to read though and get the pieces together, i agree, if i manage i will share.
1 Like
thank you!
Last weekend, I reflashed the Firmware and updated to the latest Ground Control. I have received feedback from @jimr about issues related to pushing the calibration to the machine. I tried to reproduce those issues, and was able to reproduce them. However, the issues are not specifically related to Holey Calibration. They are, instead, part of the core of the Firmware and Ground Control.
Right now, I am torn between how to address all the issues, and how those issues should be prioritized Holey Calibration developments. Because the issues seem to be very distributed in nature, and it might take a long time to fix them, I am thinking I should just ignore them for now, and finish Holey Calibration. After that, I could re-evaluate my ambitions and determine if I want to take on any additional work.
2 Likes
My vote is to get it out then squash the bugs. If its in more hands you can get more feedback. Is the plan to integrate it into the main stream to simplify installation? maybe it can be in the main branch and have a checkbox in advanced settings if your worried about it not working properly for some ppl or disrupting ppl that have they’re setup already tuned.
3 Likes
Right now, it is a selectable option. That is how it is integrated. There is very little risk, outside of the Firmware Kinematics calculations.
It is available. You can download and use it if you wish. Again, I haven’t actually gone through the calibration process with these specific revisions.
- Firmware: https://github.com/schmittjoshc/Firmware
- Ground Control: https://github.com/schmittjoshc/GroundControl
1 Like
So I can install the GC and firmware from those links and its in there!? Awsome! I bought the blue smoke when it came out this will work as well, correct?
2 Likes
It should work.
Hi Joshua
I make a product with 10 base pieces. The 10 parts have multiples, i.e. Part 1 is six total. I use a 48by 48 sheet for ease of carry. Here r issues i have after multiple holey calibrations:
First cutting 2 part 1s per sheet parts are different as much as3/4 inch. I cut 6 part 1s on 3 sheets.parts r same based on position On sheet.
SEcond, parts cut On top of sheet r thinner by3/4 inch. Ie, same part, a horizontal placement cut on lower 2/3 of sheet vs part cut at to top of sheet is fullsize.whereas part cut at top is thinner.
Third, my product uses multiple glue ups of same parts. One case I glue 10 identical parts together. Doing this right is hard. I put Dowell holes in parts to make easier. However, the Dowell holes do not line up on parts needed to be put to gether. Off by 1/8 or more.
I run a smallbiz and run mazlow up to 6 hrs per day. Perhaps I demand too much from the mazlow, which I now describe as a hobbyist tool.
Pls suggest fixes i f possible. Thxjr