Parent/Child Modules
Hi and Welcome to the Forum!
Your first paragraph reads like you've posted an extract from an email that a disgruntled customer sent you?
Anyway...
This is the centralized controller we are looking at, I take it?
When you add a local EN2T communications module to the backplane, you are effectively adding a port for which the backplane can access that particular network. The local EN2T is the Parent over all the modules that are added under its Ethernet port. When you expand the EN2T module, you can see the Ethernet port.
For the I/O Configuration, this Ethernet port represents everything that will be added to the network, and everything that may communicate with each other on that network. This includes the local EN2T module itself. So as soon as you add an Ethernet Child module, under the Ethernet port, the local EN2T Parent module is automatically added as well, as it too will be part of this network.
Once this duplicate instance of the EN2T is added you cannot delete it. It is an integral part of the local I/O Configuration and must be present under the Ethernet port, else all other added modules cannot communicate with this local EN2T. Only if you were to delete the last remaining module from under the Ethernet port would the EN2T module instance disappear again.
Note how it has the very same name "OVENS02" as the Parent EN2T module. You cannot add two modules with the same name or you will get a Duplicate Name error. If you double-click the apparently Child EN2T module, you will see that the properties for the Parent module will open and the same IP address will be displayed. They are one and the same. Both instances are of the Parent EN2T module.
So what you are seeing is normal, except for one thing...
What does look odd, however, is where it has placed itself in the I/O Configuration tree, midway down? Normally, when you add the first Child module, the second instance of the Parent module plants itself right underneath the Ethernet port and never budges? How it could get down there, I'm not sure?
The fact that, in the I/O configuration tree, it's right at the Oven that is giving the erroneous readings could mean it's a glitch, corruption, or it could be nothing at all? The I/O tree normally lists the modules in the order they were added, rather than alphanumerically. When the first Child module is created, the Parent module's second instance, that is automatically added, sits right under the port and then the first created Child module underneath that. All other Child modules created after that are added underneath the last, and so on.
But the second instance of the Parent module should stay at the top? The order that RSLogix 5000/Logix Designer displays the I/O modules may have no bearing whatsoever on how they communicate in reality. This I/O tree representation is just a GUI, after all.
So I just cannot say with any certainty whether this is an issue or not.
An original copy of the program would be useful to compare with. Or else you could rebuild the I/O Configuration. That's not necessarily my recommendation, just yet, but something to consider if other options run dry.
Another thing, but not so important, is the naming convention...
It is a little mixed up, by the looks of things?
In my opinion, the local EN2T should not really be named "OVENS02" if it...
1. Is part of a centralized controller over a number of "OVENS"...
...and...
2. There is already an apparently correctly named 1794-AENT "OVENS02..."
Something like "OVENS_ENET" would be more suitable, perhaps? Anyway, it can be renamed if needs be, but it is not that important, just confusing to look at.
To summarize...
The fact that the second instance of the parent EN2T is present under the Ethernet port is perfectly normal.
The fact that it is not present directly underneath the Ethernet port does not look right, but whether it is a problem or not, I cannot say for sure.
The name of the EN2T may need to be addressed, if you so wish.
What I would be interested in knowing, if the above all proves irrelevant, is what erroneous readings are they getting?
What exactly is not working correctly?
Are there any error messages, particularly for communications?
Regards,
George
Attached is how the I/O Configuration would normally look (minus Flex I/O modules)...