Cutter Comp and motion digital outputs yields unexpected behavior

[ArcEye]

Issue by dkhughes
Wed Sep 7 19:25:39 2016
Originally opened as machinekit/machinekit#1055

---

Other issues address the problem of the tp tripping over non motion commands, which are related, but, specifically, I want this issue to be an anchor for working out why motion digital outputs act "differently" when cutter comp is turned on. Currently in the source there is a guard that disallows auxiliary output when cutter comp is enabled, but I feel like that is a bit of a kludge considering coolant io and spindle io work properly.

For instance, when cutter comp is enabled, spindle control commands function identically to when cutter comp is disabled - which is to say as expected in a naive mindset. If you ask the spindle to be on or off, it obliges. A functional example of (what I consider to be) expected behavior:

G17 G20 G90 G40 G54

S100. (GIVE A NONZERO SPINDLE SPEED TO ALLOW SPINDLE-ON)
G91 G1 G41.1D0.05X0.25 F100. (FORCE CUTTER COMP)

#<count>=0.0

o100 do
M3
G04 P0.5
M5
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

G40 G1 X-0.25 F100.

M02

The above produces the spindle-on output toggling as expected with a 1Hz period. Aux DO do not mimic this behavior, and remain in a locked state when cutter comp is turned on. Here is the equivalent example of above but modified to use a digital output instead of the spindle:

G17 G20 G90 G40 G54

G91 G1 G41.1D0.05X0.25 F100. (FORCE CUTTER COMP)

#<count>=0.0

o100 do
M64 P1
G04 P0.5
M65 P1
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

G40 G1 X-0.25 F100.

M02

This example does not produce the expected bit toggling from the face value of the nc code. Turning cutter comp off, the following example does produce the expected bit toggling:

G17 G20 G90 G40 G54

#<count>=0.0

o100 do
M64 P1
G04 P0.5
M65 P1
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

M02

I would like to make digital output handling when cutter comp is turned on match the other two cases, as I can think of plenty of use cases where this type of digital io + cutter compensation are beneficial.

[ArcEye]

Comment by dkhughes
Sat Dec 3 17:49:43 2016

---

Little update on this - I adapted the aux outputs in the interpreter to call the queue functions similar to how the coolant/spindle commands behave. Now, M64/M65 function as expected with cutter compensation turned on. Needs more testing, I can wrap it into a branch if anyone is interested in giving it a whirl.

Oh, also, is there a reason M64/M65 should cause the tp to not blend? M64/M65 without a forced pause would be really nice since there are times we do not have a motion G01,G02, etc. following a toggle of a digital pin, and using M64/M65 instead of M62/M63 makes handling the no move following case irrelevant.

Last, I wonder if it would also be useful to have a way to set a default "safe" value for the dio that is enforced on aborts. Maybe a tristate option like safe-high, safe-low, don't care.

[ArcEye]

Comment by luminize
Sat Dec 3 21:05:26 2016

---

Hi Devin

On 03 Dec 2016, at 18:49, dkhughes [email protected] wrote:

Oh, also, is there a reason M64/M65 should cause the tp to not blend? M64/M65 without a forced pause would be really nice since there are times we do not have a motion G01,G02, etc. following a toggle of a digital pin, and using M64/M65 instead of M62/M63 makes handling the no move following case irrelevant.

M64 and M65 are queue busters. You could use M62 and M63 which synchronise with motion http://www.machinekit.io/docs/gcode/m-code/#sec:M62-M65

[ArcEye]

Comment by dkhughes
Sun Dec 4 03:20:06 2016

---

M64 and M65 are queue busters.

@luminize Thanks for the response! That behavior is exactly what I'm asking about. In the code for emctaskmain, I can see where the decision was made to make M64/M65 queuebusters (it waits for motion to complete on that command). But, as I've been digging through this IO stuff more and more, it's apparent that the work wasn't entirely finished. For instance, there are many places where motion synchronized io reference both a start value and an end value corresponding to the value along the trajectory - none of the actual work for that is implemented.

The fix that I have been testing for digital outputs with cutter comp turned on seems promising. The fix isn't complicated, I figure no one in the past has had much interest in the use case that is critical for my application.

In an effort to be more clear about my earlier question I'll restate it:

Why are M64/M65 queuebusters? I totally understand why reading an input with an M66 L value, or probing would bust a queue - undefined return values - but setting an open loop output is controlled and known. I think it would be beneficial to have one type of output not affect nor require motion commands to correctly operate. What is the use case where we want to stop all motion on an auxiliary output before letting tp continue on? If it is waiting for a spindle / coolant / lube style IO, we can set the pin then poll a handshake input via the incredibly handy #<_hal[pin]> api.

Right now I am looking at a double edged sword. If I use M62/M63, I am required to include a motion afterwards or the output toggle gets lost. This is a sticking point due to some specific types of cutting and their interaction with CAM software. Or I can choose M64/M65 that translates to a pause in motion, but guarantees the pin will behave at face value in the g-code. Thermal cutting, knife cutting, etc., cut quality gets severely degraded when motion halts during the cut.

I hope that makes more sense.

[ArcEye]

Comment by dkhughes
Sun Dec 4 22:30:34 2016

---

Here is a link to the changes I made allowing cutter comp to be active when controlling a digital output:

https://github.com/JDSquared/machinekit/tree/io-rebased

Using the queue structures from interp_* corrected the out of phase issues that I think are the reason the original error guards were put into place. Testers welcome - I can't see any bad side affects from these changes being merged into the main code base.

[ArcEye]

Comment by luminize
Mon Dec 5 09:26:01 2016

---

@dkhughes I'm afraid I don't have an answer to your question, but I did find some more info (link here)