M42 command delay



  • When I issue an M42, I've noticed a slight pause while the command is issued as this is not part of the move buffer. I need to turn on the output instantaneously without interrupting the move sequence. Is there any way to do this?

    I've tried utilizing M571 P24 S1 without success. If I issue an extrude command the output will fire, but then the controller will go into an unknown error state and reset once the move is completed. If I issue the M571 command I am not able to home without the controller going into the same error state.

    Before I spend to much more time trying to get the M571 to work, is this a viable solution or will I still see a delay turning the input on/off

    Firmware version 2.02(RTOS) (2018-12-24b1)



  • What is issuing the M42? And via what path? File? Macro? Triggered Macro? DWC console?



  • I am issuing the M42 via a path. I am using the output to open and close a pneumatic valve. I can account for the delay at the start of the move, but when the output turns off I need to continue moving..

    Current gcode is something like

    M42 open valve
    G4 dwell
    G1 XYZ
    M42 Close
    G1 XYZ

    The delay between the M42 close and the next G1 creates issues. I'm hoping to somehow mitigate this delay as much possible. In a perfect world I would be able to issue the G42 close command mid move, but I understand this is not feasible within the current firmware.


  • administrators

    @Eduma said in M42 command delay:

    I am issuing the M42 via a path. I am using the output to open and close a pneumatic valve. I can account for the delay at the start of the move, but when the output turns off I need to continue moving..

    Current gcode is something like

    M42 open valve
    G4 dwell
    G1 XYZ
    M42 Close
    G1 XYZ

    The delay between the M42 close and the next G1 creates issues. I'm hoping to somehow mitigate this delay as much possible. In a perfect world I would be able to issue the G42 close command mid move, but I understand this is not feasible within the current firmware.

    What I think is happening is that the G4 command suspends execution of the move until it completes; then the M42 command is executed; then the next G1 command is put in the queue. At that point the firmware waits for a short while to see whether any more movement commands arrive, in order to avoid stop-start movement. So if the next few movement commands are available immediately, there should be no delay.

    What commands do you have after that last G1 command?



  • @dc42

    Below is a sample of the actual code path to create to 2 dispense lines (very basic test path). I'm using a solenoid off pin pin 24 to open and close a valve to dispense a liquid. I'm using the G4 to account for the delay between the solenoid firing and the valve opening. The issue is when the valve closes the delay creates a blob of material. To counteract this I close the valve a few mm before the target position, similar to a coast command in a slicer program. This almost works, but the head will stop for a split second to issue the M42 command which still results in a blob at that point. It is my understanding that the M42 is not part of the movement buffer so their will be a delay to execute the command.

    I'm wondering if the M42 is the correct command to use or if I should further investigate the M571 (encountered some strange behavior on an initial test) or maybe try to use the laser/cnc mode as a work around.

    T1
    G01 Z 50.000000 F 20000.0
    G01 X 200.000000 Y 145.000000
    G01 Z 14.000000 F 20000.0 ;Penetrate
    M42 P24 S1 ;VALVE OPEN
    G04 P75.0 ;Valve Delay ms
    G01 X 200.000000 Y 75.000000 Z 14.000000 F 6000.000000
    M42 P24 S0 ;VALVE CLOSED
    G01 X 200.000000 Y 55.000000 Z 14.000000 F 6000.000000
    G01 Z 50.000000 F 20000.0
    G01 X 210.000000 Y 145.000000
    G01 Z 14.000000 F 20000.0 ;Penetrate
    M42 P24 S1 ;VALVE OPEN
    G04 P75.0 ;Valve Delay ms
    G01 X 210.000000 Y 75.000000 Z 14.000000 F 6000.000000
    M42 P24 S0 ;VALVE CLOSED
    G01 X 210.000000 Y 55.000000 Z 14.000000 F 6000.000000
    G01 Z 50.000000 F 20000.0

    M98 P"END.G" ;End of Program Macro


  • administrators

    I suspect the issue is that there are not enough movement commands between the M42 command to close the valve and the next G4 command. I will check whether the firmware delays starting movement in this case. If it does then I should be able to fix that.

    You might consider using M670 and the G1 P parameter instead.



  • @dc42

    I did not know that existed. I will look into M670 further and give that a shot



  • @dc42

    Is there any more details on how to properly utilize the P parameter in the G1 command. I didn't find much detail in the wiki.

    If I send M670 P24:P25 I am able to activate output 24 and 25 by adding a P1 or P2 to the G1 commands. Is there a way to activate multiple outputs during the move. I tried adding P1:2 without any luck.


  • administrators

    @Eduma said in M42 command delay:

    @dc42

    Is there any more details on how to properly utilize the P parameter in the G1 command. I didn't find much detail in the wiki.

    If I send M670 P24:P25 I am able to activate output 24 and 25 by adding a P1 or P2 to the G1 commands. Is there a way to activate multiple outputs during the move. I tried adding P1:2 without any luck.

    I presume you used M670 P24:25.

    P3 will activate both. The P parameter is a bit map of output numbers (whose mapping is defined by M670) that you want to activate.



  • @dc42

    that seems to do the trick. I'll have to some more testing.

    Thank you for the prompt response.


  • administrators

    In RRF 3.01RC3, which I hope to release tomorrow, I've also changed the scheduler to avoid the small delay between M42 and the next G1 command starting that you might get in some situations.



  • @dc42

    Utilizing the M670 command greatly improved response time. What I've seen is that once a P command is issued in a G1 move, the output will continue to trigger in any subsequent G1 or G0 moves until a P0 is issued. Is this intended behavior?


  • administrators

    @Eduma said in M42 command delay:

    @dc42

    Utilizing the M670 command greatly improved response time. What I've seen is that once a P command is issued in a G1 move, the output will continue to trigger in any subsequent G1 or G0 moves until a P0 is issued. Is this intended behavior?

    Yes. We added that functionality for an OEM, and that is what they asked for.



  • @dc42

    Fair enough. I suppose I can modify the gcode generation to always include a P0 with G0 moves and ensure I'm using them for travel moves.

    One more question for you. Is there any P command to turn all of the associated outputs on regardless of number; something like a P99 for example? We're actually looking at using this board as an oem in some dispensing equipment and I'm looking at a couple different tools configurations that will have different output configurations. I initially went down the m42 road for flexibility. I think I can associate the outputs in the tool change command but the gcode generation could get tricky if I need to assign different p values based on the number of outputs.


  • administrators

    @Eduma said in M42 command delay:

    @dc42

    Fair enough. I suppose I can modify the gcode generation to always include a P0 with G0 moves and ensure I'm using them for travel moves.

    One more question for you. Is there any P command to turn all of the associated outputs on regardless of number; something like a P99 for example? We're actually looking at using this board as an oem in some dispensing equipment and I'm looking at a couple different tools configurations that will have different output configurations. I initially went down the m42 road for flexibility. I think I can associate the outputs in the tool change command but the gcode generation could get tricky if I need to assign different p values based on the number of outputs.

    You could try P65535, that might work. Or P255 if you won't have more than 8 outputs. I can't remember whether trying to turn on an unconfigured output gives rise to a message.



  • @dc42

    P255 should do the trick


Log in to reply