M4 v.86 no longer extends

I basically upgraded my M4 to an M4.1. I put in a new controller, new encoders and belts and I updated the firmware to .86 and mounted it vertically to a classic frame. I set the dimensions, extended the arms, mounted it, applied tension and told it to calibrate. It appeared to calibrate successfully but then did an emergency stop for a reason I couldn’t figure. I dismounted the M4 from the frame and retracted.

After that, all attempts to extend fail. When I tell it to retract, I hear the fan briefly for half a second familiarly, but when I subsequently tell it to extend, the fan, which normally turns on in preparation for the pulling of the belts, doesn’t make a sound. When I try to wiggle the belts, nothing happens. Here is the log:

Serial Messages
Index.html Version: 0.86
$/Maslow_vertical=true
$/Maslow_calibration_grid_width_mm_X=1500.000
$/Maslow_calibration_grid_height_mm_Y=800.000
$/Maslow_calibration_grid_size=7
$/Maslow_Retract_Current_Threshold=1400
$/Maslow_trX=0.000
$/Maslow_trY=0.000
$/Maslow_Acceptable_Calibration_Threshold=0.450
$/Maslow_tlX=0.000
$/Maslow_tlY=0.000
$/Maslow_trX=0.000
$/Maslow_trY=0.000
$/Maslow_brX=0.000
[MSG:INFO: Channel auto report interval set to 50 ms]
[MSG:INFO: Channel auto report interval set to 50 ms]
[MSG:INFO: Channel auto report interval set to 50 ms]
$/Maslow_tlX=0.000
$/Maslow_tlY=0.000
$/Maslow_trX=0.000
$/Maslow_trY=0.000
$/Maslow_brX=0.000
[MSG:INFO: Retracting all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset -0.032]
[MSG:INFO: Top Right pulled tight with offset -0.032]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset -0.011]
[MSG:INFO: Top Left pulled tight with offset -0.011]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset -0.011]
[MSG:INFO: Top Left pulled tight with offset -0.011]
[MSG:INFO: Extending all belts]
[MSG:INFO: All belts extended to center position]

Does anyone know what can be failing?

it looks as if it has lost the configuration (see the tlX/tlY etc values all
being zero)

per the log it thinks that it’s extended, which would make sense if it has no
data.

check the bootup log, I’ll bet that it didn’t see the maslow.yaml file and
recreated it or something like that.

David Lang

1 Like

Hi @bar, I’ve just experienced this too. Probably a bug.
Maslow-serial.log (6.0 KB)

hi @bar/@dlang , I’m getting an issue while trying to calibrate on 0.86.
I keep getting an errors when calibrating:
Please check for any error messages.
[MSG:INFO: Setting z-stop position]
[MSG:ERR: Unable to move safely, stopping calibration]
[MSG:ERR: Emergency stop! Stopping all motors]
[MSG:WARN: The machine will not respond until turned off and back on again]
[MSG:ERR: Unable to move safely, stopping calibration]

any ideas?
Maslow-serial(1).log (7.6 KB)

I tried downgrading to .84 but got the same problem.
I’m going to try reverting to my previous calibration which wasn’t brilliant but at least I could cut.

Maslow-serial(2).log (6.1 KB)

hi @bar, I think the issue is running out of space in the maslow.yaml directory (root, no?)

I’ve just uploaded the default files after deleting everything and did a firmware upgrade. It reports Total: 192.00 KB | Used: 180.00 KB which is 93% usage.
That would explain why the maslow.yaml file is not being saved and why two of us end up with the width of the frame being set as 0 for X &Y during calibration.

I deleted all previous gcode files but it looks to me that they are on a separate file system. Perhaps this can be resolved by increasing the filesystem of the maslow.yaml directory.

hi @pmodiano, my working theory for what is going wrong is that the config file filesystem is too full. I’ve had some progress by uploading the index.html.gz file from version 0.71 as that’s a bit smaller than the one with 0.87.
Once you finish calibrating, then upload the new version of index.html.gz.

hi @bar, it’s really bad practice to have a filesystem at 90% usage in normal operating conditions. Can you please find a way for it to be bigger so that the configs are only taking up 50% of the space.

1 Like

Grim wrote:

I deleted all previous gcode files but it looks to me that they are on a
separate file system. Perhaps this can be resolved by increasing the
filesystem of the maslow.yaml directory.

it’s not just a different filesystem, it’s different chips, so the size can’t be
changed. What other files do you have on the machine here?

David Lang

nothing. I’ve even removed the favicon.

I’m currently calibrating and it seems to be going well. I used an old index.html.gz to get it to work.

1 Like

Grim wrote:

hi @bar, it’s really bad practice to have a filesystem at 90% usage in normal operating conditions. Can you please find a way for it to be bigger so that the configs are only taking up 50% of the space.

that would require a different ESP32 chip

David Lang

I can report that I’ve successfully calibrated using the index.html.gz from 0.71. (only took 5 hours of trial and error to figure out the issue).

The thing is, does the maslow really need index.html.gz in that filesystem/on that chip? Could it not store it in the same directory as the gcode?

@grim The issue you are seeing is this:

[MSG:ERR: Unable to move safely, stopping calibration]

It happens when the math is producing results which are nonsensical, for example the math is saying that to move to the left the left belts need to get longer (they should obviously get shorter).

We would like to make the math more robust to handling when something goes wrong, but it’s tricky because we need to be 100% certain that an error is safe to ignore because if something goes wrong and we ignore it we could break something.

Try changing your initial frame dimensions slightly and restarting should fix the issue.

You can find a full list of error messages and how to fix them here: Error Messages — Maslow

hi @bar, the maths is nonsensical cos the size of the frame is 0x0. That’s cos the attempt by calibration to write maslow.yaml is failing.
That’s what @pmodiano was experiencing (just like me)

1 Like

Gotcha! Sorry I misunderstood that

1 Like

I will look into what we can do free up some space on the file system!

1 Like

@grim, have you noticed any functionality implications from reverting the index.html.gz all the way back to .71, or was your intention just to revert it back in order to perform the calibration then update it to the latest version to use the M4 after calibration?

Hi @pmodiano, I did the calibration with 0.86 firmware but 0.71 index.html.gz.
The moment that the calibration was finished, I uploaded the 0.86 index.html.gz

1 Like

hi @bar, the ideal is to move index.html.gz off of that filesystem and somewhere else with far more memory.

1 Like

I agree, unfortunately that’s a pretty core part of FluidNC so it would require us to fork off of the main project pretty hard. I think that with a bit of work we should be able to reduce the size of the index.html file enough that it isn’t an issue, at least in the short term.

Great job identifying the issue!

1 Like

Years of sysadmin work :wink:

I really need to build a horizontal frame as the debugging was a massive pain in the arse.

1 Like