Delay response for Macro called during printing
-
@dc42 and all
-
There is delay response when using Macro file, which has M106/M42 in it, to control the LED ON/OFF during printing on PanelDue. I guess there is some delay to load the Macro,however there is no delay if I send M106/M42 directly and not through Macro. How can I know the the immediate action after Macro file clicked?
-
Duet MCU has to print with queue and clean all the commands already in queue before. I have one case have to stop Extruder immediately as below. Any command or any method for it?
For filament loading, refer to UM firmware, there are 3 speed types, slow(insert to extruder), fast(load in PTFE), slow(load in hotend). For the last step "slow(load in hotend)", it can stop immediately after we see the material comes out from nozzle by click the confirm button, however it is not emergency stop. Is there any way to implement this?
-
-
G1 E500 F300
M291 P"Forwarding material! Wait till material comes out the nozzle" S2Something like above, I need to stop extruder at anytime. It can easily implement this on Marlin firmware with "plan_set_e_position(0);". However I don't know how can Reprap firmware implement this.
-
Anyone has such requirement?
-
@hestiahuang said in Delay response for Macro called during printing:
- There is delay response when using Macro file, which has M106/M42 in it, to control the LED ON/OFF during printing on PanelDue. I guess there is some delay to load the Macro,however there is no delay if I send M106/M42 directly and not through Macro. How can I know the the immediate action after Macro file clicked?
M106 and M42 commands that occur within a GCode stream (directly, or indirectly via a macro call) will be synced to the GCode movement stream. So those commands will be delayed until any movement commands that were encountered before them have completed.
- Duet MCU has to print with queue and clean all the commands already in queue before. I have one case have to stop Extruder immediately as below. Any command or any method for it?
For filament loading, refer to UM firmware, there are 3 speed types, slow(insert to extruder), fast(load in PTFE), slow(load in hotend). For the last step "slow(load in hotend)", it can stop immediately after we see the material comes out from nozzle by click the confirm button, however it is not emergency stop. Is there any way to implement this?
Currently there is no command to stop movement without doing an emergency stop. If you are using a Duet WiFi or Duet Ethernet, have you considered using extruder stall detection to stop feeding filament when resistance is encountered?
-
@dc42 said in Delay response for Macro called during printing:
@hestiahuang said in Delay response for Macro called during printing:
- There is delay response when using Macro file, which has M106/M42 in it, to control the LED ON/OFF during printing on PanelDue. I guess there is some delay to load the Macro,however there is no delay if I send M106/M42 directly and not through Macro. How can I know the the immediate action after Macro file clicked?
M106 and M42 commands that occur within a GCode stream (directly, or indirectly via a macro call) will be synced to the GCode movement stream. So those commands will be delayed until any movement commands that were encountered before them have completed.
- Duet MCU has to print with queue and clean all the commands already in queue before. I have one case have to stop Extruder immediately as below. Any command or any method for it?
For filament loading, refer to UM firmware, there are 3 speed types, slow(insert to extruder), fast(load in PTFE), slow(load in hotend). For the last step "slow(load in hotend)", it can stop immediately after we see the material comes out from nozzle by click the confirm button, however it is not emergency stop. Is there any way to implement this?
Currently there is no command to stop movement without doing an emergency stop. If you are using a Duet WiFi or Duet Ethernet, have you considered using extruder stall detection to stop feeding filament when resistance is encountered?
@dc42 , really appreciate for your reply with the cube.
For the item#1, If I control the LED via FAN3 button on DWC, it can take the effective immediately, the turn on or turn off, even it is in printing status. Refer to the log on DWC, it calls M106 directly to control it.
However I setup a marco file on PanelDue, and it just include the same command M106. then there is delay about turn on/off LED while it is printing status. I guess it is due to M98, firmware have call M98 first. Then it has to wait for the M98 run and open the macro to load M106. Is there any way to make M106 take immediate effective via macro from PanelDue?For the item#2, your reply is awesome, 'extruder stall detection' is really a cube to me. I will try to check the details and have a try.
-
@hestiahuang said in Delay response for Macro called during printing:
However I setup a marco file on PanelDue, and it just include the same command M106. then there is delay about turn on/off LED while it is printing status. I guess it is due to M98, firmware have call M98 first. Then it has to wait for the M98 run and open the macro to load M106. Is there any way to make M106 take immediate effective via macro from PanelDue?
M106 run from PanelDue, whether directly or via a macro, should take effect more or less instantly unless the firmware is waiting to complete the previous command sent from PanelDue.
-
@dc42 said in Delay response for Macro called during printing:
@hestiahuang said in Delay response for Macro called during printing:
However I setup a marco file on PanelDue, and it just include the same command M106. then there is delay about turn on/off LED while it is printing status. I guess it is due to M98, firmware have call M98 first. Then it has to wait for the M98 run and open the macro to load M106. Is there any way to make M106 take immediate effective via macro from PanelDue?
M106 run from PanelDue, whether directly or via a macro, should take effect more or less instantly unless the firmware is waiting to complete the previous command sent from PanelDue.
I don't use the SD Card socket on PanelDue, there should be no gcode data via 4 serial lines, just print from Duet mainboard TF card. Do you mean the data to fresh the PanelDue?
-
@hestiahuang said in Delay response for Macro called during printing:
@dc42 said in Delay response for Macro called during printing:
@hestiahuang said in Delay response for Macro called during printing:
However I setup a marco file on PanelDue, and it just include the same command M106. then there is delay about turn on/off LED while it is printing status. I guess it is due to M98, firmware have call M98 first. Then it has to wait for the M98 run and open the macro to load M106. Is there any way to make M106 take immediate effective via macro from PanelDue?
M106 run from PanelDue, whether directly or via a macro, should take effect more or less instantly unless the firmware is waiting to complete the previous command sent from PanelDue.
I don't use the SD Card socket on PanelDue, there should be no gcode data via 4 serial lines, just print from Duet mainboard TF card. Do you mean the data to fresh the PanelDue?
No, I mean any command you sent previously from PanelDue that might take some time to execute. For example, a tool change command if your tool files wait for temperatures to be reached; or a homing command.
-
@dc42 said in Delay response for Macro called during printing:
@hestiahuang said in Delay response for Macro called during printing:
@dc42 said in Delay response for Macro called during printing:
@hestiahuang said in Delay response for Macro called during printing:
However I setup a marco file on PanelDue, and it just include the same command M106. then there is delay about turn on/off LED while it is printing status. I guess it is due to M98, firmware have call M98 first. Then it has to wait for the M98 run and open the macro to load M106. Is there any way to make M106 take immediate effective via macro from PanelDue?
M106 run from PanelDue, whether directly or via a macro, should take effect more or less instantly unless the firmware is waiting to complete the previous command sent from PanelDue.
I don't use the SD Card socket on PanelDue, there should be no gcode data via 4 serial lines, just print from Duet mainboard TF card. Do you mean the data to fresh the PanelDue?
No, I mean any command you sent previously from PanelDue that might take some time to execute. For example, a tool change command if your tool files wait for temperatures to be reached; or a homing command.
Actually, I don't send any command from PanelDue.
Take this example- Print Gcode model file from DWC, and then I go away
- 10 or 20 mins later, I come back and I found the LED is still turned on.
- I touch PanelDue, and click the 'Turn Off LED' macro, there is deplay of the "Off effective"
or - I open DWC, and click the 'Turn Off LED' button, there is no deplay of the "Off effective"
Just tested many times, it is not related to PanelDue
-
Turn off LED via DWC page by glide bar => no delay.
-
Turn off LED via DWC page Macro => there is delay.
-
When the command is inside a macro file, how long is the delay?
-
@dc42 said in Delay response for Macro called during printing:
When the command is inside a macro file, how long is the delay?
Only one line command in Macro. Sometimes it needs 1~2 seconds, sometimes it needs around 5 seconds. It makes me confused and I doubt that if I have run Macro or not. The important point is it just happens while machine is printing.