AB OPC Server, RSLinx

M

Thread Starter

Mike Woods

I'm thinking of using an IN-GEAR AB OPC Server to communicate via DH+ to a PLC (5/40). The MMI that will be communicating with the OPC Server is RSView32. What are the alternatives to using an OPC server (besides DDE) to accomplish my task? Is RSLinx an alternative or not an alternative? I'm trying to figure out what's good about RSLinx if anything, or what RSLinx is even used for because I really don't understand the RSLinx product information on Rockwell's web site. Thanks for any advice, Mike
 
Mike, Why don't you contact your local Allen-Bradley/Rockwell Automation sales office and have them answer all your questions? That's what those people get paid for. You'll never get enough information off of anybody's web-site to do a project. BTW - RSLinx is the direct driver for communications between RSView32 and AB PLCs. There is no better or faster communications between the two in the industry. It even has preferred connectivity features (like importation of the PLC tags into the RSView32 tag database) that you can't get anywhere else. But again, don't take my word for it. Call up your local sales office and have somebody come out and give you a demonstration. I hope this helps! Shiggy
 
A

amora fibrianto

Mike, RSLinx is both OPC and DDE server.......depend on your application.....it can act as an OPC server or a DDE server. If you're trying to communicate with AB peripheral, i think RSLinx is still your best chance....although i've done it with others.... try to download the RSLinx getting result book, to give you a better understanding....... hope this could help.. Amora Fibrianto Engineering Dept. Somit Automation
 
Mike, RSLinx is often confusing because RSI sells so many versions. Various higher-functionality features are included with higher-functionality licenses. With the exception of RSLinx Lite, RSLinx versions only differ by what features are enabled by the activation keydisk. RSLinx Lite: Provides only enough services to allow RSI programming and configuration software (such as RSLogix or RSNetworx) to access Rockwell networks and controllers. Provided free with all programming packages. RSLinx OEM: Allows programs that use the C-API to call RSLinx routines. Chief among these is RSView32. At least RSLinx OEM is required for RSView32 ( it cannot use RSLinx Lite). RSLinx Professional: All the functions of RSLinx OEM, plus OPC and DDE server functionality to allow 3rd party software that does not use the API to communicate with Rockwell networks and controllers. This is the version that is often bundled with RSView32. RSLinx Gateway: All the functions of RSLinx Professional, plus the ability to route communications from a TCP/IP network to any A-B legacy or open network that is connected to the physical computer running RSLinx Gateway. Usually used as a way to spread data throughout an enterprise Ethernet system from a Data Highway+ network of older PLC's. Generally with RSView32 you should buy the bundled RSLinx Professional package. It costs less than RSLinx OEM when it's bundled, and you have the option to use OPC or DDE connectivity as well as native RSView32 tags. I'll leave the "why OPC vs DDE vs ....." to another thread. Ken Roach Rockwell Automation Seattle, WA
 
D

Dobrowolski, Jacek

Hi Mike, I tried to use In-gear OPC Server to communicate via DH+ in the past. And I had some troubles with it (I don't know how it works now). RSLinx allows you to connect to PLC by OPC, DDE or proprietary DH+ driver - which is the fastest, as long as RSView32 is concerned. Regards Jacek Dobrowolski Software Eng. Automation Department Secondary Division International Tobacco Machinery Ltd. POLAND mailto: [email protected]
 
R

Radovan Podhradsky

Hi Mike, I tested short time In-Gear OPC Server with ControlLogix PLC on Ethernet and my result on reading several hundreds of INT, FLOAT and BOOLEAN variables and writing several variables manually from Citect SCADA package using simple data types and arrays too was, RS Linx v.2.20.01 had better response time on reading and writing variables and you must administrate OPC server name space (can be imported from .CSV file) manually. Response time depends on implementation on OPC server and OPC client driver in your MMI software too, so it can be little different on RSView. I think, you can link tags in RSView with RS Linx, so you don't need configure them manually in RSView. RS Linx Professional or Gateway includes OPC server. Best regards, Rado.
 
C

Chuck Karwoski

> Hi Mike, > > I tested short time In-Gear OPC Server with ControlLogix PLC on Ethernet. The performance issue boils down to the approach used for optimization. Unlike a PLC, Control Logix native tags are akin to user defined variables. It is impossible for the I/O server to know if 2 tags "Tag1" and "Tag2" are in a contiguous block of memory, or if they are the even same data type. As a result the I/O server cannot create an optimized block and is forced to read Tag1 and Tag2 as individual items. A series of Control Logix firmware and software upgrades does now permit RSLinx to perform optimized reads on individual native tags. This does provide an inherent advantage in the fact that the user does not need to know if native tags are in a contiguous block. However, it is important to understand a penalty in memory overhead is paid by the processor. For RSLinx to optimize 500 native integer tags, will add 22.6k in memory overhead. An optimized read of 1000 native integers will add 42.7k in processor overhead. (See Rockwell Software Knowledge Base Article R486). If your HMI application needs serveral thousand tags, the memory overhead can become quite significant. According the article, if you can't spare the memory overhead, it is recommended to create PLC-5 mappings. This is kind of like robbing Peter to pay Paul. Yes there is an overhead savings, but the PLC-5 mappings will consume processor resource as well, and you're limited to keeping PLC-5 mapped tags within the controller scope. Our approach for Control Logix packet optimization relies on the use of native tag arrays. Like developing a PLC application, it does require up front planning to gain optimal throughput from the Control Logix processor. However, our optimization approach using arrays does not add memory overhead to the processor, and is Control Logix firmware independent. Finally, although it is a common practice for most OPC Servers to administrate OPC Namespace, it is not required for our server. A client can dynamically add Items to the server. Hope this helps to clarify some of the issues you perceived our INGEAR AB OPC Server. If you have any questions please feel free to contact us directly. That's what we're here for. :eek:) Best Regards, Chuck Karwoski CimQuest INGEAR Products Group. 610.935.7979
 
D

Dave Ferguson

RSLinx is a communications engine to the various AB protocols. You can connect via DDE (Advanced) or OPC and can use a number of drivers, ethernet, DH+, serial (DF1), Controlnet and a number of others depending on what communications card you are using. RSLinx can also be used for direct communications drivers (Rockwells own vs DDE or OPC) which is theoretically faster. You also can use RSLinx for gateway servises (RSLinx Gateway) to traverse say an Ethernet connection out a KT card to a DH+ network. Also you can use RSLinx for PLC programming with the use of RSLogix 5. E-mail me off site if more info is desired, we have like 50 copies of RSLinx in various configurations from DDE servers to OPC and direct using many protocols and drivers to many formats and also use it for PLC programming. Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
P

PatentEnforcer

Dear Amaro: Could you help spread the word about the Roseman patent posted at www.ipex.net/schneider.asp because the Roseman patent (5,038,318) covers DDE and possibly OPC applications? In your opinion does it appear that some industry players may have a misconception that every aspect of the DDE technology is open when in fact part of the industry may be using this company's patented technology without a software license? Thanks! http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5038318'.WKU.&OS=PN/5038318&RS=PN/5038318
 
A

amora fibrianto

I'm getting little bit confused here.......who actually owns DDE and OPC technology.....my first thought it is something like VBA or ActiveX technology that we could do anything on it. Could somebody help me ??? Viewing your link.....get me more confusing. What the hell is schneider trying to bid ??
 
Ken, From my experience, your description of RSLinxOEM is incorrect. We use RSLinxOEM as an OPC server to our HMI, Citect. Our most recent RSLinxOEM purchase was summer 2000. Mike Ryan Aerojet Fine Chemicals -----Original Message----- From: Ken Roach [mailto:[email protected]] <snip> RSLinx OEM: Allows programs that use the C-API to call RSLinx routines. Chief among these is RSView32. At least RSLinx OEM is required for RSView32 ( it cannot use RSLinx Lite). RSLinx Professional: All the functions of RSLinx OEM, plus OPC and DDE server functionality to allow 3rd party software that does not use the API to communicate with Rockwell networks and controllers. This is the version that is often bundled with RSView32. <snip> Generally with RSView32 you should buy the bundled RSLinx Professional package. It costs less than RSLinx OEM when it's bundled, and you have the option to use OPC or DDE connectivity as well as native RSView32 tags. I'll leave the "why OPC vs DDE vs ....." to another thread.
 
P

PatentEnforcer

Hi Schneider is bidding a patent on OPC/DDE for industrial automation applications making writes and reads of relevant control information into and out of a CPU and with a PLC. Many companies using the above idea are potentially infringing S's patent. Companies have products that use S's patented technology like AB, Siemens, Wonderware (large product offering) just to name a few. Of course it may take enforcement to make any company pay a license fee, but it may cost three to four times as much if these companies do not pay. It would seem to me that the industry must recognize that just because an Association like the OPC Foundation decides to publish a protocol or standard does not make it so. The OPC Foundation may have led astray alot of companies and their customers into believing that the technology is open when in fact a company like Schneider invested money and time into patenting its ideas for the industrial automation industry. Just look at Schneider's patent position on technologies such as Web enabled automation - AB, Siemens and others should find themselves losing market share when they promise Web enabled automation, but cannot get around Schneider's patents. In my opinion, S's position on their spreadsheet patent may indicate a significant and important shift in automation technology. Automation suppliers promising a new technology that runs afoul of S's patent may be misrepsenting themselves, something that their customer will soon learn about when they cannot deliver without secreting in the technology. Important customers like Ford, GM and others do not want infringement actions or companies placing in non-licensed technology into their operations on any process or product that they use in critical applications. More importantly, if S decides to enforce its patents these efforts will place added pressure on the product development of its competitors, and Wall Street will obtain information on S's enforcement, another variable in everyone's already variable and sensitive stock prices. Just my opinion. > I'm getting little bit confused here.......who actually owns DDE and OPC technology.....my first thought it is something like VBA or ActiveX technology that we could do anything on it. > > Could somebody help me ??? > Viewing your link.....get me more confusing. What the hell is schneider trying to bid ?? >
 
A

Amora Fibrianto

>>> Hi > It would seem to me that the industry must recognize that just because an Association like the OPC Foundation decides to publish a protocol or standard does not make it so. ........ >> Do you mean that OPC is actually not open protocol/standard ? What about DDE ? Who is behind the OPC foundation ? and how come is getting much more confusing to me ?
 
Top