M400 / G4 P0 Not working?

dc42

Which Duet are you using?
If it is a Duet 3, is it with/without RPi?
If it is Duet 3 with RPi, what versions of DSF are you using?

RobMink

Sorry, yes, Duet3 with 3 exp boards, RPI4 with DSF 2.1.4

The Servo is on the main board and the core xy moment system is on the EXP1 board. Could that be causing the issue?

dc42

@RobMink said in M400 / G4 P0 Not working?:

Sorry, yes, Duet3 with 3 exp boards, RPI4 with DSF 2.1.4

2.1.4 sounds like the DWC version. Please check the DSF version.

RobMink

Sorry, I forgot what the abbreviation was and had to look it up. I gleaned this from the apt-get upgrade

Setting up duetsoftwareframework (2.1.0) ...
Thanks again!

dc42

Are you able to run in standalone mode temporarily and see if the problem still occurs? You don't need to disconnect the Pi to run in standalone mode.

PS - you can verify the DSF version in DWC, it's shown in Settings->Machine Specific along with the firmware version.

chrishamm

I tried to reproduce this problem on my test setup but failed to do so. Can you please hook up a computer to your Duet 3, open a serial monitor, run M111 P3 S1, try to provoke the problem once again, and post the output here? You can disable debugging after that again by running M111 S0.

dc42

One further question: if you run the tpre3.g file manually by sending M98 P"tpre3.g"), does the problem still occur?

RobMink

@dc42

Thanks for the info!

If I run the command M98 P"tpre3.g" it works, but if I just go T0 T3 it does not. T0 will load correctly the first time, then exhibit the same behavior. I apologize if this is a bug on my end!

EDIT: I tried plugging the duet into my laptop and running pronterface. I get "Board 1 does not have input handle 1000" when I try and home until I reboot the printer afterwards.

dc42

@RobMink said in M400 / G4 P0 Not working?:

If I run the command M98 P"tpre3.g" it works, but if I just go T0 T3 it does not. T0 will load correctly the first time, then exhibit the same behavior. I apologize if this is a bug on my end!

No bug at your end, I'm just trying to identify the circumstances that cause the problem. Did you have a chance to try standalone mode? EDIT: and/or getting a debug trace from RRF as chrishamm suggested.

EDIT: I tried plugging the duet into my laptop and running pronterface. I get "Board 1 does not have input handle 1000" when I try and home until I reboot the printer afterwards.

That message normally means that the expansion board was reset (e.g. because of a firmware update, reset button being pressed, or firmware crash) and config.g hasn't been run since then. If you think this problem is reproducible without a deliberate reset, please let us know and post the result of M122 and M112 B1.

RobMink

I tried a USB connection again, and this time it (USB) worked. Not sure what caused the issue the first time.

SENDING:M111 P3 S1
Debugging enabled for modules: GCodes(3)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) WiFi(14) Display(15) LinuxInterface(16)
>>> T0
SENDING:T0
USB: T0
USB: G1 X96 Y760 F5000
USB: G1 Y830 F2400
USB: M400
USB: M280 P0 S150
USB: G4 P500
USB: G1 Y800 F2400
USB: G1 Y760 F3600
USB: M116 P0
USB: M105
>>> T3
SENDING:T3
USB: T3
USB: G1 X96 Y760 F5000
USB: G1 Y800 F1200
USB: M280 P0 S40
USB: G1 Y830 F2400
USB: G1 Y760 F2400
Queue: M280 P0 S40
USB: G1 X306 Y760 F5000
USB: G1 Y830 F2400
USB: M400
USB: M280 P0 S150
USB: G4 P400
USB: G1 Y800 F2400
USB: G1 Y760 F3600
USB: M105

All the edits! Oops!

Ok, so a little clarification, the tool 0 docking in the last chunk after T3 ends at USB: G1 Y760 F2400 and T3 picks up at USB: G1 X306 Y760 F5000

dc42

Thanks. You sent the T0 and T3 commands from USB this time. Did the problem occur when you selected T0, with no tool initially selected? Did it occur when you changed from T0 to T3?

I think I've spotted a problem:

T3
SENDING:T3
USB: T3
USB: G1 X96 Y760 F5000
USB: G1 Y800 F1200
USB: M280 P0 S40
USB: G1 Y830 F2400
USB: G1 Y760 F2400
Queue: M280 P0 S40
; T0 finished docking at this point
USB: G1 X306 Y760 F5000
USB: G1 Y830 F2400
USB: M400
USB: M280 P0 S150
USB: G4 P400
USB: G1 Y800 F2400
USB: G1 Y760 F3600
USB: M105

What I think is happening is that you have a M280 P0 S40 command in tfree.g and it is that command that is still being executed when the next tpre is run. RRF can't tell when the servo has finished responding to that command.

RobMink

It happend after I went from T0 to T3.

M280 P0 S40 is the tool release command, and the M280 P0 S150 tool grab command happens before the printer isin position to grab the tool.

Here is

; tfree0.g
; called when tool 0 is freed
G1 X96 Y760 F5000 
G1 Y800 F1200
M280 P0 S40
G1 Y830 F2400
G1 Y760	F2400

Should I put a G4 P1000 or something in the end of this file and test?

dc42

@RobMink said in M400 / G4 P0 Not working?:

It happend after I went from T0 to T3.

M280 P0 S40 is the tool release command, and the M280 P0 S150 tool grab command happens before the printer isin position to grab the tool.

Here is
; tfree0.g
; called when tool 0 is freed
G1 X96 Y760 F5000 
G1 Y800 F1200
M280 P0 S40
G1 Y830 F2400
G1 Y760	F2400
Should I put a G4 P1000 or something in the end of this file and test?

Yes please, assuming 1 sec is long enough for the servo. Or put it directly after the M280 command, if you want the servo move to complete before the G1 Y830 command.

RobMink

Ok, I gave that a go. It releases the tool correctly and pulls back, pauses, but does the 'grab' command (M280 P0 S150) for T3 en route to T3. I can post a video if that would help.

dc42

Thanks. I'll see if I can reproduce that. I may ask for a video later.

RobMink

Upgrading all using a sudo apt-get/apt-upgrade to RC10 and removing the M400 fixed the issue.

dc42

@RobMink said in M400 / G4 P0 Not working?:

Upgrading all using a sudo apt-get/apt-upgrade to RC10 and removing the M400 fixed the issue.

Thanks, I suspected that it might because of this bug fix:

Non-movement commands that needed to be synchronised to the movement queue were sometimes executed too early

RobMink

@dc42

Yep! Thanks for all the great work! I thought it would give it a shot when I saw that release note.