expand AB with OPTO22

[gendy 0]

Dear All could any body tell me about opto22 is it good?, what the difference between its products and PLC? why use intelligent remote I/O from it to expand AB PLC i see its prices not low ? for information about it you can see http://www.opto22.com/ Edited 7 Nov 2010 by gendy

[Steve G 1]

Never used it, but why are you looking at Optp22 for a source of AB remote I/O. Is there something Opto22 is providing you that AB does not? For the question of the difference between there product and AB's, I assume you mean they are called there product a PAC (programmable automation controller). AB make's a PAC with there Control-logix / Compact-Logix line of controller’s.

[gendy 0]

Thanks for reply, I just wonder about the products they introduce the products as new technology and more advanced + it can intergrate with exisiting system so i want to check is it true?

[kaiser_will 65]

We often use 3rd party remote I/O integrated into an Allen-Bradley PLC, and with great success. Sometimes the driving force is cost (Beckhoff has Ethernet/IP I/O that is significantly cheaper than Allen-Bradley), sometimes it is a panel/machine designer competence issue (someone is more comfortable laying out Turck port blocks instead of Allen-Bradley Armor-Point I/O). Usually the final criteria is lowest cost, highest reliability, and don't try something unless it is proven. If one was to build many similar machines, improvements in profit margin can often be attained by switching to similar but inexpensive element (such as remote I/O).

[gendy 0]

did any one use OPTO22 products ? they say it is new technology but i didn't now what is its advantages?

[Mtech1 0]

We have used opto for several years. In fact I recently purchased their learning center to learn their code. We have not even had to replace a card or correct any logic. Code is completely different. I still have limited experience with them but I can say they seem very reliable. We use the R1snap pac with various analog and digital. We only have 4 of these units and have hundreds of AB's. Noone except the engineer who done the programming and me because willingness to learn have touched these. Wish I could say the same for the AB products.

[JeffKiper 9]

Mtech1 kind of funny that the system that is the least understood usually has the least user induced problems.

[JeffKiper 9]

I haven't use them myself. I have heard good and bad from guys I trust. I would call Arun in thier technical suport. He is on this forum evry now and then. I have a backplane and 1 or 2 card I need to get some more because I plan on trying out thier I/O before I use it.

[Arun Opto 22 0]

I saw the post and refrained from replying since I work for Opto 22. But, since my name was mentioned, I thought I'd go ahead (and do indeed second Sparky's suggestion that I can be contacted for more details or a web demo...no problem). I won't speak to "good or bad", because obviously my opinion would be seen as biased. I'll speak to "why": We implemented ODVA EtherNet/IP about 2 years ago on our I/O so it could be used with Logix PLCs for the purpose of "Distributed Processing". Opto 22 SNAP I/O is "intelligent", in that you can do functions down at the I/O level like counting a DI, pulsing a DO, clamping an AO, and running a PID loop. All this can be done without any RSLogix programming. Our configuration tool is simply "drop boxes, radio buttons, fill-in-the-blanks". Taking a counter for example (the most simple) - - A normal DI module and point on that module is "intelligent", in that it can be configured as a counter, and deliver counts back to the Logix PLC. And, the PLC can, upon appropriate condition, write back to the I/O to clear the counts. So, each point has accessible "attributes", and these attributes can be configured, read, and written to. Further, this configuration can happen on the fly. For example, if you've configured a DO to be a pulse, and on condition have set it to pulse 1,000 times...you could, in your Logix, say that if a machine or process condition dictates, change the nature of that attribute to be, say 2,000 pulses. The purpose of distributed intelligence is to both de-burden the PLC (less code, less memoryusage, better scan times), as well as offer sophisticated programmers to take advantage of these intelligent attributes in their control scheme. The "no programming", is wrt Logix PLCs and implicit messaging. We also support explicit, so you can use SNAP I/O with SLC 5/05 and MicroLogix 1100/1400 (via MSG commands). We've got lots of successful installations. I've been personally involved in about 60 or more. We promote the distributed intelligence, though I must admit a lot of people have bought based on price...."a lower cost, reliable I/O system that easily talks EIP to A-B PLCS". No need to learn a new programming language to use it. You work in what you're familiar with, RSLogix5000. (Sorry - this may indeed have sounded like a sales pitch, but that's not intentional). I invite others to continue commenting, as I'm curious as to what others think.

[paulengr 44]

The pricing is supposed to be really good but by the time you add a "brain" (I/O interface), pricing doesn't look so good anymore. Same problem with ASi bus which is supposed to be very inexpensive (and it is) but as soon as you add the interface card, the prices get blown out of the water. That being said, the problem I've had is that each I/O point can be programmed as either an input or an output. Very nice but I've run into synchronization problems where all the configuration on the Opto 22 stuff gets lost and then the system goes absolutely nuts. Not fun. So from a reliability point of view, I removed it and stopped using it. Cost-wise, Beckhoff is very competitive and so is Siemens if you are competing with AB's Point-IO. When you get to higher densities, it seems to go one of two ways, either to AB, or to Acromag if you happen to fit the Acromag footprint. If you've got one of those oddball situations where you have say a block of analog inputs and need just one or two thermocouple or millivolt inputs, AB's prices for that stuff is outrageous. You can of course put in a discrete converter but another option is that Spectrum Controls sells a "universal" analog input card which goes right into the local rack IO. If you are using DeviceNet (or are willing to experiment with Componet...is Pointbus really Componet??), then take a close look at Omron of all companies. However, they don't support Ethernet/IP. In my case, I'm pretty much incrementally stripping all the DeviceNet and Controlnet out of my plant over time and upgrading it to Ethernet/IP. About the only place I still have left where DeviceNet is desirable is in MCC's, where AB will sell a 100% DeviceNet-controlled MCC. There are of course problems with this. The two most important are that DeviceNet (AB's implementation) is very, very, very, very finicky about power quality and stability. If you can't guarantee this to 99.9999% (six sigma) levels, don't even consider using DeviceNet. It flakes out and things will randomly start/stop! The second problem with DeviceNet is that the EN2DN card is crap. It cannot be relied on to be reliable for DeviceNet-to-Ethernet/IP networks, so your only choice is to use an SDN card. So you have this ridiculous situation where you have an AB overpriced power supply, 1756-ENBT, and 1756-SDN cards, plus enclosure, surge protection, power filtering, and whatever terminal blocks you need all mounted next to the MCC (unless you order the MCC with lots of extra panel space to fit this) just to provide a front end interface to the MCC. Personally I love the whole DeviceNet-controlled MCC idea, but the actual implementation really leaves a lot to be desired at this point, all due to reliability problems with DeviceNet and AB's particular implementation.