@Joshua I totally get where you are coming from. Would it be advantageous to provide a simplified configuration option that would automatically skip the steps that are accomplished by the prior version? To get from classic math to Holey math (from the end user’s perspective) we:
Drop the recording of the sled balance angle.
when do we record the sled balance angle?
Record the weight of the sled.
Cut and measure the 6 hole pattern.
As everything else stays(looks) the same, would it be worth while to detect
that the machine has been configured and only prompt for the missing pieces?
Then going forward there would be framework to do the same with each release.
If moving from 1.25 to 1.28 ask for sled weight and run the 6 hole, 1.28 to
1.29 no cal needed, 1.28 to 1.31 record elevation above sea level, etc.
Streamlining the process would increase adoption of new versions and therefor
reduce the need to maintain legacy compatibility.
this isn’t a bad option to have
but at least for the short term, I don’t think we should force people to switch
to the holey calibration. We need a timeframe where we offer it as an option,
because we think that it produces better results. Over time (as we gain
confidence) we can move from offering it to recommending it, and then later,
discourage the old calibration and make it the default, and even later think
about disabling the old way.
But right now it’s far too soon to force everyone to switch.
I think it’s too soon to force everyone to switch. This needs to be merged as an
option, but we don’t know for sure that this is always better, and having it in
will let us then do more experimentation.
I agree there is a cost, but if there are no updates to the old
calibration/kinematics the cost is very low (how much work are we spending
letting the quad kinematics remain in the code?)
making a separate branch increases the cost as that means that patches have to
be applied to both branches.
David Lang
P.S. the added factors in the kinematics are needed, the equasion solving method
of calibration seems to me to be the right way forward, but I think that there
is going to be room for some enhancements on the way we do the calibration
before things are finally settled.
For example, I’m thinking that instead of drilling the 6 holes and then trying
to measure between them, what if we put a pen/v-bit in the router and moved it
to ‘known’ places on the workpiece? I think this will be less accurate than good
measurements, but possibly more accurate than ‘average’ measurements.
I’m thinking something along the lines of
snap a string line corner to corner of the workpiece
use a drywall square to do a vertical line in the center and at an known
distance left/right of that
then horizontal(ish) lines connecting the points where the vertical and angled
lines meet.
move the sled to each point and record where it is (real world and calculated)
and solve the resulting equasions.
There is a file, RunHoleyCalibration.py, at the root level of the repository. It should be setup to drive the HoleyCalibration process without the GUI. It has M1-M12 measurements in it on lines 24 through 36.
The mesurements are differences between two marks on the tape-measure, in Inches. Line 37 is where the measurements are converted to mm, which are the units used by the Holey Calibration process.
I think I have holey calibration working in webcontrol but I don’t have a functioning maslow to test it out. Who is willing to give it a go? I had to push the firmware keys for the new holey calibration values out of range of my optical calibration firmware keys (no reasonable way to change the optical calibration values without a whole lot of new code work). So the firmware will be different than @joshua’s repo. But when I get it ready to test, I’ll have a compiled version of the firmware baked into the docker so it’ll be easy to update.
I can probably find some time to try in the next couple weeks! I’ve wanted to give it a go, but having to switch back and forth between WebControl and GroundControl gets annoying pretty fast.
Speaking of — @bar, @dlang and others: if I could package up WebControl so that it runs in an Electron.js desktop app would we consider replacing GroundControl all together? CNCjs does that for their desktop app. The 3d gcode visualizer alone I think makes it worth the switch.
I am thinking along similar lines, we would need to figure out the right
packaging. I’m not familiar with electron.js WC is written in python, why would
packaging it in electron be the right thing?
Support will be important. The calibration routines in GroundControl took a large amount of support in the first year, and continue to require a lot. Who will step up to provide this?
Electron.js is just the desktop web-app framework I’ve heard about the most. Possibly there are other ones that would be a better fit. You can run Python-backend web apps inside Electron.js from my understanding. Slack and Discord’s desktop apps are written in Electron.
Webcontrol has calibration in it. However, it doesn’t have that step-by-step wizard that I personally think really is the source of most of the problems… People either don’t read, don’t read closely, or misunderstand… nothing against the idea, but people get tripped up on it continually… and then it all goes wrong.
In Webcontrol, you measure the machine by hand (distance between motors, and height of motors above workarea and use those values in the “Quick Configure”. You then set sprockets to zero, extend chains (all from same page), attach sled, and start the calibration process… cut pattern, measure and enter values, hit calibrate.
The same people that help everyone else out with calibration.
But regardless of the above, I think if we can package it up into something like a desktop app, that’s a win. But maybe that discussion should be in its own thread
Related: I recently discovered that my meter stick and tape measure have a meaningful disagreement about the size of a mm, so I want to buy some better measuring equipment. I created a new thread to discuss what tape measures people recommend. I’d love input/recommendations from the experienced people here, since seems like to get the most out of HoleyCalibration, I should get my measurements as accurate as possible.
I just made a PR to the master branch of the firmware and I think your fork has ‘similar’ issues. Since I can’t make add an issue to your fork, I’m posting here. In the master branch, when chainsag and chain tolerance were being modified, the position of the sled wasn’t automatically updated. So when a move is made after making a big change, the delta from where the sled was to where the sled gets calculated to be at the first step of the move could exceed the position error limit (default 2.0 mm). This would then cause an alarm.
In your fork, you have used kinematics::recalculateGeometry, but all that does is recomputes the machine’s bedwidth and bedheight and a few variables used in quadrilateral. What should be called is kinematics::init. I’ve made that mistake a number of times (calling recomputeGeometry and not init). Init causes a kinematics::forward to occur and that then sets the position of the sled to agree with the new variables.
