Z-Stepper Motors Blistering Hot - No Z Movement [solved-ish]

Hardware Sled
1

Just tried recalibrating again after modifying the frame (again) to get a significantly larger distance between the anchor points.

And also after swapping over to using the M4 Router Mounter Be-Gone

And changing to firmware version 0.74 from Release v0.74 · BarbourSmith/FluidNC (github.com)

Calibration went well, although I had one observation that I’ll drop into a different thread.

However, after (and probably during) calibration the Z-axis motors would not move at all, although the PCB fan would come on to show that the PCB at least was thinking about it.

When I touched the Z-Steppers they were extremely hot. So I’m guessing they were being fed current when not needed, and had entered some kind of thermal overload. Everything is off now so they can cool down, and I’ll see if they are OK once they have cooled.

Here’s the steps I took leading up to this, in case something maybe relevant:
Before turning off the M4

  1. Dropped the router assembly all the way down, bottoming out Z, and then set Zero-Z.
  2. Entered the frames new width and height values in Config.
  3. Did a Retract All.

Turned off the M4, and did all the other things as listed above.
Turned the M4 back on
(Note that I did not redo config Zero Z again, I assumed that the non-volatile memory would be OK)
4. Raised the M4 by 30mm (no problems here)
5. Updated firmware and restarted M4. Updated index.html.gz and maslow.yaml (probably should not have done that last one)
6. Did a Retract All, and Extend All, then checked the Config and noticed that it had the wrong values for width, height and orientation.
7. Corrected the values, Retract All, Extend All … fine … put it on the frame, and then clicked Calibrate … nothing … checked the Config and noticed that the values had been zeroed?
8. Corrected the values again, still no Calibration action, Web UI was reporting problems and recommended a restart.
9. Did a restart, reentered the correct height, width and orientation, retract all, extend all, and put it up on the frame. This time Calibration worked (I have the logs), but in spite of statements about Zeroing z-axis position in the logs the Z-axis never moved.
10. Did a release tension, stuck a bit in the router, and then tried getting the router assembly to go down so I could set Z home, no action, check Z-Stepper motors - they were extremely hot.
11. After checking a few other things I decided to power down the M4 to reduce any further possible damage to the Z-Steppers.

2

Retried after Z-Steppers had cooled

Turned the M4 back on (did not remove from the frame, still in a ‘Release Tension’ state)
Reconnected WebUI. Clicked on Alarm to unlock
Went back to Z control, set movement to 10mm, clicked down, the PCB fan spun up, but nothing else happened.
Repeated the above a couple more times.
Z-Stepper motors already heating up.
Turned the M4 off, waiting for replies from you all @bar @RomanG @dlang

3

usually when the Z motors are getting hot, that’s an indication that something
is wrong with the maslow.yaml file. And given that you had to re-enter some
things a few times, this sounds very plausible.

David Lang

1 Like
4

Any suggestions on what to check for? I pulled the 0.74 version of the maslow.yaml file and shoved that onto the M4 first, before doing the reentry of the numbers.

5

My next step is to use my other M4 (unassembled) and connect all the motors and encoders. Power it up
Shove on everything 0.74 including default maslow.yaml (but change no settings otherwise)
Try getting the Z-Steppers to move
Leave it for a minute or two to feel if the Z-Steppers get hot even doing nothing.

6

Lee H wrote:

Any suggestions on what to check for? I pulled the 0.74 version of the maslow.yaml file and shoved that onto the M4 first, before doing the reentry of the numbers.

it would be the motor0 and motor1 pin assignments

are you setting these by editing the file? or through the advanced settings
option (next to the firmware upload)??

 motor0:
   limit_neg_pin: NO_PIN
   limit_pos_pin: NO_PIN
   limit_all_pin: NO_PIN
   hard_limits: false
   pulloff_mm: 1.000000
   tmc_2209:
     uart_num: 1
     step_pin: gpio.15
     direction_pin: gpio.16
     disable_pin: NO_PIN
     r_sense_ohms: 0.110000
     run_amps: 1.000000
     hold_amps: 0.500000
     microsteps: 1
     toff_disable: 0
     toff_stealthchop: 5
     use_enable: true
     addr: 0
     run_mode: StealthChop
     homing_mode: StealthChop
     stallguard: 0
     stallguard_debug: false
     toff_coolstep: 3


 motor1:
   limit_neg_pin: NO_PIN
   limit_pos_pin: NO_PIN
   limit_all_pin: NO_PIN
   hard_limits: false
   pulloff_mm: 1.000000
   tmc_2209:
     uart_num: 1
     step_pin: gpio.46
     direction_pin: gpio.38
     disable_pin: NO_PIN
     r_sense_ohms: 0.110000
     run_amps: 1.000000
     hold_amps: 0.500000
     microsteps: 1
     toff_disable: 0
     toff_stealthchop: 5
     use_enable: true
     addr: 1
     run_mode: StealthChop
     homing_mode: StealthChop
     stallguard: 0
     stallguard_debug: false
     toff_coolstep: 3
7

I was just having that problem and was about to post about it. My solution was to go back to 0.73 and use that maslow.yaml . These must be some setting that was changed between the 2.

2 Likes
8

I left everything in maslow.yaml as it was.

Considering that I could make Z movement before uploading a full new set of files, and I couldn’t do that afterwards (not that I knew that to start with) it makes sense that the change is in the ‘out-of-the-box’ maslow.yaml between 0.73 and 0.74

Also considering the ‘cooking’ effect, that I observed and @BuildPrintFlex also reported I’m gonna say that there’s a strong need for sensibility checks in the code that ensures there are no ‘out-of-bound’ values in maslow.yaml that could seriously mess up the equipment.

9

Lee H wrote:

I left everything in maslow.yaml as it was.

Considering that I could make Z movement before uploading a full new set of files, and I couldn’t do that afterwards (not that I knew that to start with) it makes sense that the change is in the ‘out-of-the-box’ maslow.yaml between 0.73 and 0.74

how does your yaml file compare to the section I just posted? both in the file
and in the advanced settings?

Also considering the ‘cooking’ effect, that I observed and @BuildPrintFlex
also reported I’m gonna say that there’s a strong need for sensibility checks
in the code that ensures there are no ‘out-of-bound’ values in maslow.yaml
that could seriously mess up the equipment.

unfortunantly, when it comes to telling the system what pins are hooked to what,
there is no way to know what’s on the other end of those pins.

But this is why I’ve suggested that the current yaml file needs to be split.
FluidNC requires that all pin assignments be in a single file that is loaded at
startup, so that all has to be in one file (originally named fluidnc.yaml) but
the frame dimensions could be loaded in a different step later (possibly via a
filename specified in the master yaml file so that there can be multiple of
them???

David Lang

1 Like
10

Yep - that makes a lot of sense to me

1 Like
11

Here’s a comparison of the z axis section of the 0.74 maslow.yaml vs. whatever was in and/or rewritten into maslow.yaml after a restart, which was after setting width, height, orientation and doing calibration

image
image1920×2204 278 KB

As you can see they are very different, the same goes for most of the file.

12

yep, the one on the right won’t work, it looks like a default generated by
fluidnc.

I would load in the one on the left, and then set the Maslow_* variables through
the UI

David Lang

1 Like
13

The one on the left, is the precursor to the one on the right, after loading the variables through the UI.

I think I need to explore the code @ronlawrence3 , @bar - where do I start?

1 Like
14

Does it also have the maslow values in it? If so, I’d copy them to a “stock” maslow.yaml and upload.

As to why it changed the z values I’m puzzled by this. I do expect more values in the yaml “after” than before, but not for it to have changed them. The code we have that saves values just saves what’s currently set in the configuration to the maslow.yaml file on flash, so should reflect what was happening at the time calibration saved values.

1 Like
15

Here is the maslow code in the firmware (for the most part, there were changes in the actual fluidnc code too to hook it in and register user commands, etc, but this is the maslow specific stuff): FluidNC/FluidNC/src/Maslow at Maslow-Main · BarbourSmith/FluidNC · GitHub

1 Like
16

Yes it does.

1 Like
17

@dlang and @ronlawrence3 at the very top of a “Hasn’t been configged yet” Maslow.yaml are these lines:

board: Maslow
name: Maslow S3 Board

However, after config they read

board: None
name: Default (Test Drive)

Hunting down Default (Test Drive) in the code, you find it in MachineConfig.cpp

At the top of MachineConfig.cpp is this foreshadowing comment

// TODO FIXME: Split this file up into several files, perhaps put it in some folder and namespace Machine?

The triggering of this ‘default’ yaml file is in MachineConfig::load()

bool configOkay;
//If the system crashes we skip the config file and use the default
//builtin config.  This helps prevent reset loops on bad config files.
esp_reset_reason_t reason = esp_reset_reason();
if (reason == ESP_RST_PANIC) {
    log_error("Skipping configuration file due to panic");
    configOkay = false;
} else {
    configOkay = load(config_filename->get());
}

So the ESP32 is setting ESP_RST_PANIC as its ‘reset reason’.

Well that can happen. Therefore, we want the default YAML that gets spat out in such circumstances to match maslow’s needs, not something from the original FluidNC code.

18

Lee H wrote:

Therefore, we want the default YAML that gets spat out in such circumstances to match maslow’s needs, not something from the original FluidNC code.

right now, fluidNC reads everything from a single yaml file, and the Maslow
unique things (anchor locations and tension) are put in there as well. Those are
the only things in that file that are ever expected to change.

If we just pull them out into a separate file, then we have a file that should
not ever change.

I don’t want to hard-code the maslow specifics into the default, that will jus
tmake it harder for this work to be merged upstream.

but the ability to use multiple files is something that upstream would welcome
according to the comment that you are pointing it.

David Lang

1 Like
19

I suspect that the real problem is that, after a panic reset by the ESP32, we’re still writing the ‘default’ yaml back as maslow.yaml, when we need to check for Maslow.using_default_config being false first. So that this unwanted default form cannot be written back by accident.

2 Likes
20

OK. so the first issue of super hot Z-Steppers is now fixed, i.e. the bad maslow.yaml file

I went back to the release version of maslow.yaml, copied the Maslow_(t|b)(l|r)(X|Y) parameters over from the dodgy (already run calibration and downloaded) version into it.

But not the Maslow_(t|b)(l|r)Z variables because for some reason they were all 0.

To get a ‘release, but calibrated’ version.

Turned on the M4, connected to it as fast as possible, accessed the FluidNC tab, uploaded the replacement maslow.yaml file, clicked FluidNC restart. Did a fresh download of maslow.yaml and checked it - all good. Then finally run Z-Axis tests, also good.

1 Like