Switching HMI's on controllogix

Has anyone had any problems changing HMI's on a ControlLogix (via Ethernet)? More specifically does the ControlLogix store any information about the connected HMI, if do you know where?

The wire shark I did would suggest that the ControlLogix does store the information at least somewhere, however, I can not find it. Maybe it is something as simple as resetting the controller with the new HMI connected, I have not been able to test that yet.

What are you trying to do?

Seriously, give a bit more information.
What HMI?
Are you replacing a dead HMI with a new one of the same type?
Changing from Model 123 to Model 234?
Changing out from Brand X to Brand Y?
What communication protocol is used?

---

Why would you thing that ANY information is "Stored" in a PLC about an HMI? Generally, and HMI is a device that just polls a PLC for data and writes data back directly to registers, unless you have something hideous like a Panelview on RIO.

Just answering questions at face value:

dlweber said:

Has anyone had any problems changing HMI's on a ControlLogix (via Ethernet)? More specifically does the ControlLogix store any information about the connected HMI, if do you know where?

Click to expand...

Not Normally. The rare occurrence would be that the programmer declared a Panelview in the I/O configuration (I've only done this four times that I can recall). If the HMI is no longer detected, an I/O warning or fault will be present and the I/O LED on the face of the PLC will be blinking. To get more information, you'll need to connect to the PLC and see. (Unless the programmer used a GSV instruction in the logic to detect this condition and a program fault was generated when the HMI is disconnected.)

dlweber said:

The wire shark I did would suggest that the ControlLogix does store the information at least somewhere, however, I can not find it. Maybe it is something as simple as resetting the controller with the new HMI connected, I have not been able to test that yet.

Click to expand...

If the HMI was declared in the I/O configuration, as soon as the PLC detects the HMI AND the connection is healthy (I/O assemblies match, etc, etc), the I/O warning-fault will clear (provided there were no other faults).

Again, in 99.9% of the applications I've seen/programmed, the HMI is not a device that the PLC needs to know is attached and if the PLC is NOT declared in the I/O configuration, the PLC doesn't "know" about it and doesn't care if its present or not. THe HMI initiates all communication with the PLC, and the PLC just responds. The HMI IP address could change and as long as it "sees" the PLC, the HMI works fine.

Thanks jst, will provide specifics later in this reply but what I wanted first was a generalization (what you gave). I have been fighting this stupid HMI not connecting for awhile so I thought if I could get a general answer first it might contain something that gets forgotten when people focus on specifics first.

The PLC does not fault regardless of which or any HMI is connected.

I have looked through the I/O and communication setup and cannot find anything.

The current HMI is a Red Lion G3, the one I am trying to get to work is an EZ3.

The only reason I bring up something stored in the PLC about the HMI is when I had the EZ3 hooked into the system (the G3 was not hooked in at the time) the PLC called out where is Red Lion with the RL's MAC address. The most communication I have had between the EZ3 and the PLC was a handful of tags (less than 10% of tags) updated values once on the HMI. I agree jst most of the time it is just a quick swap in panels the is the first time (well second I ran into the panelview/rio combination, to boot the rio program is written poorly the machine doesn't have many years left so we are just leaving that one alone) I have had an issue swapping panels out for an EZTouch panel. However this is also the first one I have done in Ethernet (but I am familiar with the workings of Ethernet).

The MAC IDs associated with IP addresses are stored way down at the Layer 2 level of switches and embedded IP stacks. There are simply no protocols implemented in ControlLogix that would remember the MAC ID of a network device after a power cycle.

Do you maybe have a managed switch that has per-port DHCP configured ?

One thing I've done in the past with unscheduled HMIs is to write a repeating MSG instruction in the controller that "pings" the HMI by sending it a "List Identity" service request periodically. If it doesn't respond, I know the HMI is offline and can take programmed action.

But again that's an ordinary IP address as the target. Unless your Ethernet module hasn't been through a power cycle, there should be nothing that associates the IP with a MAC ID.

So power cycling should clear the PLC's knowledge of what HMI it is connected to? I haven't had the chance to do that yet because I have to kill the whole cabinet. It looks like the machine is almost done with its current job, so I might have an opportunity to drop it sometime this afternoon.

Aside from when the HMI is included in the I/O tree (like jstolaruk says):

Some info is created/stored in the ControlLogix when an HMI is connected. Also, I am fairly certain that information is trashed some time after the HMI is disconnected; certainly less than 2 minutes if I remember correctly.
It is definitely gone after a controller power cycle.

If you power cycle the controller and still see Wireshark packets talking to the old Red Lion, then it is something different.

I am hoping to cycle the controller and have it work, today I might get a chance

Power cycle fix it, when going from the RL to the EZ3 need to cycle power switching from the EZ3 to the RL do not need to cycle power odd but hey it is atleast communicating.

The next thing is dealing with aliases, apparently EZTouch does not support them, I have a program made where I modified the .csv file to make the aliases appear to the panel as tags, but don't know if that will work, have to save that for another day. Worst case scenario create a subroutine that maps all the aliases to tags, that will be a pain.