A student type question.

This is going to sound silly and fall into the category of the rack, modular thing probably but I have to ask.

What specifically is the difference between a PLC and a Motion controller?

I have checked specifications/data/tech sheets on several of each and they seem to use the same type microprocessor in many cases. On some of the motion controllers the update/scan times were in the milliseconds compared to microseconds for plcs.

What actually differentiates a motion controller from a plc?

I am by no means an expert in this, but I believe one major difference is in logic scanning/updating.

In a nutshell, the PLC, when asked to move two devices at the same time, will move one, then the other, etc. The motion controller truely moves both at the same time. This means the motion controller can make true coordinated moves while the PLC can't.

I will let other blow holes in this and point out other differences now.

Steve

http://www2.automation.siemens.com/simatic/regelsysteme/html_76/produkte/sb-fm458.htm

http://www2.automation.siemens.com/simatic/regelsysteme/html_76/produkte/sb-cpus7-317.htm

The lines are certainly blurring a little these days. You have the ControlLogix platform, for example, that splits the motion task between the 'PLC' and the 'motion card'. The plc does the course trajectory planning at a 2msec update rate and the motion card interpolates between the course updates and does loop closure at 250usec. Neither can perform 'motion control' without the other.

That's for 'high bandwidth, precision' moves. And, yes, both 'high bandwidth' and 'precision' are subjective enough that they are almost useless terms. Generally, the slower the move the better chance a plc will have of making it happen.

I think alot of it is based on what each device is intended to do. A plc is intended to do a large number of disimilar task reasonably well. Most people also expect that it will be reasonably easy to integrate all sorts of I/O into the system. Also, while you can get these very compelling scan time specs like 500 usec/1K boolean I don't think they really hold up. I once ran a completely empty ControlLogix 5555 and got a 400 usec scan time. That's all just processor overhead. I don't doubt it could solve the logic at 500 usec/1K. But that would still give me a true scan time of 900 usec. Then you also have market pressure that sets the price/performance point as well as marketing strategies that try to intentionally differentiate one product from another. So to a certain degree the plc is kind of held back so it fits into a clean niche.

A motion controller, by contrast, is intended to do one thing extremely well. So it's designed from the ground up to perform that function flawlessly. This means very high speed I/O comes standard. The operating system is designed specifically to service motion tasks in a very timely manner. Analog I/O is extremely fast compared to plcs.

Again the lines are blurring a bit. Many motion controllers can be programmed to solve general purpose logic. But these are secondary tasks. If the position loop closure interrupt or the trajectory planner interrupt come along the general logic is abandon and the appropriate interrupt is services, period.

And then you have the position loop and trajectory planner as 'firmware' functions. With some noteable exceptions, no plc comes with a true trajectory planner or a position loop fucntion. Sure, you may have a PID. But that will only run every 25 msec, if you're lucky, not the 250 usec or faster typical of today's motion controllers. Then there are thinks like built-in coordinated motion, dual loop closure, multiple feed forward paths, high order noise filtering, etc. Granted, you could write this all into plc logic. But even if you knew what you were doing you would end up with a pretty serious scan time. Additionally I think that many motion controllers have either multiple processors or custome ASICs to perform some of the specific motion tasks.

There are also many other things I'm sure I've completely missed. But this may get the discussion rolling a bit.

Keith

Very good question Ron...

My uneducated guess is that some plc's can be adapted to perform motion control duties, but motion controllers can have limited plc functions.

My experience with GE plc's with motion controller capabilities is limited to a few machines, but they did their job quite well.

I never really messed with motion controllers much, but think they are very limited in thier overall I/O capabilities and quantities.

Since this doesn't really say much, I'll just say, it's Miller Time and let it go at that.

regards.....casey

This is not a question a student would ask.

First, I want to qualify my statement as apply to servo control only. PLC can obviously do stepper motor control.

A servo motion controller has 3 main sections to is software.
1. command processor.
2. a target or trajectory generator
3. the PID and feed forward control.

Of all these the target generator is the most difficult to get right and the PID and feed forward control is the easiest and the smallest part of control.

The are usually many trajectory generators in a motion controller. One for point to point moves, gearing, synchoronizing, camming etc.
Some the the PLCs have ramp generators that can even generate s-curves. However, gluing the s-curves together can be a real trick. Changing the motion profile or even the traget generator on-the-fly is something we put a lot of work into. One must be able to this seamlessly. In hydraulic control there are many uses for being in open loop and making a seamless transistion to closed loop control while moving.

There are usually a few different PIDs. As I pointed out last summer, there are many types of PID. Which is is best depends on the situation. A PID is easy to write. Getting a truely polished PID takes some experience. Integrator windup, saturation, resolution, dynamic ranges and losing significant bits are some example problems that must be solved. I see very poor implememtations all the time.

Keith, gave a pretty good description of how the Control Logix performs motion. Here is a question. Why do you think Rockwell decided to do the control logix motion the way they did as opposed to doing it like everyone else? Bandwidth does make a difference and there is a definition of bandwidth. It is the frequency at which the actual amplitude is -3db or .707 of a target amplitude. The higher the band with the better, normally. Yes, a PLC has a better changes at a application with a low bandwidth requirements.

I pointed out in the motion control thread that having everything synchronous and without jitter is very important. PLCs can't fulfill this requirement.

Motion controller usually have limited I/O. The reason is that there is no point in adding a lot of I/O if the motion controller doesn't have time to scan it. As pointed out above, the motion controller I/O is VERY fast, much faster than PLC I/O. It is very important to have I/O that responds to a few microseconds when doing a registration project. This I/O should not be wasted on inputs or outputs that don't required the speed.

Most PLCs don't even have a decent high speed counter card suitable for doing motion control. We learned a long time ago not to buy commercially available encoder chips. The serious motion controller use FPGAs.

This should kick the ball down the field a little more. I almost past this thread up because of the title but wondered why Ron is asking a student question.

Originally posted by Peter Nachtway:
Why do you think Rockwell decided to do the control logix motion the way they did as opposed to doing it like everyone else?

Click to expand...

A couple of things come to mind. This allows better utilization of available processor power. Since the motion card doesn't need to handle trajectory planning you can get by with reasonable performance with a less advanced processor. Also, the CLX platform can perform 3-axis coordinated motion on multiple coordinate systems. By putting the trajectory planner in the plc you can split your coordinated axes across multiple motion cards without having to worry about syncing up the moves. I don't know that any of this actually makes enough of a difference to warrent that architecture, though.

If any of you get Motion System Design magazine there is a pretty good article in the Dec. 2004 issue about non-Cartesian actuators (like a multi-jointed robot) and some of the control challenges they bring. You might want to check it out and then think about how you would implement this stuff in a plc. Again, this kind of thing can be done in a plc, just not very quickly and it would take huge design time.

You also get into the 're-inventing the wheel' argument here. Like Peter said, the good motion controllers have significant design time in them to do the things they do. While I whole-heartedly believe that it's a good thing to have some understanding of what's going on 'under the hood' of a motion controller it doesn't mean we should try to develop one.

But I think to get back to the heart of your question, Ron, it's not just about processing power and memory. Any of todays off-the-shelf plcs could run circles around the processors in the Space Shuttle. Does that mean we should retrofit the Space Shuttle with plcs?

Keith

One more thing to mention is determinism.
A PLC's scan time can vary depending on sub-routines, etc. Yes it can be done, but it is difficult.

A motion controller is set up to update at fixed intervals. The motion controller will update every XX microseconds no matter what.

PLC/motion controller

We use Acroloop motion control cards in our PC based systems. This card uses RS232 for data transfer, has 32 24VDC I/O and supports up to 16 axes of SIMULTANEOUS motion. We only use 4.

A 5000RPM servo motor driving a 1" pitch ballscrew with a 1000 count encoder = 5000 inches/min to .001" repeatable. What 83KHz counts?

The card can calculate square/trapazoidal/S-curve acc/dec curves on the fly -truncating as neccesary

It handles ALL machine I/O, including E-stops for a turret punch press including plasma and laser cutting heads.

That is a motion controller.

The DL06 allows 7Khz encoder feedback. Same ballscrew and encoder would be 7"/sec? Hmmm - gonna look into that.

Moving 2 axes 8 feet in one second to .001" accuracy could not be done by a wall of PLCs - IMHO

My VB software orders the Acro to it's next move, waits for completion/error msgs while simultaneous drawing the actions on the touch screen.

The Acroloop is quasi-intellegent in that it also runs a user defined (by us) program. The end-user has access to tuning parameters (PID) through the HMI program (my Punch Wizard software)

Does that help/hinder/obfuscate the question?

Rod (The CNC dude)

Actually I had seen that many motion controllers were using FPGA cpu's but the timing specifications didnt seem to match the application.

I get the idea now. A plc may do motion control in low end situations but doesnt offer dedicated and/or multitasking capabilities that a motion controller does.

Seems the trade off is limited I/O or expandability...can I assume that in some cases a plc may still be used in conjuction for handling non motion related I/O?

I dealt with a flexographic press that had stepper motors and controller for positioning but a plc was involved with I/O and communication.

I havent dealt specifically with dedicated motion controllers so for me this was a student question.

rsdoran said:

Seems the trade off is limited I/O or expandability...can I assume that in some cases a plc may still be used in conjuction for handling non motion related I/O?

Click to expand...

That is the most common method. Our machines use a PLC for most of the control with servo drives and motion controllers for those sections. The PLC usually talks to the motion controller via Discrete I/O (Go, stop, fault, etc.) or some sort of Field bus like interbus or DeviceNet.

Many CNC's have motion modules and PLC modules as part of the package. Separate but very tightly integrated.

Originally posted by rsdoran:

Seems the trade off is limited I/O or expandability...can I assume that in some cases a plc may still be used in conjuction for handling non motion related I/O?

Click to expand...

Yea, like Rick said.

As you see from Rod's post the speed/accuracy combination usually sets the dedicated motion controllers apart. And yes, many motion controllers can do generic logic. I just don't know that I would do a whole lot of it in a motion controller. Anything in a motion controller that is not directly related to motion ( trajectory planning, loop closure, etc) is usually treated like the proverbial red-headed stepchild. If you are running a high axis count with a high servo update rate you will starve your general purpose logic. This would be the equivalent of running a timed interrupt every 5msec in an AB or Siemens PLC. It would take you forever to get through your other logic.

Originally posted by Rod:

A 5000RPM servo motor driving a 1" pitch ballscrew with a 1000 count encoder = 5000 inches/min to .001" repeatable.

Click to expand...

A ballscrew spinning at 5000RPM. That would be cool to see. With the stuff we do around here anything over about 100 RPM will get the screw whipping like an overcooked piece of spagetti.

Keith

I have never done motion control and will probably make an absolute fool of myself interjecting here - what the heck. Best way to learn.

I was under the impression that the Omron motion cards did all the work, once fed the information as to position, acceleration, deceleration, etc. My understanding is that there are some bits that then turn on to indicate to the CPU that the position has been reached, waiting for data etc. This would indicate to me that the motion card (there a many of them and I am not familiar with them) has it's own CPU to control the motion, without calling on the PLC CPU to do anything until the position is reached. Some of these cards appear to be very complex and appear to be full motion control cards with their own processors.

Have I got it wrong?

By the way, Omron also have a Fuzzy Logic card, the first in a PLC I believe at the time. This card has no physical I/O. It does the fuzzy stuff but uses standard analogue I/O for feedback and control. It is therefore dependant on scan time but does not add a lot to the scan time itself due to the onboard fuzzy processor. I have used that card several times for various fuzzy suitable applications such as stopping swing on cranes etc.

Bob- you are correct. Most PLC motion cards do all the loop calcs and only report to the PLC. The ControLogix is a little different.

kamenges said:

Yea, like Rick said.

A ballscrew spinning at 5000RPM. That would be cool to see. With the stuff we do around here anything over about 100 RPM will get the screw whipping like an overcooked piece of spagetti.

Keith

Click to expand...

The answer is bearings, lots of bearings. They are also usually not much longer than a few feet. You can also get repeatability better than .001". With the indramat motors they have turn counts in the millions. The accuracy of the screw is usually the limiting factor.