Search Sort Posts:  Oldest to newest Newest to oldest

02-22-2005, 5:20 AM JOSHC Joined on 11-21-2003 Posts 14 Opto 22, Optomux, Allen Bradley I have a customer that has the following items: 12-B1 3-B2 1- B3000ENET 1- SNAP LCM4 Controller 1- Factory Floor 4.0 He want to convert what he has to Allen Bradley using existing equipment. He wants to add a SLC 50/4 and rslogix 500 and rsview runtime. I have tried to talk him out of converting over to allen bradley but because the rest of the plant has slc 5/04 that is what he wants. How do I make this all talk to the slc 5/04? Should I not use the LCM4 controller?    Report

03-01-2005, 1:13 AM gmitchell Joined on 12-01-2003 Optomation Systems, Madrid, Spain Posts 143 Re: Opto 22, Optomux, Allen Bradley You are right that with an LCM4 controller and Factory Floor software, the guy has a complete process control solution including HMI, third party and IT network integration, without the pricing strategy of Rockwell's operator interface. But its just not worth the time and effort in trying to convince an Allen Bradley “hard-core” to convert to Opto22, especially if he already has the rest of the factory using AB. Opto22’s ALLEN-BRADLEY DF1 INTEGRATION KIT (Part # OPTOINTAB) allows users of Opto22’s OptoControl software (version 3.0 and above) an easy method of communicating with Allen-Bradley drivers or PLCs using the DF1 protocol. Opto22 controllers can act as either a “master” or a “slave” device. They can be connected directly to the serial port on an Allen-Bradley PLC or to Data Highway networks using standard Data Highway interface devices. I am not familiar with the slc 5/04 model, but to connect the LCM4 directly, will require that the PLC has a serial RS485/232 port available. All your Opto22 I/O can be connected to the LCM4 controller. The B3000-ENET requires the use of a M4SENET-100 card. The optomux I/O can be connected to another serial port on the LCM4 and FactoryFloor includes support for the Optomux I/O protocol. You will still need to write some OptoControl code in the LCM4 controller to memory map the Allen Bradley registers to the Opto22 I/O. The end result works well, but there is some latency as a request from the allen bradley serial comms is passed through the integration software, to your program and then to the I/O processors.    Report

03-04-2005, 4:32 AM JOSHC Joined on 11-21-2003 Posts 14 Re: Opto 22, Optomux, Allen Bradley The controller is a SLC 5/05 Ethernet comunications. I have my snap b3000enet already connected to my Snap-LCM4. Can I talk from the over the network between the Lcm4 and the SLC 5/05? I don't have the convert the b1 and b2 over to b100 and b200?    Report

03-04-2005, 6:59 AM gmitchell Joined on 12-01-2003 Optomation Systems, Madrid, Spain Posts 143 Re: Opto22- Allen Bradley B1/B2 Upgrade Quick refresher/flashback course. B1 (Digital) and B2 (Analog) brain boards are the local I/O processors required for communicating via Optomux protocol over a RS485 comms line to Classic or G4 Digital I/O and Optomux Analog I/O Modules. B100 and B200 are the equivalent local I/O processors required for communicating via Mistic protocol over a RS485 line to Classic or G4 Digital I/O and Optomux Analog I/O modules. While the hardware and wiring is the same, the use of Mistic protocol allow many distributed intelligence functions to be developed. In short Mistic does everything that Optomux can, but a lot more besides to simplify the host control program. Assuming your application already works fine with read/write access provided by Optomux, there is little point in upgrading the B1's and B2's at this stage. Although FactoryFloor does handle Mistic integration more elegantly than Optomux, the command you need for Optomux is "Transmit/Receive OPTOMUX String" and then implement the necessary hex commands for your requirements. Talk to Opto22 as I believe they have these encapsulated in user friendly subroutines. So the answer is that your Optomux B1 and B2 hardware can be easily integrated to the LCM4 FactoryFloor environment without having to change any hardware. -------------------------------------------------------------------------------------------------------------------------------------------------------------- With respect to the Allen Bradley Ethernet integration ho ho hum......You might like to query AB about possibilities of integrating at the Ethernet level with third party equipment, but the answer is usually one of the following 1. Sorry, I don't understand the question 2. Why do you want to do that? 3. Yes its possible but we don't know how 4. No we don't allow that 5. Use OPC Answers 1-4 are typical because while in Opto22 equipment, standard instructions in the programming language allows sessions to be opened, controlled and closed, classic PLC's have absolutely no idea that they are connected to a network. The manufacturer basically includes a 50$ Ethernet-serial converter in the hardware and claims Ethernet compatibility. The way to spot this is to ask what Ethernet control is available at the application level. Stunned silence is the usual response, although Siemens did promise "to get back to me" over three years ago. Answer 5 also is a good way of spotting the "supplier ignorance", as many claim their PLCs incorporate OPC to communicate with other equipment. The truth is that the only manufacturer who has OPC incorporated is Microsoft. OPCServer software from the hardware supplier is simply a translator-converter that on one side talks Microsoft and on the other side talks the suppliers native protocol for the corresponding hardware. You could use some Visual to read and write between Opto22 and A/B, but it wouldnt be my first choice as when the PC falls over the communication disappears. You might ask if Rsview allows integration from OPCServers, but I doubt it does because it is not a SCADA and has been designed for communication with A/B hardware. In summary, its only when you start to examine third party integration at the Ethernet TCP/IP level that you get to understand that most suppliers have their "open" systems firmly "closed" to avoid any risk of unwanted integration at either the I/O, processor or bus level. While Opto22 is designed bottom up to integrate at the Ethernet network level, Allen Bradley does not and has no intention of offering the same functionality. Their customers might just get the idea of buying something else, and that wouldnt be such a good idea!! Which if you really think about it for a full minute, is exactly your customers situation, but he's probably too happy to even notice it..........QED.    Report

OptoForums » Application For... » Systems Integra... » Re: Opto22- Allen Bradley B1/B2 Upgrade

(please select) Forums Home |- Search Forums |- Active Topics |- Unanswered Posts User Options |- Sign In |- Join this community |- Forgot Password Product Forum |- SNAP PAC Systems |- Other Hardware Systems |- Other Software |- Protocols and Drivers |- SNAP PAC Learning |- Shoot This, Opto! Application Forum |- Automation, Control, Data Acquisition, and Remote Applications |- Systems Integrator, VAR, and OptoPartner Section |- Where's Your Opto 22? International |- Opto 22 in Latin America |- Opto 22 Forum for French (Français) Speaking Customers