Is this correct. Take the Siemens s7-300 range or any other Manuf. equivlent and compare it to a PC with a DAQ card.

Which is quicker?

Would a Very High Spec PC eg a 1500MHZ or Bigger run quicker than the PLC.

 

Hello;
Your supercharged PC would probably treat the data faster than the PLC... once it is inside the box. Your limitation here would basically the sampling and conversion time of your DAQ card. Also the PLC will not be interrupted by user input-output (no keyboard, harddisk or video screen). The PLC does very few things: reads inputs, writes outputs, scans a logic program, controls communications on its interface cards; but it does them continuously, cyclically, at a very fast pace.
Often in our projects we find it useful to mix both machines: the PLC to collect and treat the process data regularly and faithfully; the PC to sort, archive, log and manipulate the data transfered by a fast connection (Profibus, TCP/IP, firewire) from the PLC. This is where the SCADA programs reside.

Hope this helps,
Daniel Chartier

 

Really, PLC's are nothing more than a computer manufactured for a specific task.
There is nothing special in PLC's make them as PLC's!
Regarding the speed, if you can guarantee that the equivalent PC is not doing any other thing limmiting it's control task time. then your PC is quicker than your PLC. Based on the rapid improvement in the PC technology today, it is correct that in the speed point of view PC's are better and getting better day by day because we don't see such an improvement in the PLC technology all because of it's limitted usage!
REZA HASSELI

 

defintlt Plcs are slow where as a PC with modern operating system works faster utlising many technologies like cache memory, piping,multotasking video ream etc.
james

 

With the right software and hardware PC's can be much faster than PLC's. I can easily acquire 16 bit analog readings at 200ksamples/sec or record live video at reasonable frame rates. I can read digital data at staggering rates. But, that's not the whole story. These rates require much more than just the hardware capability. PLC's are
deliberately slow with input filtering and edge control because this lets folks wire just about any way and still get away with it. If you were to get 1 usec. scans with typical wiring, you would get a lot more than you bargained for and would spend your life chasing timing problems and false data caused by ringing and waveform
distortion.

Beyond a certain speed, it becomes a challange to get even digital data from one point to another with signal integrity. That's why even relatively low speed networks use transmission lines ( STP. UTP, Coax, Twinax, etc.), line termination and impedance matched connectors. It is a very illuminating exercise to hook a pulse generator to your cabling and try sending even a 10khz square wave 30 feet across open wire or bundles. Using a scope on the other end will show you exactly why bigger PLC's handle more points but don't neccesarily scan faster. At higher speeds, wiring becomes critical and becomes the most important factor in machine speed.

Believe it or not, the limiting factor for the speed of computers is getting signals from place to place and has nearly always been. Also, most of the physical events we deal with don't happen at light speed. As someone who has spent a large part of their life measuring things where an inch of uncompensated lead length makes measurement impossible, my advice is not to bitch about PLC's
being slow, but to wonder at their ability to keep things sorted out at the speeds they are running already with so little attention paid to physics. My production Linux PLC can scan at < 20 usec.

Out on the factory floor, it scans at 10 msec. because nothing it's connected to, (robots,CNC, sensors) knows the difference. At that speed it can handle a vast number of points and grab frames for a couple of cameras, run several terminal sessions and play a pretty good game of DOOM. In other words, raw horsepower is not the issue. You can't use the speed without changing the rest of the world and having a pretty good grasp of what you're doing. A working 1 mhz installation would be unrecognizable compared to
common practice.

Regards
cww
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

 

These would run much faster than a PLC. A PC based control package running on a Pentium 166 would run (scan??) much faster than most PLC's.

 

Benchmark it.

Example: since a lot of our applications involve some simple math, we have a test program of finding all of the prime numbers below 32767. This takes about 15ms in C on a 1GHz Pentium III. Written in Java and executing on a JavaVM on the same machine takes about 40ms. In Visual Basic, about 55ms. In Think & Do, it's around 500ms, because of scan rate and While block limitations. Then we switch to PLCs.

On an Allen-Bradley ControlLogix 5500, it took 12 SECONDS (not milliseconds like before). This trips out the watchdog. Chunking it up so as not to blow the scan rate, it takes around 90 seconds. On a Modicon Quantum, it took two and a half MINUTES. PLCs pretty much suck at math.

But the benchmark you need is with analog data. I haven't tried it; all our stuff is discrete and motion control, and we let the motion controller do all the loop closing. The classic test for timing discreet I/O speed is to wire an output to an input and monitor with an Oscilloscope then do an examine if open on the input to fire the output. On the o-scope you can watch how fast the ouput goes off and on.

Anyone have a reasonably simple benchmark for analog control?

-James Ingraham
Sage Automation, Inc.

 

I started to reply that this was simple, but then I realised that it *isn't* simple at all. The scan rate can be determined from the digital I/O test, but the hardware response of the A/D and D/A and filters isn't so simple to test. The normal way to test the hardware response of analogue systems is to have it read or output test waveforms. However, PLCs don't really do this very well. It may be best to simply go by the published specs for these if they are reasonably detailed.

However, here is a suggestion. To test the output, program it to output a square wave, and measure this with an oscilloscope. The shape of the waveform will tell you how fast the output will respond to a step change. If the output frequency of the waveform is missing pulses (the scan rate is faster than the output), you may need to slow down the output (e.g. every other scan, every third scan, etc.) until the output can keep up.

I don't have any good ideas for the inputs. This process is likely in most cases to be dominated by the scan rate, rather than the hardware. However, here's an idea. Perhaps you could feed a square wave into the input and use
it to clock a counter when it goes above a threshold (e.g. 90%). Use a timer to provide a time base, and you should be able to measure the input frequency (you may need a long sample period for useable accuracy). As you increase the
test frequency, you will reach a point at which the signal begins to alias significantly. Since you know the scan rate (from other tests), you can determine whether the aliasing is due to the scan rate or whether the card is actually slower than the scan rate.

I've used the digital I/O loop-back test to measure the response time of a large PLC system. Sometimes the specifications are not clear enough, and when remote I/O is not synchronous with the CPU scan, then the program scan won't tell you the true system response.
In a project I did a couple of years ago, we replaced a large PLC which controlled several adjacent machines with a number of small (and much cheaper) PLCs. The machines performed a large number of rapid operations each cycle. We found we actually reduced machine cycle time by about 12% due to decreased scan time. This wasn't the objective of the retro-fit, but it is a good example of how several small inexpensive PLCs can often out perform one larger one.

************************
Michael Griffin
London, Ont. Canada
************************

 

I would love to see the benchmark code. It was probably implemented in a non-optimized manner for PLC's. If you were using recursive looping, then PLC's would suck air. But if you would use a file compute operation with indexing, then maybe PLC's would be in the same ballpark.

We converted a cascading 5 x 100 cell computation matrix in Excel to a 10 rung code in a PLC-5, the RSView MMI station was getting updates on screen faster than hooking the cells from Excel, with Excel running on the same machine! Yes, the communication delays comme into play, but this is what we should be benchmarking...total thruput.

Also keep in mind that PLC's have fairly advanced intruction sets. If you use these instructions properly, then you can compare apples to apples.
PLCs were never meant to run C type code!
Try to get a PC to do a profiled motion move computation AND get it to the axis controller in a timely manner...Oh, and just to spice things up, try doing this when you are changing other parts of the C code ON-THE-RUN...good luck!

 

I agree that testing an analog input is likely to be limited by the scan rate, but regardless if where the limitation is it is what you have to deal with.

How about this for a test? Generate a ramped input from outside the system - i.e. from 0 to 10 volts in a smooth ramp function. Make the ramp faster until you begin to see significant granularity in the response from the PLC. This will be seen as a series of steps upward rather than a smooth slope. This will enable you to determine the responsiveness of your system.
Be aware that if you add more code after doing this you will probably change (degrade) the responsiveness.

Davis Gentry
Delta Tau Data Systems

 

In my view, it's not how fast can one run versus the other, but does one run fast enough for your application? In order to catch a digital input, your progam scan time should be at least twice as fast as the time the input is available. If you have a 50 ms digital input, and your program scan is 20-25 ms, then you don't have a problem catching the input. At this point, does it matter that a PC can scan for the input 100 times faster? On is on, off is off, no matter how fast you scan it.

As for the analog inputs, the same is true; can you sample the input fast enough to get the proper response from your system? If you can, then it doesn't matter how much faster something else can sample it. Most analog systems are slow response systems to begin with (heating, cooling, level control, position dancer, etc.) when compared to PLC scan time. When you take this, along with input signal filtering, and the response time of whatever actuator you are controlling in your analog system, into account, then the scan time of most PLC's should be more than fast enough to handle most analog control systems.

So the real question is not are PC's faster, but are PLC's fast enough? Yes, they are, and they will continue to get faster. Don't pay for more processing speed/power than you really need.

One final question, when was the lst time you could make an online, realtime progeam change to a program running on a PC? Never, you say! With many PLC's, you can make a program change whil your system is running, with out haveing to recompile, take the system down, download, and start all over again.