M4 Emergency stop during calibration

[jurgis]

hey all,
Total cnc newb here.
I built a square frame for testing and learning, the anchors measure 1900x1900mm roughly and that’s what I’m inputting into the configs.

I’ve set the calibration grid to 1000x1000mm for starters.

The calibration starts, reaches the first point and stops with an emergency message.

here’s a video of the calibration. One belt gets very loose, that may be a symptom of something, right?

Here’s a log as well:

Serial Messages
Index.html Version: 0.8
[MSG:INFO: Channel auto report interval set to 50 ms]
[MSG:INFO: FluidNC v0.79 (Maslow-Main-7b9f3a44-dirty)]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:maslow.yaml]
[MSG:INFO: Machine Maslow S3 Board]
[MSG:INFO: Board Maslow]
[MSG:INFO: UART1 Tx:gpio.1 Rx:gpio.2 RTS:NO_PIN Baud:115200]
[MSG:INFO: SPI SCK:gpio.12 MOSI:gpio.11 MISO:gpio.13]
[MSG:INFO: SD Card cs_pin:gpio.10 detect:NO_PIN freq:8000000]
[MSG:INFO: Stepping:Timed Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:240ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (-2438.400,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis Y (-1219.200,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: Axis Z (-100.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: tmc_2209 UART1 Addr:0 Step:gpio.15 Dir:gpio.16 Disable:NO_PIN R:0.110]
[MSG:INFO: Motor1]
[MSG:INFO: tmc_2209 UART1 Addr:1 Step:gpio.46 Dir:gpio.38 Disable:NO_PIN R:0.110]
[MSG:INFO: Z Axis driver test passed]
[MSG:INFO: Z2 Axis driver test passed]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Using spindle NoSpindle]
[MSG:INFO: STA SSID is not set]
[MSG:INFO: AP SSID maslow IP 192.168.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset -1103.261]
[MSG:INFO: Bottom Right pulled tight with offset -1203.944]
[MSG:INFO: Top Left pulled tight with offset -1195.205]
[MSG:INFO: Top Right pulled tight with offset -1273.224]
[MSG:INFO: Extending all belts]
[MSG:WARN: Low memory: 9608 bytes]
[MSG:WARN: Low memory: 9468 bytes]
[MSG:WARN: Low memory: 9420 bytes]
[MSG:WARN: Low memory: 9292 bytes]
[MSG:WARN: Low memory: 9092 bytes]
[MSG:WARN: Low memory: 7420 bytes]
[MSG:WARN: Low memory: 5816 bytes]
[MSG:WARN: Low memory: 5636 bytes]
[MSG:WARN: Low memory: 5500 bytes]
[MSG:WARN: Low memory: 4672 bytes]
[MSG:WARN: Low memory: 3928 bytes]
[MSG:INFO: All belts extended to center position]
[MSG:INFO: Setting z-stop position]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.353 TR: 0.240 BL: -31.025 BR: 1.015]
[MSG:INFO: Measured waypoint 1]
[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]
[MSG:INFO: Set to comply]

Any ideas what is going wrong or what mistakes am I making?
Any input would be helpful, thanks a lot.

[Carson_Barry]

I’m not sure what is causing your issue in this instance, I don’t see anything that stands out to me in your description of your set up. That said, I’m not versed in spotting issues in the logs yet, so someone else may see something there and report it. Looking at the end, though, it just looks like it was taking a measurement and something broke down during anchor coordinate calculations; what are you using to run calibration?

If it’s not that, this stands out to me as the machine thinking that something is ~30 mm off, then it tries to measure the first waypoint other than the starting location. It may just be that your initial frame numbers are not accurate enough and it can’t compensate for how different reality is from your rough measurements.

[MSG:INFO: Center point deviation: TL: 0.353 TR: 0.240 BL: -31.025 BR: 1.015]

There is also a newer firmware available, so it would be a good idea to try that. It appears you have v0.79 from the console log you shared. The version you have is able to complete calibration, of course, newer has just generally had higher success rates, may “power through” whatever issue you’re having by nature of just being better.

I don’t know if any of the below will be helpful to you in this instance, but it’s the general calibration advice I’ve assembled since I ran my own and have been soaking up conversations here on the forum.

Calibration Experience Report

iirc, it’s improved with updates, but you should still expect some belt slack during the first part of calibration and, especially if horizontal, have to tend the belts during that time to keep the slack outside of the spool assemblies.

The device you are controlling the maslow from is the device providing the processing power for calibration and it needs to be connected at all times so that the data the maslow is recording when it takes measurements is processed properly.

I highly recommend using the most powerful machine you can for calibration. e.g. If you have a gaming laptop, for instance, it would be much faster during the calculations than a basic office laptop that would normally be fine for driving the maslow, and worlds faster than a tablet (which would also be fine for driving the maslow, normally).

Secondarily, it would also likely be prudent to directly connect to the maslow rather than having it on your home wifi (if you have it on your wifi) for calibration, as it can be much more reliable. On top of this, I would set your laptop’s power plan to not shut off or go to sleep while plugged in, and then remember to plug it in while you calibrate so you don’t have disconnects from that end.

[jurgis]

First of all, thank you so much for taking the time to write up such an extensive answer @Carson_Barry . I will surely pick up more variables to try from your tips and will be able to come back here with a more exact situation. Firstly, I’ll go through the firmware update.

what are you using to run calibration?

I’m using macbook pro M2, connected to the maslow on it’s original network, not my home wifi. It’s running arc browser (would it be worthwhile to try other browsers?) and never sleeps during my interactions with maslow.

Cheers!

[Carson_Barry]

That should breeze through the calcs this calls for. Trying another browser wouldn’t hurt, though it’s more “something to try” than “I think that’s potentially the issue”.

[Aggiehouse]

I’ll just ask the obvious. Did you select the horizontal/vertical correctly? It is referring to the physical config of the frame, not portrait vs landscape orientation. Ie, if you are using floor anchors, it is horizontal, if you are hanging the Maslow on an angle, it is vertical. I screwed this up once.

[Carson_Barry]

Thanks to the context of you bringing this up, I’m actually of the mind that I think the orientation setting should be something that prints out during the console log as the machine starts up.

[jurgis]

wow, I have always assumed that this setting was about portrait/ landscape orientation and was puzzled by it. And to be honest - I don’t remember setting it deliberately, since my frame is square. I’ll try to recalibrate before updating firmware during lunch today, just to be sure that I’ve set this correctly and isolated the real issue. Thanks for pointing this out!

[jurgis]

UPDATE:

Turns out you were completely correct - I’ve set the vertical orientation and Maslow breezed through the whole calibration no problem. Silly mistake, but your insight was crucial. Thanks a lot, @Aggiehouse and @Carson_Barry for your feedback. Can’t wait to get my bits in post so that I can finally start cutting.

Calibration complete
Calibration values:
Fitness: 1.0606368190738138
Maslow_tlX: -13.5
Maslow_tlY: 1949.3
Maslow_trX: 1826.9
Maslow_trY: 1930.6
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 1848.4
Maslow_brY: 0.0
A command to save these values has been successfully sent for you. Please check for any error messages.
[MSG:INFO: Setting z-stop position]
[MSG:INFO: Calibration complete]

Cheers!

P.S. I cannot edit the title to add the [SOLVED] and cannot find an appropriate tag to mark it as solved, if any admins see this - feel free to mark it as such or add a tag to the collection.

[jwolter]

I’m going to be a broken record here and say once again that we really should switch to terminology like “upright” and “flat”.

[Aggiehouse]

@jwolter, broken record away, I hadn’t heard your suggestion, but wholeheartedly agree, great terminology.

Also, @jurgis, amazing calibration number, and I almost didn’t mention it because you had a square frame, lol.

[jurgis]

Indeed, “upright” and “flat” would be much more clear for begginers like me, that’s a solid suggestion @jwolter

Also, @Aggiehouse maybe I missed this info somewhere, but what is the range of good to great calibration numbers? should I be aiming towards 1 or more like to 2 (I’ve seen 1.7 during the process). What are the main factors that decide this number during calibration - frame stiffness, I assume?

[Carson_Barry]

fitness is 1/average error

New user experience and first cut!

Thanks to @dlang for fitness explantion: fitness = 1/average error where average error is looking at each point and measuring the difference between the belt lengths that it thinks it should have at that point with the calculated frame size and the belt length measurements that it got at that point. Yes, larger frames typically have larger errors and lower fitness.

[jurgis]

that’s good to know, 1,06 value now really does look amazing:))

[Carson_Barry]

Yep. You are, should everything else work out, looking at sub-millimeter precision, if I’m not mistaken.