Speed controller drive

[aand74]

I have included a trace of speed setpoint, actual speed and actual torque of a Siemens Sinamics drive. The motor is a servomotor, the load is a heavy print cylinder that has to be rotated at constant speed. At certain moments we get a speed deviation and consequent torque peak of the drive. The moment of the peak is not linked to a specific position of the load.
I see the drive reacts on the speed dip with higher torque, but I also see after the speed dip we have a short speed rise.
Difficult if the load is the cause of the speed rise, or the regulation of the drive.
The total torque peak is about 50 ms long.
The speed setpoint is always constant.
This is pure a case of the speed controller (we consider the current controller well tuned), so I only have the tools of P an I of the speed controller and maybe current setpoint filters.
In what way should I try to solve this speed overshoot after the speed dip?
What are the advisable steps?

 

[Peter Nachtwey]

In what way should I try to solve this speed overshoot after the speed dip?
What are the advisable steps?

Doesn't the print cylinder need to be in phase with what ever material you are printing on? If so you are not really doing speed control but position or more specifically angle control.

If so you are trying to solve the wrong problem. The problem is not that the speed increases to make up for lost position and get back in position synchronization, it is why the print cylinder is slowed down in the first place. It is a mechanical problem not a tuning one.

It looks to me like the servo control is doing what it should be doing.

 

[aand74]

Indeed, when printing the cylinder is geared to a virtual master, so in position control.
But I wanted to go back to lower level to optimize the drive.
I should first have it as good as possible on the speed controller level, so the curve is made when the axis has a constant speed setpoint.
The slowing down will probably have mechanical (conceptual) reasons, but it is a retrofit of older drives and the mechanics (motor-gearbox-cylinder) are in good condition.
We have the phenomen on all of the 12 print cilinders. It must have been there also with the older drives. But these drives are not comparable towards regulation concept.
I doubt however that now the speed controller is at the best settings, I don't like the overschoot of the speed after the dip.

 

[aand74]

Just to add, the mechanical concept is : the print cylinder is 1000 mm diameter, 4 m long, there is a total reduction of (1/60) between motor en cylinder axis. The final gear is on the print cylinder and has 60 teeth on a diameter of approx. 25 cm, so very coarse.
But the peaks do not happen exactly on the frequency of the teeth the couple in (that should then be +- 50ms).

 

[ColDownunder]

This is a problem of distinguishing cause and effect!
It appears to me that the torque rise is the likely cause and the speed the effect. What is the torque rise due to?
Usually servo drives are really stable! You need to find the root cause. Observation of the machine in operation usually highlights the issue. Observe with eyes and ears.

 

[Peter Nachtwey]

I doubt however that now the speed controller is at the best settings, I don't like the overschoot of the speed after the dip.

It is now obvious you have no clue about the relationship between position and velocity.

If the motor doesn't momentarily speed up to make up for that fact that it was slowed by some external force then the print cylinder will be lagging in phase.

The momentary speed increase is necessary to keep the print cylinder in phase.
That is all there is too it. What you need to do is find what is causing the print cylinder to slow down. This is a NOT a control problem, it is a mechanical one.

What you should be doing is asking the mechanical guys when the print cylinder slows down when it is obvious that the torque signal is constant. It is easy to see the torque signal is simply reacting to external forces.

You can reduce the peak of the speed spike but then then it will take longer for the print cylinder to get back in phase. If the positions are to stay in phase the sum of the speed errors must be 0. It is simple calculus.

 

[ColDownunder]

I concur. There is "something" slowing the cylinder, usually associated with the paper / material feed to the printer. It needs to be observed in the real world with eyes and ears. Trends can often confuse. Note also, if there are multiple rollers being synchronised, the problem can be messier!

 

[Peter Nachtwey]

Trust the trend. The trend is your friend.

It needs to be observed in the real world with eyes and ears.

NO! NO! NO! NO! NO! People aren't calibrated instruments. If they were they could move print cylinder more accurately than the servo motors. You need to trust the evidence you have provided. It is clear to me it is a mechanical problem.

Trends can often confuse.

NO! NO! NO! NO! NO! They clarify. They prove and I am thousands of miles ( Km ) away. If you ignore the trends you will only waste time and money. When we do tech support for our own product the first thing we ask for is a trend or graph of the motion similar to what you provided. I rarely trust the people's interpretation of what is happening because they have pre-conceived ideas like it is the controller's fault.

Note also, if there are multiple rollers being synchronised, the problem can be messier!

But now you have a tool and need to do some detective work. Think about it. If you are printing on paper then the down stream cylinders can only pull forward on the upstream cylinders. Likewise the upstream cylinder can only pull backwards. Since your trend shows the paper being pulled backwards I would look at the upstream print cylinders or even farther upstream. Now it is time to divide and conquer. You can't debug the whole machine at once.

I was hired to solve a similar problem once. It was a flying shear instead of a printing machine but they are much the same in that there is something that is doing the work that must be synchronized to the line of material to be worked on. In my case I was able to detect the problem within 1/2 hour of arriving on site using a graph similar to the graph you showed. The lack of a good trend prevented the customer from seeing the problem until I showed up with my equipment. In this case it was bad bearings causing bindings and releasing of the sheet metal but the customer was blaming the controller.

I still have the graphs of that machine and how it was binding and releasing.

 

[ColDownunder]

NO! NO! NO! NO! NO! People aren't calibrated instruments. If they were they could move print cylinder more accurately than the servo motors. You need to trust the evidence you have provided. It is clear to me it is a mechanical problem.

Peter,
I did NOT say not to look at the trend, but 3 lines don't make a picture.
This guy needs to look at the machine, because as sure as my but points to the ground, he's looking at an effect caused by something else! This trend shows a problem, but it doesn't identify the cause!
As you say, the problem is likely in the paper feed, which is what I said! The cause will be identified by observation, the effect is shown in the trend! There may be other trends which can pinpoint the issue, but this is not it, and no amount of tuning will fix the cause of this effect!
Optimism is born of blissful ignorance.
Pessimism is the product of bitter experience.

 

[aand74]

Unfortunately I did not mention that this trace was taken when the cylinder was away from the printmaterial, so no other components could drive it.
When the print cylinder is pushing the print material, the peaks get a lot smaller.
Nevertheless we should also want to optimize the tuning in this case where the cylinder is not touching other components.
And the trace is still the situation where the axis in speedmode (no position controller active), just to narrow the problem situation.

 

[Manglemender]

It looks to me like the drive is behaving entirely correctly.

You have said that this affects all the print stations and also that you can still see the effect without any material in the machine. So we can conclude that the cause is something common and that it isn't related to the material.

What else is common to all print stations: Virtual master? Old mechanical line shaft? Registration system? Power supply?

Nick

 

[Peter Nachtwey]

Unfortunately I did not mention that this trace was taken when the cylinder was away from the printmaterial, so no other components could drive it.

So now you know which print cylinder is the culprit.
Do other print cylinders behave the same way when tested under the same conditions?

When the print cylinder is pushing the print material, the peaks get a lot smaller.

The extra mass of the extra print cylinders would dampen disturbances. You need to test each print cylinder separately but you already know the current print cylinder is a problem.

Nevertheless we should also want to optimize the tuning in this case where the cylinder is not touching other components.

Arrrggghhhh!!! You don't get it. The tuning is fine. You have 3 options. Stick with what you have, make the tuning more responsive, and make the tuning less responsive. If you make the tuning less responsive the motor will not try to catch up as quickly so the spike will be smaller but longer. If you remove the over shoot altogether then in normal operation the response will be sluggish. Tuning is not the answer.

And the trace is still the situation where the axis in speedmode (no position controller active), just to narrow the problem situation.

Are you sure? Did you disable an outer position loop?

It is a mechanical problem. Ask the mechanical guys why the print cylinder slows down when given a relatively constant torque. The mechanical guys are probably too stupid to understand the trend. You will need more patience than I have and explain it too them.

 

[aand74]

So now you know which print cylinder is the culprit.
Do other print cylinders behave the same way when tested under the same conditions?
.

Yes, the other print cilinders behave the same way when tested under the same conditions.

Are you sure? Did you disable an outer position loop?

Yes, With a parameter in my move command I can move the axis
without position controller and thus with constant speed setpoint.
As said the reason for this is strictly to analyse the speed controller without influence of the position controller

 

[Manglemender]

Yes, With a parameter in my move command I can move the axis
without position controller and thus with constant speed setpoint.

A move command is still a motion control function and so the position loop is still likely to be active. To test a drive in velocity mode, use the diagnostic functions in Scout/starter to control the drive directly.

Nick

 

[ColDownunder]

Stabbing in the dark as we all are, if the response is the same on all controllers, is the glitch a simultaneous on all controllers, i.e. if 2 are running, do they BOTH glitch at the same time. If yes, then there is obviously a common mode disturbance. If the speed signal to the servo is sent via a +/-10Vdc signal, there could be noise on the signal, especially if shielding is broken. Can you trend the speed set point being RECEIVED BY the SERVO? If yes, see whether it changes.
Does it glitch at a regular frequency, or is it random? If regular, this should be easy enough to pinpoint.
It is obviously a disturbance, you've just got to remove all of the possible gremlins, one by one. Not knowing what the set-up looks like is just stabbing in the dark. Don't look at one thing, but look at how you have setup your test and where the control cables run and what else can possibly overwrite the MOVE instruction.
Optimism is born of blissful ignorance.
Pessimism is the product of bitter experience.
Frustration awaits.