This for sure looks like there is something off in the calibration results. Basically it’s not getting a good reading on on the anchor point locations.
We came up with a series of tests to try to figure out what is going on here basically by running calibration over and over in different configurations and Anna is working through them now, but it will take a bit of time to gather the data and see if it tells us something helpful.
No edits. Again, I recommend adding the printout of all the configuration settings in the serial log at startup, or upon save action, or something like that for interacting with Support.
I finally got my M4 mounted on my garage floor and attempted to calibrate last night. I haven’t gotten it to properly calibrate yet. Initially, I realized I mixed up the width and height frame dimensions. At first, I kept getting errors that the frame dimensions were off by greater than 100.
Suggestion: Perhaps in the config menu, instead of “Machine Width” and “Machine Height” it would be better to put something like “Frame X” and “Frame Y”. Alternatively, would it be possible to have the user enter the dimensions without a reference to width, height, x, y, or whatever one wants to call them and have calibration infer which dimension is which? Ultimately though, this isn’t a big problem and is easy enough to figure out as is.
After switching the width and height, I tried to calibrate again. I believe I received the frame dimensions error again, so I re-measured my anchor points and put in values closer to true. I ran calibration again, but fitness scores were too off. (What range should fitness scores be in, anyways?) I had it directly on my garage floor and I think was getting a bit too much resistance. I don’t have a full plywood sheet right now for spoil, so I just had it on the floor at first. I grabbed the biggest plywood sheet I do have and set the calibration grid to the dimensions of the spoilboard. Re-ran calibration and it ended up tipping off the edge a bit. I think it was trying to calibrate to the edge of the spoilboard, and I need to set the calibration grid dimensions lower than the actual spoil dimensions so that the grid stays on the board.
Suggestion: (assuming the calibration grid must be smaller than the spoil board) Config could just ask for the spoilboard dimensions instead of the grid dimensions then have the program make a smaller calibration grid based on the spoilboard dimensions.
I ran out of time to run calibration again, but I think after adjusting the calibration grid dimensions down that I should be able to get it properly calibrated tonight.
I’m working on an updated calibration process which should automate most of that. All the information that the calibration process asks for is easy in hindsight, but it can for sure be confusing the first time you see it. If we can eliminate the need to ask for the user to enter any information that will solve a lot of issues I think.
And really it is the relative positions of the anchors points that define everything.
As Anna has been working on all the tests, have you guys been reproducing my abysmal post-calibration jog results? Or no matter the various frame & work areas, your test machines are jogging well and not de-spooling.
I’m trying to get a sense if this is possibly a faulty unit/assembly or something that we think can be fixed in software?
Yes… there is a book “Don’t make me think” which is all about simplified UX/UI design
We haven’t seen that issue at all 
There are generally one of two things which can lead to that.
The magnet not being aligned with the encoder. Pressing test will check to see if the magnet is detected in the correct place.
The magnet is slipping in the roller (it needs more glue). To test for that press Retract All → Extend All → Retract All. After extending the belts fully and then retracting them check to see that all of the offsets that print out are close to zero. If one magnet is slipping that will tell you.
OK, I’m updated on maslow.yaml, index.html.gz and firmware.bin as of this posting. v0.84 but the version numbers have been are a little confusing to me. honestly.
Anyway, I didn’t attempt jog yet, but everything else seems to be unchanged so far. I DO newly notice a symptom though: Top Right is easily refusing to retract all the way, though it does not seem to be jammed or blocked.
after a retract, we see it doesn’t even THINK it’s done:
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 94.080]
[MSG:INFO: Bottom Right pulled tight with offset 0.032]
Then an immediate next click to retract (no fiddling):
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset -5.293]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
and after that no amount of clicking gets it to move any more.
The belt is left hanging out an inch or so, and the belt CAN be pushed in through the rollers freely.
When I do this, the intensity of the amber light on the ethernet jack increases and off - seems like an intentional visual indicator of the percentage of the way through an inch of belt. Is that correct?
After a soft reboot of FluidNC (that’s enough, right?) No fiddling. The spool doesn’t seem blocked and the belt is still drooped out an inch:
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Right pulled tight with offset -0.032]
[MSG:INFO: Bottom Left pulled tight with offset -0.064]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -0.011]
So I extend all and retract all twice immediately (no intermediate fiddling):
[MSG:INFO: Extending all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset -0.011]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 763.722] << Seems about right! Belt is totally loose, no blockage.
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -3.811]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
Jason wrote:
OK, I’m updated on maslow.yaml, index.html.gz and firmware.bin as of this posting. v0.84 but the version numbers have been are a little confusing to me. honestly.
Anyway, I didn’t attempt jog yet, but everything else seems to be unchanged so far. I DO newly notice a symptom though: Top Right is easily refusing to retract all the way, though it does not seem to be jammed or blocked.
after a retract, we see it doesn’t even THINK it’s done:
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 94.080]
[MSG:INFO: Bottom Right pulled tight with offset 0.032]Then an immediate next click to retract (no fiddling):
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset -5.293]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]and after that no amount of clicking gets it to move any more.
This is a problem. When you retract, it pulls until it’s applying enough force
(the retraction limit) and then it reports where it thinks it got to. the fact
that it’s not near zero is a problem (the 0.032 on the bottom right of the first
one is acceptable)
try increasing the retraction (and calibration) limits
The belt is left hanging out an inch or so, and the belt CAN be pushed in through the rollers freely.
When I do this, the intensity of the amber light on the ethernet jack increases and off - seems like an intentional visual indicator of the percentage of the way through an inch of belt. Is that correct?
an indicator of belt movement, based on the rotation of the magnet.
After a soft reboot of FluidNC (that’s enough, right?) No fiddling. The spool doesn’t seem blocked and the belt is still drooped out an inch:
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Right pulled tight with offset -0.032]
[MSG:INFO: Bottom Left pulled tight with offset -0.064]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -0.011]So I extend all and retract all twice immediately (no intermediate fiddling):
[MSG:INFO: Extending all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset -0.011]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 763.722] << Seems about right! Belt is totally loose, no blockage.
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -3.811]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
the top right arm seems to have a problem. it could be the idler and motor are
too close together, the screws holding the two halves together are too tight,
the magnet is not in the right place, the magnet is not glued solidly enough, or
something else.
David Lang
With the arms removed from the assembly, is it expected to be able to have just the data and power connection to one dislocated arm to move and control that arm from the FluidNC interface? Mine just says
[MSG:INFO: Retracting all belts]
[MSG:INFO: Retracting all belts]
and no movement. I assume that’s some error condition because not all connections are reporting in properly. Assuming this is typical: Recommendation: fix this, at least in some kind of diagnostic mode.
I verified that the length of my belt is 14.5 ft as expected. Still, I’m surprised how tight a fit a the belt is against the gear collar. Unable to assemble it fully spooled. I assume this is typical.
It still confuses me why the walls of the spool aren’t sized for the fully-spooled belt, which is consistently two wraps bigger and allows the outer wraps to droop. I have a mind to put some thin extension barrier between spools to guard against the cross-wrapping that I sometimes see.
@anna says she hasn’t tested such smaller frames yet though. I disassembled the one arm that was perhaps too tight between drive and idler gear. That seemed to fix the problem retracting, but the overall slack jog problem persists. The magnet seemed sturdily glued in place in its correct roller.
Recommendation: provide a setting for overall z-offset contributed by a) spoil board thickness and b) workpiece if these would matter. The only alternative I’m aware of is a manual adjustment to the z-offsets of all 4 corners individually.
Are my z-offsets bad? They seem to mismatch the info tips regarding what’s “normal”. Is the calibration discovering them or is this just corruption? If it is from calibration, then are we supposed to recalibrate when our spoil board/workpiece thickness changes too and not only if the frame were to change dimensions?
Jason wrote:
Are my z-offsets bad? They seem to mismatch the info tips regarding what’s “normal”. Is the calibration discovering them or is this just corruption? If it is from calibration, then are we supposed to recalibrate when our spoil board/workpiece thickness changes too and not only if the frame were to change dimensions?
it does not discover the Z offsets, but the defaults have changed over time, so
it’s possible that the info tips hasn’t been updated.
David Lang
I think that this is a great suggestion. We’ll do some testing to make sure that it matters (we don’t want to waste folks time if its not important), but if it makes a difference we should have a setting for it.
Bar wrote:
I think that this is a great suggestion. We’ll do some testing to make sure
that it matters (we don’t want to waste folks time if its not important), but
if it makes a difference we should have a setting for it.
I think it will matter sometimes, but not others. Going from 3/4 ply to 1/2" it
isn’t going to matter, going from calibrating just on the wasteboard to cutting
on top of a 3" slab, it will matter.
It will also vary based on how big the frame is, if the workspace is 4x8 it’s
not going to matter nearly as much as if the workspace is 2x2
David Lang
I added 1.5" of workpiece/spoil board to my work area. The situation is not improving.
These seem 100% to me like software/firmware bugs, but so far it doesn’t sound like anyone in HQ has actually tested M4 on smaller frames, despite the claims on the website that remain up currently and despite claims that test of “[such] different configurations” were already in progress.
During calibration, so much slack is let out on the spools that they can overwrap themselves, other spools, or go between spools. I haven’t completed a single cut yet, and already a belt is mangled in at least one spot because of slack allowing it to get caught in the gears (not so fatally that they can’t be used to continue to diagnose these calibration problems, but bad enough that it’ll need replacing soon). Yes, I think a hardware fix (wider spools or shorter belts) could mitigate this but a software fix would be faster and cheaper.
Post calibration, even if all care was taking to keep spools from overwrapping during calibration and spools are tight and the sled is centered in the work area, a single jog EVEN Z-UP!! will let out a tangle of belt on the spools. The beginning of calibration lets out way too much slack but later in the calibration process the spools don’t go as crazy (if I manage the belts with my fingers early on). The calibration can finish with a good score and tight spools before going to sh*t on the first jog. Apply Tension will also let out a tangle of belt. I believe these are neighboring belts being unrolled by friction as neighboring belts take in. Idle spools shouldn’t really be allowed to be fully idle - maybe some overridable light tension is possible to keep them from unspooling?
I understand that some users are seeing huge successes with M4 and I’m jealous! Please dedicate some time to testing smaller frame sizes such as mine. My magnets and encoders seem to be working properly and consistently in certain phases of runtime, and the M4 is failing completely at consistent spots in the workflow which suggests to me that these are not hardware problems but programming/math bugs.
Please clarify the firmware/UI upgrade process. The version numbers are not matching the GitHub Releases downloads. It’s also very frustrating that the maslow.yaml does not get migrated, yet we’re supposed to replace it.
I’m getting pretty frustrated by this because I don’t get a lot of time to work with M4 and since my first weekend fully assembling it, we haven’t made really any progress on getting this one to work. What diagnostic questions does Maslow Team have for me that I can answer, please?
Jason wrote:
I added 1.5" of workpiece/spoil board to my work area. The situation is not improving.
These seem 100% to me like software/firmware bugs, but so far it doesn’t sound like anyone in HQ has actually tested M4 on smaller frames, despite the claims on the website that remain up currently and despite claims that test of “[such] different configurations” were already in progress.
During calibration, so much slack is let out on the spools that they can overwrap themselves, other spools, or go between spools. I haven’t completed a single cut yet, and already a belt is mangled in at least one spot because of slack allowing it to get caught in the gears (not so fatally that they can’t be used to continue to diagnose these calibration problems, but bad enough that it’ll need replacing soon). Yes, I think a hardware fix (wider spools or shorter belts) could mitigate this but a software fix would be faster and cheaper.
what frame size do you have, what workpiece size do you have, and what size do
you set when you get ready to do your calibration?
the machine uses the frame size that it thinks it has to determine how much belt
to spool out, so if it’s spooling out a huge amount, then it thinks it has a
much larger frame than it has.
Post calibration, even if all care was taking to keep spools from overwrapping
during calibration and spools are tight and the sled is centered in the work
area, a single jog EVEN Z-UP!! will let out a tangle of belt on the spools.
did you do the calibration with the Z axis all the way down? are the Z offset
values correct for your frame?
The beginning of calibration lets out way too much slack but later in the
calibration process the spools don’t go as crazy (if I manage the belts with
my fingers early on).
to some extent this is expected, the machine is trying to figure out what the
frame size is, when you start calibration, it’s using the frame size you enter
until the first few points are measured, then it updates it’s estimate and does
the next set of points. That’s why it gets better in each stage of calibration.
The calibration can finish with a good score and tight
spools before going to sh*t on the first jog. Apply Tension will also let out
a tangle of belt. I believe these are neighboring belts being unrolled by
friction as neighboring belts take in. Idle spools shouldn’t really be
allowed to be fully idle - maybe some overridable light tension is possible to
keep them from unspooling?
if things are properly assembled, you are not going to be able to extend belts
without the motor powering them out. The gear ratio involved is very high.
apply tension won’t spool out any belt unless the belt was wrapped around the
spool the wrong way (which could be the case for you based on your explination
of way too much belt being spooled out and getting tangled)
I understand that some users are seeing huge successes with M4 and I’m
jealous! Please dedicate some time to testing smaller frame sizes such as
mine. My magnets and encoders seem to be working properly and consistently in
certain phases of runtime, and the M4 is failing completely at consistent
spots in the workflow which suggests to me that these are not hardware
problems but programming/math bugs.Please clarify the firmware/UI upgrade process. The version numbers are not
matching the GitHub Releases downloads. It’s also very frustrating that the
maslow.yaml does not get migrated, yet we’re supposed to replace it.
There has been a bug in the release process that has had the reported version
being updated after the release is cut rather than before it is cut, so what’s
reported is one version earlier than it actually is.
I’m getting pretty frustrated by this because I don’t get a lot of time to
work with M4 and since my first weekend fully assembling it, we haven’t made
really any progress on getting this one to work. What diagnostic questions
does Maslow Team have for me that I can answer, please?
As I said above, what size frame do you have, what size workpiece, what size is
the calibration grid you are using. Was the Z axis all the way down, have you
changed the Z axis offsets (do you need to for your frame).
you can try using my manual calibration doc in onshape (no account needed) and
enter the results into your maslow.yaml file
David Lang
what frame size do you have, what workpiece size do you have, and what size do
you set when you get ready to do your calibration?
After the latest maslow.yaml, I updated to this configuration again. I’ve tried various sizes near these.
the machine uses the frame size that it thinks it has to determine how much belt
to spool out, so if it’s spooling out a huge amount, then it thinks it has a
much larger frame than it has.
Except for the messy spools, the M4 does traverse the 5x5 or 7x7 grids basically as expected. I do believe there could be some math errors in the M4 code that decides to give out way too much slack in the case of a smaller frame. Once of the reasons I want this to get actually tested in the lab.
did you do the calibration with the Z axis all the way down? are the Z offset values correct for your frame?
I’ve calibrated with no bit close to the platform and also with no bit at 1.5" spoil+workpiece and I’ve also done a nearly-zeroed bit above the 1.5" spoil+workpiece. I don’t recall seeing much about correct z-offsets in the setup guide other than to say that generally they don’t need changing(?) and as I’ve noted previously, the UI tooltips are out of date and therefore misleading. I do wonder if the z-offset which DOES change the triangles is correctly accounted for in the software - I haven’t really gotten far enough. However, since the Z JOG UP did far-over-slack the belts, it seems like the software is attempting to compensate for the height, just not very well.
to some extent this is expected, the machine is trying to figure out what the frame size is, when you start calibration, it’s using the frame size you enter until the first few points are measured, then it updates it’s estimate and does the next set of points. That’s why it gets better in each stage of calibration.
Nice, that’s what I’ve figured. However, I think the software is over-doing it at least in the case of a smaller frame, perhaps. Lab tests should be able to confirm or reject this theory.
if things are properly assembled, you are not going to be able to extend belts without the motor powering them out. The gear ratio involved is very high.
I realize my “friction” theory isn’t likely - but this means the software is letting the belts out intentionally.
apply tension won’t spool out any belt unless the belt was wrapped around the spool the wrong way (which could be the case for you based on your explination of way too much belt being spooled out and getting tangled)
“Apply Tension” also attempts to Center/Home the sled, right? So the spooling out of the belts IS happening, probably as part of the jogging-to-home plan. The belts are definitely spooled the correct way around. Many actions are working sensibly, just not enough to get all the way through calibration and a complete cut.
There has been a bug in the release process that has had the reported version being updated after the release is cut rather than before it is cut, so what’s reported is one version earlier than it actually is.
Good to know - worth fixing. And also differentiating between firmware and UI version numbers IF they’re not expected to stay in sync.
As I said above, what size frame do you have, what size workpiece, what size is the calibration grid you are using. Was the Z axis all the way down, have you changed the Z axis offsets (do you need to for your frame).
I believe I’ve answered those above and previously but please let me know if I seem to have misunderstood a question.
you can try using my manual calibration doc in onshape (no account needed) and
enter the results into your maslow.yaml file
I do know how to use onshape, but please tell me about this file - origin of the onshape workspace and the in-model labels seem to be relative to the lower left corner (good), but I guess I’m supposed to edit the Configurations panel which have values I’m not understanding as examples:
I would kinda expect Left and Bottom to be about 0. Should I divide my widths and heights by 2? But that isn’t really what the example output seems to me doing (it isn’t 4800w x 6000h). Probably I’m being dense.
Ok, that size should work
Apply tension should be retracting the belts. Yes it should roughly center the router, but the main purpose is to retract the extra belt that was fed out to make it easier to hook up the belts to the anchors.
The version number bug should be fixed in the next release.
When I talk about doing calibration with the X axis all the way down, that’s not referring to the spoil+workpiece, but rather that the router should be all the way down against the steppers. If you calibrate with the router higher, then when you are operating, the machine thinks it needs to feed out more belt (as it thinks that the Z height is more than it really is)
The two most common causes of the belts getting slack are
The Z travel is not quite correctly calculated (see the ‘a new source of error’ thread I made a few weeks ago), but the bug there makes the belts slightly shorter than they should be, but it’s only a few mm shorter.
yes, in the onshape doc you edit the configuration. measure the 6 distances between anchor points and enter them into the configuration, and then the numbers on the right will tell you what measurements to put into the maslow.yaml file (the diagonal_error should be close to zero, if it’s not, re-measure everything)
Since your frame is 1738x1214 the left and right values should be close to 1214 and top and bottom values should be close to 1738
if you have a perfect rectangle, the diagonals should be 2120, but if it’s not, the numbers will vary a bit.
This is what a near perfect rectangle would show (the actual diagonal would be 2120.0094, which you are not going to be able to measure)
It seems to me that it’s likely if there is a bug on a smaller frame that it’s likely that the same bug exists on larger frames too but it might just be less noticeable. Fixing it for smaller frames will improve things for everyone, not just smaller frames.
This coming weekend is Makerfaire so I’m going to be swamped this week getting ready, but I will try to test it out and see what I can learn.
