Connecting joint.n.index-enable to spindle.n.index-enable breaks spindle-synchronized motion

[Sigma1912]

[edit]
See this post further down on how to reproduce this issue in a sim config:
#3556 (comment)
[/edit]

Background:
Some users want to setup a joint as a spindle/rotary-axis (eg using a lathe spindle as a Caxis). The usual approach is to configure a rotary axis with homing to index and then use hal logic to disconnect the encoder signal before switching to spindle mode to avoid triggering a joint following error. The spindle has to be rehomed (using the encoder index) before the encoder can be reconnected in hal.

Issue:
While the above method works reliably, it has been reported that synchronized motion (eg G33, G33.1) shows erratic behavior while in spindle mode:

https://forum.linuxcnc.org/38-general-linuxcnc-questions/55116-g33-1-synchronized-tapping-problem?start=20#324268

As described in the forum thread above, I have done testing which reproduced the issue. Further testing showed that the erratic behavior seems to only appear if 'joint.n.index-enable' (where n is the joint for the caxis) is connected to the encoder index-enable and subsequently also to spindle.n.index-enable. This is used to home the caxis to index on startup.

Testing a configuration where joint 4 is setup as rotary/spindle:

1. start config and home all (joint 4 is set to home to index)
2. testing g33 shows broken behavior (does a rapid move to target coordinate)
3. open 'hal configuration' tool and issue HAL command: 'unlinkp joint.4.index-enable'
4. testing g33 shows expected behavior
5. issue HAL command: 'net c-index-enable joint.4.index-enable'
6. testing g33 shows broken behavior (does a rapid move to target coordinate)

So a workaround seems to be to disconnect 'joint.n.index-enable' (where n is the joint for the caxis) when switching to spindle mode.

I attach my test configuration including the components used for future reference.

Drehachse.tar.gz

Some notes about the test config:

• Rotary (Caxis) is on Joint 4, uses a stepgen with settings from ini [JOINT_4] section
• Spindle also uses stepgen but with setting from ini [SPINDLE_0]
• Startup mode is rotary with joint.4 homing to index (ie joint.4.index-enable is connected in HAL)
• 'M419' moves rotary to 0 position, sets hal pin to freeze joint.4.pos-fb and calls M119 to set stepgen values as set in ini [SPINDLE_0] and disconnect 'joint.4.index-enable' to avoid breaking sinchronized motion as outlined in my last post
• 'M420' orients the spindle to 0° (using index to rehome first) sets hal pin to reconnect the encder to joint.4.pos-fb and calls M120 to set stepgen values as set in ini [JOINT_4] and reconnect the 'joint.4.index-enable' pin

Conclusion:
The underlying issue seems to be that the 'joint.n.index-enable' pin is not 'released' after the homing procedure.

[andypugh]

The "fix" seems to indicate that this isn't because the encoder counts (C axis position) is being reset, which would be the obvious place to look.

So it seems that either the unexpected toggling of joint-N-index-enable (out of the control of the joint itself) is causing some odd behaviour.

Or, the joint is randomly toggling the index-enable and that is breaking the spindle-synch motion.

Both seem unexpected. If you scope the index-enable pin do you see it toggling anywhere other than at the starting Z position (where the G33 waits)

[Sigma1912]

If you scope the index-enable pin do you see it toggling anywhere other than at the starting Z position (where the G33 waits)

I'm afraid I can't say and can unfortunately no longer test as I was waiting for feedback on the forum for the last 6 months and have since had to return the test setup to the owner.

[pcw-mesa]

"The underlying issue seems to be that the 'joint.n.index-enable' pin is not 'released' after the homing procedure"

It sounds like the homing routine index handling logic should simply ignore joint.x-index-enable when not homing
but is in fact is still reacting to it in some way, maybe just a missing conditional.

[andypugh]

I was waiting for feedback on the forum for the last 6 months

Sorry, but I didn't see it there. I am no-longer able to read every forum post.

[Sigma1912]

Sorry, but I didn't see it there. I am no-longer able to read every forum post.

No problem. I was mostly hoping for somebody with the necessary hardware, like the OP of the thread, to confirm my findings and test the workaround. In the end I decided to file it here so it does not get lost.

[Sigma1912]

I have setup another test assembly to probe this issue.

• Spindle is running at 500rpm (M3 s500)
• X is at -50
• command: G33 X-80 K1

This shows the unexpected rapid. Doesn't even wait for an index it just rapids to X-80 and that's it:

This is the expected behavior after 'unlinkp joint.2.index-enable':

[Sigma1912]

Further testing with 'joint.2.index-enable' connected and g33 failing:

• Running spindle at 5rpm (M3 S5) I can manually set 'index-enable' using 'tristate_bit' and watch it being cleared during one encoder revolultion.
• The length of the rapid move depends on the encoder position value when the g33 command is issued which I guess would be part of the expected behavior as the controller would want to catch up to the spindle position. If the encoder position value is small enough (eg by manually setting the index-enable) the rapid move is actually followed by synchronized movement to X-80.

The problem thus seems to be that with joint.n.index-enable connected the controller is no longer setting 'spindle.n.index-enable' before starting synchronized motion.

[Sigma1912]

Trying to find out why 'spindle.n.index-enable' is not being set before starting synchronized motion I have added some debug printing to 'control.c':

Testing again with spindle running at 5rpm (M3 S5) and 'joint.2.index-enable' connected the two lines are printed immediately after issuing 'G33 X-80 K1' (testing shows that it index-enable is reset to 0 in the next servo thread)

setting index-enable on spindle 0
UNsetting index-enable on spindle 0

With 'joint.2.index-enable' DIS-connected the first line is printed immediately after issuing 'G33 X-80 K1' but the second line is only printed after the spindle has passed the reference signal

setting index-enable on spindle 0
.
. <- delay until encoder reaches the reference signal
.
UNsetting index-enable on spindle 0

So, since I can set index-enable manually and see it cleared when the spindle encoder passes the reference position I conclude that somewhere in the code 'joint.2.index-enable' is being cleared right after 'spindle.0.index-enable' has been set.

[Sigma1912]

The only place I can find where a joint.n.index_enable is set to zero is in homing.c and that is clearly not what is causing this issue. (Yes I actually checked.)
So for now I'm out of ideas.

[Sigma1912]

This can actually be easily reproduced in a sim config:

Start 'axis_mm' sim config, enable machine and home.

For expected behavior:

1. MDI command: 's100 m3'
2. MDI command: 'g33 x-100 k1

For reported issue with rapid move:

1. MDI command: 'g0 x0'
2. Open 'Halshow' and execute HAL command: 'net spindle-index-enable joint.2.index-enable'
3. MDI command: 's100 m3'
4. MDI command: 'g33 x-100 k1

Back to expected behavior:

1. MDI command: 'g0 x0'
2. HAL command: 'unlinkp joint.2.index-enable'
3. MDI command: 's100 m3'
4. MDI command: 'g33 x-100 k1

The difference in tool velocity is easily noticed during the G33 moves.
Note that it does not matter which joint we connect the spindle index to (eg we can also connect to joint.1.index-enable )

[spumco1234]

No problem. I was mostly hoping for somebody with the necessary hardware, like the OP of the thread, to confirm my findings and test the workaround. In the end I decided to file it here so it does not get lost.

It's been close to a year, but I finally got my hardware and LCNC configuration sorted out enough to test this. Needed a new spindle motor, life gets in the way, procrastination...Mea Maxima Culpa.

I have created a config that closely mimics the one in the zip file attached earlier.

Single servo motor with switchable modes (spindle/orient/c-axis), using the encoder disconnect component.

My tests this evening confirm @Sigma1912's findings exactly:

1. Leaving joint.2.index-enable connected to the encoder index signal results in a Z- rapid immediately upon executing a G33.1 tapping program.

2. The rapid move is worse the farther from C0 the spindle is when it starts.

2a. Just to be clear, the encoder disconnect sequence results in the C-axis moving to C0, and encoder position being held at C0 when disconnected.

2b. If the spindle (in spindle mode) hasn't moved from the index position when the G33.1 program starts, the rapid move is barely noticeable.

2c. If the spindle is moved (using orient) 180 degrees from the index position, the rapid move is dramatic. I didn't have the courage to try it past ~270 out - that was violent.

2d. I did not try moving the spindle in the other direction (M4) before launching the Z-axis. I presume the Z-axis would move in the opposite direction (positive) as the joint tries to catch up to the spindle position.

3. If joint.2.index-enable is disconnected while in spindle/velocity mode, there is no Z- rapid move at all.

4. I can repeat the above indefinitely. Both triggering a Z- rapid move and changing the rapid move's magnitude with spindle start position, as well as perfectly normal G33.1 moves when joint.2.index-enable is disconnected.

So the problem exists, and the workaround seems to fix it. In my case I followed the sample configuration and used an M-code to disconnect & reconnect joint.2.index-enable pin from the encoder index-enable pin whenever changing between spindle & axis modes.

In case it matters, testing was done using LCNC 2.10.0-pre0-4165-g55fb1a0267 (I've not updated since originally reporting on the forum)

My complete configuration is rather complicated, but I am happy to attach it (or parts) if that will help anyone attempting to resolve this.

Thank you for being patient and working on this.