Programming AB Servo with standard PLC vs PLC w/motion option

[controlsgirl]

I have programmed servos from a handful of variety of manufacturers and series. Each time I used a PLC without motion functions. I have not worked with AB servos though and I am hearing from my engineering department that it takes controls engineers a couple of days to get a AB servo up and running with a standard PLC vs a couple of hours with a PLC with motion. All of our applications are simple point to point moves on a single axis. Is there something about the AB servo that makes it very difficult to program without the motion option on the PLC?

In my experience of programming single-axis, point-to-point applications, there are three main chunks of work to do to program a servo function.

1. 1) Figure out the hardware configuration and how to setup the I/O in the servo controller. All of the servos I have worked with have a similar move motion profile that takes inputs of distance, speed, accel, decel, and a run trigger. (There are usually options to run in a different motion profile like torque with its set of parameters). [I configure I/O for the setpoints: location, speed, accel, and decel so I can manipulate them in the PLC vs hardcoding them in the servo controller.]
2. 2) Write a chunk of code to handle triggering a motion command while sending the necessary parameters. This code handles things like setting the mode type for the servo motion, triggering a motion command, passing setpoint parameters, monitoring the feedback, triggering faults, etc.It abstracts the layer of code that controls a servo motion from most servo make/model dependent data. I use this same chunk of code for all servos I program, regardless of the brand/series.
3. 3) Write the motion logic specific to the application. Write the sequence logic to trigger the motion commands. I write code for each move of the servo just like I write motion logic for cylinders. (interlocks, command request, output, feedback, fault). For example, instead of "Cylinder 1 adv/return, advanced/returned, adv fault/ret fault" there is "Servo 1 Motion1/Motion2/Motion3, InPos1/InPos2/InPos3, and Motion1fault/Motion2fault/Motion3fault".

Would I be able to do this same thing with an AB servo controller? And if so, what would make it faster using a AB PLC with motion option? I am confused as to why it would take our engineers so much longer each and every application. I understand the extra time learning the nuances of an unfamiliar servo brand/series. I even remember the big chunk of extra time I needed to take to figure out how to write code that would allow me to program the servo like a cylinder. But, once the abstracted layer is complete, that code is reused. And, once the I/O handling part of the code is written for a certain servo controller, that code can be reused. What's left is coding each motion call which is nothing more than if you were programming cylinders.

I hope all of that makes sense. If you read this far, thank you. Part of me explained the code for anyone who may need help sorting that out.

 

[Jeev]

To be honest, a simple point-to-point or indexing application probably takes a similar amount of time between an "Indexing" drive and a "Motion" drive. There's a huge difference when you try to do anything "motion", such as Camming, Gearing, Virtual Axes, Master-Slave, and so on...

If you only require simple point-to-point indexing, then buying an indexing drive may save a bit of cost in processor and inverter. If you have a huge number of axes, then it may also save cost in network infrastructure.

I suspect the extra time may also be a result of understanding and setting up the motion stuff - Especially if someone has spec'd the motor, so you are running a higher inertia ratio where there may need to be some tuning of the axis. This is not an Indexing vs. Motion problem. This is a someone didn't design the motor or drivetrain correctly or didn't understand the load problem.

 

[Ken Roach]

Historically, A-B's indexing drives have been private-labeled or developed separately from the Motion Control Division's main product lines. So the software and functionality has varied quite a bit.

One thing A-B has done pretty well with the modern Kinetix 5100 products is that they provide a set of Add-On Instructions that emulate the CIP Motion instruction set. There's still standalone configuration tools and applications that integrate with something other than ControlLogix and CompactLogix.

When you use the AOI's, you don't run the Kinetix 5100 with an "M" model CompactLogix or define it as an axis. But you do execute an instruction that is "MSO_5100" or "MAM_5100" or "MAFR_5100": they look and work similar to the MSO and MAM and MAFR that are in the CIP Motion subsystem.

They're not perfect: sometimes the timing is a little different and the diagnostics are not identical. But they do the abstraction layer that you're describing, out of the box.

I've seen other vendors do similar things, providing their equivalent AOI. Wittenstein does it for their Cyber Drive motors, Yaskawa does it very well with some Sigma family controllers, and I'm sure some others.

 

[joseph_e2]

I didn't know AB did that for the Kinetix 5100. That's actually very helpful info to have.


Mitsubishi has AOIs for their J4 servo drives. They've been pretty straight forward for us. If AB's are similar, I would seriously consider them for our next motion project. Well, maybe the next one after that. The next one is a hydraulic system that *may* need to be servo driven.

 

[controlsgirl]

Thanks for the feedback. I also suspected it might have to do with experience and motor tuning as well. I like the your differentiation between the "indexing" and "motion" servos. It makes sense.

What are some of the more demanding motion applications you've worked on where having a motion PLC would have a clear advantage over using the servo's controller to program?

To be honest, a simple point-to-point or indexing application probably takes a similar amount of time between an "Indexing" drive and a "Motion" drive. There's a huge difference when you try to do anything "motion", such as Camming, Gearing, Virtual Axes, Master-Slave, and so on...

If you only require simple point-to-point indexing, then buying an indexing drive may save a bit of cost in processor and inverter. If you have a huge number of axes, then it may also save cost in network infrastructure.

I suspect the extra time may also be a result of understanding and setting up the motion stuff - Especially if someone has spec'd the motor, so you are running a higher inertia ratio where there may need to be some tuning of the axis. This is not an Indexing vs. Motion problem. This is a someone didn't design the motor or drivetrain correctly or didn't understand the load problem.

 

[Jeev]

What are some of the more demanding motion applications you've worked on where having a motion PLC would have a clear advantage over using the servo's controller to program?

The notable ones all required camming or gearing, and virtual master axes (Mostly K6000 and K5500). The one that took me a while to get my head around was indexing accumulation belts where one set of indexers chases the other without interrupting product flow. More recently I was involved in doing a modification with the SEW Movi-C stuff, where we were retro-fitting a couple of axes to someone else's machine. That one used an external encoder to follow the main transport of the machine, and synchronised two new indexers to it with a camming profile. That one helped pull product away from the transport on the outfeed of the machine, which was causing damage to the product when the line speed was increased.

Most of my experience is in point-to-point type stuff with AB, SEW, Festo or SMC drives/motors.

 

[sparky66]

Yaskawa has the SigmaLogic line of servo drives that are great for point-to-point motion. A full set of AOI's to work with Control/Compact Logix PLC without the need for a motion PLC or motion card.

 

[dwoodlock]

The next one is a hydraulic system that *may* need to be servo driven.

My company makes a servo powerpack using a rexroth drive/servo/pump with sytronix firmware, and I can say with confidence it works well, and collaborates fine with Ab controllers.

 

[joseph_e2]

My company makes a servo powerpack using a rexroth drive/servo/pump with sytronix firmware, and I can say with confidence it works well, and collaborates fine with Ab controllers.

That sounds promising...if we can ever get it re-launched. It's been on hold for 3 years now...

 

[Peter Nachtwey]

Thanks for the feedback. I also suspected it might have to do with experience and motor tuning as well.

Motion controllers should have auto tuning that work.T

What are some of the more demanding motion applications you've worked on where having a motion PLC would have a clear advantage over using the servo's controller to program?

Anything that requires a linear to rotatory conversions.
Many applications require camming a function of another axis. Many times, the gains need to change on-the-fly
https://deltamotion.com/solutions/pipe-handling-oil-gas

There is no way you can roll your own and cover all the bases.