@DonStauffer that's as expected in RRF 3.5. Where a parameter expects an array, you must either provide a colon-separated list of plain values, or an array-valued expression; except that if the array is allowed to have length 1 then you may instead provide either a single plain value or a non-array expression of the appropriate type. So in your examples 5, 6 and 7 everything following B{ ... } is ignored.

@mikeabuilder extruders don't have position limits. The recommended way to wait for motion to stop is to use M400.

@chrishamm thanks, chris!

@Nazar what do you mean that the Z positions is not consistent?

@dc42 Just to clear with the build as of 27th Mar, the version of the file using M3.8 directly does not seem to delay when you might expect it to. The version using M98 to run the same macro file does delay as expected.

I've just tried the same test files on a Duet3 running 3.5.0-rc.3+8 and see the same "odd" behaviour with the macro being "called" as a substitute for a gcode then the dwell does not happen when expected (they seem to happen at the end of the print), but with the same macro call using M98 then the dwell happens as expected.

These are the test files I used on the duet3, first the file I print (from my "jobs" directory):

G92 X0 Y0 M564 H0 ;(Home) ;G28 ;(Movement Configuration) G90 G21 ;(Park ppindle) ;(Move to center of table) G0 X150 ;(Start spindle) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #1" } M3.8 S24000 I1 ;M98 p"M3.8.g" S24000 I1 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #1" } ;(Do some moves) G0 X100 G0 X0 G0 X200 G0 X100 G0 X40 ;(Change spindle speed) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #2" } M3.8 S12000 I2 ;M98 p"M3.8.g" S12000 I2 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #2" } ;(Do some more moves) G0 X50 G0 X0 G0 X200 G0 X100 G0 X80 G0 X150 ;(Stop spindle) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #3" } M3.8 S0 I3 ;M98 p"M3.8.g" S0 I3 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #3" } G0 X0 echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] File complete" }

Then the M3.8 macro (that goes in system):

;if { !inputs[state.thisInput].active } ; M99 var dwellTime = 10 echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] Waiting " ^ var.dwellTime ^ " seconds for spindle to change speed - #" ^ param.I } G4 S{var.dwellTime} echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] Finished waiting for spindle to change speed - #" ^ param.I }

Note my Duet3 is a bench test system that only has a single stepper motor attached (as X) and has no homing switches hence the changes to allow the print file to run. I don't think any of these changes make any difference to the problem described here.

@kerfun I got a solution that does what I wanted to do. I have my power off script now that looks like this:

var now = state.time var timeOut = 60 M98 P"0:/macros/YesNoInput.g" H"Shutdown Requested" S"Start the shutdown procedure?" T{var.timeOut} var startShutdown = true if state.time - var.now >= {var.timeOut} set var.startShutdown = true elif input == null set var.startShutdown = false if var.startShutdown == true echo "shutdown started" M18 ; Turn off motors M568 H1 R41 S0 ; Set hotend standby to 41 and active to 0 M568 H1 A1 ; Set hotend to standby temp M140 S0 ; Set bed to 0 M116 H1 ; Wait for hotend to reach 41 degrees (This is the lowest you can wait for a temp) M568 H1 A2 ; Set hotend back to active M42 P0 S1 ; Turn bed ps off M42 P1 S1 ; Turn main ps off

And then I have my YesNoInput.g file that looks like this:

M291 R{param.H} P{param.S} K{"Yes",} S4 F"Yes" T{param.T} J1

When the print is done I have the slicer always call the shutdown macro. When the shutdown macro runs it will ask the user if they want the printer to power down (in case they want to keep printing). If the user presses "Yes" the printer will start the shutoff procedure (the shutdown procedure usually takes pretty long because I want to wait for the hotend to cool off). If the user doesn't press any buttons on the message the printer will shut off. If the user presses "cancel" before the 60 seconds, the printer will stay on.

If you have multiple tools, you might also not have the extruders assign in order (example extruder 0 assigned to tool1). You might also have two extruders assigned to one tool. In these cases, you need to use look at the tools section of the Object model where you can find an array of objects in tools.extruders. For each tool, the array maps that tools extruders to the move.extruder number.

start.g is a good place to put any sanity checks in.

Check docs.duet3d.com for setting up triggers if you also want to do things like automatic pauses when the door is opened.

Look into daemon.g for continuously repeating tasks.

Check the Gcode meta command language and object model to tie it all together.

@dc42 yes that would work as well for the particular usecase of naming a file with a datetime that's a valid filename. Its less generalisable than being able to use just the date or just the time - but that's not necessarily an urgent requirement.

It depends on the overhead to implement various types of string handling.

@chrishamm Thank you very much I'll stick with the G4 in the macro then. Will report if the event occurs

@oliof Thank you, that was it - missed that in the docs

@gloomyandy Perfect, that did the trick. Thank you.

@Mike-1 said in Muti tool setup:

Warning: Obsolete use of S parameter on G1 command. Use H parameter instead.

This is because you are using S instead of H in the G1 command, see:

https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g0g1-h-and-s-parameter

@D-J-Klomp

similar tot his thread;
https://forum.duet3d.com/topic/35152/emergency-stop/11
Did you try M0?

@oliof true, if we were looking at this now and not in 2014 then it might be different!

@modl thanks for sharing that.

In the future I have it in mind to be able to use the second file reader to run a simulation of the print in parallel with but ahead of the actual print. The simulation would be able to warn about upcoming tool changes, allowing for automatic tool preheat.

@jay_s_uk

That will do the trick, thank you 🙂

@Mogatek I confirm that this is not possible at present. Please raise an issue at https://github.com/Duet3D/RepRapFirmware/issues.

@gloomyandy said in Position Verification Floor / Ceil inconsistencies.:

@NineMile I would also check that the machine that is showing the problem is actually running 3.5 rc3 (get a M122 output from it, unfortunately people sometimes get things wrong).

This was the first thing I asked for as I thought the issue was the machinePosition update delay on RC2 and below. It's definitely on RC3 and we're looking to test on more boards soon.

@amimafe

Thanks for the feedback.

Frederick