What does it mean when a TS16 is non-responsive with the following lights:
PWR green
LI green
10/100 green
ACT green, regular fast blink, 2-3 times/sec at a guess.
COLL off
Is this an error code or diagnostic code? If so, what is it, and where are they described?
Thanks!
Page 110 of the Digi One and PortServer TS Family User’s Guide describes the LEDs: http://ftp1.digi.com/support/documentation/90000583_L.pdf
That said, it does seem like your ACT is blinking rather quickly. Could you please describe any issues that you may be having?
Thank you for the prompt reply. I had seen that, but hoped there was more information available. So there is no diagnostic information or codes that are conveyed via the lights?
This is an issue we have been working for several months with several TS16’s. Unit will be working fine and then will drop offline (ethernet side) No pings. Either immediately or within a few seconds after that the port we have set up as a serial console quits responding. Only solution is to power cycle the unit. Firmware on all units is the 12/2009. We’ve mixed and matched units and purchased new ones. We are now trying to home in on the datafeed that apparently triggers the failure in some manner.
Understand that after failure, the ACT light blink is a steady blinking, not an ‘activity’ blinking. Perhaps that wasn’t clear.
Also, we have a total of 10 TS16’s in service at this location, and more at another location. They all work fine, and have done so since installation last year. There is only the one service that causes this failure, no matter which physical box is placed in this service, and if a box is taken out of this service after failure and put into another service, it works fine in that other service.
There are ten DIGI TS16’s in service as serial-to-IP converters used to convert serial DNP3 data from field Remote Terminal Units (RTU).
A partner utility has a similar number in service. These were all initially set up, configured, installed and commissioned last year by our SCADA vendor. All are similarly configured.
This DNP data is ‘raw’ RS232 data, and has no control codes or other ‘telnet’ behavior embedded in it.
After commissioning, all TS16’s worked perfectly with the exception of one TS16 ‘slot’. In this case, the TS16 will be working fine and then will drop offline (ethernet side).
No ping replies. Either immediately or within a few seconds after that the port we have set up as a serial console quits responding. The only resolution is to power cycle the unit.
No patterns have been detected, no timing is apparent.
We have done the following:
None of the above has made any difference. No matter which physical box is placed into this service it eventually fails. If a box is taken out of this service after failure
and put into another service, it works fine in that other service.
mlnpscda - regarding this old thread, we are currently experiencing the same issue. Our environment is very similar to what you are describing. Using TS-16’s to convert from IP to serial. We have a mix of Telegyr and DNP protocols on different ports. Everything worked fine for 5 years when the serial side was connected to Bell 202 modems. Upgrades for redundancy move the connection over to a serial port on a cisco device that is not using hardware handshaking. Now we experience lockups nearly daily. The only solution is to power cycle the digi.
Initially when the problem started the digi would stop accepting new tcp sessions, but channels that maintained their session would remain working and the device could be pinged.
Since then we have upgraded to the newest POST and Firmware. Lockups continue, but now the device will not respond to a ping when it is locked up.
The activity light on the locked up device does not appear to be behaving any differently than the light on a properly working device.
Did you ever find a solution to the problem you described in your post from August 19 2010?
Short version:
No we never did get it resolved; in fact it got worse as about half our Digi TS16’s started behaving the same way. Our final resolution was to remove the Digi TS16’s and replace them with Moxa Nport 5610’s.
Longer version:
Our integration vendor spent a lot of man-hours trying to resolve this as they had other clients experiencing the same issue; they ended up eating a lot of their costs on the changeout.
There are actually 2 possible resolutions that we discused.
The best, of course, is total changeout with the Moxas (or box of your choice; I will say our Moxas have been flawless for over two years now). If I had it to do again, I’d probably have a close look at the Moxa CN2610 because it comes with a dual redundant ethernet ports for LAN redundancy, or the Nport 6610 because it can be configured with dual redundant fiber (or ethernet) and supports ssh. The 6610 does take forever to reboot though.
Option 2 is to just install a ‘pingswitch’. That is like an intelligent ‘plugstrip’ that you plug the power cord of the Digi TS16 into. It pings the Digi TS16, and when the pings aren’t returned (configurable) it automatically power cycles the Digi. There are several vendors that makes these; we have the ones from WTI. Others are IT Watchdog and Sentry Power Systems.
Good luck!