AKM52G ANCNEM00 - Not reading encoder, it seems

Picked up a 52G EM servo on Ebay, installed on my rig to test tonight - loaded a DRC I obtained from Joe - seems Granity accepts the DRC, and Simucube software will initialize the servo, finding center and beeping indicating all is good - but there’s no reading of the steering input in the Simucube UI.

The Granity interface doesn’t make it immediately clear how I can confirm whether or not it’s reading steering input, but I gather it wouldn’t initialize if it didn’t have SOME kind of encoder feedback.

I’ve got the 15 pin cable which came with the servo plugged directly into the Simucube board; SDR-480-48V PSU. Not certain what could be wrong here.

I noticed tonight when I went to hook it up, the servo took a hit in shipping, bending the metal housing for the servo power cable - bent that back into shape, and no issues there. I suppose it’s possible the pinout is incorrect in the encoder cable? But again, I would expect the system wouldn’t initialize without some kind of feedback. Curious about this - if someone is bored and feels like troubleshooting, I would appreciate it!

Below is the current config from Granity:

[X] Initialized
[ ] Error recovering
[ ] Tracking error warn
[ ] Target reached
[X] Enabled
[X] Run (drive active)
[ ] Homing active
[ ] Braking
[ ] Permanent stop
[X] Voltages good
[ ] Fault stopped
[X] Ready for use
[ ] STO active
[ ] Safe torque mode
[X] Standing still
[ ] Quick stop active

[ ] Tracking error
[ ] Over velocity
[ ] Hardware
[ ] Over temperature
[ ] Feedback
[ ] Over current
[ ] Internal comm error
[ ] Power stage forced off
[ ] Under voltage
[ ] Over voltage
[ ] Motion range
[ ] Firmware error
[ ] Init
[ ] Motion
[X] SimpleMotion
[ ] Configuration

What caused this fault?

Fault location ID1 481001 (info)
Fault location ID2 0 (info)[X] GPI 1
[X] GPI 2
[X] GPI 3
[ ] GPI 4
[X] GPI 5
[ ] GPI 6
[ ] HSIN 1
[ ] HSIN 2
[ ] ANA1 as digital
[ ] ANA2 as digital
[ ] ENC A
[X] ENC B
[ ] ENC C
[ ] ENC D
[X] Hall U
[X] Hall V
[X] Hall W

[X] Soft enable
[X] Phys enable
[ ] Pos feed enable
[ ] Neg feed enable
[X] Home switch
[ ] Clear faults

Analog in 1 1.72 V
Analog in 2 0.00 V
Analog Enc A -1.61 V
Analog Enc B 1.21 V

HV bus voltage 47.7 VDC
Device temperature 39 °C
Actual current limit ±13.1 A
Last limit reason Voltage limit
Output current -0.01 A
Velocity feedback 0 r/s
Velocity feedback (raw) 0
Position feedback 0 r
Position feedback (raw) 0
Setpoint value (raw) 0

Debug 1 -1
Debug 2 -1
Debug 3 -1
Debug 4 -1
Debug 5 -1
Debug 6 -1

Parameters

| GCFWVER=10716 | HWTYPE=11201 | HWSERIAL=112015595 | BUILDREVISION=2782abfc
| CEI=2 | UID=e911233 | SMO=0 | TRF1=0
| TRF2=0 | TRA1=0 | TRA2=0 | MPP=480
| NOTCHFILT=655616 | TED=2 | TEF=0.4 | TEI=1
| SERIALENCBITS=6 | COMMUTATIONCFG=0 | HAO=0 | FBR=4096
| FBD=1 | FB2D=0 | TBW=10 | KVP=300
| KVI=190 | KPP=120 | VFF=120 | AFF=0
| PFF=98.5 | CM=2 | MT=3 | AD=0
| FLAGS=147469 | MMC=13.12 | MCC=6.67 | FOC=6
| FOV=49.75 | FUV=25 | FPT=1000 | FVT=100
| FEV=100 | FMO=0 | LSF=0 | LFO=0
| AXS=1 | AXT=3 | FFT=0 | TSR=0
| TCH=2.09715e+06 | TTR=1 | TBT=0 | CRI=3
| DIV=100 | PIF=2500 | MUL=100 | CAL=10
| CSD=10 | CVL=1000 | CRV=100 | MR=3.89
| ML=13.284 | MTC=2000 | MPC=10 | MMS=6000
| CAO=0 | HOMING=0 | HMV=100 | HMA=10
| HMH=500 | HMT=1 | HHL=0 | HLL=0
| HMF=0 | HSA=0 | HSS=0 | overrideAddr1=0
| overrideAddr2=0 | overrideAddr3=0 | overrideVal1=0 | overrideVal2=0
| overrideVal3=0 | BED=1.5 | BER=0 | BDD=1
| CAPS1=6.29143e+07 | CAPS2=81823

Whelp. Now I’ve done it. Put my 52K servo back on my rig, loaded it’s DRC file, and now the 52K servo is non responsive. Should have left well enough alone. Le sigh. Is this a reset Simucube and reflash kind of thing?

The latter screenshot shows that you don’t have software enable on. You can find that on the first tab in Granity.

Position feedback value on the testing tab shows encoder operating.

If/when I check the software enable, should I expect the motor to phase? I don’t recall unchecking this box.

Currently, my (original) AKM52K is not phasing at power on, and Simucube software reports connection state unknown. The servo itself feels to have resistance in it - firm and constant, able to be turned - but unlike any other feedback I’ve had.

Thanks for the note on the position feedback - I will observe that with the other motor to determine if the encoder is being read.

Latest Simucube firmware releases require the servo drive to have “require software enable” to be enabled.

OK Mika - I’ll check what the setting is in the DRC I have saved for that servo and confirm that is set, and saved to drive.

No need, Simucube firmware will write that parameter to correct value automatically.

And yes, you should see the motor phasing unless you have enabled the commutation sensor functionality for BiSS-C encoder.

I know in the Granity config for my 52K previously, I did not have the commutation sensor enabled - the servo only has a 2048ppr encoder. When I first re-installed my 52K, it phased once, I attempted to turn the wheel and it reacted oddly. I checked the config and saw for some reason the settings for the 52G persisted (With 4096 encoder). Re-loading and saving the config for the 52K was unsuccessful, and now the motor won’t phase.

Is it possible the simucube/IONI is persisting values for some reason? Or that the servo is somehow locked up? I can’t see status lights on the Simucube board - it looks to be booting fine.

Would there be any different between configuring the motor/encoder via Simucube software vs. Granity - via loading DRC file?

No, Simucube firmware does not touch any other parameters than the MMC value when tuning FFB strength and the require software enable setting. Uploading the drc file works the same via Simucube and via Granity.

Figured it out:

52K (my original servo) - FOV was incorrect, despite all other settings being correct for this servo. Once that was resolved, the servo would phase correctly, and it returned to working order.

52G (new to me servo) - it seems two of the pins, I think for the encoder, had pushed into the amphenol housing on the servo side. I took the backing off the amphenol connector, after connecting the encoder cable, and pushed those pins in from behind, and then packed the amphenol housing with electrical tape to keep the pins seated in the cable side connector - until such time as I can re-build the amphenol. So, I should be able to drive on it for a while.

Thanks to Mika for scratching his head on this one with me - sorry it wasn’t anything obvious :frowning:

Cheers,
Ian