1734 point IO flashing red network and point bus lights

[patjdixon]

About every 5 minutes we are seeing both network and point bus status lights on our 1734-AENTR blink red simultaneously for about 30 seconds, then return back to solid green. When this happens, it looks like we get yellow warning on the devices in Logix. Is this normal? If not, what could be the cause?

 

[Ken Roach]

No, that is not normal !

The first thing I would do is write a little code to monitor the StatusBits in the POINT connection; when all 32 are true (DINT value = -1) then the connection is broken. That will help you figure out if it's exactly 5 minutes, or more or less 5 minutes, or maybe if there's a time-related clue.

Power down the POINT adapter and try to PING its address... if something else answers there's an address conflict. That shouldn't be the case (the NS LED would be solid red) but it can't hurt to check.

Examine the embedded web pages in the 1734-AENT, in particular to see if the Uptime timer keeps increasing or if it resets, which indicates a reboot or power cycle.

Spend some time thinking about any heavy DC loads that share the same power supply as the 1734-AENT, which might be dropping the voltage and forcing a reboot.

 

[patjdixon]

Looks like we have some mac transmit errors

The ethernet statistics show mac transmit errors (see images)

 

[0151paul]

If the there is no address conflict on the network, I have normally seen the sort of issue caused by EMC interference. Do you have a lot of VFD's on the system?

1. Check the grounding in the panel and segregation of the network cables
2. Check the shielding of the network cabling

 

[patjdixon]

DHCP required for 1734 rev C?

It can't be anything related to power or EMF because the plant has not started up yet, nothing energized except digital devices.

Got got into 2 of the 1734 that seem to be working and confirm DHCP is enabled with 999 switches, but they are rev C. Documentation 1734-UM018F-EN-E - May 2023 page 35 says "The 1734-AENT/C adapter should be configured using only DHCP." Attached are photos of one of the devices. We think there is another device causing us problems and we will try to get the same photos for it.

Should rev C always use DHCP? Is this a problem?

 

[Ken Roach]

Since this is a startup, the problem is very probably in the cabling and terminations. Do you have any cable testing hardware available ?

That comment in the installation manual about the Series C module "using only DHCP" means that it doesn't support the ancient BOOTP protocol, rather than that it doesn't support the nonvolatile TCP/IP object or physical dial methods of setting the IP address.

 

[James Mcquade]

we have had this happen with our systems.
AENT was configured with 6 i/o modules.
1 time it was the module, another time it was the terminal block, and then the last time, it was both.
are the terminal bases locked together, misaligned, modules seated properly?
be careful with the safety i/o blocks, they cannot be switched and placed in different slots.
james

 

[patjdixon]

Did you mean that for ver C BOOTP does work, thumbwheel and DHCP don't work? Since the thumbwheel is set to 999 and DHCP is not enable, I assume you mean that you can use BOOTP on rev C?

 

[Ken Roach]

No, the other way around.

The 1734-AENTR Series C supports DHCP, NVRAM-set Static IP, and rotary-dial 192.168.1.x configuration methods for the IP address.

It does not (according to the documentation) support BOOTP.

Virtually all devices built in the past 20 years that support both BOOTP and DHCP try DHCP first.

 

[robertmee]

Since it's an AENTR, is it part of a ring network? If you have a complete ring and no supervisor configured, you will get random drops like this from any device on the ring. Also, 1734-AENTRs are very sensitive to heat. If in a hot environment that can cause this behavior.

 

[patjdixon]

Looks like hardware

We looked at the configuration of every 1734, they all match 100 mbps full duplex, same as the ethernet adapter in the processor rack. Therefore, it doesn't look like there are any mismatches. Looking a lot more like it is installation/cabling/hardware.

 

[alan_505]

If you have more than one AENTR can you swap the one you are having a problem with, with a known good one to prove it is the AENTR or the cabling?

 

[patjdixon]

Partial success

We now are able to connect to all remote Io cabinets, but there is still a problem.

The culprit we identified yesterday was a cabinet with a Stratix, Prosoft, and 1769 AENTR. It was cabled incorrectly, the IP address on the 1769 was wrong, and the Stratix was not configured correctly. That enabled us to get all cabinets talking on the network.

However, the last cabinet on one end of the ring has a problem when we connect it back to the main processor. When we connect, we have communication problems to all cabinets on the network. By leaving it disconnected on the end that return to the processor, we have everything working but of course that kills the benefit of having a ring.

I am leaving site and new people are coming in, so I don't know if you will see a conclusion here. If I hear anything I will post it.

Thank you everyone for your helpful contributions.

 

[robertmee]

We now are able to connect to all remote Io cabinets, but there is still a problem.

The culprit we identified yesterday was a cabinet with a Stratix, Prosoft, and 1769 AENTR. It was cabled incorrectly, the IP address on the 1769 was wrong, and the Stratix was not configured correctly. That enabled us to get all cabinets talking on the network.

However, the last cabinet on one end of the ring has a problem when we connect it back to the main processor. When we connect, we have communication problems to all cabinets on the network. By leaving it disconnected on the end that return to the processor, we have everything working but of course that kills the benefit of having a ring.

I am leaving site and new people are coming in, so I don't know if you will see a conclusion here. If I hear anything I will post it.

Thank you everyone for your helpful contributions.

You don't have a ring supervisor configured. That's what is causing all the nodes to drop when physically completing the ring. Go to the network tab of your ENxTR module and enable supervisor.