note that if the maslow thinks distances are X and your tape measure says they are Y, the maslow is correct (at least as far as getting good cuts are concerned)
since the current calibration gives different coordinates on different runs of up to a couple of mm, that seems in the same ballpark as the errors of manually reading a tape measure, so I threw together this onshape doc that lets you enter measurements and it shows the frame and calculates the coordinates.
I have you measure both diagonals, and if the measured diagonal and calculated diagonal are not really close to each other (within a couple mm) then you should re-measure until you find what you did wrong. sorry I haven’t been able to make it something you can cut-n-paste directly.
when you open the doc, hit top on the cube in the top right to re-orient the image so you are seeing it square
If you are looking for more accurate measurements, I’ve updated the tape measure vernier to have a hook to go over anchor pins/bolts
remember, tape measures are not perfect, since 2020, the EU changed their classification system
class 1 ±1.1mm/10m
class 2 ±2.3mm/10m
class 3 ±4.6mm/10m
(prior to that there was a more complex system that had both a fixed and a per meter error restriction) so even if the vernier says you are getting to 0.01mm, you still have the error up to the class rating as well
could people with good calibration results please measure their frames and enter the numbers into this and report how the results of this compare to what the automated calibration had figured out?
rather than trying to measure the center of a hole, I would suggest putting a hex bolt in each anchor and measuring from the flat of one hex bolt to the near flat of the other one.
I’d like to avoid anything based on asking folks to take measurements. We went down that road on the first Maslow and it never really worked well, but lead to a lot of support emails.
I fully support this existing for experimentation, but I don’t think that we should integrate it into the main UI. I’d really like to work towards less user input not more during the calibration process. Ideally there would just be a “Calibrate” button and it would take no user input at all and figure everything out.
If calibration was working more reliably, I’d agree with your. But given the
problems that we are having, I think we need to provide the manual option while
we continue to work on the automatic one.
would it make sense to combine the two? if someone does the manual version, then
spot check a couple places to validate that the result is reasonable?
I would be of the mind to have a manual option accessible, but out of the way.
I would think that having this accessible, but out of the way and postured to not look like a part of the normal process, would give people more options when it comes to troubleshooting without introducing potential hiccups in the ideal process that users are guided through by UX.
I’ve noticed some similar pushback on being worried that other things that would be helpful when used judiciously could cause problems for some users:
For instance, there are commands for manually moving the belts, but they are only commands and you’re avoiding making UI for it because you don’t want people to accidentally use those commands at a bad time. These would be much easier to use when there are issues if there was UI, and it would be hard to accidentally click on them if you had to do something like when you click “alarm” before you’re able to adjust Z, etc., that opens a menu with them in it. Users also wouldn’t have to use a terminal command to get their belts out of their gears when they are stuck, which would just be seen as furthering the annoyance they are already dealing with.
Also the request for being able to save location data across power cycles (only problematic if the sled is left suspended on the belts instead of affixed to the work surface). It would just be a matter of having proper warnings and lockouts that make the user confirm that it was secured and didn’t move. This would save me 4-5 minutes of set up time with the machine every time I go to use it, which is not insignificant and has already added up to over an hour and a half (for just me alone) that would have been saved since I’ve assembled my unit and first brought it up.
Having an “advanced” section in config and settings is a pretty common practice for “use at your own risk” options, feels like the same mentality could apply, here.
I think that most of the problems we are having are with the steps where we ask for input
I’d like to get away from asking for the rough frame dimensions and the horizontal vs vertical and I think that would make things go much smoother.
sounds good. I’ve suggested elsewhere how to detect vertical vs horizontal.
As far as frame dimensions go. If you stop having extend-all tied to the
existing frame size and instead just allow people to pull belts until they stop
pulling (including having the belt retract) you can eliminate asking for the
frame size first. Then retract the belts and adjust them to make all belts be
the same length (or close to it) to find the center.
I’m still not 100% sure what the workflow looks like in my head. It’s kind of nice having a clear amount to pull out and in the case of a vertical frame we need to stop extending the belts before it can be hung up so that’s going to require some thinking through how that works.
@bar@ronlawrence3
I think we need to start an experimental branch that has weekly releases to keep it up to date with the main version.
I can understand Bar not wanting to put confusing/risky things in the main branch. He is concerned that opensource has a way of adding too many feature flags and that ends up confusing users. He’s not completely wrong, but in order to have a feature tested widely, it needs to be available to test.
We have a lot of ideas out there, many with code (or could have code if there was a chance of them being accepted), and while individuals can release firmware versions, unless we keep them up to date with other changes, they quickly vanish from usability (see the frame flex test for example), so I think we need a place to put things that we don’t want in the main release (at least not yet) but where the firmware is kept up to date with the current main updates.
I also think that it would be better to have the main firmware and an experimental version released weekly by Bar rather than having the Bar firmware, the dlang firmware, the ronlawrence3 firmware, etc.
In terms of effort, it should be fairly simple to have a stack of patches that get rebased on the main branch every week.
Features so far for the experimental branch
code exists:
frame flex testing
make arm lengths configurable rather than hard-coded
allow for belt extensions (also supports putting stop clamps on belts to be able to fully retract belts but still remain attached to anchors)
code exists except for UI:
manual calibration
UI options to control each belt manually (stop, feed out, feed in, comply, retract-and-zero)
code does not yet exist, but could be created pretty trivially.
slightly modified kinematics (spools at corner of sled rather than around center)
other ideas to consider
different calibration options
As an example, use the maslow to measure the distances between anchors, either via opposite belts, or by chucking a pin in the router that you put in one anchor and extend a belt to the other anchors (may require a belt extension), then use the manual calibration math to compute the corners
I’m happy for us to have a place to sandbox ideas that are potentially not even going to see the light of day. I do this on my own fork to learn the codebase and try new things.
Also, speaking for myself my spurts of contributions will probably be sporadic, so committing to a weekly cadence of changes is definitely unlikely for me. For instance, I try to keep that calibration experiment up to date with the UI calibration, but its a “when I think of it” kind of thing.
That said, I’m happy to contribute what I can when I can. To be totally up-front about my priorities, I will probably focus on things that I’m seeing I am either in need of for my personal use cases or that are real stumbling blocks for people in the forums.
I absolutely had better luck with my manual measurements of my frame using your 6 measurement technique than the calibration routine has come up with, so while I might agree with Bar that I don’t think will end up wanting to rely on users measuring things in the public release, it seems useful today to have access to, and if we can keep that branch up to date with Maslow-Main over time, then I think that is a great idea.
Machine telemetry - I don’t mean in terms of sending data anywhere as this word is sometimes used, but more like spacecraft telemetry… recording machine data to a file on the SD that can be used by “us” in instances of failures to gather data about what was happening.
