Servo issue : inconsistent displacement

[nyanpasu]

Hello everyone

I am inexperienced with motion and I have an issue I cannot wrap my head around.

Using Kinetix drives, Rockwell servos and a Rockwell motion PLC.

I have two rotary servo axes working a kind of crankshaft. I need to introduce a position difference between both axes in order to move a cylinder. The first one is geared to a "main" virtual axis, the second is position cammed to the first. The goal is to do a move on the virtual axis, have the first axis follow the move, then introduce a controlled position difference between both physical rotary axes for a length of time, then sync them back. The intended application is volumetric portioning.

The transmission is a disk with plastic plugs that fit into another disk with holes. Both axes are linked by a timing belt.

The issue is that for the same position difference, the results are inconsistent. The real displacement of the cylinder gets smaller and smaller for about 6-7 cycles, then it returns to the expected displacement.

I have trended command and actual position and velocity, as well as the error of each returned by the axes. The error stays at zero and the overall trending seems to report that the motor follows the commands fine.

Rehoming the system does nothing, the performance stays the same.

The mechanical system hits its home sensor every 3 cycles. I've noticed some position jitter of +\- 0.7 degrees on both axes. I have tried to introduce some logic to compensate for this jitter but as it is in itself inconsistent and by the time I hit the sensor, I've already done 3 cycles, this didn't seem to help. Besides, the jitter doesn't seem to build up and it's too small for the errors I'm seeing at the end effector.

Exporting the trend results to Excel gives me the defined position cam exactly.

I have another system like this on the machine, which is more consistent. Not perfect, but you can't see the variation. Both are programmed the same.

It seems like a mechanical issue to me but I want to hedge my bets and consider every avenue. I usually do wet process so I am a bit at a loss on what to check next. Any other avenues I could explore would be much appreciated.

Thank you for your consideration.

 

[Peter Nachtwey]

The issue is that for the same position difference, the results are inconsistent. The real displacement of the cylinder gets smaller and smaller for about 6-7 cycles, then it returns to the expected displacement.

Cylinder? Is this a hydraulic system or a servo motor one?

I have trended command and actual position and velocity, as well as the error of each returned by the axes. The error stays at zero and the overall trending seems to report that the motor follows the commands fine.

You should trend the target position and the actual position. As long as the actual position is following the target position the tuning/control is fine. Now the question is are the two targets doing what they are supposed to be doing?

Rehoming the system does nothing, the performance stays the same.

Do the positions change when you home? If the encoder is not losing counts then the counts should not change from one homing to the next.

The mechanical system hits its home sensor every 3 cycles. I've noticed some position jitter of +\- 0.7 degrees on both axes.

It would be nice to have more info on the feed back. Use your cell phone to take a picture.

I have tried to introduce some logic to compensate for this jitter but as it is in itself inconsistent and by the time I hit the sensor, I've already done 3 cycles, this didn't seem to help. Besides, the jitter doesn't seem to build up and it's too small for the errors I'm seeing at the end effector.

Fix it in software sometimes works but it can't fix real hardware problems.

Exporting the trend results to Excel gives me the defined position cam exactly.

So the target position is moving where it should?

I have another system like this on the machine, which is more consistent. Not perfect, but you can't see the variation. Both are programmed the same.

Must be a mechanical or encoder problem.



Need to make a trend of the target and actual position of both axes on the same trend. You might also trend the counts too.

 

[nyanpasu]

Thank you for replying.

Cylinder? Is this a hydraulic system or a servo motor one?

Sorry, English isn't my first language. By cylinder I meant the literal geometrical form. This is a crankshaft system where an angular difference between the two axes introduces a linear displacement that moves a cylindrical block up and down. There are no hydraulics involved.

You should trend the target position and the actual position. As long as the actual position is following the target position the tuning/control is fine. Now the question is are the two targets doing what they are supposed to be doing?

I have already done so, and the actual position tracks the command position near exactly (as well as the velocities). As well, the servo drive reports an error of almost zero during the movement at all times. This is what has me scratching my head. The behaviour I'm seeing is inconsistent with the feedback I get from the devices but the behaviour is consistent. The volume will go down then back up over about 12 cycles. It reminds me a bit of a sinusoidal wave.

Do the positions change when you home? If the encoder is not losing counts then the counts should not change from one homing to the next.

They do not.

It would be nice to have more info on the feed back. Use your cell phone to take a picture.

Unfortunately the phone is not allowed in this facility. The homing switches are two proximity switches located on a bracket above the transmission disks. There is a metal extrusion on the disk. When that bump meets the sensor then that position is home.

The encoder itself is located inside the servo motor, before all transmission mechanisms.

Fix it in software sometimes works but it can't fix real hardware problems.

Agreed.

So the target position is moving where it should?

Yes.

Must be a mechanical or encoder problem.

My thoughts too.

 

[drbitboy]

Is the encoder solidly attached to the device, or could it be it slipping?

 

[nyanpasu]

Is the encoder solidly attached to the device, or could it be it slipping?

Thank you for replying. The encoder is located inside the servomotor. I did try changing them for new ones but the issue remain.

The system has been dismantled and there doesn't seem to be much mechanical slack. The consistency of the inconsistency is intriguing. I have tried gearing the virtual axis of this contraption to the main machine axis (instead of moving it on a trigger) so everything spins in theoretical sync all the time but the problem remains.

 

[Peter Nachtwey]

Is the encoder solidly attached to the device, or could it be it slipping?

If the encoder was slipping you would see the position change by a lot every time the device is homed. So now I wonder if the target generator doesn't have a round of error.

I should have asked above it the target position changes when the home switch is hit.

I would be nice to see a plot of the motion and how the move commands are implemented.
Often the number of counts per millimeter is not a whole number. The target positions should always be perfect unless they are implemented in some weird way.

 

[nyanpasu]

Hello again

I have a trend of one cycle. Red and blue are the first servo position plots, purple and green the second servo. Red and purple are command, blue and green are actual.

There are three such cycles in a revolution of the mechanism.

I have been working with the whole cam in linear and I now have an almost constant residual error. With the "differentiation" part of the cam in cubic there used to be much less error. However, as I had this problem with both styles of cam, I don't believe this residual error is the cause of the problem. I don't know if it might be a scan/communication artifact. I am not knowledgeable enough about motion. :|

This station is now geared on the machine's main virtual axis. It will thus do one revolution every machine cycle, doling out three strokes during each revolution. It should all be in sync but the variation remains.

We've decoupled the station itself and stuck a protractor to the transmission then filmed it. We've discovered that the problem lies in the returning part of the cam, where the four plots start to converge. At first it will go back to zero degrees from its home position, then the error will increase one degree once in a while until it reaches about 4 degrees. Then this displacement error will similarly decrease by about one degree until it reaches zero again. This is this "self-correcting" behaviour that is throwing me for a loop. I could compensate for it, if I had a means to measure it. However, nothing in the servo drive feedback show me this exact positional error, unless I am missing something.

Zooming in on the plot, the commands merge together and also the actual positions, however there remains that small residual error between command and actual. That said, the actual position shows the servos converge with no error between them (their values are equal even if different from command).

 

[Peter Nachtwey]

This is why I wanted to see multiple cycles. The Rockwell trends are not very good. Can you export the data to a .csv or similar file that can be read into Excel?
Also, all I see is a magenta and cyan line. No green or read lines.
The acceleration and deceleration ramps for the axis that is slowing down then trying to catch up does not look like a cubic ramp.

 

[nyanpasu]

Hello

Sorry for the delay. I took a lot of trends of different tests and I meant to upload them but life got in the way.

Anyway, I have found the problem. It is hysteresis in the transmission system. I can spin the gearbox input by hand with a tool and see the same phenomenon across multiple turns at the output. I can also reproduce the behaviour with direct motion commands. I have removed the mechanical hardstops and commanded one motor to do 10 turns, then the other do 10 turns and so on. I visually see the same behaviour.

Looks like I get to push this in the mech guys' hands.

Thank you for your time

 

[Peter Nachtwey]

It is always the machinery. Don't let a millwright tell you otherwise.

 

[Tinine]

It is hysteresis in the transmission system.

I was recently called out to a client to assist with a "metal-forming" problem. It was a bit awkward because some years ago, this client was about to pull the trigger on an order for me to retrofit six or seven machines.
Their internal "controls engineer" who has them by the short-n-curlies had them change their minds at the last minute because he wanted to do the upgrade himself.
They spent a fortune on the big-name supplier and he set about "coding". What a mess but that's a different story.

The control was "working great!" and with "amazing repeatability" (according to the position display).
But parts were not at all repeatable, they were all over the place and so they figured that there was something about this metal-forming that they weren't aware of and hadn't catered for.

Originally, the machine had Moog servo motors with resolver feedback to the Moog drives. The position loop consisted of load-mounted encoders that fed back to the motion-control card in the DOS-based PC.

The in-house guy decided to dispense with the load-mounted encoders because his shiny-new Omron servo-motors provided position feedback, themselves.

Control loop was totally oblivious to the 3mm slop in the rack & pinion and whatever slop they had in the rotary axis.

I have always used dual-loop wherever I have a mechanical transmission.

Craig

 

[nyanpasu]

It is always the machinery. Don't let a millwright tell you otherwise.

Something I'm learning more and more as I gain experience in this field. Unfortunately, I'm too "helpful" and don't stick in my lane.

I was recently called out to a client to assist with a "metal-forming" problem. It was a bit awkward because some years ago, this client was about to pull the trigger on an order for me to retrofit six or seven machines.
Their internal "controls engineer" who has them by the short-n-curlies had them change their minds at the last minute because he wanted to do the upgrade himself.
They spent a fortune on the big-name supplier and he set about "coding". What a mess but that's a different story.

The control was "working great!" and with "amazing repeatability" (according to the position display).
But parts were not at all repeatable, they were all over the place and so they figured that there was something about this metal-forming that they weren't aware of and hadn't catered for.

Originally, the machine had Moog servo motors with resolver feedback to the Moog drives. The position loop consisted of load-mounted encoders that fed back to the motion-control card in the DOS-based PC.

The in-house guy decided to dispense with the load-mounted encoders because his shiny-new Omron servo-motors provided position feedback, themselves.

Control loop was totally oblivious to the 3mm slop in the rack & pinion and whatever slop they had in the rotary axis.

I have always used dual-loop wherever I have a mechanical transmission.

Craig

Thanks for the anecdote. It makes a lot of sense. As I said, I usually do wet process so this first motion project was a bit daunting for me at first. When I can, I like to have positioner feedback wired back to the PLC for control valves for similar reasons (don't we want confirmation the equipment physically does what we tell it to do?)

The more I gain experience in this field, the more I get the impression everything is different, but some of it is pretty similar in spirit. At least the basic blocks.

 

[Tinine]

don't we want confirmation the equipment physically does what we tell it to do?

"Stepper-Motor Control" (open loop) for me, is an oxymoron. How can one be in control when there is no verification.



Craig

 

[robertmee]

Post a picture of your Virtual Axis Motion Planner Tab. Sounds like you have Master Delay Compensation turned on which will induce artificial offsets for geared axes.