Recovery from Estop is always finicky
Been looking at the ACD file on knowledge base 69996
that code is $hite - the sequencer has errors in it
What I think matters is you need inspect the axis.CIPAxisState and then do the right thing to recover or wait for the drive to finish doing something
The thing that's ambiguous in that ACD sample is the "Faults are repaired then cleared based on the type of fault seen." on rung 8. No mention on how to determine this, esp. since the drives don't do the same thing consistently. I am right now doing a Shutdown reset first and then Fault reset for every fault.
Once you get to recovering from over-travel limits it's a whole another animal. I can't understand A-B's logic behind complicating this basic stuff.
That is typical - as an extra I'll scare you with complicating simple stuff - Knowledge base article 66060 - Power Programming V4.1 – ( ISA-88 & PackML Based)
This is what rockwell want their OEM's to use http://rockwellautomation.custhelp.com/app/answers/detail/a_id/66060/kw/power%20programming
Does - Axis_1.CIPShutdownStatus change state and help your logic?
Hmm i`ll have to set one up on a test bench and play hardball
I was using ShutdownStatus, and it didn't do squat. I didn't see the CIPShutdownstatus member. Is there a document with an explanation for all the Axis_CIP_Drive members (not GSV stuff in the help)? I was actually using GSV for CIPAxisState, I just realized that there is member for that as well...
Every once in a while I get this motion instruction error 82 while homing/enabling/disabling a Kinetix module. Error code 82 doesn't exist in the RSLogix help. Anybody knows what this secret code means?
look at (Default location on your PC)
C:\Program Files\Rockwell Software\RSLogix 5000\Common\ENU\Docs\motion_instr.pdf
Appendix A
The Error code is "CIP axis in incorrect state." The axis was found to be in the incorrect operational axis state.
ohh what a useless error message