M915: Configure motor stall detection
-
I am using a Duet 3 board with three Z-axis stepper motors connected. If any motor connector becomes disconnected, a warning message appears:
"Driver 0.4 Phase A or B may be disconnected."
**I would like to implement code that automatically performs the following actions when this warning is triggered:- Immediately disable all motors.
- Display the message: "Please check Z motor connection."**
I have tried using stall detection and created a driver-warning.g file with the following command:
M915 Z0.2:0.4:0.5 S2 R3
However, this approach did not work as expected. I am testing this on a table-top setup. -
@R006 stall detection is not relevant to detecting open-load conditions, however the driver-warning.g file should catch it if you are running a sufficiently recent version of RRF.
-
@dc42
I am currently using RepRapFirmware version 3.6.0rc1 and testing it on a table-top setup.
Could you please provide an example of a driver-warning file for reference? -
@R006 said in M915: Configure motor stall detection:
M915 Z0.2:0.4:0.5 S2 R3
I think this should be either
M915 Z S2 R3
orM915 P0.2:0.4:0.5 S2 R3
to enable stall detection. Check it is configured correctly by sendingM915
on it's own.EDIT2: Sorry, I overlooked that phase disconnection IS mentioned as a driver warning, not a driver error.
According to https://docs.duet3d.com/User_manual/RepRapFirmware/Events#events it is 'driver error' that is triggered for phase disconnection, not driver warning:
(EDIT: sorry, phase disconnection is not mentioned in the driver error section, but I would think it does count as a 'driver error' rather than 'driver warning'.)Driver error (e.g. over temperature shutdown, short-to-ground, or closed loop driver position difference error limit exceeded)The default behaviour is to "Pause print without running pause.g and inform user via message box" according to the table here https://docs.duet3d.com/User_manual/RepRapFirmware/Events#processing-eventsCreate a file called 'driver-error.g' in /sys on the SD card. It could contain something like:Create a file called 'driver-warning.g' in /sys on the SD card. It could contain something like:
M25 ; pause print M0 ; cancel job (note cancel.g will be run) M18 ; turn off motors echo "Please check motor connection on driver "^{param.B}^"."^{param.D}
M0 may not be the behaviour you want, M1 or M112 might be more appropriate, or just pause. M18 will cause the motors to lose position, so will need rehoming if you want to continue with the job.
You can use M957 to simulate an event to check it works, see https://docs.duet3d.com/User_manual/RepRapFirmware/Events#simulating-events
To decrease the time it takes to pause a print, make sure that segmentation is enabled with M669.
Ian
-
@droftarts phase disconnection is mentioned here:
Driver warning (e.g. over temperature warning, or phase disconnected, or closed loop driver position difference warning limit exceeded)
on this page: https://docs.duet3d.com/User_manual/RepRapFirmware/Events#events
So it would seem it is indeed a warning that will trigger driver-warning.g
-
Thank you for your response.
I have one question and observation:
I created two macro files:- driver-warning.g – for handling the "phase may be disconnected" warning
- driver-stall.g – for handling stall detection
When testing:
driver-warning.g is triggered correctly when the error is "Phase may be disconnected."
However, when testing for a stall condition (e.g., by physically obstructing the axis), driver-stall.g is also triggered even if a phase is disconnected.
So, in both cases — stall detection and disconnected phase — the driver-stall.g macro is executed.Question:
Is there a way to differentiate between a true stall detection and a driver error like "phase may be disconnected", so that only one specific macro is called for each event(is there any object model)?
I would like to handle these two cases differently in macros or messages. Is there any solution for this? -
@R006 I think the issue is that if a motor phase is disconnected, then the motor doesn't usually move when commanded, so it produces no back EMF due to rotation, causing the stall detection to trigger. Indeed, it is stalled because it is not moving. That's why you get both events raised.
Unfortunately the "phase may be disconnected" conditions doesn't identify definitively that a phase is disconnected. RRF does suppress this warning under some conditions that are known to trigger it spuriously, such as when the motor current is low or when the motor is at standstill at an exact phase position. Also, the "phase may be disconnected" and "driver stall" status flags normally won't both become active at the same time when a phase becomes disconnected. So we couldn't suppress the driver stall warning if a phase is flagged as possibly disconnected, even if we wanted to.
You could try setting a global variable in driver-warning.g if a phase is flagged as disconnected, then test that in driver-stall.g and suppress the stall error if the driver is flagged as having a phase disconnected.
Phases becoming disconnected should be a very rare event, except perhaps when commissioning a machine.
-
Thank you.
Could you please provide example files for both driver-warning.g and driver-stall.g, if available?