DataSocket sending shared variables error 56

[EJS]

I am having a problem with my DataSocket connection dropping out and not reconnecting.

I am using DataSockets to send data from a Compact FieldPoint controller(cFP-2220) to my host computer, an NI Touchscreen PPC 2115.  Both systems can run independently when their Ethernet connection is broken and reconnect when the connection is restored.  The data from the cFP system is periodically updated, every 200msec using a timed loop to the PPC.  Should the connection be broken, an error 56 occurs, which I mask.  I am not concerned with lost data in this direction.  After 6 weeks of flawless operation, the cFP system had some higher activity and the DataSocket sends ended and could only be restored by rebooting the cFP system.  This has occurred once again during higher activity.  I am using LabVIEW 8.5.1 and RT.  I am writing 3 shared variables, similar to the attached VI.

I am looking for some insight into a fix for this problem, a method to reconnect without rebooting.

Thanks,

Eric S.

[LaRisa_M]

Hi Eric,

Can you describe in more detail the "higher activity" that causes the DataSocket sends to end? Is there any type of error when the DS sends end, or do you just not see any data transfer anymore? When the DS sends end, is the cFP-PCC connection still in tact? Your VI is a very typical DataSocket write, so I think more information on what the system is doing before this happens will help shed some light on the problem.

[EJS]

LaRisa,

I presently have 5 simultaneous loops running: Communications/Control Loop, Deterministic Loop, Comsumer Loop, Shared Variable Write Loop, and Generate Report Loop.

The Communications/Control Loop reads commands from the PC through TCP/IP and monitors background status and periodic timers.  When an event occurs, it sends a command through the RT FIFO to the consumer loop.  This loop should not see increased activity.  It has a minimum loop time of 100 msec.

The Deterministic Loop is a high priority Timed Loop Structure with a 500 msec loop time.  It monitors and controls hardware I/O functions and updates arrays when events occur, i.e., changes of I/O states.  Upon I/O input activation, it uses more time to update records.

The Consumer Loop is a while loop with a 100msec loop time.  It handles FIFO commands generated by the Coomunications/Control Loop and the Deterministic Loop and checks time limits when I/O is activated.  Upon I/O input activation, it uses more time to handle limit detection.

The Shared Variable Write Loop is a lower priority Timed Loop Structure with a 200 msec loop time.  It writes 3 shared variables to the PC using DataSockets.  If a timeout occurs on the write, an error 56 occurs, which I mask out.  A periodic loss of data is not a problem as it will resend upon the next loop.  If communication is lost with the PC or the PC program is not running, there is no problem, as the send will work properly when both are restored.

The Generate Report Loop is the lowest priority Timed Loop with a 1000 msec update time.  Reports are generated once per day and include large .txt and .html reports that are written to nonvolatile memory on the cFP.  With higher activity, the reports become larger as more events occur.

When the DataSocket communication is lost and not restored, no other loop functions are affected.  I have a monitoring LED giving a heartbeat that shows if the system is bogged down, but it appears normal.  I am not sure exactly when the communication is lost as this has only occurred twice within the last 6 weeks, but it is critical that I fix this problem.  No functionality is lost on the PC and it can still send TCP/IP commands to the cFP program.

The only error that could occur is error 56, as any other error would stop the cFP program per my coding.

I hope this gives you the information you need to proceed.

Thanks,

 Eric S.

[LaRisa_M]

Eric,

Intermittent problems are the hardest things in the world to trouble-shoot effectively. My thought is that you may be pushing the limits of DataSocket communication when too much is going on or the data size becomes too large. But rather than trouble-shoot something so intermittent, I think you should just go for a workaround. Since TCP/IP and other communications reconnect fine without fail, I think your best option for ensuring that the Shared Variable Write Loop reconnects also is to rewrite the code to use another communication method. TCP/IP is the most reliable and can have the highest throughput, so that's my suggestion.

Good luck!