Switch I/O pins during macros?

[stevenim]

Can you switch I/O pins with the M42 command during a macro or home?

[Phaedrux]

I believe so. What specifically are you trying to do?

[stevenim]

I'm just trying to set set a pin high during macros/homing routine by calling "M42 P0 S1" although I find that it isn't working.

FYI, I'm sending HTTP GET requests over Ethernet with my Duet 3 MB6HC v1.01 board running Firmware version 3.1.1

[JoergS5]

@stevenim did you allocate the GPIO with M950?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M42_Switch_I_O_pin

[stevenim]

Yup. Even with the DWC I can switch the pin but the moment I home, I can't switch until after the home.

[JoergS5]

@stevenim Moving may have higher priority than Http requests/M42. (generating the steps use interrupt requests which will be higher than the http). You could try a slower homing, so the lower priority interrupt has a chance.
see dc42

[dc42]

@stevenim said in Switch I/O pins during macros?:

Yup. Even with the DWC I can switch the pin but the moment I home, I can't switch until after the home.

Each GCode channel can only execute one command at a time. So if you send a G28 command followed by a M42 command over the same channel, it will complete the G28 command before it executes the M42 command. OTOH if you send G28 on one channel and then M42 from another, they will execute concurrently, subject to some locking mechanisms (e.g. only one channel can command movement at a time, the other will wait).

[stevenim]

@dc42 Does this specifically pertain to macros? I'm able to switch i/o pins during regular moves such as G0/G1. As in, while the motor is moving, I can send an M42 command to a pin just fine.

[Hugsy]

I'm trying the same thing, I need to get out of a while loop with a software trigger.
My current idea was to have "sensors.probes[1].value[0] == 0" as the while condition and have a i/o pin send current to the probe port.
But when in the macro that contains the while loop is being executed, it's impossible to send a M42 command to get out of the while loop.
Any ideas how could I get it done? I'm down to modify the firmware just to have it working if it means giving M42 the priority over a M98 command.

[Phaedrux]

@hugsy Probably a good idea to create a new thread for your problem in the gcode meta command forum.
https://forum.duet3d.com/category/34/gcode-meta-commands

[Tinchus]

@dc42 How do you choose wich channel to use and what specifically a channel is?

[dc42]

@tinchus a channel is an input source, normally one of: USB, http (e.g. from DWC) aux (e.g. PanelDue), SD card print, trigger (from a M581 trigger firing), daemon, or autopause (for executing the power fail script).

[Tinchus]

@dc42 this is super usefull information. Lets see if I uderstood correctly. For example: if I have a print going on, wich is launch from the DWC interface, i guess that is HTTP channel, if I have a macro lauched from daemon.g, that would be a separate channel, so the execution of that macro will not stop or affect the execution of the gcode buffer in any way, is that corret? because both run in different channel so they are parallel processes, is that right?

[dc42]

@tinchus that's correct, except that a print from SD card is executed by the File channel regardless of which channel launched it. The channels execute in parallel except when they compete for a resource such as the motion system.

[Tinchus]

@dc42 When they compete with motion system... That explain my problem about this. My macro trigger the use of an extra stepper motor, which is connected to a driver on an expansion board. So depending on the printing speed, Im detecting strange "pauses" either on the gcode printing or in the time the extra motor moves..
Now I understand why, the re is a competition for the motion system even when this extra motor is not really part of the motion of the printer, it is just vor moving a heavy filament spool, but I guess since it is using a stepper driver, it is considered part of the motion system?