RT: acquisition, logging and monitoring at 1 kHz

[emmemme]

Hi,

I've a cRIO-9012 and I'm trying to set up a system that:

- acquire three analog signals at 1 kHz with a NI-9205 module and a simple FPGA vi;

- if a certain control is true, log all the data in a binary file;

- when a client is ready, stream the signals while acquiring it.

I've almost done a system that performs the first two tasks: I've two parallel loops, one for the acquisition and some control routines and one for the logging. Running it from Windows, it totally works.

I've found some troubles in the third point: I've tried to add another parallel loop in order to stream the signal using a network stream.

I succeeded in making the connection, but the signal I see on the Windows pc from the network stream reader is distorted because of a too slow reading process.

Any ideas? Am I using the right tools?

Thanks.

[Julien_31]

Hello,

I think that you should post your code, or at least screenshots (RT code and Windows code), so that we can try helping you...

[emmemme]

Sorry, I was from my notebook without Labview. Here's the vi, I hope it isn't too messy.

I have three loops, the main one with acquisition and control (highest priority), the other two, one for logging, the other for streaming.

Let me know if something is not clear.

[emmemme]

Here's the Windows VI.

[Julien_31]

I cannot test anything but maybe you should send data arrays instead of scalar values.

You could try to "accumulate" 250 points and send this array so that your theoritical stream loop rate could be 4 Hz instead of 1000 Hz...

[emmemme]

That could be an idea. I've read on a NI tutorial some tricks to pass array of data in RT programming, basically using array and shift register, but I'm wondering if there is a simpler way.

Anyone has other ideas?

[Riv]

On my sbRIO I was sending 20bits data x 100 elements with 1kHz, could it be so much difference comparing to cRIO? 1kHz doesn't seem to be much. I'm just wondering.

Firstly, try to add Wait/Wait until next multiple function to the second loop. I think it can be the thing that occupies the processor too much and a reason of your problem (even if not the one). You could also add "-1" to your "timeout in ms" input of RT FIFO read function.

Does it help?

If not check few things:

1. Check "# elements" otuput from RT FIFO Read function. Does it overflow?

2. Check "Avaliable elements for Reading/Writing" and "Total elements read/written" on both sides of a network stream.

3. When you check "Number of disconnections" and "Remote EndptDistroyed" on both sides - does they every show that something happened?

Please, write about the results,

Bluesheep

EDITED:

I just edited numbers.

[emmemme]

I'm going to try, but I didn't understand a thing: to which loop I should add a wait function? Are you talking about the network stream loop right?

[Riv]

You should add a Wait function to the loop that saves data to a file.

And you could add "-1" to the RT FIFO Read function to the loop that uses network streaming.

[emmemme]

I'm pretty sure that the logging loop isn't occupying that much the cpu: I put an indicator to the iteration, and the speed of the second loop is almost the one of the first. However, I've also tried to remove the logging loop, leaving only acquisition and streaming: also in this case, the stream can't catch up with the main loop. I've also add '-1' to the rt fifo reader, but nothing.

Looking at the #elements of the fifo: yes, it overflows, it's always at 999 (the size of the FIFO is 1000).

The rest of the values:

- Available elements for writing: almost ever near 4096 (buffer size: 4096);

- Available elements for reading: always 0;

- Total elements written is equal to total elements read;

For the number of disconnection and the remote endpoint destroyed: nothing strange, the connection is OK.

I still think that the network streaming loop can't catch up with the acquisition loop in a point-to-point situation, but I don't know what can I change.