ASCII closes COM port randomly during long periods of unsolicited response monitoring

[erblock]

I have lots of serial ASCII objects monitoring for unsolicited responses (every two seconds, from 20 different COM ports).  Randomly, sometimes a few times a day, sometimes no problem for 2-3 days....but the ASCII object somehow lets the COM ports close or it loses contact with the COM port occasionally.  All I have to do is go into edit mode and "touch" the properties....such as changing the "Retry Attempts" setting and the communication returns.

There are no alarms logged when this happens!

Ed

[erblock]

Actually, just opening the ASCII properties and closing without touching any settings can awake the objects "filter" for unsolicited response processing!

[Ryan.S]

Could you give me an email address to access you directly?

I see the unsolicited data can't be logged currently. I'm fixing it.

[erblock]

"My username" at "mit" dot "edu"

Please look also at the IPASCII object also, in case it has the same issue.....Thanks!

Ed

Message Edited by erblock on 03-02-2008 09:54 PM

[jrcamenzind]

Ryan,

I also have quite a number of ASCII objects and have the same problem described.  I use hypertrends to plot the unsolicited responses from the ASCII objects.  Its easy to see when the object fails because the hypertrend data just stops showing up.  The offending ASCII object can be reset by selecting the properties box and just waiting (maybe minutes) for it to get clear of the hour-glass.  Then it works again. 

Is there a solution or work around for this problem? I use v6.0.2 

Thanks,

Joe C.

[Ryan.S]

How many ASCII object do you have? They monitor the different ports, right?

How frequently does the ASCII object receive the unsolicited data?

Besides the unsolicited data, do they also send out data?

I will try to reproduce it.

[jrcamenzind]

Ryan,

I currently use 6 Ascii objects from 6 ports and plan to use 2 more.  Unsolicited data arrives every two minutes (as measured by the sending end).  I have a button on the panel for each object that I can press to send a request to the sending end.  Each of the senders connects to a digi portserver II and is delivered to lookout via an ethernet connection (as a virtual com port).  The ethernet connection is routed over various paths including micowave, which could have an occasional traffic interupting fade. One or more of the Ascii objects may fail to respond at any time, but several days may pass without a problem.  When a failure is noticed, you can usually select the properties for that object and the problem clears.  If instead, you send a request to any of the other Ascii objects , Lookout may just hang (permanet hour glass).   When a failure is noticed, if Lookout is then turned off and the offending port is monitored with hyperterminal, the data from the sending port is on time and correctly formatted.  The help file has a section "Ascii alarm and error messages" with a section named "Early temination when parsing the response frame".  There are a bunch of reasons listed there as to why the Ascii object might not function properly.  I've tried everything that I can think of to make this work reliably.  Any ideas?  See the link for response format information. http://jrcamenzind.googlepages.com/lookout