Slide Runaway Problem in Siemens Master Drive

Hi,

We are facing slide runaway problem in our two machine which contains, Siemens PLC S7 200 (CPU 226 - 6ES7216-2D23-OXBO), Master Drive (6SE7018-OEA51-Z), TP 170A and for spindle drive VFD (6SE6440-2UD27-5CA1 (MM440) (7.5 KW). USS protocol is used for communication between servo drive and PLC.

We separated VFD from main control panel, proper grounding done for machine to avoid electrical noise, but problem not solved.

In each of machine two slides (axis) are there, problem come either of these slides. As problem comes once a day we are unable to find cause.



I will provide any other information if needed.



Your comment suggestion to solve the problem highly appreciated.



Best regards,

Riyazahmad.

Has this machine every worked correctly? Or, is it a new problem in a machine which used to work correctly?

Problem is from commissioning (Starting)

Thanks bluebyu for interest in my problem.
This problem is from commissioning.
Slide runaway and tool and component damage, this happens once or twice a day. Some time all ok for couple of days.
Best regards,
Riyazahmad

I'm not a Siemens user, so others will jump in and help I'm sure.

You may want to think about a way to identify which componet is telling the drive to move. Perhaps install a counter in the PLC that counts each time the drive is told to move, and install a counter on the drive output. If they don't match over time, you will have a indication of which device is causing the problem.

Going "way out on the limb", (wild guess), I would say their exist a certain set of events that was unforseen by the designer, that has the PLC telling the drive to move.

Is the orginal designer of the machine around?

I don't have a lot of direct experience with servos but, whenever a motion device is controlled by a tachometer or encoder, a failure of the encoder is suspect when the axis runs away.

I'd take a look at the tach or encoder first to make sure the speed and position feedback is correct.

When you say "once a day", do you mean... "once a day, everyday, at the same time of day"?

Is this true?
"When the problem occurs it happens to one slide, or the other, but not both at the same time."

Except when the problem occurs, do the drives always work properly?

Is it the case that the PLC passes a Target Position, Speed, Rate, etc. to the Drive, then the PLC waits for the Drive to indicate "Move Done"?

Or does the PLC control the position, speed, rate, etc. directly and constantly?

Just thinking... (using 3:00 as an example only)

Cable Connections:
At 3:00 (or very nearly), everyday, a heavy truck drives near the machine. The truck causes the comm-cable to vibrate and miscommunicate. A loose connector can produce very erratic results!

If you have safety limits for travel, or at least someone standing by the E-Stop, wiggle all of the connections... try to make the slides mis-behave. If nothing happens, then retract one slide back to full extent, then direct it to move, slowly, to the other extent... wiggle all the connections while the slide is moving.

If you can't make the slides mis-behave by wiggling the connections, then I think you have either a corrupted data problem, or a corrupted function, or possibly a corrupted comm call.

Corrupt Data:
At 3:00, everyday, whichever slide happens to be moving at that time, that slide suddenly goes berserk. (Or maybe it's the other way round?)

When these failures occur, are there any similarities?

Is the run-away speed always the same? How about direction?
Does the run-away always occur at the same position?

After going through and verifying the drive configurations, I would try to find a way to trap the current conditions when a run-away occurs.

Here is the easiest thing to trap... Direction.

Configure the drive to provide a digital output signal indicating "current direction" (0=Fwd/1=Rev). In your program, keep track of the intended direction and the actual direction... if they don't match then grab and log a bunch of related data to see what the program thought should be happening at the time.

If the comm-link is good, then... either the PLC is passing bad data, or the drive is mis-interpreting good-data.

If you answer some of my questions, I might be able to come up with better, more specific, traps.

Are the drives displaying any fault codes when your problem occurs?

Going on what DickDV has offered, the drive would show fault 90 if it detects an encoder feedback loss. But even if it doesn't show fault 90, don't rule out an encoder feedback fault.

I was going to mention traps, but I see that Terry has replied while I was typing.

Paul

Do you have the USS Protocol communication timeout enabled in the master drive? Therefore if there is a communication problem, the drive will fault and you can determine if thats the problem.

We have checked as below

We have command in only in + ve direction and it some time it goes in same direction in high speed( may be velocity set point changed) or start moving in high speed in opposite direction. ( both pos as well as velocity set point changed). We could not monitor the data receipt at drive end but we monitored the data at plc end. We get actualv position and one analog data in reception. We monitored the actual position for the out of range and found that very frequently we are receiving junk poistion. We had doubt about the actual position getting corrupted in the drive itself. So we set trace funtion for the same limit in the drive and cound not get trigger indicated that the actual position dose not get corrupted in the drive. Then we transfed actual position twice in the protocol in the another double word and found that some time (when value is out of reference ) both values are not same.
We have similar machines at another city on the same concepts working from last 3 years in which we used s7-200 cpu 226 XM. In these machine we have used new version of s7-200 cpu 226. Will that make any diffirence.

when we make the time out active contineously the fault F65 comes, which we are not able to remove. We have two drives communicating to plc on time sharing basis. We have put the time division as 400 ms.

What is your baud rate set to? Perhaps 400ms is too short. I would make the timeout about 5 seconds and see if the fault goes away.

Data lost

During ONLINE observation we found that data tranfer function block colour changes from blue (Done-High) to red, for fraction of seconds.
We think that data may be croupted.
Is this coused to drive runaway?
Riyazahmad

Of course, corrupted control data will cause the drive to behave erratically.

So far, you say...

- Direction changes, sometimes...
- Velocity changes sometimes...
- Actual Position data is reported differently over two different routes...

Actual Position:
If this data is acquired at two different times, you can expect them to be different. It depends on how and when the data is acquired.

Do you modify velocity and direction control in the PLC based on Actual Position feed-back? If so, do you then send the new velocity and direction data to the drive?

Or... do you simply send a Position value to the drive and let the drive handle the velocity and direction?

Basically, what method do you use to control the position and velocity values? What about Acceleration and Deceleration?
Is the encoder an Absolute Position Encoder, or a Pulse Encoder?

We Called Siemens Person

Hi All,

At last we called to Siemens person, as per him programming of drive and PLC not correct.

As per him, we should dump drive data once instead of sending every scan.

We are developing new logic for PLC and Drive.

Let see what happen.

Riyazahmad,