M42 command delay

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