M42 command delay

Eduma

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