G33.1 synchronized tapping problem

I might have found a clue as to what causes this problem with G33.

I just noticed on my test setup that synchronized motion (eg G33, G33.1) shows this erratic behavior 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.

In your rev 1.713 config you have
Seems to me like a bug in how joint index-enable is handled.

[edit]
I just confirmed this on my test bed (caxis is on joint 4):
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)

I have found a workaround for the issue described above using hal commands.
Here is my config including the hal component I use to disconnect the encoder position value and the modified orient component to rehome to index before orienting the spindle:

 
Some notes:
- 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

Also note that [JOINT_4] FERROR=10 and MIN_FERROR=1 may seem a bit large but are due to a lag in the simulated encoder feedback from the Mitsubishi controller I use here.

Have you raised an issue on GH about this?

Not yet. I would like to have somebody else confirm this first.