-
@hpiz Thanks again for all these tests and measurements that go far beyond what I would have asked for.
I guess I can't help you any further and @dc42 needs to take over, as it appears to me, that there is a problem with the following configuration:
- Duet 3 Main Board 6XD standalone mode
- CNC Mode
- Firmware 3.4.6
- Emergency Stop (DWC, gcode (M112 even within the jobfile itself) and external trigger (trigger0) confirmed)
- Maybe: two motors on one axis
Observed behaviour:
- movement commands are queued and the Movement System starts to move the drives
- M112 is processed
- all drives are disabled
- at least one movemend command is still being processed in the queue and this will reactivate the drives again
- all drives are disabled again (is it done by the M112 or maybe a stop.g/cancle.g?)
maybe I can reproduce it with a simple bench setup.
-
@dc42 I was able to reproduce this behaviour with an brand new of the shelf 6XD WD32096 v1.01 firmware 3.4.6 reflashed to be sure. In standalone mode.
Enable Jumper in active Enable.
Following config.g
; Enable network M552 P0.0.0.0 S1 ;CNC Mode M453 ; Select CNC device mode M669 K0 S2 T1 M569 R0 P0.4 S0 T3:3:6:0 ; physical drive 0.4 goes backwards M569 R0 P0.5 S0 T3:3:6:0 ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time M569 R0 P0.3 S0 T3:3:6:0 ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time M569 P0.0 S0 R0 T5:5:9:0 ; physical drive 0.0 goes backwards M569 P0.1 S1 ; physical drive 0.1 goes forwards M569 P0.2 S1 ; physical drive 0.2 goes forwards M584 X0.3 Y0.4:0.5 Z0.0 ; set drive mapping M92 X160.00 Y320.00 Z640.00 ; set steps per mm M566 X1800.00 Y180.00 Z120.00 ; set maximum instantaneous speed changes (mm/min) M203 X15000.00 Y12000.00 Z5000.00 I5 ; set maximum speeds (mm/min) M201 X400.00 Y200.00 Z200.00 ; set accelerations (mm/s^2) ;M564 H0 ; Allow stepper movement before homing ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X600 Y1200 Z170 S0 ; set axis maxima ;Machine Initialization M18 ; disable all steppers M17 ; enable z stepper so it doesn't falltest_movement.gcode
G90 G21 G1 Y500 F4000 G1 Y600 F4000 G1 Y500 F4000 G1 Y600 F4000 G1 Y500 F4000 G1 Y600 F4000 G1 Y500 F4000 G1 Y600 F4000 G1 Y500 F4000 G1 Y600 F4000M122
EmergencyStop pressed mid job via DWC
Channel 1 (yellow) is STEP-
Channel 2 (pink) is ENABLE-
there is a ENABLE low, when the Emergency Stop is pressed, then high again, then low, high, low again (low is off in this setup). I've tried it also the other was around with R1 - it just inverts the curve.
The Setup:
-
@timschneider If you still have the test system available, is there any chance you could run the test again but use M112 entered in the console rather than using the emergency stop button. The reason I ask is because the emergency stop button in DWC runs M112 followed by M999 so some of what you are seeing may be down to the software reset (M999) operation.
-
@gloomyandy sure. I did even more tests.
run M112 from console will change the behaviour a bit, the last disable / enable toggle will disappear. It appears to me, that a reset will also toggle the driver enable once.I've changed the test setup to be able to test the sbc setup.
Unfortunately, it will also fail, so there is also movement after the M112.the following screens are all taken with SBC setup 3.4.6
and the following config.gM669 K0 X1:0:0 Y0:1:0 Z0:0:1 S1 T1 ; Cartesian kinematics ; Drives M569 P0 R0 T1:1:2:0 M569 P1 R0 T1:1:2:0 M569 P2 R0 T1:1:2:0 M569 P3 R0 T1:1:2:0 M569 P4 R0 T1:1:2:0 M569 P5 R0 T1:1:2:0 M569 P0 S1 M569 P1 S1 M569 P2 S1 M569 P3 S1 M569 P4 S1 M569 P5 S1 G90 ; send absolute coordinates... M584 X0 Y4:5 Z3 ; set drive mapping M92 X400 Y400 Z800 ; set steps per mm 4000 steps/rev / 10 mm pitch - 5mm on z M566 X120.0 Y120.0 Z120.00 P1 ; set maximum instantaneous speed changes (mm/min) and apply jerk on every move M203 X10000.00 Y10000.00 Z7000.00 ; set maximum speeds (mm/min) M201 X400.00 Y500.00 Z1000.00 ; set accelerations (mm/s^2) M204 P250 T1250 ; Set printing and travel accelerations M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X1330 Y1036 Z278 S0 ; set axis maxima ; Mode Selector M453 ; Select CNC Modewithout M669 S1 T1
with M669 S1 T1
with M112 in console
with Emergency Stop in DWC
-
@timschneider What a relief to hear this is reproducible, I was starting to get really depressed. And you beat me to yanking my 6xd out of the cabinet and wiring resistors on an unconnected drive output on the 6xd. That was literally gonna be my next course of troubleshooting.
I took a vacation day today, so I'm about to test the Z (although your test all but confirm this is board/firmware behavior). Will post vid shortly.
-
I did some more test, as I was not able to see this behaviour in my last cnc build. So I was recording the STEP and Enable Signal for the other driver 0,1,2,3 and 5 as well, all with M112 mapped to the Y-axis.
M584 X4 Y0:1:3:5 Z2
and
M584 X4 Y0:1:2:5 Z3btw. the resistors are all 15k
driver0
driver1
driver2
driver3
driver5
-
it looks like the motion system takes some time to shut down - so is it possible that the following will reactivate the drive again after an EmergencyStop?
In the function
void DDA::Prepare(SimulationMode simMode) noexcept
-
@timschneider Obviously my scope is way worse than Tim's so I would reference Tim's scope grabs over my shoddy videos, but I'm trying to do what I can...
Z stepper test with M112 in job
Z stepper test with no M112 in job, using DWC EStop
And lastly...
Z stepper test using external estop trigger with T0That last one, in my mind, all but confirms there is a wait delay in that driver after enable is reactivated, and depending on how long the Duet keeps it enabled, eventually it too does move, but reacts to disabling immediately.
-
@hpiz I was using the 6XD quite a while without noticeing, so I think it is a good teamwork!
and I guess I maybe found the place where the delay kicks in
when the seperate move thread was added, the active switch fall overboard and it appears to me, that
TerminateAndUnlinkneeds some time to terminate and unlink, and in the meantime, new moves are prepared, and the prepare move is enableing the drive again. -
@timschneider @hpiz Thanks for all your investigative work, I've flagged this to @dc42.
Ian
-
Hi all, so does this issue occur only when using external drivers, for example with a 6XD?
Does it occur only in SBC mode?@timschneider which source code branch are you looking at? The current 3.5-dev and 3.4-dev source code has this for Move::Exit:
void Move::Exit() noexcept { StepTimer::DisableTimerInterrupt(); rings[0].Exit(); #if SUPPORT_ASYNC_MOVES rings[1].Exit(); #endif #if SUPPORT_LASER || SUPPORT_IOBITS delete laserTask; laserTask = nullptr; #endif moveTask.TerminateAndUnlink(); }That should be sufficient to stop all movement.
@hpiz which firmware version are you using?
PS - when Emergency Stop is pressed in DWC, it sends M112 and then after a little while it sends M999 to reset the Duet. At the reset the driver Enable signal may go to Enabled again, depending on its polarity. But by then the movement queue is empty because RRF has re-initialised.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42
sorry I was referring to the commit where the Move Task was added.
But you give the right hint, I was looking in the wrong direction, as it can bee seen from the oscilloscope that the stop of the step generation is delayed. So I guess, another code beforeMove::Exitis delayed or the very first lineStepTimer::DisableTimerInterruptis slow.
I'll be back in the office on monday, then I can do the above tests with Duet 3 6HC.
hpiz is using 3.4.6 - from the debug log
power up + 00:00:00 [info] Running: Duet 3 MB6XD v1.01 or later: 3.4.6 (2023-07-21 14:11:58) -
@dc42 Hi, I have a Duet 2 I could test 3.4.6 with to see steps on my analog scope. Not sure if that helps...
-
All, when you see this behaviour is it just the remainder of the current move that continues to execute after a pause? The Move::Exit code empties the movement queues but I'm wondering whether the step interrupt might be getting re-enabled and perhaps that might cause the current move to complete.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 From my experience, it would seem it is just continuing with the moves it was already performing. For example, I don't really see any behavior difference between the following two GCode jobs...
G90 G21 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 M112 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000vs
G90 G21 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 G1 Y500 Z100 F4000 G1 Y600 Z0 F4000 M112The M112 seems to be executed as it's read into the buffer, around the second movement loop, it then tries to complete the third loop after a brief stop (0.25 secs), nothing after M112 seems to ever try to execute, so that's good. Not sure if this matters, but the continued moves seem to move beyond where they should, which in my mind could only happen if more steps are sent than should. I'm gonna test my Duet 2 ethernet today (will post back maybe 2 hours from now) and see if it's got the same step continuation.
As far as the code goes, I wish I could help more but I mostly make websites in C#. Though, I will keep trying.
-
@dc42 My Duet 2 does not produce pulses after M112 running 3.4.6
Note: The scope is in trigger mode
-
Thanks all, I'll be away at FormNext for a week but I'll look into this as a matter of urgency when I return.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 we have to thank you for your very fast response and in the middle of the preperation for the Formnext!
@dc42 said in Movement after M112 E-Stop!:
All, when you see this behaviour is it just the remainder of the current move that continues to execute after a pause?
To check that, I did another test. Setup as above with SBC. Jobfile the following:
G90 G21 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60 G1 Y0 F60 G1 Y1 F60So every move is around 1 sec (F60 is within the jerk so i guess there is not much acceleration). Based on that, the delay should be less than 1-1.5s, but in fact, it is again around 3.5s (3.46s) as in all the samples above, regardless of the movement length and speed.
So from my understanding, it is not only the remainder of the current move. -
@timschneider
I think the problem is in the IterateDrivers Function in the Platform.cppthe following code snippets are based on the 3.4-dev branch
The else if branch will disable all extruders, but the problem is, that it will start working from GetTotalAxes() to MaxAxesPlusExtruders. But there are only MaxExtruders allowed.
That means in numbers for the MB6XDMaxAxesPlusExtruders = 25 GetTotalAxes() = 3 in this case XYZ MaxExtruders = 16So from 3 - 24 it will work with the else if branch
size_t LogicalDriveToExtruder(size_t drive) noexcept { return MaxAxesPlusExtruders - 1 - drive; } 25 - 1 - 3 = 21 25 - 1 - 4 = 20 ... 25 - 1 - 24 = 0 DriverId extruderDrivers[MaxExtruders] -> array of 16 elements so the following code will read some random data for the elements from 3 - 8 const DriverId id = extruderDrivers[LogicalDriveToExtruder(axisOrExtruder)]; and this code will sometimes end up in the remoteFunc e.g. in our case send can message and wait for a reply if (id.IsLocal()) { localFunc(id.localDriver); } else { remoteFunc(id); } but there will be no reply and this will delay the e-stop (stop step generation and clear the movement system) around 3 - 3.5 secI've changed the IterateDrivers the following:
// Function to identify and iterate through all drivers attached to an axis or extruder void Platform::IterateDrivers(size_t axisOrExtruder, function_ref<void(uint8_t)> localFunc, function_ref<void(DriverId)> remoteFunc) noexcept { if (axisOrExtruder < reprap.GetGCodes().GetTotalAxes()) { for (size_t i = 0; i < axisDrivers[axisOrExtruder].numDrivers; ++i) { const DriverId id = axisDrivers[axisOrExtruder].driverNumbers[i]; if (id.IsLocal()) { localFunc(id.localDriver); } else { remoteFunc(id); } } } else if (axisOrExtruder >= (MaxAxesPlusExtruders - MaxExtruders) && axisOrExtruder < MaxAxesPlusExtruders) { const DriverId id = extruderDrivers[LogicalDriveToExtruder(axisOrExtruder)]; if (id.IsLocal()) { localFunc(id.localDriver); } else { remoteFunc(id); } } }But this will only address the delay - I think this is a good time to add a secondary layer to prevent the EnableSignale from getting high again. (Because of the delay, prepare moves where re-enableing the drivers again)
platform.cpp
src/Platform/Platform.cpp | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/Platform/Platform.cpp b/src/Platform/Platform.cpp index c8f7793c..fdd6f2d3 100644 --- a/src/Platform/Platform.cpp +++ b/src/Platform/Platform.cpp @@ -424,7 +424,7 @@ Platform::Platform() noexcept : #if HAS_MASS_STORAGE logger(nullptr), #endif - board(DEFAULT_BOARD_TYPE), active(false), errorCodeBits(0), + board(DEFAULT_BOARD_TYPE), active(false), preventDriverEnable(true), errorCodeBits(0), nextDriveToPoll(0), lastFanCheckTime(0), #if SUPPORT_PANELDUE_FLASH @@ -861,6 +861,7 @@ void Platform::Init() noexcept DuetExpansion::DueXnTaskInit(); // must initialise interrupt priorities before calling this #endif active = true; + preventDriverEnable = false; } // Reset the min and max recorded voltages to the current values @@ -2439,7 +2440,7 @@ void Platform::IterateDrivers(size_t axisOrExtruder, function_ref<void(uint8_t)> } } } - else if (axisOrExtruder < MaxAxesPlusExtruders) + else if (axisOrExtruder >= (MaxAxesPlusExtruders - MaxExtruders) && axisOrExtruder < MaxAxesPlusExtruders) { const DriverId id = extruderDrivers[LogicalDriveToExtruder(axisOrExtruder)]; if (id.IsLocal()) @@ -2572,7 +2573,7 @@ void Platform::DisableOneLocalDriver(size_t driver) noexcept // Enable the local drivers for a drive. Must not be called from an ISR, or with interrupts disabled. void Platform::EnableDrivers(size_t axisOrExtruder, bool unconditional) noexcept { - if (unconditional || driverState[axisOrExtruder] != DriverStatus::enabled) + if (unconditional || (driverState[axisOrExtruder] != DriverStatus::enabled && !preventDriverEnable)) { driverState[axisOrExtruder] = DriverStatus::enabled; const float requiredCurrent = motorCurrents[axisOrExtruder] * motorCurrentFraction[axisOrExtruder];platform.h
src/Platform/Platform.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/Platform/Platform.h b/src/Platform/Platform.h index c3f006b4..4f2b2196 100644 --- a/src/Platform/Platform.h +++ b/src/Platform/Platform.h @@ -528,7 +528,7 @@ public: uint32_t GetSteppingEnabledDrivers() const noexcept { return steppingEnabledDriversBitmap; } void DisableSteppingDriver(uint8_t driver) noexcept { steppingEnabledDriversBitmap &= ~StepPins::CalcDriverBitmap(driver); } - void EnableAllSteppingDrivers() noexcept { steppingEnabledDriversBitmap = 0xFFFFFFFFu; } + void EnableAllSteppingDrivers() noexcept { if (!preventDriverEnable) { steppingEnabledDriversBitmap = 0xFFFFFFFFu; } } #ifdef DUET3_MB6XD bool HasDriverError(size_t driver) const noexcept; @@ -643,6 +643,8 @@ public: const GpInputPort& GetGpInPort(size_t gpinPortNumber) const noexcept pre(gpinPortNumber < MaxGpInPorts) { return gpinPorts[gpinPortNumber]; } + void SetPreventDriverEnable() noexcept { preventDriverEnable = true; } + #if MCU_HAS_UNIQUE_ID const UniqueId& GetUniqueId() const noexcept { return uniqueId; } uint32_t Random() noexcept; @@ -742,6 +744,7 @@ private: #endif bool active; + bool preventDriverEnable; uint32_t errorCodeBits; void InitialiseInterrupts() noexcept;RepRap.cpp
src/Platform/RepRap.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/Platform/RepRap.cpp b/src/Platform/RepRap.cpp index 5d5a28aa..168619c4 100644 --- a/src/Platform/RepRap.cpp +++ b/src/Platform/RepRap.cpp @@ -1004,6 +1004,7 @@ void RepRap::EmergencyStop() noexcept else #endif { + platform->SetPreventDriverEnable(); // prevent any conditional call to EnableDrivers platform->DisableAllDrivers(); // disable all local and remote drivers - need to do this to ensure that any motor brakes are re-engaged switch (gCodes->GetMachineType())With these changes, there will be no delay at all after the estop is pressed in DWC and processed by RRF.
-
@hpiz so I've recompiled a clean version of the 3.4-dev branch with only the IterateDrivers fix pull request on github.
This is not a production version and only for testing purpose, it is based on the current 3.4-dev branch and only for MB6XD. Use on your own risk.
Maybe you can try, and we can see if this will fix the problem for you too.
