Hi all, I am trying to solve a communications problem, between a Pro-face AGP3600-TI-D24 touchsreen and an AB CompactLogix PLC. The touchscreen does not seem to be able to communicate with the PLC, although maybe one or two buttons appear to work. The error on the touchscreen is: ' RHAE132:xxx: Error has been responded for device write command (CIP error code:05H) ' (where xxx is the name of the PLC). The strange thing is that we have exactly the same problem at two totally different installation sites right now, at the same time. Everything is basically the same, except one site has an L32E and the other an L35E. Both screens are using Pro-face's 'Rockwell CompactLogix Native' ethernet/IP driver to communicate with the PLC (allows the use of direct comms with tags etc, no need for address mapping).
Make sure to set up the following safety circuits outside the PLC to ensure safe system operation even during external power supply problems or PLC failure. Otherwise, malfunctions may cause serious accidents. (1) Note that when the CPU module detects an error, such as a watchdog timer error, during self-diagnosis, all outputs are turned off. Ya, I'm having the same thing happen. Just started after running the final release of Win 7 now for about 6 weeks. I had also changed permissions to get some things to work so that could be it.
Even stranger, the previous installation where we used these screens worked fine. That site had two PLCs & two screens. Same model touchscreens, same drivers, and same PLCs - one L32E and one L35E.
In fact, the touchscreen programs and PLC programs I am using for the new systems are simply modified versions of those used on this previous installation. The Pro-face manual says that this Pro-face error code means a failure to write to the PLC. I could not find any reference to the CIP error code in the AB literature. I have asked our Pro-face supplier, they have checked with head office, and reported that the AB CIP error code (05H) means 'Local processor is off-line (possible duplicate node situation)', and that they suspect a duplicate node (I'm not sure if 'node' is interchangeable with IP address.) While there are a few network issues (mostly VPN related), all local ethernet network communications (RSLinx etc) seems to be working fine. Besides, the LAN at each site was used to transfer the touchscreen program (actually via the VPN at one site), so that much is working we know. At one of these sites though, it did take a long time to get the Pro-face software to be able to communicate with touschreen, to transfer the program.
We had to mess around with port numbers etc, before it would work. But after that first time, it now works every time.
Currently, both touchscreens have the port set to Auto. I suspected network issues at the time, as it had all just been set up then. But now the network is fine (eg now am PLC programming remotely via the VPN etc) As I said, I was thinking that both sites have some network setup problems - but what are the changes of two totally unrelated sites & systems both experiencing the same problem, and both being due to network issues? Besides, the previous two systems worked fine.
I have checked all settings on the PLC, the PLC ethernet port, the touchscreen, port settings, IP addresses, everything, but no luck. Cheers, Andrew W. The problem is local (the PLC and touchscreen are right next to each other) Both devices have been allocated static IPs, and both devices are on the same subnet.
There is also a default gateway set in the PLC and the touchscreen. The PLC has some DNS server addresses set, but the touchscreen does not. But there should be no need for the DNS servers. All devices are local and connected to the one switch. Connected to the switch is: one touchscreen, one PLC, one computer, and the customer's network connection (to allow us to come in via the VPN). I'm not sure about the firewall, but its a local comms problem, so any firewall shouldn't effect it. Both sites have the same problem - even if the customer's network connection is pulled, the touchscreen is still unable to talk to the PLC.
At one site, the VPN connections is a Cisco VPN (with this one there is some unresolved problem with the setup which is preventing me from pinging either of the two devices, but is a teething problem, the exact same setup is working at other sites) The other site's VPN is just a windows VPN, and I can see all devices. Cheers, Andrew W. Hi newpageboba, The PLC & touchscreen are connected to a local unmanaged Hirchsmann Spider 5TX 5 port switch. The customer's network gets comes into this switch also, but even when it is disconnected, we are getting the same error. At one site, I had the guy try connecting directly from the PLC to the touchscreen (with a crossover cable) - same error So I am thinking it could be a problem or setup problem on the PLC side.
Anything I should check with the setup of the ethernet port? But we can go online with RSLogix5000 fine, upload, download, (locally, and over the VPNs too), and our VB HMI program can communicate fine with the PLC (via RSLinx DDE). So it can't be that? I don't know what else to do! Cheers, Andrew W. Verify that the Compact logix is really talking AB Ethernet IP. We recently used a new micro logix and it was AB Ethernet CIP.
This created a problem as we were talking to a SLC500. We ended up finding out that the CIP device could write and read to the IP device but not the other way around. We ran out of time before I could reallly dig into what they changed on us.
When I configure a touchscreen using cimplicity software it gives me the option of selecting ethernet IP for Control logix, SCLC500, or PLC5. Does your software differentiate between the two?
Hi rammin48, Not sure how to verify that the CompactLogix PLC is using EthernetIP? I thought that CIP was the protocol and EthernetIP the comms network? Anyway, the Pro-face touchscreen has many comms drivers. The one i'm using is the CompactLogix / ControlLogix native ethernetIP driver. Extra info: On the last project, initially I started out using their AB CompactLogix / ControLogix ethernet driver, which requires address mapping using RSLogix5000 to map tags into SLC-style files. But then they released the CompacLogix / ControlLogix native ethernet driver, which can use the PLC tags directly (any data type).
The first driver worked fine, but was a pain due the address mapping. So 'native' driver was much easier, and worked fine.
That project is still running fine so I am stumped for what the problem with this new project could be! Cheers, Andrew W. I know AB has been upgrading their ethernet boards on various processors and I had assumed that the Control logix was CIP.
The difference as it was explained to me was with the ethernet board in the SLC500. I pointed you in that directions as the problem sounded familiar.
As I said I did not get any time to dig into it, rather found a way to work around it. SLC500 talks AB Ethernet I/P and Micrologic has been redefined as AB Ethernet CI/P. As I understand it the original AB ethernet I/P was suceptable to collisions and random update times as it was not deterministic. The CIP(control and information Protocol) was developed to make the system more deterministic and reduce the collision problem. There is a difference and I do not know whether the Proface can handle both protocol types or not. Or wether they have upgraded the ethernet board on the L35E. This probably does not help you any but it is the best I can do.
This is something reletively new as a problem that I will also be dealing with shortly so let me know what you find out. Hi rammin48 Something does not sound right there. As I said, my understanding is that CIP is the protocol and EtherNet/IP is the network etc. People feel free to correct me if i'm wrong! Regardless, everyone else. If I can't get it to work, I am faced with changing the Pro-face driver to DF1 (serial), and having to change every single tag address in the touchscreen program to an SLC-style file address, and mapping these with RSLogix5000. I really don't want to do that.
And i'm not even sure it would work. Will I get the same or similar error?? Besides, it would remove our ability to 'see' the touchscreen on the network, upload or download, etc. Other than that, i'm out of ideas. I'm still talking to my Allen Bradely rep & Pro-face rep. Cheers, Andrew W.
Product DescriptionPFXGP4501TMD is a Schneider Electric ProFace Display. A system error on the display means that there is a fault in the basic operations of the GP.
An illegal address in the screen data is caused by an overlap of addresses. An unsupported tag in the screen data means that the current GP version does not support the list of tags currently in use. When the PLC is not connected, communication with the PLC has stopped for more than 60 seconds, there has been a transmission timeout error, or their is excess noise. When the PLC is not responding, there has been a Reply Timeout Error, or there is excess noise. A receive data error occurs when there is a problem in trying to receive the data, the PLC setup for the data is different from the connected PLC, or there is excess noise.A GP station number duplication error occurs when the GP number is the same as the station number for another GP, or when the PLC power has been turned on or off in the middle of correspondences.
A network address error means that the SIO address setup for the GP is different from the SIO address setup of other GPs. A PLC communication error occurs when the address setup for the tags in use exceeds host side address range.
When the screen memory data is corrupt, the checksum of the screen memory data does not match because the screen files are corrupted. The display unit may be operated in OFFLINE mode.