Mike Carter

Hello Ken, The sub net mask for the side card 3.26.5.61 IP address is 255.0.0.0. The gateway is 3.26.1.100. It does predate the Internet. The gateway for the 4.2.6.xxx is 4.2.4.1. I changed the IP address on the side card via an Ethernet connection and things went south in a hurry. Because I didn't want to disrupt our start up tomorrow night, I connected to the PLC5 with a Laptop and in program mode put it back to the original settings. Changing the IP address will be something for another day, because some RSLINX topics will need to be updated. I guess from a networking perspective I need to get with my IT guys. We are using domain controllers, and VLANS but I am not quite sure how all of our computers on the 4.2.6.xxx network can communicate with the old 3.26.5.xxx stuff. Regardless, I need to change the IP addresses on both of the PLC5's to the same set up as everything else. Aside from the IP conflicts, I am pretty sure my hardware is up to date on the PLC5 side. It is a 5/60 Enhanced Series E, Rev E.2. The 1785-ENET is a B. Does everything else look normal?

Hello All, I want to read data from a Control Logix PLC, into a PLC5/60, using Ethernet and a MSG instruction in the PLC5. When verifying the MSG instruction in the PLC5, I get an error message. "Target Address in invalid". Once I figure out how to do this I need to replicate it in another PLC5. Scope is to read the status of 4 paint pumps controlled by the CLX. If any of the 4 stop, the PLC5 needs to know, because it is controlling the paint application equipment. Source data resides in a Control Logix 1756-L63. The tag is INT type, 4 elements long, and the name is PUMP_STS_B2. The IP address of the CLX is 4.2.6.230. There are 2 ENBT cards, one in slot 1, and the other in slot 3. 4.2.6.230 is slot 3. PLC2,5 / SLC Mapping has been created in the CLX. File=421 Name PUMP_STS_B1 and File=422 Name Pump_STS_B2. The file mappings represent a binary file created in each of the PLC5's B421:0~4 in Booth 1, and B422:0~4 in Booth 2. The PLC5/60 is Enhanced series E model using the Ethernet side card. The IP address of the PLC5 is 3.26.5.61. I also created MG file types in each of the PLC5/60. MG420:0~19 in each processor. This was necessary to use the MSG instruction in the PLC5. I have searched the forums for examples of how to do this with no solid results. I am trying to follow the best practices of reading the data into my PLC so anyone who follows can tell where it is coming from. While the IP addresses are not closely related they should be able to communicate. I say this because all of our PC's are on the 4.2.6.XXX network on a 255.255.252.0 sub net and we have no issue communicating with the 3.26.5.61 IP address. Any help and advice would be greatly appreciated. Regards, Mike Carter

Did you ever figure out how to make this work? We are attempting to do the same thing and we are not finding a lot of information. In our case we are using a PLC5/60 Enhanced with an Ethernet side card. We want to read 100 words starting at N44:0 and ending at N44:99 and put these into a Cimplicity Point as an array. From there we want to create screen that reads the value of each word and if necessary write a "1" into the word from the Cimplicity screen. We have found some information from AB on using a MSG instruction and an MG control word. Where we are running into a wall is configuring the communication parameters of the MSG instruction. What type of transfer, where you would put the IP address of the target PC who will be receiving the data.

I believe I have found the answer to the question. The 1771-ASB manual answers it in the Question and Answers section of the manual. It is actually the first question posed. Q. What happens to my inputs and outputs when an adapter communication failure occurs? A. On a communication failure, inputs in this rack will appear in the processor input image table in the last state they were reported to be in before the failure. Outputs in this rack will either remain in their last state or be turned off, depending on the I/O chassis backplane switch setting for output last state. We must add logic to our program to monitor the status of the racks and take action to control outputs that might remain high when they are dependant on the inputs from the faulted rack. At least it is here in the forum for someone elses benefit in the future.

I have a question about what should be the expected result if a 1771 rack is faulted or loses power in a system that uses multiple 1771 racks with a Control Logix processor. We upgraded two PLC5 projects with a total of 11 1771 I/O racks into 1 Control Logix program. All of the racks communicate back to the Processor utilizing a pair of 1756 DHRIO modules in the local Control Logix rack, and 1771 ASB modules in each of the 1771 racks. We had a opportunity for failure analysis the other night. A fuse blew in one of the control panels shutting down the power to 2 racks. Obviously, all the equipment controlled by those I/O modules stopped working but an interlock relay related to that equipment that is controlled from another rack in another panel stayed energized because the logic in the program never went false. Why? The input and output states in the processor memory stayed in their last state when the rack faulted. Bit 00 in the chassis input status word was set to 1 (indicating a rack fault), but all of the data values stayed in their last state. After we recovered we duplicated the failure during the off shifts to see why. We checked the last state dip switch on the 1771 rack back plane and it was set to the position to retain the last state. We changed that dip switch so that the last state would not be held. Then we duplicated the failure. Looking at the controller tags we found that all of the input and output bits still maintained their last state value. Is this what should happen? It should be noted that once power is returned to the rack all of the I/O states do turn off in logic but during the power failure all of the logical inputs and outputs are still on. Within the program it knows nothing of the failure. At this point we are not monitoring the status of the rack but it would be easy enough to add logic that examines the status of the rack and take action if it is faulted. I just wonder if what we are seeing is normal. If the last state bit is set to off in this situation should the I/O table go to 0's when the rack faults or loses power? If anyone has any experience with this I would greatly appreciate their comments. Fortunately this incident did not result in an unsafe condition but I can see how it could in another application.

We did exactly what you are asking about 2 years ago. A PLC5/15 and PLC5/25 running similar processes in an automotive paint shop. We mounted a Control Logix Rack with a 1756-L61 processor an ENBT card and a pair of DHRIO modules for the separate RIO paths. Both processors were running similar but not identical processes. I/O addresses were mapped with SYS1_* and SYS2_* as preceding characters for the tags. Heavy on the Analog I/O as well. We had 32 separate stand alone process controllers between the two original PLC5's and we brought all of the input and output signals into the PLC to take advantage of PIDE function blocks. All of the original I/O remained in place (some of it dating back to when the 5/15 was a PLC3) and we added flex I/O blocks to handle the addition analog signals. We are controlling oven temps, air house temps and humidity and some level controls for liquid filled tanks. This was all done with version 13. The only thing I would do over is the addressing of the real I/O. Our integrator aliased all of the real I/O tags and then used a COP function to new tags that retained the Octal addressing scheme. This was fine for making the addresses similar to what it was before but eliminated the ability to force an input or output in the ladder. Back tracking through the COP and alias function to get to the original controller tags is a pain. I did make it a little easier by showing my guys how to find tags that can be forced and then doing some extensive labling of the tags to show what they were in the original drawings. We were also using a Cimplicity HMI project to talk to both of the PLC5's and it was converted rather painlessly as well. We had about 2K tags in the HMI and maybe 20 screens.