M1 issues with Slic3r PE Single Extruder Multi Material option

[keyz182]

I've now gotten my printer to work doing multi material using Slic3r PE and it's Single Extruder Multi Material option. The only issue remaining is that I need to manually edit the gcode before sending to print.

It seems after priming, but before printing, this snippet is added:

G1 E-1.40000 F7500.00000
G1 F9600;_WIPE
G1 X121.562 Y5.760 E-1.99500
G1 E-0.10500 F7500.00000
G1 Z0.500 F12000.000
M300 S800 P500
M1 S10
M900 K0
G1 E-1.25000 F7500.00000
G1 X253.966 Y144.229 F12000.000
G1 Z0.300
G1 E5.75000 F2100.00000

For me, the print ends unless I remove the M1. My understanding is that even though it behaves slightly differently to the Marlin M1 in that it wont pause for 10 seconds, it should, if followed by an M or G command on the Duet, resume.

Could it be in this case that even though it's followed by an M command in M900 K0, that because that's not valid on Duet, it's assuming the end of the print?

I'm not sure if this would be a bug, or expected behaviour. Could it be made to assume that even if the M (or G) command following the M1 should unpause even if it's not a valid one.

Would M555 P2 help here, or would the M900 still being invalid have the same effect?

[timcurtis67]

If you need a 10 second pause then you add a G4 (pause ) command.

See https://duet3d.dozuki.com/Wiki/GCode#Section_G4_Dwell

[keyz182]

@timcurtis67 I don't need the 10 seconds, it's inserted automatically be Slic3r PE. I just edit it out. My issue is that without editing it out, the printer decides that the print is finished at that point.

I will post up a bug report to Slic3r PE github, but want to figure out if this is considered correct behaviour or a bug on Duet before doing so.

[deckingman]

@keyz182 The Wiki (https://duet3d.dozuki.com/Wiki/GCode#Section_M1_Sleep_or_Conditional_stop) states...

"The firmware finishes any moves left in its buffer, then shuts down. All motors and heaters are turned off. It can still be sent G and M codes, the first of which will wake it up again."

So although a subsequent G or M code might wake it up, if the motors have been turned off, then the printer will show as not homed. So if you did manage to wake it up again, you'd have to re-home the printer an turn on the heaters etc.

Maybe that M1 will work with Prusa's version of firmware - I'm assuming it does. If that is the case, then it's not likely that the authors of Prusa Edition Slic3R will see it as bug.

[keyz182]

@deckingman They do seem to be supporting non Prusa printers, just at a lower priority. They recently added send to printer functionality for duet.

The output compatibility mode was set to RepRap, but I guess they've not been fully obeying that. I'll take a look and see if I can put together a pull request to take that into account.

[deckingman]

@keyz182 Are you sure the PE version supports the send to Duet functionality? I thought that was the the non PE version of Slic3R but I'm happy to be corrected if that is the case. I use Slic3r myself but not the latest versions. I have "std Slic3r" version 1.3.1 dev and PE version 1.40 so both or mine are a bit out of date.

I'm leaning more towards using the non PE version myself because some of the stuff that the PE version does makes it a bit of pain to use with my Diamond mixing hot ends (multiple inputs running concurrently into a single nozzle). The PE version seems to be diverging away from the functionality required of mixing hot ends.

[keyz182]

@deckingman yeah, definitely in PE, 1.41. Their focus is on the MMU style setup, so makes sense it's diverging. While they do support non Prusa stuff, Prusa is obviously the focus.