trouble with tcp read write

[hervend]

Hello everybody,

I'm currently developing an LabVIEW RT application which consists in acquiring voltage and current waveforms, performing signal processing algorithms and derive some relevant quantities. Since this system is intended to record whatever happens on the grid, it has been developped using an RT Target and LabVIEW RT.

The different components of this systems are as follows:

- PXIe8133 controller

- PXIe-6366 for multichannels simultaneous data acquisition (up to 2 MS/s)

- PXI  -6682H for GPS synchronization,

- PXIe-6674T for timing

- ...

I have implemented a LabVIEW program for data acquisition by PXIe-6366 (RT Data Target Acquisition.vi) and display of the acquired data on the host computer (Communication with RT Target.vi).

RT Target Data Acquisition .vi performs three parallel tasks:

  - waveforms acquisition in a timed loop of the highest priority,

  - transmission of the acquired waveforms across the network owing to TCP communication VIs,

  - look for messages sent by the host computer

Communication with RT Target.vi performs two parallel tasks:

  - set the expected signal frequency from its front panel to the network so that the RT Target can use this frequency to perform the sampling of the input signals,

  - get the acquired waveforms through the network and display them on a graph (before performing signal processing algorithms and so on, not implemented yet).

The problem encountered here lays in TCP data transfer. The waveforms are correctly acquired in the timed loop of the highest priority but only the first set of data is correctly sent through the network. after this transfer, the TCP write message VI waits indefinitely for what?, I don't know and generates the error 56 code. The same process occurs again and again even when I increase the timeout value. And I cannot find out the reason of this behaviour. May be if one could execute the code (RT Target Data Acquisition.vi and Communication with RT Target.vi)  he/she will better understand what I'm talking about.

I'm urgently requiring some assistance since I couldn't find out for some days what is wrong with my diagram.

[GregFreeman]

Edit: disregard all I said below. I found where you handle errors. I will keep looking.

I have noticed TCP will have trouble writing if you don't have a reader. I don't see any errors being cleared anywhere in your read (top) loop on the host. Are you sure you aren't getting an error there (other than a timeout)? That would prevent any future reads being done because you would be holding the error in the shift register. That could cause the RT to do weird things on the write. Sorry if I'm off base and missed this if it actually is being handled. Judging by your code, which is very clean, I'm assuming you may have checked for errors on the host already, so I'm not so sure this will help. I'll dig through it a bit more.

[GregFreeman]

accidentally posted twice.

[hervend]

Hello for (imstuck),

Thank you for your proposition. You're right, I hadn't planned, up to now to clear errors in the read loop on the host. Some errors may come from that loop, but the one I have noticed comes from the "Target -> Host message sender" loop in "RT Data Acquisition.vi" and more specifically from "Host-RT_Write Acq Data.vi" which is the VI intended to send a message (after its length has firstly been determined) either from host to RT target, or in the opposite direction. The first call in the "Target -> Host message sender" loop of this VI executes without any problem reported. But the problem seems to arise at the second call although the data to be written through Ethernet to host are available in the relevant queue.

I keep looking to check what's going on. But sometimes we do need an outside view to identify where the mistake has been committed.

[Texas_Diaz]

I would like to toss in one additional piece of helpful information.

In your "RT Target Data Acquisition.vi" VI, you read data from an RT FIFO within a TIMED LOOP (named NDL), and then you perform two TCP Send operations based on whether or not there was data in that RT FIFO.  You should NEVER perform TCP operations (read or write) from within a TIMED LOOP - the issue is that the TIMED LOOP runs at a level that is higher than anything else in the system, including network traffic processing, memory allocation, and others.  All a TCP Write operation will do within a TIMED LOOP is queue TCP data to be processed in a given socket.  There's only so much memory allocated for TCP processing (it gets allocated within "pools") and if you run out of memory within the pool then we may not be able to allocate more memory for the operation within that TIMED LOOP structure.  This could lead to serious problems down the line of anything were to "hiccup" on the network.  That TIMED LOOP should be a WHILE LOOP - the RT FIFO is meant to shuttle data acquired within a TIMED LOOP to a WHILE loop (or some other loop not running at such a high level as a TIMED LOOP).  I understand that you think you want to control how often you check for data or transmit data from the target to the host, but this is not the way to do it - you'll likely be stymied by protocol "wonderfulness" like the TCP Nagle Algorithm or others anyway.  Plus both TIMED LOOPs are being told to run on a 1 MHz clock - I bet dollars to donuts you're always running late, you can't do DAQ in 1us; all you're doing is causing a scheduling nightmare within your system and unnecessarily sucking every resource dry.

-Danny