Any servo gurus out there?

[coolhand 0]

Well we just got a new palletizer with 4 Servos. In the past (this is their first stab w/ servos)this OEM built their machine w/VFD's and it worked OK. These palletizers are built with sheet metal and use #60 chain for the mechanical coupling to the hoist area and belt drive on linear bearings on the horizontal sections -it's rigid enough for the old style but I can see gusets and braces added on the new style. The reason for the move for servos was speed. With the VFD, if the "envelope" is pushed, controling the load is quite rough and the drive train takes a beating. We also see a lot of over bussing due to rapid deceleration or reversing speed too quickly. There seems to be a physical limit to how fast it could be run and not shake apart. Well the new machine has been in service for about a month now and does run fast and a lot smoother than we able to do with the VFDs, but a LOT of faults are occuring. I am seeing "thermal" and "folowing errors" in the Hoist (suspended on chain) and I suspect this may be from the back lash from the chain. And I am seeing a LOT of "over buss" faults on one of the horizontal sections (Rowformer). The rowformer brings the product onto an accumulation bed at a high rate of speed and then matches speeds with it before delivery. From what I can gather for info, I believe the overbussing is happening during decel when matching speed occurs and when the PLC (AB 504) sends a stop command to the drive (obstruction in the path, opperator, etc.). Since this is a new line for our factory politics will no doubt ensure between us and the OEM. In the meantime this machine is faulting about 4-6 times a day and I'm not ready (or permited because of the politics) to start making changes. I have a Rockwell Automation guy coming in first part of next week to survey the application and make recomendations for getting this line going. Do any of the gurus have any experience with the Serco 3000 series? Rather than using the AB 5000 and the Sercos drives as they were designed they are using a 504 and simply sending run commands for different steps and monitoring the motion with seperate encoders. I feel that backlash from the chain will become an issue for us within a couple months. Is there paramater adjustments for an application like this I sould be asking about? The other question I have is the drive undersized for the Rowformer? Would a larger drive offer more control of the load and re-gen less? And would a larger servo controler have a larger buss to control this re-gen. I do believe that there are some errors in there PLC logic in how this portion of the machine is controlling all this mass. I mentioned that when an opperator put the machine in hand mode, etc. It will come to an abrupt stop (i.e. re-gen). I think that if I programed it for a coast to stop and then applied the brake it may take care of a lot of problems in this area. So if there are any Servo guys out here I may start asking a few questions about this. Thanks for the help. Luke

[jstolaruk 9]

I've been doing a lot Ultra3K apps lately. The errors you're seeing can be due to a number of things; the drives may need to be tuned, the following error range parameter may be too tight, or as you mentioned, the drives are sized too small. As far as the Sercos, the only thing it really gains you is a better interface to the Ultra. You get to use the ControlLogix motion command set which is nice and rich without worrying about the interface portion and having to tweak things in the Ultra yourself. Using the Sercos interface won't get rid of the errors you're experiencing. Is the 5/04 using the devicenet interface or is it a discrete connection? Either way, you'll want to have a copy of Ultraware handy so that you can connect to the Ultras. If its devicenet, editting the Ultra's parameters via devicenet is pretty basic. Ultraware gives you some tools to work with; autotuning, graphs, etc. The R.A. guy should be able to tell you via Ultraware on your sizing questions after he auto-tunes the drives. Please post your progress. -Jeff Edited 30 Apr 2006 by jstolaruk

[Gerry 13]

Re: "over-bussing" I presume that's an over voltage trip. The Ultra 3K drives are fitted with an internal shunt, but you may need the optional external shunt to handle the regenerative energy in your application.

[coolhand 0]

Thanks for the replies. The aplication is discreat I/O -Devicenet would have been a much better option. A couple of these axis are using a seperate encoder to verifiy position. Had Dnet been used the servos encoders data could have been used. Using Control Logix would have been the ultimate -but it is what it is. A trouble I am having with trouble shooting is figuring out what exactly is happening. The line opperator is not looking and communiating all the info as to where it was in the process. If another maintenance guy gets called they are not always looking for the same either -just get it going. We do have the Ultraware software and I have been using that to look at Fault History, etc. The Rowformer at last count had 19 Overbuss faults and I think I have an idea where this is comming from aside from the rapid decceleration. If the gaurd door is opened, put in pause, or a jam condition occurs it is stopping too fast. If this were a VFD I would lengthen my Decel or at least set it to "coast to stop". Are my stop selections also available with the servo drive? I'm sure I'll have 101 questions for the RA guy but I don't know how much "tweaking" will be allowed because of the politics surrounding this install. The OEM should be the ones in the plant fixing this 6 weeks after production. If it were a new car it would have been back to the garage. I did notice the Shunts on the drive and see that an external Shunt can be installed. This may be an easy option. I'll keep you guys posted. Thanks Luke

[jstolaruk 9]

Luke, as Gerry pointed out, its sounding like you need an external shunt to absorb some of the energy being regen'd back because of the sudden E-stops. Or, if possible, make the E-stop on the servo a controlled stop but that usually requires locking solenoid gate switches so that you can control when a door is allowed to open. On servo apps, I do that as standard practice because of issues like your experiencing. I have a high speed gantry application right now and I'm putting in a ton of time developing the safety strategy/circuit to avoid having these kinds of issues. -Jeff Edited 30 Apr 2006 by jstolaruk

[OkiePC 14]

I have seen several "rookie" servo users under size drives/motors/regen capacity. They guess at mass or speed requirements or end up tuning the accel and decel beyond their original calculations. Your stop command setup is critical, and e-stop wiring can also be a factor with excessive faults of various types. I have used most of ABs servo line, but not sercos yet. First, are they set up as positioning drives? Or are they being run as VFDs (enable, speed and direction). The latter is underutilizing the capability, but still a step above plain VFD drives. Also, it is important to know how the external feedback is connected and how it affects the control command from the slc. Does the slc calculate speed and direction from external encoders? This would be a terrible thing to do, but I have seen systems set up that way. Ideally, with your hardware, your SLC would send position commands and motion parameters to each amp, and the amp would close the loop with it's motor's feedback. The SLC could still use the external encoders for verification, but not for speed and direction calculation. If the SLC is just sending speed and direction commands and "closing the servo loop" itself, it will have to be detuned to deal with chain slack and the processing delays caused by the SLC itself. I would start by slowing things down a little starting with the decel parameters... That may buy you time to study exactly what you've got. If you have the SLC closing the loop, buy the regen resistors and keep the chains tensioned just right and you can tune her back up. It's not the ideal thing to do, though...if you can change things to let the servo amps close their own position loops or add a true position controller to the system, you will find a huge advancement in performance and may not need to upgrade your drives/motors. Just my 1st impression based on what you wrote...Can you share with us how the servo amps are getting their commands and what those commands are? Paul C

[coolhand 0]

Thanks for the replies, guys. Paul, the commands for the drives are as you sugested -as a move command from the PLC. The "steps" are stored in the drive.Eachstep stores the paramaters for speed, position, accel, decel, etc. For a guy that has only been exposed to VFDs it's pretty cool. The Rockwell guy has been a big help in my digesting what is going on or what should be going on. The drive stores an hour meter and we are running around hour 1200 (not very old) because of the time stamp we were able to determine that only two of the drives are an issue. One drive has been getting a drive over temp fault. Acording to Mr. Rockwell this is a "calculated" fault. This means that if my Continuous Output Current limit is running high and goes over the 23A peak that is okay once in awhile (max is 46A) but if I go over that limit continually that current multipled by Time = Thermal Protection Fault. The Servo has been peaking @ around this limit all day and seems to do fine, but if the line is running 100% this means this axis is running a lot more (time) and then the faults start to occur. The RA guy found that the drive is sized small for our application. We could slow this area down -but it would not be what was "sold"to us. I think we will push for a replacement. The other axis has only been getting Overbuss faults. The buss is capable of 800 volts and faults @ 810. Looking at the drive and motor we found out again that the drive is too small. I priced out the external shunt for about $500. We could resize the drive, or we could slow things down. This is one axis that gets a lot of opperator intervention by being put in hand mode or the logic stops it because of a "jam condition". I am also able to get this area to fault. By looking over the steps we found that it moves for 18" @ 55 inces per second and then is commanded to slow to 6.8 inces per second until 30". This 18" area is where I see a lot of the faults occur. By looking @ the first move step it's decceleration was set to 2500 1/10 in/sec/sec. He moved that to 1000 and now if put in hand mode within the first 18" it coast more and does not hit the Buss. I think we will recommend the external shunt. Oneof the big problems is that when one axis faults all axis require homing. The OEM designed it so that the E-stop is pressed which drops power to all drives. My preferance would be to only home the axis that is faulted rather than see the half hour plus of downtime -work in process creates quite a mess. I'm hoping to get some good feedback tomarrow from the rockwell guy on how this could be better handled. Thanks for the input. More to follow... Luke

[jstolaruk 9]

There is a couple of ways that this can be handled. Some of Ultra models has a auxiliary supply input that will maintain power to the encoders and counters so that home isn't lost when the main power is dropped due to a E-stop; This would have had to been thought of when the job was designed and the correct model ordered. The other option is get the breakout board that accepts an external 24VDC power supply that does the same thing. This is than an easier fix than getting new drives.

[coolhand 0]

This is something that the Rockwell guy pointed out as an option and I think may be the way I'll lean. It will take a bit of time to weed through the logic that they have surrounding the homing sequence. Unfourtunatly we are within a month of our busy season and time will be at a premium -so if these nusiance trips can go away at least it is progress. Thanks for the help. I'm sure I'll be back. Luke

[coolhand 0]

Well, this is a progress update. The visit from the Rockwell guys was very helpful since I have no training or previous exposure to servo drives. For one thing it has been interesting and my impression of the Ultraware drive software is that it is a good tool. The problem with one of the axis is that it was overbussing and after looking at the drive step commands and the logic of the machine we were able to duplicate a fault. In the first 18" of travel the servo is moving this axis 55" per second and once 18" is met it goes to the second step which is continuing forward @ 6.8 " per second until 30". The overbussing was occuring in the first step when the movement was interupted i.e. out in pause, guard door opened, etc. The decel command was to stop within 2500 1/10" per sec/per sec. He moved that value to 1000 and now when the step is interupten it doesn't stop like hitting a wall but rather coast a bit. -Can anyone out here explain this 1/10" per sec/per sec? My thinking was to go from 2500 to 3500 to get more of a decceleration time. The second drive was faulting for a drive thermal fault and we were never able to see this happen. I spoke with opperators for this new line and new that sometimes they noticed that the gaurd door indicator light was on (door open) when they came to the faulted machine. The servo has an external brake that is activated when put in hand mode, the door opens, or power is off, etc. I looked at the PLC logic and verified this, BUT the drive was still recieving it "drive enable" signal. This meant that if the door came open while the servo was in motion (especialy up), tthe move command was stopped, the brake was engaged, but since the drive was still enabled that the servo motor was tring to "catch-up" to where it thought it was in its' motion. While the servo was catching up it was trying to drive through the brake and the current draw was going through the roof and then would fault the drive. I changed the logic so that the drive is now disabled when the door is opened as well. The drive keeps an hour meter and since they are @ around 1200 hours and had had about 30 faults between these two drives it should be obvious in a week if these adjustments were succesfull. Thanks for the input and if anyone can explain this deceleration of " 1/10" per sec/per sec " I would be thrilled. Luke

[jstolaruk 9]

The OEM changed a drive parameter so that units were in 0.1 inches. I generally leave it in encoder counts but not as an absolute rule. Also, it sounds like the OEM didn't do much testing with the drive parameters that were in it. They would have seen the thermal overload faults if they had tested the safety circuit while the drives were running. Sounds like you're on your way to gettin it straightened out. You may want suggest to management that they review their buyoff procedure (if they have one). When GM, Daimler, or Ford comes in to buyoff a machine from us, it takes a couple of days to get through their review and also there is a recorded 20 hour run we do that has to occur with no faults; we use a strip chart recorder monitoring some I/O. Of course they buy a ton of equipment all the time and have learned the hard way. Edited 5 May 2006 by jstolaruk

[Gerry 13]

As jstolaruk explained, there's a 0.1 multiplier on your units. So, decel of 2500 is 250 inches/sec/sec Assuming linear deceleration: If the axis is travelling at 55 inches/sec and told to stop with decel at 250 in/sec/sec it will try to stop in 0.22 sec (55/250). Stopping distance would be about 6.05 inches (0.22*55/2). If you changed the decel to 3500 or 350 in/sec/sec then stopping time would be 0.16 sec and distance would be about 4.3 in. Your OEM should be informed that the brake on a servo motor is a holding brake, not a service brake. It is intended for holding a load against gravity when the axis is disabled, not for assistance in stopping. Servo motors are designed to supply full rated torque at zero speed continuously.

[OkiePC 14]

If the decel rate is too slow on the drive that was adjusted, a regen brake kit may get you the stopping power you need without bus over voltage faults. It should only be necessary to home the axes when the drive logic power is removed. It is usually (but not always) possible to leave the drives powered in an estop condition and open a contactor between the drive and motor when an e-stop occurs. I have dozens of 1391 servos, and a bunch of ultra 100 and ultra 200 drives wired that way. I've also done it with industrial dirves (kollmorgen). Nothing can stop the load faster than a functioning servo drive. To let the drive stop the motor and still meet compliance for our risk assessment, we put a 3 second off delay safety relay in charge of our servo contactors. The drives are commanded to stop as fast as possible (without faulting!) immediately, then they are disabled by the controller, then the contactors open. Timing can be critical here. You don't want to open a contactor while the drive is applying power or receiving power from the motor. The only real risk is that if a servo amplifier goes nuts, it will have about 3 seconds to tear things up. I have never had that happen on our machines, and I have at least 100 axes of servo motion connected this way. The other time you want to ensure that an axis is homed is if there is a feedback related fault (encoder loss/noise, resolver loss, etc.). Most of my servos are connected to a controller which handles the position loop so I can pick and choose when to require homing based on very specific problems. Since your drives are PLC controlled, it would be best to require homing on each axis that has a fault, (assuming the fault/ready status is available to the PLC). Using external logic power as suggested is good, but you still may get occasional faults if your drives are not disabled before the bus voltage drops on an e-stop, and you really won't be able to use the servo amplifier's ability to stop the load, you will be stuck with a little coasting or external braking of some sort. Paul

[coolhand 0]

Thanks for all the responses and input -I apreciate you all taking the time. It's been a week since Rockwell guy and no faults have occured! This is a huge plus to production since it was taking around a half hour to recove and clean the mess and a good part of the shift to smooth the line out again. The other downside I was starting to see was rejection/lack of trust from the opperators towards the new line. It turns out that the servos we have could have had different encoders. The ones that are on ours read 360* and then start back @ "0" hed they cept track of total movment we could have used the idea of aux. power to keep track of location. -If I am understanding all this correctly. I did price out the shunt for the drive and it will cost about $500. Not bad. I still have a question about the decel. Ours was at 2500 and stoped on a dime (and faulted out). The tech put 1000 in for decel and now it coasts a few inches in a more controled manner. My thought would have been to put a larger number in this setting rather than the smaller number. I have not had time to sit down and read all about the parameters yet but do have the Ultradrive software on my laptop for my reading enjoyment . The comment about the brake is true. The brake is only for holding the load and not controling or possitioning. As I was working with the guys on a changover today playing with VFDs and moving limit switches around I couldn't help but think servos would be a lot nicer. I don't see the bosses making a big move towards upgrading this new line, but at least I have a better insight to what was happening and have some answers to future events. I'm sure I'll be back this summer when things get "broke-in" and things start crashing and getting out of square, etc. Luke

[BobLfoot 302]

I've read a lot of the posts which follow the May 4th progress update and no seems to answer this directly so I'll put by B.S. Math hat back on and try to explain. 1. Your deceleration parameter is not in time but in rate. In you case inches per second squared. 2. Going back to basic physics - Distance = Average Velocity x Time or D=VT 3. Also from Physics we know that Instantaneous Velocity = Acceleration X Time or V = AT To get a velocity in Feet per Second after X? seconds acceleration must be in Feet per second Squared. I used Acceleration here , but the same applies to Deceleration. If you combine formulas 2 & 3 you will get that D = 1/2 AT^2. so with Acceleration the larger the number the greater the distance covered. Deceleration being the inverse the larger the decel rate the fatser the stop in time and distance. Edited 10 May 2006 by BobLfoot

[OkiePC 14]

In other words, if you decelerate at 2500 units per second, as each second of time elapses, that is a lot faster than decelerating at a rate of 1000 units per second, per second. Paul

[coolhand 0]

Thanks for the replies concerning the accel/decel. Instead of hundreds of servos in our plant we have hundreds of VFDs that we are used to entering a time value. Now I have a better understanding of what's going on and warn the other guys