M42 command delay

Eduma

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)

Danal

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

Eduma

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.

dc42

@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?

Eduma

@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

dc42

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.

Eduma

@dc42

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

Eduma

@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.

dc42

@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.

Eduma

@dc42

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

Thank you for the prompt response.

dc42

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.

Eduma

@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?

dc42

@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.

Eduma

@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.

dc42

@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.

Eduma

@dc42

P255 should do the trick