Enough already with the beating up on the PLC scantime nonsense. I have, in the past 25 years used quite a few PLCs, and have resisted using the cheaper PLCs that you make frequent reference to. Use a decent PLC and you get predictable scan times. With PLC-5s I have controlled entire rail-car positioning and dumping systems with 12 ms scan time, bin sorters with 8 ms, positioners with 10 ms and 2 ms STI (I tested that one with solid operation on an STI of 1 ms). Those are scope tested, repetitive stable times. With the ControlLogic platform I'm doing large scale pump stations with flow computing, batching, sampling, first out alarm capturing, local HMI and SCADA interfacing all in 7 ms. So I don't see where the problem is. Every bit of "erratic" or "intermittant" problem I have been able to trace out with just decent logic approach to troubleshooting to someones (or my own) bad programming. The scan nature of the PLC is an attribute - not a problem. And the best part is, there are no secrets in PLC programming (that is until just recently with their silly program protection - and you can kill me if I ever use it). In the PLCs that I use there is nothing loose or erratic. In the end I'm with you though, I want to provide a magnitude better than what end users expect. That's whay I use PLCs.

Hugo

 

In reply to Ken Emmons, Jr. - The PLC you are referring to may be quite fast, but that doesn't really address the point. A fast CPU matched with a fast I/O system (which was the subject of our discussion) may be useful in some
circumstances, but most machines in production today would not benefit significantly from greater speed.

A few numbers will put things in perspective. Let us assume a a PLC with a total scan time (I/O plus CPU plus other overhead), of 50 msec. We would on average expect to "lose" on average 0.025 msec for each step of the sequence
waiting for the PLC. This is not a lot compared to the time waiting for the mechanical motions. Where your sensors are attached along a pneumatic cylinder will be far more significant. Reducing this time by several orders
of magnitude has relatively little benefit.

So, I feel it is quite reasonable to say that a complete scan, including the Ethernet I/O system which can reach a 50 to 25 msec effective scan rate will be quite acceptable for most applications.

 

The IO system I am using is fast, Input response is in microseconds, and output response is 1 millisecond. I am performing anywhere from 10-20 operations in the bottleneck process of a typical machine cycle, so incurred delay is mulitpilied by these numbers.

While getting things much faster than millisecond speeds are arguable for simple pneumatic cylinders, having a 25-50 millisecond response time is ridiculous for modern high speed machinery. If a machine is designed properly and is moving small parts around you can expect things to move in 50-150ms, so if you had a 50ms actuation with a 50ms response time of your IO system you would incurr 200% time delay in that one step of your machine sequence.

Lets play it safe and say that all of your actuators took 200ms to move to end of stroke, and you had to wait for 5 actuations total in your machine cycle. (Very conservative, most machines are worse than that). In theory your cycle time would be 1000ms. Adding 50ms in both directions (one delay to actuate the valve, and another delay to wait for the cylinder switch input). At worst case this would add 100ms to each step, so your worst case cycle time would be 1500ms, or 50% more cycle time. Even if you assume that the delay somehow averages out, its still 25% more cycle time. I don't think any shop supervisor or foreman would be happy with this kind of speed change if they knew it existed.

I'm not one to argue about splitting the millisecond in pneumatic systems much, but 25-50 milliseconds is extreme.

KEJR

 

Hi Hugo,

On August 30, 2005, Hugo at IAI wrote:
>Enough already with the beating up on the PLC scantime nonsense. I have, in
>the past 25 years used quite a few PLCs, and have resisted using the
>cheaper PLCs that you make frequent reference to. Use a decent PLC and you
>get predictable scan times. <

My frame of reference would be GE and AB controllers. I dislike Siemens PLCs for reasons unrelated to scan time, mostly bizarre and tedious software design. I am working towards a decent PLC design. It should disappear, leaving only the logic and the problem to be solved. But it should be said that all of the above private branded the "cheap" Koyo designs at one point or another. That seems like a stellar endorsement considering that none of them would even consider using the other's design. But I digress.

> With PLC-5s I have controlled entire rail-car
>positioning and dumping systems with 12 ms scan time, bin sorters with 8 ms,
>positioners with 10 ms and 2 ms STI (I tested that one with solid operation
>on an STI of 1 ms). Those are scope tested, repetitive stable times. With
>the ControlLogic platform I'm doing large scale pump stations with flow
>computing, batching, sampling, first out alarm capturing, local HMI and
>SCADA interfacing all in 7 ms. So I don't see where the problem is. Every
>bit of "erratic" or "intermittant" problem I have been able to trace out
>with just decent logic approach to troubleshooting to someones (or my own)
>bad programming. <

That's wonderful! But interrupts are completely foreign to ladder logic, included as a workaround for the fact that things you need to do happen faster than your scan rate can adequately service.

>The scan nature of the PLC is an attribute - not a problem.
>And the best part is, there are no secrets in PLC programming (that is until
>just recently with their silly program protection - and you can kill me if I
>ever use it). In the PLCs that I use there is nothing loose or erratic. <

That you can see.

>In
>the end I'm with you though, I want to provide a magnitude better than what
>end users expect. That's whay I use PLCs. <

Yes, but I'll bet to get the whole job done, you also use PCs and some sensors and devices that are more ";intelligent" than the PLC. And you have mediocre and occult networking, a half dozen licenses to watch, and a single source for tools, equipment and resources. Industrial automation is the last anachronistic arena where these limitations exist. When all you have is the status quo, everything begins to be separated into the PLC part and the rest of the problem. With the availability of inexpensive >500 MIPS hardware, one could reasonably expect all the logic for an entire company could be solved in real time on one box. How is the status quo doing on that expectation? It's a great plateau, but we are not far advanced from the first PLCs, and none is remarkably advanced in comparison to another. They solve a class of
problems well, but that class of problems is a diminishing part of the solutions needed as we move along the advancement of industry. Perhaps you haven't noticed?

Regards

cww

 

Hello Curt,

I should have known you will not let a good word about conventional PLC stand...

> Hi Hugo,
>
> On August 30, 2005, Hugo at IAI wrote:
> >Enough already with the beating up on the PLC scantime nonsense. I have,
in
> >the past 25 years used quite a few PLCs, and have resisted using the
> >cheaper PLCs that you make frequent reference to. Use a decent PLC and
you
> >get predictable scan times. <
>
> My frame of reference would be GE and AB controllers. I dislike Siemens
> PLCs for reasons unrelated to scan time, mostly bizarre and tedious
software
> design. <

Here is something else we agree on!

> I am working towards a decent PLC design. It should disappear,
> leaving only the logic and the problem to be solved. <

How great of an ambition this revolutionary PLC design is must by now have trickled down. I salute the effort - and respect those involved with it, but as far as I am concerned the real problem is not the technical side. The
promoters of the Revolution PLC are very much computer science guys. That is reflected in the products (and the higher level PLC's as well, wittness "featuritis" that manufacturers programmers promote, producer/consumer functions in ladder logic for instance). That scares the shit out of technical applications people responsible for control systems and projects. Electricians are the backbone of industries where I work. Yes, those of us with a bit more education and experience in computing and other technologies are leading the rest toward some higher level of acceptance for new stuff. But by and large we can only lead the crowd where they are willing to go. And there is usually only one Control Champion per company. Whenever I find myself getting too interested in programming I do find my concern with customers and reality slipping (but that may be a personal defect). Back to the topic, in my area of experience and influence I would consider it a mistake to go with an Opto-22 solution and would advise toward the ControlLogix.

> But it should be
> said that
> all of the above private branded the "cheap" Koyo designs at one point or
> another. That seems like a stellar endorsement considering that none of
them
> would even consider using the other's design. But I digress. <

If the marketing departments of the majors have a moment of insecurity about not covering all aspects of "their market", and re-brand some plastic from someone else it does not mean we have to buy it. In 25 years of involvement in the PLC side of automation in quite a variety of industries I have only had a couple of lapses and applied a small PLC - and promptly regretted it. Mostly when it comes time to discuss what the client looses by saving some money and using the small PLC, the decision for a decent PLC comes easy.

> > With PLC-5s I have controlled entire rail-car
> >positioning and dumping systems with 12 ms scan time, bin sorters with 8
ms,
> >positioners with 10 ms and 2 ms STI (I tested that one with solid
operation
> >on an STI of 1 ms). Those are scope tested, repetitive stable times. With
> >the ControlLogic platform I'm doing large scale pump stations with flow
> >computing, batching, sampling, first out alarm capturing, local HMI and
> >SCADA interfacing all in 7 ms. So I don't see where the problem is. Every
> >bit of "erratic" or "intermittant" problem I have been able to trace out
> >with just decent logic approach to troubleshooting to someones (or my
own)
> >bad programming. <
>
> That's wonderful! But interrupts are completely foreign to ladder
> logic, included
> as a workaround for the fact that things you need to do happen faster
> than your
> scan rate can adequately service. <

That's plain bull! STIs (Selectible Timed Interrupts) are a feature like any other. Been available since the days of the PLC-2. How does your micro perform realtime tasks if not with interrupts in the kernal. On larger generic machines, how does the real time operating system perform if not with interrupts?

> >The scan nature of the PLC is an attribute - not a problem.
> >And the best part is, there are no secrets in PLC programming (that is
until
> >just recently with their silly program protection - and you can kill me
if I
> >ever use it). In the PLCs that I use there is nothing loose or erratic. <
>
> That you can see. <

I measure. And when I can guarantee to my client the task required will be done with a comfortable margin of time, speed or position, that's when the equipment gets applied - not before. And after it does, I quit splitting hairs about nanosecond jitter.

> >In
> >the end I'm with you though, I want to provide a magnitude better than
what
> >end users expect. That's whay I use PLCs. <
>
> Yes, but I'll bet to get the whole job done, you also use PCs and some
> sensors
> and devices that are more ";intelligent" than the PLC. And you have
> mediocre
> and occult networking, a half dozen licenses to watch, and a single
> source for
> tools, equipment and resources. Industrial automation is the last
> anachronistic
> arena where these limitations exist. When all you have is the status quo,
> everything begins to be separated into the PLC part and the rest of the
> problem.
> With the availability of inexpensive >500 MIPS hardware, one could
> reasonably
> expect all the logic for an entire company could be solved in real time
> on one
> box. How is the status quo doing on that expectation? <

There are very few people who harbour or express that expectation. In fact I would ask those reading this who are in the business of applying PLCs to respond and tell us what their expectations are. In my arena, there was a
PLC that was supposed to solve all control applications. The PLC-3 was a powerhouse intended for central control. It was a miserable failure. Not because of any technical fault, rather another PLC, the PLC-5 with a network optimized for distributed control became available and people voted with their wallets. One machine for each task is a well understood concept. Distributed control is something that has a lot going for it yet.

> It's a great plateau, but we are not far advanced from the first PLCs,
> and none
> is remarkably advanced in comparison to another. They solve a class of
> problems
> well, but that class of problems is a diminishing part of the solutions
> needed as
> we move along the advancement of industry. Perhaps you haven't noticed? <

For the first ten years running my own automation business I was very much focused on - and frustrated by - the kind of stuff you are talking about. The hardware available was too expensive to solve all the neat applications that I could see. And don't even get me started with Rockwell's policies and belly gazing. Today I have changed my focus. I'm not interested in being the cheapest, not interested in solving every problem. And if the cost of a decent processor weeds out some projects, then that is not a bad thing. And that applies to me as well, as soon as I get sufficiently pissed at the annual cost of my Rockwell software contract I will do something else. So yes, there are likely a whole lot of things that could advance industry, but I have limits to my resources. So I will focus on where I can make a difference. And that happens to be with off the shelf powerful PLC's made by a reputable manufacturer stocked accross Nort America and the world, programmed with ladder logic (and with modules specifically designed to solve all the applications needs).

Hugo

In closing one thought just occurred to me: Dick Morley's "invention" of the PLC was accepted (by GE and the industry in general) primarily because the concept of modularity made sense (and was missing from prior control
solutions). An all in one all powerful control solution Revolutionary Super PLC in software only, in many ways goes against the grain of that insight (and success story).

 

In reply to Ken Emmons, Jr. - Your application however is not typical for a PLC. You are apparently describing machines with small short stroke actuators operating with short cycle times.

Those same speeds however on larger and more powerful equipment can be destructive of the parts, and possibly of the equipment itself. Many processes take time, due to the laws of physics. Heat takes time to flow, metal or plastic takes time to deform or cut, etc. A faster PLC doesn't change this.

You estimates assume cycle times of 1 second or less. However, apply your same reasoning to cycle times of 10 seconds, or 30 seconds. Now a 25 msec delay doesn't appear so significant. PLCs running at this speed are controlling
millions of machines like these around the world today, and people find this quite acceptable and do not see an economic justification for replacing them.

So to return to the point, if the response time of Opto-22 Snap I/O limits the effective scan rate of a PC based control system (either a soft logic system, or a computerised test system) to 25 or even 50 msec., this is quite likely acceptable in most cases, and indeed faster than the PLCs in service in many machines today.

Mr. Wuollet stated that he had conducted some timing experiments, and suggested checking the archives for results. I did see where he mentioned Opto-22 several times, but unfortunately it doesn't appear that he documented results of his experiments.

I am surprised that the I/O response wasn't faster, but it certainly doesn't mean there is no use for Opto-22, particulary given its attractive price. It does suggest however that response time should be a matter for serious
investigation when researching I/O systems for PC based controls.

 

Just because the PLC scan time is 25 ms (a huge number by my experience) does not have to translate into a 25 ms delay in everything the PLC does. First, usually control applications work with external non-synchronized (not synchronized to the scan time) inputs. So the average response is somewhere near half the scan time. But more importantly, most decent PLC's (and maybe Opto-22 as well - I don't know) have immediate input and immediate output functions. Using these you can accomplish a number of time critical things in microseconds. I remember an application with linear array optical scanner
interfaced to a PLC-5 with a few wires and TTL logic that provided measurement data with handshaking in a sub-scan loop in less than 300 micro seconds. It may be worth digging a little deeper and comparing the available instructions.

Hugo

 

Hi Hugo

I have many good words for conventional PLCs, I've usually got a couple projects going with them at any given time. I probably buy at least a dozen a year, mostly from AB and AD. And for what I am doing with them, they are a no brain choice, you can't build much for $130 in qty. one. I use them to do what people want automated. My boss is happy. But what I am producing is islands of automation. To do anything else is expensive and difficult with PLCs. And it bears no resemblance to what I _could_ do
with a platform that is inherently networked with seamless integration of things like a rdbms, machine vision, OCR, motion, serious compute power and the like. One printing press for example, may have 5 PLCs and a dozen add on boxes, none of which are really integrated or even
integratable with each other. And the data, which would be invaluable to refine and improve the process, either goes to /dev/null or is locked
up in each incompatible box. And we have lots and lots of small PLC driven machines that are used in line to process what the presses produce. I add PLCs to integrate these various machines and systems together. And because having all these islands working in isolation is insanity, what coordination and integration I can provide between
the black boxes makes people very happy. It's difficult and tedious when vendors won't cooperate and fairly straightforward when they
will. But, in most cases, it's a bandaid for a really dumb way to build streams. And at the moment, I've been asked to evaluate hostile takeovers, that is dumping the native controls for machines and replacing them with my own so that we can make them less stupid.

Now from your perspective, each of the PLC people involved, myself included, was successful and the PLCs perform admirably.

The end result simply isn't anywhere near as useful as it could be, done differently. And it takes bizarre cabling, dummy plugs, and the machines are anything but interchangeable. And there is no overall control.

Let me explain my vision and see if it makes sense to you. We should be able to create a stream with the machines and an Ethernet hub. We should be able to configure the stream from any convenient location and be able to use the data wherever we wish because it's our data. I can do that with commodity technology, at extremely low
cost, if the individual machines use a PC compatible controller and OSS, instead of a dozen brands and ages of PLCs. It is quite impossible with the PLCs.

That is a perfectly reasonable way to build a line or stream, and far more useful. And there would be no loss of functionality, in fact it would be greatly enhanced, because it's trivial for a PC to do what a PLC does and expensive, complex or impossible to do what a PC can do with PLCs. All we need is a toolchain that's reasonable for automation types to work with, a framework and some hardware.

 

In reply to Hugo at IAI - As far as PLC scan rates are concerned, I think that perhaps I have not been clear enough in the point I was making. 25 msec is not a "huge" number. I can state with some confidence that this is faster than the PLCs in the majority of existing production machinery in use today, even if it may not be up to the fastest of the newer PLC models on the market. This means that an ethernet based I/O system that can meet this number is feasible for use in most automation applications.

The point of comparing it to a PLC was to show that it is feasible to use it in applications which are now using a PLC. My own interest in this arises from investigations into using PC based systems instead of PLCs in simple production test systems. I'm not interested in replacing PLCs per say, so much as not using them in applications in which they are not well suited.

Yet, it would still be nice to use "industrial" type I/O (as opposed to data acquisition boards) in undemanding applications, as it integrates into the machines so nicely, and is easier to install and troubleshoot. Network based I/O is moving to Ethernet, and it is only a matter of time berfore the older RS-485 based (and similar) systems disappear. So as Ethernet based I/O systems seems to be it, it seems worthwhile finding out what can be done with them.

I reported some timing experiments several months ago on the maximum practical rate at which a PC based system could operate using standard PC hardware, operating systems and application development software. My conclusion was that a realistic scheduling rate for a PC program would be in the low 10s of milliseconds. An I/O system with a 25 msec I/O scan rate would be acceptable in this appication if it were conducted asynchronously with the PC logic.

Opto-22 isn't the only ethernet based I/O system on the market. There are several others as well which support Modbus TCP (which seems to be the closest thing to a standard protocol today). I haven't found anything in Opto-22's literature which defines their maximum polling rate. The point may be moot if their own or their competitor's systems can in fact operate faster than this.

This entire discussion is based on some rather vaguely described numbers from Mr. Wuollet, and we are not sure of the conditions under which those results were obtained. Any measurements obtained under more carefully defined conditions would no doubt be of interest to a great many people besides myself.

Michael Griffin

 

Hi Michael,

I would be most interested if the state of the art has improved since my first look. Unfortunately, the hardware is a bit too expensive for out of pocket experiments and my current job situation does not include much (any?) R&D. This is where the vendors could pick it up and either loan hardware for more extensive testing or do the work and publish the results. I'm fairly sure these products are aimed at PC automation and such use should be within the
envelope. It is certainly feasible to build Ethernet IO that could handle at least 1 message per msec. In fact I was pondering doing so when I ran into the Opto-22 and Optimate products. For the sake of completeness, Automation Direct has an Ethernet base for some of their PLC IO. Again, I would love to look at it, but can't spend the money. It's quite possible that setup might have respectable rep rates. I don't think it does Modbus/TCP but Host Engineering will share the proto. Cost per point for low counts would be an issue.

Regards

cww

 

I have to go back to why I made my first comments. I see (not just in this thread) what I call "PLC bashing" happening that is surrounded by statements which at best are only marginally true - for the PLCs that I work with. This is a point I have made for some two decades: Buy some good PLCs, structure a good solution, write some well planned code and you will have a PLC solution that will make the "owners" (and you) happy. These days my average scan times are about 6 ms, and I am not worried about sub-millisecond control requirements.

For machine control the first requirement, buying a good PLC, is often seen as too expensive. In my experience that is mainly the case as long as the machine building cost is taken in isolation, and not related to the long term lost functionality. So I lose a few contracts, that is not so bad from my perspective (this way I get to work with companies and people who want a good solution above all else).

So we work in different areas (come to think of it that is why I voice my opinion), today I mainly work with large networked control systems, often with multiple vendors and multi-million dollar systems at stake, where large PLC solutions are the norm. There is little I can think of that we can not accomplish with off the shelf hardware and software. Invariably, when we have to incorporate some "homebrew solution" it's trouble (even if it's simply a custom program). I have also worked on small machine systems, stackers, bottling, bearing assembly, winders and so on, where I have been successful by applying the larger more powerful PLCs - rather than the cheaper small ones. Basically I just can't stand the whining: My PLC can't do this or that... The PLCs I work with can. I work with the ControlLogix platform. The opportunities for a PC based Revolutionary PLC with networked I/O are different for me, but that's another topic.

Hugo

 

A couple of points that I want to add about Ethernet I/O and control:
On critical processes you want the processing being done at the I/O level and not through a communication channel (serial or ethernet). See my earlier comments regarding Opto22 (on this thread) on how Opto is more of a DCS type of system, if setup correctly.

Ethernet communication speed is dependent on Network traffic and collisions. On Ethernet based systems you should effectively utilize Ethernet Switches, etc. to increase network speed. Improper networking of your system will greatly reduce the speed of your network.

Going back to the Original topic of this thread (Opto vs Rockwell), I think you'll find that you can meet most of the criteria you're looking for with the Opto system. Too often engineers look at I/O as one item and a controller as another. Distribution of Control and I/O can effectively give you the speed (controller with local I/O) on critical processes, cost saving on non-critical I/O, and greater system integration of a DCS type of system (peer to peer communication).

Lou

 

I just found this topic as I have not been on here in quite awhile. But all of your comments warrant my input. I have used Opto-22 I/O and controllers in many projects over the years.

What I have learned is, you cannot associate the words "scan time" with an Opto-22 controller or I/O system. First of all, you read and write to the I/O as needed; whereas in most PLC's, to read one point, you have to go out and get a "table-full" of I/O values. Hence on larger PLC applications, the scan time becomes longer.

The scan time of an Opto-22 flow chart program cannot be compared to a ladder logic program because the two are scanned entirely different from each other. Opto-22's program scanning methodology in their Mistic and Snap controllers comes very close to multitasking.

The interrupt feature mentioned throughout this thread is a powerful part of the Opto-22 I/O system and the PID function handled at the I/O level is something I wish more automation manufacturers would adopt.

All in all, if I had to have a cost-effective solution that offered flexibility, reliability and scalability, I would use Opto-22. If I needed speed at a cost-effective price, again, Opto-22. If I wanted something that will integrate easily with other products in the future, again, Opto-22. If I were designing something anyone could work on that has gone through a vo-tech training course, I would have to use Allen-Bradley since their product is in so many schools throughout the region.

As for the lack of technical support, I can list numerous stories of above-average to great technical support experiences with Opto-22. I can also list the same number of great experiences with Allen-Bradley. However, I have never had to pay a penny for tech support at Opto-22 and even if the answer was "we're still working on your problem" (which was rare) at least I got a response in a timely manner. Bud, I'm not too sure about what happened in your case, but I personally apologize for your bad experience.

As to which platform to use? It really depends upon your application and your budget.

Jon Money

 

Hi Guys,

We went with the Allen-Bradley/Rockwell Automation CompactLogix. The scale-tipper was the 1769-HSC: I have three flowmeters that operate at ca. 2kHz, and I can feed these directly into the AB/RA control. The overall cost is 10% more than the Opto because of the reduced needs for ancillary peripherals. The price differential comes primarily from the software licenses (RSLogix 5000 and RSView), but the client may well have use for these on other projects. I have to admit that I had a very comfortable budget- money is a concern but an effective design edges that out a bit. The system will be using two L35E processors, which does take advantage of "local" processing, as well as increasing available connection bandwidth at the processors. One legacy panel will be interfaced using Acromag Ethernet/IP addressable I/O- one e-m relay space and I am interfaced with the relay panel. Not bad for $350.00 a pop.

I thank each and every one of you- your discussions have made my decison making much better informed.

Best to each of you!

Karl

 

Hi Lou
You bring up a good point. With the decreasing cost of powerful silicon, it's not hard to imagine systems built of essentially identical local processors.

Let's examine what this would be like. Let's imagine for a moment something like a network of micro PLCs. We can build a perfectly usable brick with 20-32 IO for a couple hundred bucks. If these bricks had a TCP/IP stack and ethernet port, (maybe another $10 in qty.), and a well designed and Open protocol on top, the results would far exceed the status quo of remote racks under proprietary protocols. With an underlying operating system and tools that could transparently distribute functions among the processors based on say, minimum network traffic, everyone's criteria would be met. Fast scans, simple programming, etc. and the cost would be much less than the present schemes. All the foundation bits of this scenario are already available and free to all in Linux technology.

The task distribution from server farms, the free stack, the massaging from Beowulf, etc. All that would be needed is the automation specific front ends and the hardware. The algorithms and heuristics aren't rocket science. This is probably even possible with existing hardware as there are some PLCs with the resources to support Linux. If any of the big automation folks would cooperate, this could happen in a few months. But with the prevailing attitudes, it's not very likely. That's why I see the situation a little differently than most folks.

Good enough is now way, way, behind what's possible. I'd love to do something like this with a budget and the resources.

Regards
cww