RSLinx Remote OPC

[Guest Jaroslaw]

Hi all, First, a little background: -we have a bunch of PLCs on the shopfloor which are not capable of communicating over Ethernet -each has a PC connected to it (mostly via PIC boxes) -each PC is running RSLinx Professional and custom software which interfaces with RSLinx via DDE Now to my question. With the above setup, is it possible to develop a VB application which would gather various information from the shopfloor. The application should run on a single dedicated PC and communicate with RSLinx running on each of the shopfloor PCs via Remote OPC Automation. I guess the basic question is: is it possible to communicate with an instance of RSLinx Professional on a remote PC using OPC Automation (by linking to library rsiopcauto.dll in my VB project) or do I need to upgrade to RSLinx Gateway or something like that? Any comments or suggestions are welcome Jaroslaw

[b2barker 0]

Yes, you need Gateway on each machine get OPC data from a remote machine . Are your current connections serial (maybe DF1 or DeviceNet if you are using RSLinx)? Maybe if would be cheaper to bring all to data to one central point with one RSLinx Gateway, and then the other machines in the field connect to this Gateway to get their their data with their RSLinx Pro. You could then run your VB code on this central machine or on remote machine.

[Guest Jaroslaw]

Thanks for your reply b2barker Yes, all (exept one) our local connections are serial. Therefore, your suggestion of buying one RSLinx Gateway license and running it on one central PC sounds very enticing. This leads me to the following questions: 1. How would you accomplish connecting multiple (lets say 10) PLCs to one machine (multiple com ports?) ? 2. What is the maximum distance that a serial PLC connection can go and still have reliable communication? 3. If the above is somehow accomplished, will the Gateway be able to distinguish between each connected PLC? 4. If I have 10 PLCs connected to one PC which is running RSLinx (not Gateway), I should be able to eliminate the need to buy RSLinx Gateway altogether provided I run my vb program on that same PC, shouldn't I? As I understand it, there would be no need for remote OPC then. Any comments are welcome, Jaroslaw

[Guest kaiser_will]

In designing a data collection system, there are a few design questions that you should ask up front in helping to design your solution... 1. How important is the data? If the data is be used to verify the quality of your operation, there are data collection packages, such as WonderWare InSQL server and Intellution iHistorian that comply with recent FDA regulations for validity confirmation of data. 2. What is the minimum time stamp of data (Delta-T) that you are looking for? The issue you might run into here is that DH-485 (the communication protocol for the PIC boxes) is not terribly fast. 3. Does the data need to be collected on a time-driven or event-driven basis? 4. What is the purpose of the data? If the data is just so engineering and maintenance can see squiggly lines, then a trending package is probably more of use than data itself. Allen-Bradley's RSView, WonderWare's InTouch and Intellution's iFix are all great for this. All of these applications have free drivers with their software that let you connect to Allen-Bradley DH-485 processors. Keep in mind control system articles have indicated that the majority of data collected from control systems never end up being of any value. Been there, done that. If you have not done so already, you can string DH-485 cable from PLC processor to PLC processor (there are design constraints for max line length, number of processors and node addressing) and build a network of processors. DH-485 is easy to bring to its knees with too much traffic. There are 3rd party products for dropping a DH-485 node on Ethernet. Check out this vendor... http://www.factorycomm.com/datahighway.html

[b2barker 0]

First 2. RS232 (DF1) is good for about 50m, 485 (DH485) I am not sure I think in the order of 500m though it may be more 1. If the distance allows then you can put in multiple physical comm ports. If not you could consider serial/ethernet convertors. We have used Lantronix, RuggedComm and Advantech Adam convertors before. Most of these have a driver you would put on central machine that make virual comms port where the driver redirects comms port traffic via an ethernet address. For example, if you put 2 eight port Lantronix serial/ethernet convertors in the field near you PLCs, and have ethernet to central machine, the software would give you COM2-9 for one and COM10-17 for the other. This would work for DF1, but I am not sure about DH485. For DH485 I think you would need multiple KT cards but you could multidrop. 3. For DF1 you configure a driver for each, port physical or virtual. For DH485 a driver for each card. You would then configure an OPC topic for each PLC. 4. No you wouldn't need gateway if you OPC connection is on the same machine, but you would need it if you want to maintain the existing PC's in the field and they are DF1 connected. That is, you would be removing the connection to the local machine in order to connect it to the central machine, so you would need gateway on the central machine in order for the field machines to connect through the central machine. If it's DH485 you can multidrop both the field and central machines so you wouldn't need gateway. There are many solutions including an off the shelf HMI. I would add Citect to kaiser_will's list, not just because it's Australian like me, but because is a very good package. Hope than helps

[Guest Jaroslaw]

kaiser_will: I am not really a PLC/Automation expert. I work in the IS department for our company as a developer, so some of the terms you used went right over my head . Actually, we want this data available for our in-house developed downtime monitoring software and to interface with our ERP and Production Scheduling systems. So data would be collected on both time-driven (production counts, current job running etc.) and event-driven (press stops/starts running) basis. I have already got it partially working but only writing to an ORACLE database from each local PC (which is directly connected to the PLC) via our LAN. However, I think that gathering this data from a central location (bypassing local PCs) would be much easier to manage/support/debug. b2barker: How you going mate? . Currently, out of 16 PLCs, 14 are connected using PIC boxes which convert DH485 to a serial which is then plugged in to a com port on the local PC. 2 of them are using DH+ with KT cards. However, they all have both RS232 and DH485. The RS232 is a DB9 type connector and DH485 is a RJ45 (same as ethernet) connector. So lets say we buy a single port (since we already have ethernet connectivity at each press) ethernet/serial converters for each of our PLCs and connect them all to our LAN (give them IPs etc.). S Will I be able to access data from all of them on 1 machine running a copy of RSLinx Professional? If the above is true, how will RSLinx distinguish between each PLC? As I understood from you reply, the driver which comes with the converters would allow me to map an IP address of each to a software COM port on my central machine. Then, in RSLinx it would only be a matter of configuring a driver for each software COM port. So RSLinx would see all PLCs as if they were connected directly to the PC. Is my understanding correct? Thanks a lot for your help guys Jaroslaw

[Snerkel 0]

You would be better to setup a DH485 network, this uses daisy chained data cabling that is designed for factory PLC communications (a bit long in tooth now but still used a lot). Each PLC with a DH485 port would need a 1747-AIC for each PLC this gives screw terminal connections and provides signal isolation. This system is good for 5/01 5/02 5/03 processors. 5/04 5/05 processors would need the RS232 port configuring for DH485 and would need a 1761NETAIC (AIC+) for each PLC The AIC+ and AIC are similar, both are designed to provide signal isolation onto a DH485 network, the AIC+ is designed to connect by RS232 to the processor the AIC connects directly into the RJ45 port on the processor. A DH485 network supports 32 devices Each PLC would have a different node number on the network RSlinx will see all the nodes on the DH485 network, for the PC connection you can use either an AIC & PIC box or just an AIC+ connected directly to the RS232 port on the PC. All AIC+ would need a 24v DC power supply, all AIC connected directly to a PLC will draw power from processor (or a 24v DC power supply if required) Edited 25 Sep 2004 by Snerkel

[b2barker 0]

You understanding about COM port mapping is correct. As Snerkel has said with DH485 and DH you would better off combining all your equipment into one DH485 network and one DH network, unless speed is an issue. If I understand correctly you would have a DH485 network with 14 PLCs, 14 field PC's and one central PC, and a DH network with 2 PLC's, 2 field PCs and the same central PC. If I remember correctly DH is a token passing system where each node takes turns in exchanging data. Your current system each 'network' has one PLC and one PC. If you have 14 PC requesting data from their PLCs and one central plc requesting data from 14 PLCs, I would expect existing data transfer significantly slower (maybe 1/28th). Less of issue for the DH due to reduced number of nodes Edited 28 Sep 2004 by b2barker

[Guest Guest]

I understand your points about the DH485 network. There are a couple of reasons as to why I would prefer to go with a separate ethernet connection for each PLC: 1. Since one of the applications of this system is to monitor uptime/downtime, the speed is indeed an important issue. 2. If I understand correctly, with all PLCs chain-linked together, a failure of one link (for maintenance etc) can cause other links to fail. As I have been told by upper management, this is unacceptable in our production environment. Our operation is very time-critical (we are a first-tier supplier for GM). That being said, could somebody recommend a reliable and cost effective 1 port serial/ethernet converter (I'm talking brand/model) which would work with my PLCs. The connectors which are available on each PLC are DH485 (RJ45 connector) and RS232 (DB9 connector). I have looked at the manufacturers you guys have mentioned but I am not sure as to what is the best choice: 1. Keep using PIC boxes and buy a converters with RS232 DB25 connector? 2. Get a converter with RS232 RJ45 connector? 3. Get one with RS232 DB9 connector (haven't seen too many of those)? As you can see I am quite confused about the array of choices available. Just one more question: does RS485 correspond to DH485? That is, if I buy a converter with a RS485 (or RS232) port (RJ45 connector), will I be able to plug it into the DH485 port on the PLC (also an RJ45 connector) using a regular network cable? If this is possible, it looks like the best solution so far. Thanks in advance for any suggestions, Jaroslaw

[Snerkel 0]

If the data is that critical I would just ditch all the processors and replace them with 5/05 processors that have an Ethernet port built-in, you can then build your infrastructure as you like, with no local PCs to worry about. ps the logic for all your existing PLCs will slip straight into the 5/05, most if not all will just require the PLC type changing in the software.

[Guest Guest_rock]

The company that I work for is also getting into wanting to collect data from production machiner, such as cycles,down time, bad barcode scans etc. I have recently recieved three new packaging lines that have the AB Micrologix plc's. They originally had the micrologixs 1000, but have replaced all of them with the Micrologixs 1200. Am curious as to exactly how to connect my laptop to a Micrologixs 1200 and using excell, be able to experiment with pulling data from the plc and placing them in the excel file. I have rslogics 500 and rslinx. The post that I have read keep refering to rslinx professional. Is it possible to do this with rslinx instead of professional. Thanks

[Snerkel 0]

Guest_rock to avoid confussion please start you own thread.

[b2barker 0]

DH485 is AB's Data Highway protocol on a RS485 wired multridrop serial network. I agree that having an ethernet port on each PLC is the best solution. But is it's cost prohibitive... I have used the following for serial to ethernet, but there are heaps of them around these days: 1) Adam Avantech http://www.advantech.com/products/sub_cate...1-KM5V2&PD=ICOM 2) RuggedCom 3) Lantronix The first two I have used for Citect to read Serial Modbus from drives and power monitors remote substations. These didn't need COM port mapping as Citect can read a serial protocol through an ethernet port. The last I used some time ago for comms to multiple very old GE Series 6 PLC's. They all have versions with one to one or one ethernet to many serial ports. The Adam and the RuggedCom I used had terminals for serial connections. The lantronix had RJ45 serial ports. Guest_Rock : You need RSLinx Pro or Gateway for DDE links to RSLinx. Lite or OEM doesn't cut it.

[Guest Guest]

Snerkel: I do agree that upgrading all PLCs is the best solution. Our maintenance department did consider this step, but it was deemed too expensive. b2barker: After looking at company websites you mentioned, I came up with the following choice: ADAM-4571 http://www.advantech.com/products/Model_De...-KM4US&PD=ICOM# So I if use the above device and change the mode to RS485 will I be able to connect it to the DH485 (RJ45 style) port on my PLC using a regular (or crossover) ethernet cable? Or do I need some special expensive cables from AB? Thanks, Jaroslaw

[Snerkel 0]

I would be careful with any converter as the DH485 protocol is very demanding, the DH485 drivers may not like the virtual comm ports used in such a setup. Unless someone can provide a definative device that works with the DH485 protocol then you may need to do a lot of experimenting to get something (if anything) that works. If you do get it working posting the make and model of a working device would help us all

[shechtman 0]

I wouldn't mess around with DH485 with all those processors. Been there and done that and DH485 bogs down very quickly. Its a wimpy protocol. Need to upgrade those processors to Ethernet processors. AB now has the MicroLogix 1100 out with is Ethernet and could replace the Micrologix 1200s. It has the big bonus of being online programmable as well. Then once you get all of these connected online I saw no discussion of how to actually collect up the data into the SQL database. For that, especially since you seem to be so price conscious, you should use FactorySQL. See www.inductiveautomation.com/factorysql

[Stupidav 1]

From what I have read, First you don't neccesarily need RSLinx Gateway. I would set up a small VB app to run along side of your current HMI apps, to collect and serve the data. From there you new primary PC can access the all the data you are serving. This way, yea you have a little more programming, but you eliminate the networing and additional software licences.

[Christopher Barker 0]

Question: I am running RSLinx Pro (v: 2.40.01), with RSView32 (v: 6.30.17) and my display has no data. My driver (ETHERNET) is properly configured and browsing. My topic and channel are set. Node is set to topic. My tag monitor is returning stale and error messages. I tried everything: created new Node (OPC Server-local). My question, should the controller key be set to RUN or REM (remote)? Do I need to configure DCOM. My setup looks like this: Channel: 1 Network Type: TCP/IP Primary Communication Driver: AB_ETH-1 Messages: 3 Active Driver:Primary Data Source: OPC Server Name: Chris (enabled) Server Name: RSLinx OPC Server Server Type: Local Access Path: (blank) Tag Database (added) Scan Class (default)

[paulengr 44]

DH-485 is not as bad as it sounds. It is limited to the speed of the serial port which is 19.2 kbps with the equipment you are talking about. DH+ is capable of between 56 kbps and 230 kbps depending on the PLC's involved and the cable lengths. However, it requires a KTX card for the PC, or a ControlLogix backplane (use as a bridge), or a KT2 box, or something similar to act as a bridge to serial. The problem with trying to run DH-485 across Ethernet, wireless, etc., is that the timing on DH-485 is VERY strict. So strict in fact that a lot of USB-to-serial port adapters cannot deal with it. And all wireless/Ethernet options are completely out of the question. It is a "daisy-chain" style network, but if you lose a PLC, it will not affect it. The data stream is not "looped" through each PLC. Think of DH-485 as a party-line or a "radio" type interface. All nodes on a DH-485 network see the same signals at exactly the same time (within cable propagation limits). If you physically pull the connector off of a PLC or power it down, the DH-485 interface is not affected by this. Only physical damage to the DH-485 cabling will take the system down. The same statements are true about DH+ networks as well. However, that being said, I have implemented the exact same scheme more recently and here's how I did it. I was being pushed to use a ControlLogix backplane and DHRIO. The way that you would do this is to install a 1756 backplane, power supply, one 1756-DHRIO card, and one 1756-ENBT card. You get 2 DH+ ports per DHRIO card. Then you connect to the Ethernet port (1756-ENBT) and route across the backplane and then out the DHRIO card ports. RS-Linx can easily navigate this interface. I decided to go another way for cost reasons, among other things. I installed Digi One IAP cards. You can buy these from www.bb-elec.com. Each card gives you 2 serial ports and one Ethernet port. The serial ports can be configured as a "pass-thru" system so that you don't "lose" the serial port on the PLC, or you can use one card for every 2 PLC's. The Ethernet port can support a variety of protocols simultaneously, including Modbus/TCP which you can access from VB with free drivers. Better yet, the PLC programming software can simultaneously access the PLC at the same time. Just remember that each PLC is limited to serial port speed (19.2kbps), but once you get out the Ethernet port, speed limitations are no longer a factor. Now I already had an established DH+ network (from a predecessor's work) so for several of the processors I connected a KT2 box (also a leftover) to the DH+ network and then connected the serial port of the KT2 to the Digi One IAP. This simultaneously gave me direct Ethernet access to 6 of my PLC's. If you use say the Digi One SP, you can save some money per processor and still get Ethernet data. Just use the "virtual serial port" software on the PC side and tell RS-Linx that it is connected to a "real" serial port. You can get other Digi One cards with more than just a single port as well if the PLC's are physically close to each other. However, there is a huge downside. Since these "serial servers" are very dumb (just copying data from the serial port to a TCP session and vice versa), they don't obey the legitimate protocol requirements of "real" Ethernet PLC's (unlike the Digi One IAP for instance). So only one PC at a time can connect to the virtual serial port. You can of course use RS-Linx Gateway to allow other PC's to multiplex their data but it's just not as clean. I noticed the suggestion about upgrading to SLC 5/05's. You might check into it because it's becoming more cost effective lately to upgrade to a CompactLogix or ControlLogix processor including the I/O upgrades. Also, the bit about "instantaneous" downtime/uptime detection is rather specious. You have to have a VERY high speed assembly line to require detecting downtime with a finer granularity than once per second. If this is the case then you have no choice but to upgrade to a ControlLogix processor for bandwidth reasons, among other things. DH485 and DH+ is "slow" but as long as you don't overload things (and you can always split the network up by adding additional PC's or PLC's as bridges/gateways). If you are operating at those kinds of speeds, then you need to write special code to buffer data at the PLC anyways because even with Ethernet, you run the risk of a packet being dropped now and then and causing a delay that might stretch out for a few hundred milliseconds. Finally, I have an even bigger suggestion. There is already software out there to do the data logging for you. All the "major players" such as PI, GE Fanuc, Wonderware, and Rockwell (Allen Bradley) already have premade MES-type software which does exactly what you need. It is definitely not cheap. But it already has downtime, defect counts, production rates, etc., already preprogrammed and they already have web-based and desktop-based reporting systems already developed. It would take you 6-12 months to do what these systems already do. They are NOT cheap (all carry 5 digit price tags) by a long stretch but you are looking at a long endeavor and probably many months of additions, support, updates, etc., that this software already does as a built-in feature. There are also reporting systems that give you the capability of writing your own reports based on your SQL data, usually either Java or web based (or both). They are well under 5 digits. As a cut down version of this, you can also get a reasonably priced historian software. This does the data logging for you to either to a special high speed data logger, or to standard general purpose SQL. With either one, the data is accessible via SQL queries. Again the above vendors sell this plus my personal favorite, FactorySQL (sold by inductiveautomation.com). All offer either 2-week trial periods or 2-hour fully capable demos. For Historian/data logging software, the price is much more reasonable than the above MES software. Either way, it saves you a LOT of development time (and costs) and you can then concentrate on developing the reporting aspect of things. From personal experience, I've done everything except the fully canned software option. I have written my own data logger and reporting system. I've used a custom data logger but written all the reports in VB/VBA. And I've used one of the web-based reporting systems. I was never truly satisfied with the first two options, and I found that I was constantly adding/modifying/changing things to support whatever management wanted to do this time, and it took days and days of time for every change. In addition, the data-logger-only version was Wonderware Historian, which was extremely unstable and broke all the time, and the SQL interface was just downright ugly for anything other than trend charting (about the only thing it was good for). With the web-based reporting system, I had it up and running in about a week. I could develop meaningful reports in about a half day of time if it required extensive new additions to the data gathering, or minutes if it was just a small tweak such as another column or calculation. I was also able to easily train other people to add/modify/update the reports, even the more savvy managers. This tremendously relieved the load and allowed the system to scale up much faster. If I had to do it all over again and could pick any package to do this, I think inductiveautomation probably has one of the best packages out there and the price is very reasonable compared to most software packages that sell you either per-seat or per-PC licenses which quickly amount to mid-5 digit price tags. Mind you, I didn't mind doing the programming. In fact, I rather enjoyed it. But the issue at hand is one of productivity. The reporting and data logging systems eliminate weeks if not months of work and allow you to provide a better, more flexible, and more comprehensive solution in a much shorter period of time, short enough that it entirely mitigates the cost when compared to your salary and time involved. In addition, it allows you to drive the "support" function out of your shop and into the hands of others so that you can concentrate on "doing IT" rather than getting forever trapped in supporting the ravenous desire for data that management has.