G33.1 synchronized tapping problem

I wonder if this could be related to the order of how the components are added in hal. I've just had a somewhat similar issue with my own encoder disconnect component and I moved the addf of my component up above 'motion-...' and it worked fine.

so maybe try to change this


to this order

@Aciera,

Thanks, I'll try that if it doesn't work out doing the 3-way mux2 (velocity, orient, c-axis) config.

Kinda stuck at the moment as I realized my spindle motor was a contributing problem.  Once i put a heavy chuck on the spindle it became obvious while tuning the servo that the inertia ratio was really unfavorable.

I've got a more appropriate Yaskawa motor on hand, but getting the cables, 90VDC brake converter, and shaft bushing is taking a while for everything to show up.

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.

Aciera wrote:

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


 

Thank you so much for confirming the behavior I saw, and for the workaround guidance.

Have you raised an issue on GH about this?

NOTE: It'll be a bit before I can test this on my lathe as the 2nd motor I was planning to use turned out not to work.  So I threw money at the problem and have to rearrange my electrical cabinet to fit a significantly larger drive.  Re-wiring seems to take me an eternity.