Cincinnati Milacron Arrow 750 Retrofit

Yes, it faults with the U,V,W wire connected (after turning the shaft a bit) or not connected at all. It seems as though there is a fault within the 8i20 card that can't be cleared by restarting linuxcnc or repowering the 8i20card.

Sounds like maybe a damaged IGBT module
What is the DC supply voltage?

The DC supply voltage is fixed at 54 volts.

Is there some way I can test the IGBT module to verify it is the culprit?

Is there anything I can do on my end to figure out the issue with the 8i20 card or should I just ship it to have MESA take a look at it?

Probably has to go back to mesa under RMA.

I setup another 8i20 card to another servo off the milling machine. When I run the servo in open loop, I hear a small internal clicking/ticking sound that occurs at the same angular location. (The previous servo and 8i20 card did the same thing). I can hear and feel the internal click/tick when I apply 0 amps and turn the shaft by hand.

When I power down Linuxcnc, the shaft spins smooth and free with no indication of an internal tick. Is this the result of misalignment between encoder zero and servo zero? (As a note, I'm currently only running the servo using an SSI interpolated coarse single SIN/COS wave per revolution. The absolute angle value dances around at standstill.)

I'd like to incorporate the fine 2048 SIN/COS waves per revolution but I'm not sure how in bldc.comp. The coarse single SIN/COS wave produces 2048 interpolated readings per revolution while the fine 2048 SIN/COS waves produce 16384 readings per revolution. I was thinking about starting the servo using the coarse single SIN/COS wave and then switching to the fine 2048 SIN/COS waves after it passes an index. The question I have is does BLDC.comp (or Linuxcnc) care if I scale the initial coarse 2048 readings up to 16384 (by a factor of 8) so that the coarse single and fine 2048 SIN/COS waves both have 16384 reading per revolution? (This would mean that the coarse single SIN/COS wave would produce readings that skip values by a factor of 8 until an index is read.)

I would not think its an alignment error but rather a discontinuity in the angle
sent to the 8I20. You might plot the angle with halscope when moving at a low speed
to see what's going on

I reduced the coarse angle resolution to 256 (from 2048) which has eliminated the absolute angle dancing around values at standstill. If there isn't anything significant to be gained from higher signal resolutions (for commutation purposes), I might leave it at this value or reduce it further in the future.

I manually spun the servo shaft and plotted the coarse absolute angle and the 8i20 angle in Hal Oscilloscope. There is definitely something going on. It seems like the 8i20 angle is momentarily being driven to zero just after the absolute angle resets back to 255.
Attached are screenshots as well as some zoomed in areas. Anybody have any ideas what may be causing this?