We swapped the 1756 EN2T on the number two filler on Friday, the old one had been running warm and dropping the odd connection. Since then the whole rack under it goes to (16#0204) Connection Request Error for about ten seconds, three or four times a shift, and then it all comes back on its own like nothing happened. I'm not sure whether I'm looking at a module or at the network.
Swapped the patch lead first, no change. Moved it to a different port on the panel switch, no change either. Read a couple of threads that said open the RPI up a bit so I put the rack from 20ms to 50ms, made no odds at all. Has anyone seen a 0204 that comes and goes on a pattern like that, or am I chasing the wrong module entirely?
Switch model first, and is the filler on its own switch or does it uplink to a core?
When you say three or four times a shift, is it actually random, or does it land on something. A washdown, a big motor starting, somebody plugging a laptop in.
And does the EN2T itself go with the rack in RSWho, or do you keep the adapter and lose only the modules under it?
Stratix 5700, the eight port one, uplinked to the core in the MCC room. One VLAN for the lot of it.
I went back over the times against the shift log and it isn't random. It's every CIP clean. Three cleans a shift on the filler bowl and the drops sit right on top of them, within a minute.
The EN2T goes with it. Red X in RSLinx for the ten seconds then it comes back green. No luck in the switch log either, it doesn't even log a port going down.
A clean means the utilities panel wakes up. What is in that panel?
Before you go chasing panels I'd put a mirror on the EN2T port and watch what the link actually does when the clean starts. Ten seconds that heals itself is also what you get from a broadcast burst with the connection timeout multiplier left at 4, and a Stratix will not log that as anything.
If I remember right the multiplier is on the Connection tab of the module properties, not the port config. Worth knowing whether the wire is busy before you go pulling things out of cabinets.
Mirrored the port and sat through the 06:00 clean with Wireshark running. No storm. The link is quiet right up to the second the modules go, so that one's a dead end.
What I did catch is our EN2T's MAC vanishing out of the switch table for a second and coming back on a different port, and that port is the one feeding the utilities panel. So I went and had a look in there. There's a 1756-EN2T sitting in that panel that was not in it a week ago.
That is your duplicate then. Whoever built the CIP skid went to the crib for a spare and took the module you pulled off the filler on Friday, and it still has the filler's address in it.
It only joins the network when the skid has power, so you get ten seconds while the two of them argue and nothing at all in between. The switch moves the MAC entry to whichever one spoke last, which is exactly what you watched it do.
Take it out, set it on the bench to an address nobody else owns, then switch BOOTP off with the row selected so it keeps it. The tool and the order it wants are written up here: https://plctr.com/bootp-dhcp-ethernet-ip-tool/
That was the whole of it. The module I pulled off the filler on Friday went back in the crib, and the night fitter took it straight back out the same evening for the CIP skid. It was still holding 192.168.4.22, which is the filler adapter's address.
Bench, BOOTP tool, gave the skid one 192.168.4.58, disabled BOOTP so it sticks, put it back. Four shifts and not one 0204 since.
What I still don't follow is why neither of them ever shut its own port. I was pretty sure duplicate detection latched the module out until you power cycled it, and neither of ours did. Thanks hkraus, and petek for asking what it lined up with, that was the question that cracked it.
Glad it wasn't the wire. Every spare on our shelf has its last address taped to it now.