controlsgirl
Lifetime Supporting Member
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.
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.
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) 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) 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) 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.