Eddie Willers

"Error code 30, The remote host is not there, disconnected, or shut down." This means that the message is getting through to the Digi One IAP, which is responding with an error code instead of with a success code and the data you requested. This is the same kind of error code you'd get if you were sending a message through any Rockwell protocol bridge and the device on the far network (the remote host) did not respond. If the message were not getting through to the Digi One IAP, you would get a different error code, usually 0x37 Message Timed out in Local Processor.

Now that's more like it ! While I digest that information, I have two questions for clarification: 1. When you trigger the MSG instruction in the SLC and allow it to complete just once, is there an error code, or does it complete successfully ? 2. You mentioned "I am attempting to poll a function 4, address 3207, which should be the current voltage of the drive." Modbus can get confusing because the Functions are different from the prefix numbers used in Modicon controllers. Function Code 0x03 reads Holding Registers, which are addressed as "4xxxxx" Function Code 0x04 reads Analog Input Registers, which are addressed as "3xxxx" Can you post a link or details about the Modbus implementation in the Altivar 31's ? [Edit: I read a document that says the Altivar 31 supports Modbus Functions 03, 06, and 16, all of which address Holding Registers, "4xxxxxx"]

A confirmation of what I was thinking about using the Remote Destination Address to designate the Modbus Slave Node number: http://iatips.wikispaces.com/Edit-RSLogix-500-MSG-SLC505

Take a deep breath, Tim, and please accept this in a constructive light. It would be more informative if you would post the configuration of the MSG block in tabular format or a cropped screenshot of the MSG instruction configuration window in RSLogix 500. It would also be informative for you to post the DOIAP configuration or at least describe it in detail, rather than just designating that it's set up for one protocol or another. "I set it up for all three protocols" is an act of panic, not of analysis. Post the Modbus node numbers of your Modbus RTU slave drives, and post the Modbus addresses you are trying to read and write from them. The SLC-style addressing to Modbus addressing translation is pretty straightforward, especially with the Excel calculator. What you're having trouble with is you confidence in the basic Ethernet setup, and in the mechanism that the Digi One IAP uses to designate the remote Modbus slave address. In a ControlLogix message block, the "CIP With Source ID" addressing option is used. This is the sneaky part of the implementation. If you read the RSLogix 5000 Help file, or the RA Knowledgebase, you'll find that this mechanism is used to send a CIP message to RSLinx Unsolicited Topics, which use the Source ID to identify the data that's coming to it. in RSLogix 5000: Source Link: 0 Source ID: Modbus destination node number Destination Link: 0 The Digi One IAP uses the Source ID not to identify the source of the data, but rather as the Remote Modbus Slave address when it generates a Modbus Read or Modbus Write. So how do we get the same configuration in RSLogix 500 with the MSG instruction, which has a different configuration window ? When you configure the MSG instruction block (in the ladder editor) there are options for Read/Write and Target Device (500CPU/485CIF/PLC5), as well as for Local/Remote. Select Read, and 500CPU (this makes it an SLC Typed Read, which the Digi One IAP supports). Select Remote, and then look at the Setup Screen. The target configuration has three extra fields: Remote Bridge Addr (decimal): 0 Remote Station Address (decimal): Modbus Slave node number Remote Bridge Link ID (decimal): 0 That's my understanding of the Remote Addressing mechanism. I haven't specifically done this with SLC-5/05 and Digi One IAP, so I'm not actually giving you instructions by heart. Because you have set "Multi-Hop" to "No" in the RSLogix 500 MSG instruction configuration, the SLC will use the older A-B Ethernet (CSPv4) protocol, not EtherNet/IP. Configure the Digi One IAP accordingly for only that older protocol.

This is consistent with the way RSLinx works. The "EtherNet/IP" driver performs a broadcast of the "List Identity" function of the CIP protocol, and everything on the subnet answers with its identity object information. The "Ethernet Devices" driver requires a table of IP addresses to which it attempts to connect using the older TCP Port 2222 based A-B Ethernet protocol. A general description of how to do the the function you need is here: http://iatips.wikispaces.com/Rockwell-PLC-...g-Modbus-slaves

The "HP" is Hiprom Technologies of South Africa. http://www.hiprom.com/ Brilliant bunch, those lads.

Post the exact part number of the Lantronix device you have. It might or might not be a protocol translator. From your description it might be an XPress DR1+, which is almost what you need. The SLC-5/05 does not support Modbus/TCP on the Ethernet port nor does it support Modbus RTU on the serial port. The most successful device I have used to translate between SLC-5/05 controllers and Modbus RTU with an intervening Ethernet link is the Digi One IAP. That device is aware of both the A-B and Modbus protocols on Ethernet and can translate either one to Modbus RTU.

The old PV Classic and Standard terminals were black, and I remember asking an A-B manager why they changed to grey for the PV+ terminals. He said that they grey PVC was more UV resistant and generally matched the gray used in most control enclosures. I don't know if he was kidding when he said that the Chinese wouldn't buy black terminals because they associated the color with death. You'll note that CompactLogix is grey, and ControlLogix CPUs and power supplies are still black. I suspect it's mostly because of the available stable resins more than anything. The insert labels are made by GM Nameplate in Seattle; I don't know if they make the whole bezel as well.

RSLogix 500 version 6.00 was released in February 2003, so there's a full five years of development and enhancements that have happened since then. The current release of RSLogix 500 is version 8. If you post the whole program, somebody might be able to help you. I think it's possible that there's something about the firmware of the current controller that's confusing your older compiler/editor.

Despite the presence of "sale" in the EULA's prohibitions, integrators resell runtime software and whole systems get transferred from OEMs to end users. Rockwell has a simple form to fill out to transfer the license from one registered user to another: http://www.software.rockwell.com/support/regtrns/ I figure this "report of sale" legally transfers the EULA to another party. The odds of you getting a legitimate license transfer sale off eBay are virtually zero. Consider these fine gentlemen: http://www.jsonline.com/story/index.aspx?id=586300

The full part number for the "AIC+" is 1761-NET-AIC. Yes, this is the correct interface for connecting RS485 Modbus with any A-B controller except the MicroLogix 1100, which has an internal isolated RS485 port and uses a simpler "breakout box" cable called the 1763-NC01.

Security should be your first consideration and your last consideration. Use a hardware VPN endpoint, as sophisticated as you can afford. In the middle, you're going to need a webserver HMI that is compatible with your chosen controller. You posted this in the A-B forum section, but you didn't specify what you're using. Do you need a local display as well as the Internet-based display ? If so, you probably will want to use a PC-based HMI like RSView ME, Intouch, or Lookout Direct. Then dial-in to the local computer and use Windows Remote Desktop to take it over. If you don't need a local display, this is probably a good application for a Red Lion Data Station Plus, which is notable for their serial connectivity and display-less HMI product.

Without getting into the complexities of TCP Connections versus CIP or CSPv4 Connections, the simple answer is that your system should not encounter TCP connection problems. Each controller will be handling: 1 incoming TCP connection from the PanelView 1 incoming TCP connection from the SCADA system 1 Outgoing TCP connection to the supervisory SLC-5/05. The Supervisory SLC-5/05 will be handling: 8 incoming TCP connections from the other controllers 1 incoming TCP connection from the SCADA system The SLC-5/05 controllers support a limited number of simultaneous TCP connections, depending on model number and firmware. I'm not certain about the precise firmware history, but I think the increased number of connections was part of the enhancements in OS501 Series C FRN 10, almost 2 years ago. You can get all the details from Appendix E of the SLC User Manual, 1747-UM011F. The current 1747-L551, -552, and -553 controllers support 32, 48, or 64 simultaneous TCP connections. I worked on a system maybe 8 years ago that had twenty-two 1747-L551 controllers, which supported only 16 simultaneous TCP connections. They attempting to write from each controller to each other controller to create a sort of global data array. Not too successful, since they were also trying to do it over 900 MHz Ethernet radio modems. We ended up using a ControlLogix as a data concentrator and having all the controllers write to it.

My recollection is that the 1747-PIC/AIC driver in RSLinx 2.20 (and maybe 2.30 too) did not work in Windows XP, so if you install those versions on XP the driver intentionally was not listed. That was around 2001 or 2002. I think they added it back in RSLinx 2.31. RSLinx Lite is a free download; just go through the normal software update website and when you select RSLinx Lite, the field that would normally require a serial number is not present, so you just download the software. The RSLinx Lite download will work with any license that activates the OEM, Professional, or Gateway functions too. Just make sure you are on a fast Internet connection; RSLinx Lite is a really big download because of all the stuff included in it (like EDS libraries).

The difference is that when you connect to a hub or switch, you are using a "Patch Cable". When you connect one host to another, you must use a "Crossover Cable".

I don't have direct experience with the FDA's electronic records law (21 CFR Part 11) but I've read some ISA articles about it. Part of that law demands that control systems used in pharmaceutical production must have components, firmware, and control code that are carefully developed, documented, and maintained according to strict recordkeeping rules. My understanding is that if you built a 21 CFR Part 11 validated control system and used an off-the-shelf CF card in a PanelView and had to replace it with a different one, you would invalidate the system. I have attempted to duplicate the internal CF cards in PanelView Plus terminals and found they have partitions that are accessible to the boot firmware of the terminal but not to Windows. The external cards have no format restrictions; if you can format it as FAT16, the terminal should be able to read and write to it.

Here's a rundown of the component parts of PanelView Plus terminals: A-B Catalog Pages for 2711P Detach the PanelView Plus 700 logic module from the display bezel and turn it over. Snugly attached in the middle of the board with a plastic bracket and screw is a CompactFlash card with an A-B part number on it, 2711P-RW1, -RW2, or -RW3. This card is the "hard drive" of the terminal, and holds the boot firmware, the Windows CE operating system, the RSView ME runtime software, and any internal storage logs and applications. If that card is the one that you judge has failed, then you absolutely need to buy an A-B card because it will include the operating system and firmware. This is what I was talking about when I said I'd had the failed ones replaced under warranty. For the external CompactFlash cards that you insert into the slot on the side of the terminal, I have always had good luck with SanDisk brand cards. If you can get the "Professional" type cards for high-end digital cameras, they are generally built with the same kind of memory cells as the A-B cards are. I've always been told that unless you have a government-regulated industry requirement or a very high temperature or vibration environment, that you ought be be OK with a commercial CF card in the external slot. I understand that for long-term use of data logs or trends that "single-cell" NAND memories will last about 10x longer than the cheaper "multi-cell" ones. Recently I purchased three 1GB SanDisk CF cards for PanelView Plus terminals. Two of them worked, one of them was not recognized. When I put them into my laptop with an adapter and examined their device identities, I found that two were internally Hitachi units, and the third was a Fuji. Mind you, I bought all three at the same time with the same part number and the same package at the same retailer. So it's kind of a "pay your money and take your chances" situation with regard to compatibility. Personally, I can gamble on a lot of incompatible CF cards for the price difference, and my applications aren't federally regulated or very hot or buzzy.

That price can't be for the removable memory card; that has to be internal CompactFlash card that holds the operating system and application firmware of the terminal. I had two CF cards fail about 2 years ago in PV+700 terminals and had them replaced under warranty. Pursue that before buying a totally new card. I have had good luck with SanDisk cards used as external storage cards with PV+.

It sounds like a job for On Top displays and Global Objects. While a Global Object isn't exactly "displaying content from other displays", it is using the same objects with the same links in multiple places in the project. When you change the base contents of the object, they change in all the instances of the object. Instead of copying content from a page, grouping it, and automating the visibility, you will copy content from a page and create a Global Object with it. Place that Global Object into an On-Top display that you launch with a Display button instead of animating its visibility.

That's how you make an I/O connection in one of the 1756-series ControlLogix that has a ControlNet bridge in the chassis. But that CompactLogix doesn't have a ControlNet bridge, only an EtherNet/IP bridge. Probably the simplest thing to do is have the ControlLogix make the I/O connection, then Produce and Consume the same data over EtherNet/IP to the CompactLogix. The 1756 ControlLogix will be the "man in the middle", but the data exchange willl be fast and reliable.

The rule of thumb I have been told is no more than 5 PanelView Plus terminals per ControlLogix controller. While a PanelView Plus will make just one TCP connection, it can make up to four CIP connections, each of which can use a backplane buffer on the ControlLogix. The number of CIP connections depends on a lot of factors; the number of tags on scan, the scan rate at which they are running, and the use of Global Tags, the Datalog model, and the Alarm system. Even though most EtherNet/IP modules can bridge many CIP connections (Ken Moore's numbers look familiar), the backplane buffers to the ControlLogix are where you can come up short. The ControlLogix has 20 backplane buffers available. There are some methods to measure and increase the number of backplane buffers. You're probably going to want to talk to your local Rockwell tech person about this application.

How is the CompactLogix 1769-L32E connected to the ControlLogix 1756-L1 ? The picture seems to illustrate an RS232 DF1 connection. Even if the 1769-L32E was connected over Ethernet, it can't make an I/O connection to the ControlNet chassis. Only controllers with a direct connection to ControlNet (PLC5C15) or with a backplane-resident ControlNet bridge (1756, 1769, 1794, and 1789 controllers) can make I/O connections on ControlNet. Can you substitute a 1769-L32C controller, and connect it to the ControlNet ?

Siemens ProfiNet and Rockwell EtherNet/IP are fundamentally different application protocols and cannot directly communicate with one another. PC-based middleware is a common solution; OPC Mirror software from several vendors can be used. Hardware gateways are also common; HMS Fieldbus' "Anybus-X" device will link data between ProfiNet and EtherNet/IP systems. The most common link that I see established (and install myself) between A-B and Siemens systems is Profibus DP.

Clay is right on in his explanations of why programmers clear the math fault bits in MicroLogix and SLC controllers. I've done this many times myself, to keep the program running while I chase down where I made the error and caused an overflow or divide-by-zero. Sometimes I'll do it on small routines because I plan to add overflow limiting and user-entry checking later. Sometimes I even get around to it ! In the hierarchy of programming sins, disabling overflow faults is a venial offense.

RSLinx will not autodetect the COM port, data rate, or framing of the 1747-UIC. The COM port must be determined using Windows Control Panel, and the data rate, framing, and error checking must be manually set as described on Page 12 of the Installation Instructions pamphlet (which is in the box) for the 1747-UIC.