Re-Zero a Kinetix 5300/MPAI Electric Cylinder

[OhNo]

Hello PLCS.Net Forum,

First time posting. Let's assume I am a novice.

BASIC PROBLEM:
My servo/linear piston is no longer zeroed to the original zero. Meaning, Studio 5000 V35 thinks the servo is positioned at 32 mm but I can see the physical system is positioned closer to 47 mm. This creates a major risk for mechanical destruction.

DETAILS:
__A 2198-C1004-ERS KINETIX 5300 servo drives an MPAIA3076RM14A MP series heavy duty electric cylinder (piston's total range is 76 mm).
__Cables are brand new (2090-CPBM7DF-16AA03 3 m Power/Brake & 2090-CFBM7DF-CEAA03 3 m Feedback). The feedback cable's battery is pretty new.
__Other hardware: 5069-L306ERM CompactLogix, 2711P-T7C22D8S PanelView Plus 7
__The piston controls the spacing of some grind wheels.
__Soft limits at 32mm and 58mm (mechanical limitations of the system). Home to 34 mm.
__HMI provides specific recipe for a single selected position. Servo should go to that position and stay held with a brake until a different recipe is selected and motion triggered.
__In initial set-up/programming trials, I can manually toggle MSO to turn on the servo, MAM to a specific location, MSF to turn off the servo & apply the brake. Worked fine.
__I'm trying to advance (automate) my code to allow for functions such as moving to the HOME position, moving to the selected recipe location, etc. Maybe some of this code has created this problem.
__I examined (Kinetix 5300 Manual) but didn't find what I was looking for (in terms of re-zeroing).
__Within my Controller Tags I tried to manually redefine my "linear_piston.ActualPosition" but it is read only. Which makes me think I didn't necessarily overwrite it with bad code.
__You're going to want to see code and I'm going to tell you it is on a non-networked computer (security reasons). I can likely figure out something if there is a specific ask.
__My instruction outputs for servo motion are limited to MSO, MSF, MAM, MAH, MASR, MAFR, and MAJ. I do write my target recipe position to a variable I use as the "pos" value in a MAM. That's it.
__My employer pays dearly for several layers of Rockwell support. But, of course, support for Motion or components purchased on a Tuesday is not included. (Yes, I am grumpy).

KEY QUESTIONS:
__How do I restore/re-zero my drive/piston to match the actual physical world?
__Autopsy: how did I cause this? Code? Power cycle? How can I never do this again?
__Am I misunderstanding encoding? Doesn't absolute encoding know where it is for the full 4,096 turns (inside the piston)?

MISC/BONUS:
__I was already thinking about adding limit switches for added protection and now I am sure I will. I'd be happy to hear any switch recommendations/successes/fails on that, including sensor recommendations and tips for a homing sequence... a key puzzle being if I have a piston with an encoder resolution of 0.000,012 mm/feedback count, what kind of sensor am I going to find that doesn't introduce error into my system? Or, do I just live with the resolution of the sensor being my new tolerance? I am trying to hold about 0.1 mm, so maybe that is OK.

Thank You in Advance,
--OhNo!

 

[atc222]

Take a look at MAH instruction. Motion Axis Home. I believe you can home to a hard stop (good idea to limit torque when doing this,) or home to a limit switch. I believe instruction also allows you to apply an offset..

I believe you can also use an SSV to redefine 0, but it’s been a while…

In my experience, homing to a hard stop at at low velocity with limited torque has produced the best results.

Rockwells documentation for servo programming is worth downloading and reading. Will answer all your questions.

 

[OhNo]

Take a look at MAH instruction. Motion Axis Home. I believe you can home to a hard stop (good idea to limit torque when doing this,) or home to a limit switch. I believe instruction also allows you to apply an offset..

I believe you can also use an SSV to redefine 0, but it’s been a while…

In my experience, homing to a hard stop at at low velocity with limited torque has produced the best results.

Rockwells documentation for servo programming is worth downloading and reading. Will answer all your questions.

Thank you for the prompt reply. I will look for some specific manuals on programming.

Cheers,
--OhNo!

 

[atc222]

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/motion-um003_-en-p.pdf

 

[Ken Roach]

Doesn't absolute encoding know where it is for the full 4,096 turns (inside the piston)?

Oh yes, it definitely does !

At some point, you have to define how many absolute encoder turns and counts equals a "zero" position on the axis. The relationship between motor turns and displacement millimeters is part of the simplified definition of the drivetrain mechanism in Studio 5000.

The most common way to do that are with a physical switch that is detected when the mechanism arrives at a "home" position. There are multiple options for how that's handled: you can stop when the switch is made and call that zero, or go into reverse at a creep speed and call it zero when the switch is released, and so on.

Or, some mechanisms lend themselves to "home to hard stop", which is what it sounds like. You reduce the torque of the motor and move the mechanism until it reaches an end stop point and detects the current going up but the position not changing. ControlLogix does not have a built-in home-to-hard-stop function, even though you can limit the torque during a seek-the-sensor Home function. Some A-B branded indexing drives do have that feature.

Seeking and finding and setting the "home" or "zero" position of the axis is usually done with the Motion Axis Home (MAH) instruction.

You probably did the same thing at some point during commissioning when you opened the Axis Properties and selected the Homing window, set the Sequence = Immediate, and clicked Apply. That was literally the same as executing the MAH in logic, or with the Motion Immediate feature.

You can do the same thing programmatically with the MAH instruction by executing it your user program. It will execute with the arguments set in the Axis configuration.

Something that has tripped me up before but is clear in the Help file: the difference between Active + Immediate and Passive homing. Active + Immediate sets the position of the axis to that Position value on the Homing screen right away. "Passive" homing relies on a once-per-revolution Z-pulse to complete: you often do that with feedback-only axes that move freely.

 

[Ken Roach]

I think that for your system you should take a step back and think about how it functions on a day-to-day basis and how you would align it during assembly or maintenance.

Without the encoder or motor, how do you measure the position of your grind wheels ? Do you have a probe, or a switch, or a scale ? Do you get out a laser tracker and measure against fixed parts of the frame ? Do you back the mechanism up until it bottoms out or hard-stops against something ?

The big risk of having no sensors or verification is that someone will un-bolt the motor and turn it and then re-assemble. Or, they'll find the HMI page and the password and poke at the "Zero Encoder" button you put there, thinking it will reset some malfunction that it's unrelated to. (Ask me how I know).

You could just use whatever measurement method you like to line up the machine, then enter that position and use Active/Immediate Home with the MAH while the axis is disabled and the brake is engaged. Bam, the axis thinks it is exactly where you have told it that it is.

To get really precise Home functions by seeking the home sensor you need fairly precise sensors, and the ability to go slowly. Even a general-purpose limit switch might be good enough if you use the "find sensor / reverse / leave sensor" method.

Or, you could get a proximity sensor with a fairly wide sensing range and use it along with the Passive Homing feature. Run the mechanism slowly until you sense that proximity sensor, then execute an MAH with Passive Homing and very slowly jog the mechanism one motor revolution (or physically shove it). When the Z-pulse on the encoder (presuming your encoder has one) goes by, that will be the precise zero point applied to the Axis. You can use a precise measurement system (like a laser tracker or micrometer) to determine exactly where the system really is, and read online where the Axis thinks it is, then apply the difference as an offset.

 

[Ken Roach]

And before I forget... welcome to the PLCTalk forum community !

One more thing about the Axis tag. You mentioned the "linear_piston.ActualPosition" tag as being Read-Only, and it definitely is. It gives you the position of the axis based on the encoder counts after they've been run through the scaling factors in the Scaling tab for the Axis. That's where you've put in the type of power transmission, and the reducer ratio and the inches/rev and the soft travel limits.

If you want to temporarily tell the Axis that it's at a different location, you can use the Motion Redefine Position (MRP) instruction. That takes a tag value or literal argument and applies it to the Command or Actual position of the axis.

You can actually execute that while the axis is in motion ! It's use for adjustments and indexing and synch-up sort of things.

But it does not change the Axis relationship with the encoder. After a power cycle, the position of the Axis will be taken from the absolute encoder's count value and offset that was saved when you last performed a Home function with MAH or clicking Apply on the Homing page for the Axis.

 

[atc222]

Hey Ken,

Great posts!

 

[OhNo]

Hi Guys,

Thank you for the thoughtful replies. Lots for me to work on/read/consider. I am planning to get started reading the aforementioned programming manual after completing this post. (I've read thousands of pages of technical manuals for this project, but apparently not the right ones ).


OhNo!>> Doesn't absolute encoding know where it is for the full 4,096 turns (inside the piston)?
KR>> Oh yes, it definitely does !

Can you please say more about that? If it is absolutely sure of where it is, what's gone wrong? Have I (probably) simply redefined which encoding count the drive thinks is zero, but the encoder count is still absolute? I will be studying the MAH command closely.


KR>> At some point, you have to define how many absolute encoder turns and counts equals a "zero" position on the axis.



Given I know -1192.46=0, is there someway I can restore to the original specs (and not just temporarily, per the MRP instruction)?


KR>>Or, some mechanisms lend themselves to "home to hard stop"

I think that might be good for this application. Really, the brake is keeping the piston located during operation. Friction should be the only load during MAM, so I will try putting the max torque at 1-2%. Speed is not a big concern. Even 3 mm/s is plenty fast. At the risk of looking cool, I am also considering sensors for travel limits.


KR>> Seeking and finding and setting the "home" or "zero" position of the axis is usually done with the Motion Axis Home (MAH) instruction.

I'm guessing I misused the MAH command and that's how I got where I am now. It was fine until the day I used that.

Thank you for the great posts! I really appreciate it. I've been reading this forum intermittently for years. It is great to finally join. I will follow up when I have more information to share.

Cheers,
--OhNo!

 

[OhNo]

Hi Guys,

1. After just a brief look at a MAH YouTube video, I am pretty sure I know what happened:

I misunderstood how the "Position" parameter in the Homing tab of the drive configuration functions. I had it set to 32 mm, thinking the MAH would drive the piston to that position. El-wrongo. While my piston was at, say 48 mm, my MAH told the drive that it was actually at 32. Now I'm suddenly off by 16 mm and ripe for a crash.

Here's a snip of that parameter field from the YouTube video (not my project, which is in mm).


At 3:54 he gives an overview of the key homing parameters.

2. So... to undo my damage in the short term...
__measure the piston's actual position,
__enter that into the Position parameter,
__run the MAH 1x to redefine/correct the system's position?
__Delete it from my code until I have homing sensor(s) in place and properly understand the MAH instruction.

3. And, just to clarify best (or maybe not worst?) practice, if I am not doing a traditional homing sequence and just want to move the piston out of the way to "Home-like" position, I can just use MAM and either type the target position or use a Tag such as piston_retracted_pos ?


Thanks for the help. I hope my mistake helps someone else down the line.

Cheers,
--OhNo!