Do G4EB2's have a hardware timeout?

[dvereb]

Short Version: Will the G4EB2 eventually shut off if it doesn’t receive new data?

Details:

We have a G4EB2 board that seems to be shutting off after a while. It’s part of a five board setup (a 10/100/1000 switch that has a daisy chain with three G4EB2s and an additional daisy chain with two G4EB2s). It’s part of the second daisy chain that only has two boards, and it is the second board that’s eventually shutting off.

I’m being told the lights on the G4EB2 are off, yet it’s still receiving five volts DC. I still need to confirm that their meter has decimals, as I know the B4 boards used to be a bit touchy if you got too far away from 5.0, and if they’re reading 4.6 or 5.4 as “5” due to rounding this could easily be the culprit.

I have C++ code that uses the dev kit code to access the five boards over and over (somewhere around 100 times per second) where I write all of the outputs (even if they’re the same) and read all the inputs. In my opinion this would be considered continuous activity, so even if there was an inactivity timeout it shouldn’t ever occur. The only reason I question it is this board doesn’t often receive different data. Some days it could be writing & reading the exact same values all day long.

It eventually times out with a -2 SIOMM_TIME_OUT, and I start to receive errno 113, which I believe is No route to host. I’m unable to ping it at this point. The only way to get it back is to disconnect & reconnect the brain board (power cycling it, essentially).

Sorry for the huge chunk of text, but I didn’t want to leave out any details that might assist in troubleshooting my issue. Thanks in advance to anyone who can assist!

[Beno]

Hi David. Welcome to the Opto forums!

Short answer. No.

Longer answer.
The G4EB2 is based on our SNAP-EB. They share similar CPU, network etc. They have been around for a very long time and used by zillions of customers without issues like this.

There is a watchdog timeout, but I bet you don’t have the check box turned on…

Not only, but also, even if you did, just writing the same information is enough to reset that watchdog. It does not look for what information, just traffic addressed to itself.

Bottom line. You are on the right track with the voltage.
I bet the G4REG is on its way out. Hopefully you have a new spare you can swap it out with. If you need to buy one, get two. You want to have a spare power supply for those racks since you have a few of them.

In closing… 100 times a second? Daisy chain? Yikes!

[dvereb]

Thank you so much for the quick response! We use O22SnapIoMemMap::SetPtWatchdog() to manually set a watchdog for every single I/O position on each board. I have no experience with any of the GUI tools Opto22 provides, aside from configuring an IP for the board. It’s all done from our C++ code.

In any event, that’s exactly what I suspected: the constant communication would keep the board alive & running. Even if the communications stopped, it’s not like the board would lose all of its LED indicators. They’d still be blinking with the other board’s traffic routing through the two port switches or the STAT LED would still be on, right?

The way our boards are set up we have never used the G4REG. We have a separate 5V power supply that has done well enough over the years, but then again I’m no electrical engineer! We use the PB32HQ with the G4EB2, eight quad-packs (usually 4 input & 4 output) and nothing more. I’ll get with the electrical guys here and bring up the G4REG to see what they say. If they insist the power is fine, I’ll get back to you, otherwise perhaps that’s the way to go.

Oh, and I feel I should mention that this network goes through a completely separate switch to a second, dedicated gigabit NIC, so I assure you the network conditions aren’t as bad as you’d expect. We did take a performance hit compared to the old ribbon connections, but, aside from a few misconfigured water counters that were going way too fast, it’s still fast enough for our needs. The benefits of using Ethernet cables far outweigh the detriments of the ribbon cables.

Thanks again!