ryangriggs
Lifetime Supporting Member
Hi everyone, it's a cold and rainy/snowy day in Kentucky!
I ran into this problem and can't figure out why it happened, or what's the best way to fix.
System configuration:
- SLC5/05 and Micrologix PLCs
- Ethernet and serial port comms
- Ethernet dataradios for remote telemetry
I have been working on some pump station telemetry issues all day, using a single laptop with RSLogix 500 Starter to modify programs and download them to various PLCs at different sites.
Then I went to the main plant to download a final update to the MTU, I got a notice in RSLogix 500 that the Processor Node number was different between the loaded program and the PLC. It wanted me to confirm or cancel. I cancelled because I was sure the node number had previously been 48d, but now it was being reported as 0d.
Sure enough, looking in the Controller Properties of the project, it shows the Processor Node ID as 48d. So I opened a new RSLogix project and uploaded the entire running program from the PLC. In this copy, the Controller Properties shows the Processor Node ID as 0d.
Screenshot of the two projects side by side: http://is.am/y9sm
Left-hand project is an upload directly from the PLC. Right-hand side is the saved project that I was trying to download.
Here's a screenshot of the dropdown box in Controller Properties showing the Last Configured selections: http://is.am/y9sp
Also when browsing with Who Active, clicking on the processor it shows the node ID as 0d. Screenshot: http://is.am/y9sn
I had downloaded several changes to this PLC earlier in the day with no issues.
Why would the Node ID change? And how can I change the PLC's node ID back to the 48d value that it was before? Does it even matter? Should I just download the project anyway, or will it break something?
I checked the programs for all the other PLCs in the network, and none of them refer to Node 48d in their MSG commands. They all use IP communications except for one unit that communicates to the serial port of this MTU, and its target device is Node 1, and its comms are still working.
Thanks for any advice!
I ran into this problem and can't figure out why it happened, or what's the best way to fix.
System configuration:
- SLC5/05 and Micrologix PLCs
- Ethernet and serial port comms
- Ethernet dataradios for remote telemetry
I have been working on some pump station telemetry issues all day, using a single laptop with RSLogix 500 Starter to modify programs and download them to various PLCs at different sites.
Then I went to the main plant to download a final update to the MTU, I got a notice in RSLogix 500 that the Processor Node number was different between the loaded program and the PLC. It wanted me to confirm or cancel. I cancelled because I was sure the node number had previously been 48d, but now it was being reported as 0d.
Sure enough, looking in the Controller Properties of the project, it shows the Processor Node ID as 48d. So I opened a new RSLogix project and uploaded the entire running program from the PLC. In this copy, the Controller Properties shows the Processor Node ID as 0d.
Screenshot of the two projects side by side: http://is.am/y9sm
Left-hand project is an upload directly from the PLC. Right-hand side is the saved project that I was trying to download.
Here's a screenshot of the dropdown box in Controller Properties showing the Last Configured selections: http://is.am/y9sp
Also when browsing with Who Active, clicking on the processor it shows the node ID as 0d. Screenshot: http://is.am/y9sn
I had downloaded several changes to this PLC earlier in the day with no issues.
Why would the Node ID change? And how can I change the PLC's node ID back to the 48d value that it was before? Does it even matter? Should I just download the project anyway, or will it break something?
I checked the programs for all the other PLCs in the network, and none of them refer to Node 48d in their MSG commands. They all use IP communications except for one unit that communicates to the serial port of this MTU, and its target device is Node 1, and its comms are still working.
Thanks for any advice!
Last edited: