I am putting together a control system with ca 150 I/O, with about 30 analogue inputs. It will communicate with a set of PID controllers via Modbus RTU. There will be one, perhaps two touch screen HMI. There are some Class 1 Div 1 spaces involved, but I believe we'll be able to keep the electrical in relatively safe spaces. One area will I/O will be is 100F ambient average. I'm looking at distributed I/O and processing via Ethernet. The two products I am attracted to are the Opto-22 SNAP with ioControl software, or the RA Compact/ControlLogix in some combination. Anyone with thoughts or experience?

Thanks!

 

I bought a brick of analog Opto-22 I/O and couldn't get it to consistently communicate. On power down/power up cycles it wouldn't communicate 70% of the time.

3 phone calls and a couple emails over two days produced no response from Opto-22.

I gave up and wrote it off.

I know I would have gotten a response of some sort from Rockwell.

Bud

 

We have used Opto22 now for some projects and I must say these work very well and are easy to setup. We use Opto22 Ethernet Snap for data acquisition using the I/O from Opto22 and a PC application. We have used IOcontrol as well in an other application and that was also very nice to work with...

Just my two cents...

Da fripster

 

We have a customer who uses opto 22 stuff that specifies a remote reset capability as they have had problems with them locking up now and then. we now will be putting a realy in the power feed to the brain board so they can remotely cycle power to the brain boards when they fail to respond.

This does not impress me one bit.

 

This is the type of application that Opto22 ethernet I/O was designed for. It's been our experiences that most of the problems that we have seen (and fixed) with Opto22 systems have been due to shortcomings in the configuration logic (which can happen on any system). I've seen the "lock up" problem on some of the older systems (serial communication) but a simple error handler re-established communication when problems arose (which was missing on every system that had this problem).

The system you're describing could be set up with a single controller (Ultimate Controller or LCE) and Simple I/O brain boards placed at the various locations in your plant (you may want multiple controllers if you're doing process / automation at some of these locations). For a touchscreen Opto offer a couple of ethernet panels that communicates to your controllers (no extra configuration work). Modbus protocol charts are also available for communication.

We've had a lot of success with Opto. Technically it will do the job but financially it will give you the best bang for your buck (the configuration software is free and the HMI cost $129). If you have any questions feel free to contact me at [email protected].

 

our plant has a similar setup with brain boards setup to collect data from different areas of the plant. we had no major problems with communication with the opto i/o.

 

I have used Opto 22 since 1996 for every imaginable application from wastewater and substations to machine control. I have never attempted an application that did not succeed. When I have needed support, they always helped me work through the problem. Using Opto 22 hardware and software, I can typically complete an integration project for half the cost and in less time than those using AB.

MC

 

I'd be pretty worried about using that much of the Opto-22 stuff. When I evaluated it, I had to be pretty careful about timing, allowing it time for each command and response. Back to back packets are often dropped and you can't reliably get PLC like scanning rates with repeated polling. It's probably fine for human paced applications, but it would be the rate limiting factor in my Linux PLC.

Regards
cww

 

Was your experience with the older Serial Systems? We've done large systems and small. Correctly utilizing the controllers (they have a OEM Brain board that you can use with Linux) allows you to setup a truely distributed control system. Communication speed is an issue on any distributed system. By using a controller at the I/O level (for critical applications) you can have the system respond quickly and independently (if the communications network is down).

 

Hi Frank

I was using EtherNet having dabbled a bit with the serial stuff on a previous encounter. At the time there were few
remote IO solutions for Linux. I checked out Opto-22 with the EtherNet "brain" and a rack product from Optimate. Neither was suitable for PLC emulation at reasonable speeds, that is, low millisecond polling rates. In my original Linux PLC concept all the IO was to be remote on EtherNet. Although this sounds reasonable and straightforward, apparently neither of these was designed to be used in this way. There is a lot of existing PLC remote hardware that doesn't truly handle the scanning rate either. You would never know until you actually test it. IO on some highly revered ultra fast networks doesn't really sample much faster than the old serial stuff. That's why some of the discussions about determinism and
RT are such a hoot. The sampling uncertainly swamps any possible difference.

Regards

cww

 

Interesting stuff on determinism. My application has some fairly critical safety issues since we're dealing with combustible vapour. My interest is that there is a maximum guaranteed polling interval--which is pretty assured with a PLC. What sort of application do you have where the response time is so critical? I am more curious than anything else. As it stands, I am still weighing the Opto vs AB. So far the biggest complaint I've heard about AB is the price tag; although the premium on the AB is only about 25-30% when using CompactLogix (1769) and include the RSLogix software, PanelView+ and RSView. The equipment-only difference is about 8-10%, because the Opto loses it price advantage at the analogue points.

All of the comments here have helped!

K

 

A couple of items you should think about regarding the overall price of the system:
- Reduced wiring Cost. The Opto racks allow you to bring the controller to the I/O level. This allow you truely distributed control and I/O system as opposed to bringing everything back to a central node.
- Software Cost - you need the software to configure the AB while Opto provides most of it for free (or inexpensive).
- Control directly at the I/O level. Relatively inexpensive to spread out your control functions and have dedicated processors where necessary.
- Control Logic - the ability to have multiple control strategies running simultanously.

The trick with Opto is to think of it more as a Distributed Control System (DCS) and less as a simple I/O system or stand alone PLC. You can setup up critical control processes at the local controller (with I/O directly on the rack with the controller) additional I/O can be accessed via ethernet for normal I/O functions (including trips, PID control, etc.) Peer to Peer communication between the Ultimate Controllers and standalone controllers allows a fully integrated control system. In the event of a communication failure your local (at the I/O) controllers can be setup to operate independantly to make sure your process is still safe.

I've used both AB and Opto. Both have done what I've needed them to do. However I've found that Opto provided the greater bang for your buck. Our experience is that many integrators have not fully tapped into the power of the system (which happens on any control platform).

Hope this helps.
Lou

 

I've done critical control and monitoring with multiple remote racks tied into a Ultimate controller (or standalone controller). You can reduce the number of contollers if you properly use Ethernet switches, which will keep communication clean between brain boards. If you use the event/reaction feature of the brain board you can put an extra level of protection. Event/reaction is at the I/O level and will respond independently from the controller. You can save money and improve safety at the same time

I'm not a big fan of AB. I think they are too expensive for hardware, kill you on software, and the support I've gotten was lacking. They are big but doesn't mean they are better.

 

Thanks Lou. Good points all.

The Opto-22 Snap and the CompactLogix come very close in terms of hardware costs. I am working with a quasi-DCS model and will be using several processors regardless of which direction I go. AB/RA does get you with the software. I came top each of these systems because of an Ethernet or Ethernet/IP implementation- the wiring costs are not that critical but the expandibilty options on both systems is a luxury I am enjoying. The feather that will tip the scales is the reliabilty reports coming in from the field.

Thanks for your input. It will be well considered!

Karl

 

I have seen both Opto and Allen Bradley stuff in good, reliable systems and give long service in the field. If I had to choose between the two brands on the issue of reliability, I would give a slight edge to AB. OTOH, while I've never used a CompactLogix processor (I have used the ControlLogix and like the logix paradigm), I have used the 1769 Compact I/O as remote to other AB processors and worked on machines using it as local expansion I/O for the Micrologix 1200, and have not been very impressed so far. I guess my vote would be to use AB, but find another I/O family. One notable point in Opto's favor as far as maintenance costs are concerned is that their I/O modules (everything else?) is guaranteed for life, which is unusual.

 

Hi Bud,
As Team Leader of Product Support at Opto 22 I was surprised to see your posting. I realize you already gave up on that project, and I don't know how long ago that was, but I would like to offer our support. You can contact the Opto 22 support group at 1-800-835-6786 or 951-695-3080. Or you can E-mail us at [email protected], and you can contact me diretly at [email protected].

- Bill

 

When designing a general purpose machine, that is where the application is not known, it should conform as closely as possible to what people expect. Most people assume that all IO is scanned each scan and that the data is from that moment in time. This is a very dangerous assumption with many, if not most, remote IO schemes. And analog data, local or remote, from many PLCs can be several scans old and worse, of varying age. Not a big deal if you're watching push buttons or in many applications where half a second would be OK. But, I would like reasonable time coherence for test and measurement applications, motion control, etc. And many cases where PLCs don't do what is expected, especially the hard to find erratic or occasional problems are due to the rather loose timing relationship between signals. In logic design for general digital electronics, people worry a lot about timing because your logic won't work if you ignore it, In PLC applications, folks routinely ignore it. And they mostly get away with it because the filtering simply won't permit things to change rapidly. But I'll bet just about everybody has seen a case where something simply won't work that turned out to be timing related. I want to do an
order of magnitude better than typical and at least what people expect.

Regards

cww

 

In reply to Curt Wuollet - I would be interested in more details on I/O scanning with Opto-22 (or any other remote I/O). In particular, I would be
interested in maximum effective scanning rates and the details of the set-up.

You mentioned in a previous post, "low milli second", but few if any PLCs can meet that today. A 25 msec scan rate would be very good, and even 50 msec probably better than required for most applications. PLC analogue is very slow compared to PC data acquisition boards, but this is typically acceptable for these applications as you can't acquire or analyse waverforms with a PLC anyway.

As an aside, I was once asked to "fix" an AB PLC5 program that appeared to have a time delay built into it. There was no delay timer, the remote I/O
rack simply had a 130 msec scan rate which actually produced *visible* pauses in the machine.

 

Hi Michael
This is a few years ago now, but IIRC, I simply set up a Linux box for evaluation with a dhcp server and wrote a C loop that wrote and read modbus/tcp paced with microsleep. I ignored any long scheduling and I/O delays since this was just a lashup. The "brain" only groks a few commands so I just faked it. Five or ten messages a second were all it could handle. As a control, two Linux boxes were fine passing modbus back and forth to several khz. without optimization. I think I wrote about this to the list at the time, perhaps it's in the archive.

And the cheap Micrologix scan at at least 50 Hz. I'd like to do 1Khz. There really isn't any technical reason this couldn't be done, although you would want a "denser" protocol than Modbus/TCP.

Regards
cww

 

Not Really, saying: "A 25 msec scan rate would be very good" for a PLC is not really true.

I am using a Mitsubishi Q01H processor on two moderately complicated machines and the scan rates are 0.300 - 0.400 milliseconds, most of which is overhead, so my total application is scanning in something like 100-200 microseconds. I'm running six stations of sequence programs wrapped around a rotary turntable architecture, and each step of the station code includes fault handling and message generation to the operator at each step of the way.

I think the key to low scan times has to do with what hardware (and software) you pick and how you program, and dividing your application appropriately into manageable pieces. Obviously an ancient PLC running an entire factory of machines is probably not going to give you sub-millisecond scans. But if you use fast PLCs at each machine and network them together for minor synchronization and such, you will be able to pull it off.

KEJR