problem with data socket server

[BEHajder]

We have developed a program (from LabVIEW 6.1 running on Windows NT) consisting of a main executable and four other executables dedicated to collecting various i/o information. The four i/o executables convert raw data into process data and pass it on to the main executable using Data Sockets. The data is assembled as a cluster, then flattened into a string, which is published to a data socket variable. The data cluster contains a time stamp used by the main executable to verify i/o is being updated periodically (at least once a second). The main executable generates an alarm if the timestamp gets to be more than 5 to 15 seconds old, depending on the expected data. Typically, this alarm never happens, unless an i/o device is powered down o
r disconnected, or an executable or Data Socket Server is terminated.

The problem we are is experiencing is that false alarms are being generated, at precise intervals of exactly 5 days, 18 hours, 1 minute, and 1 second. The alarm condition occurs then clears immediately. The only thing I can think of is the data socket is somehow "cleared" for some reason at this interval, causing the main executable to momentarily read a time stamp of zero, and generate an alarm. Is there anything that might be corrupting the data sockets at a long interval like this? The worst thing is that the alarm horn gets falsely triggered, so we are trying to resolve this but can not see anything in any of the code to cause such an occurrence.

Thanks in advance for your help.

Brian Hajder
Despatch Industries
8860 207th Street West
Lakeville, MN 55044
Phone: 952.469.8111
Fax: 952.469.4513
behajder@despatch.com

[Matt_F]

Hello Brian,

We will need a little more information to troubleshoot this issue.

Specifically:

1. You mentioned that this alarm only occurs when the timestamps are off by more than 5 to 15 seconds. What is the threshold that causes the alarm in this specific case and what are the offending timestamps' values?

2. How many messages are sent between alarms? This number will be helpful in knowing if this may be caused by the datasocket server reseting?

3. What type of network is this application running on. Is there any firewalls or routers that may be in the data pathway that are resetting or performing maintenance at constant intervals?

4. Any other information you may think is pertinent.

Regards,

Matt F

[BEHajder]

Hello Matt,

Thank you for reading & responding. I should try to summarize this specific application in a little more detail.

We have built a manufacturing tool for a customer that is controlled by a single Windows NT PC, for which we have developed 5 executables using LabView 6.1. The main executable provides the user interface. The other four executables are dedicated to control & monitoring of specific i/o devices (serial or IEEE-488). The i/o executables pass data to and receive commands from the main using data sockets. The PC is not on any type of network. The main executable supports an optional SEMI standard host link through its ethernet port, but that is not currently active or connected. A total of 13 data sockets are used, to implement si
mple "one way" traffic through any socket, making buffering unnecessary. Some data sockets (i/o data to and from main) are updated a few times a second at most, commands from the main may only be updated a few times a day.

Data from each of the i/o executables includes a time stamp indicating the last valid i/o hardware read time. The main uses this data from each i/o executable to determine whether i/o hardware is responding properly - if the timestamp gets to be anywhere from 5 to 15 seconds old (depending on which i/o is being checked), an i/o failure alarm for that device is raised.

What seems to be happening is that, periodically, precisely every 496,861 seconds, two or more of the timestamps are found to be too old; I am assuming some external event is momentarily clearing socket data & the zero value timestamps look very old, thus triggering alarms at the exact same second. The alarm conditions clear up in less than one second.

I wonder what you mean by "the datasocket
server resetting"? Is this documented anywhere?

Thanks for plowing through this wordy description, I appreciate any help you can suggest.

Brian

[Matt_F]

Hello Brian,

There are no known issues of a data socket server resetting. The question about the number of transfers before the unexpected behavior is to see if this is related to a specific number of transfers or a certain amount of time. Would it be possible to monitor the number of transfers being made?

If this appears to be time related, it would indicate that some external application in causing the issue. While not connected to a network, there may be software firewall programs or utilities running at some interval and locking network or other computing resources. Is anything else running on your system at the same ttime?

Please let me know if you have any questions.

Regards,

Matt F

[chrisger]

hello brian,

are you sure the data is passed to datasocket by your io-Apps correctly and in-time? i would try to log each writing access to datasocket from your io-apps in a file, including the timestamp. i once had troubles with the system clock and apps running for long time. i then switched to ms-ticks (but you have to catch overflow of the tickcounter).

best regards
chris