Read Data (ASCII) and send to analog output

[sbruetsc]

Hello

I have the following MAX configuration:

• Analog input task, continous, 2 samples, rate 100Hz (PCI-6024E)
• Analog output task, continous, 64 samples, rate 100Hz (PCI-6723)

The cards are synchronized by the RTSI bus.

With Dasylab I display signals from load cells by the input task. A "Read Data" module sends values to the output task. The "Read Data" module has the following settings: Output in realtime, synchronisation with analog input task, file is an ASCII, block size 4 values, no ascii time channel.

Additional settings for DAQmx are done by DasyLab:

• Analog input: Driver buffer 30
• Analog output: Driver buffer 30, output start after 2

When I start DasyLab I get a DAQmx failure (after a couple hours): DAQmxReadAnalogF64, Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

Could anyone please explain, how to configure analog input/output task and the DasyLab settings (Read Data)? - Attached the DasyLab diagram.

Additional information: The application should read and display signals from a test bench (load cells). The output shall feed external controllers. The input and output signals shall be displayed on the same chart (as realtime as possible).

Thank you

Regards Samuel

[CJ_Butler__DASYLab_Pro]

I suspect that the analog input settings

• Analog input task, continous, 2 samples, rate 100Hz (PCI-6024E)

are not optimal.

DASYLab works best when the block size (samples to read) is at least 100ms of data.  We recommend a block size/sample rate ratio of 1:10 to 1:2.

The default is a block size that is one half the sample rate, rounded to a power of two.

With a sample rate of 100 s/sec, and a block size of 2, you are at a ratio of 1:50, which is overburdening DASYLab and causing it to not be able to keep up with the analog input.

Try increasing your samples to at least 10.

[sbruetsc]

Thanks for the prompt reply! - I have changed the settings to the following:

• Analog input task, continous, 16 samples, rate 100Hz, driver buffer 32
• Analog output task, continous, 16 samples, rate 100Hz, driver buffer 32, output start after 32
• In the "Data read" module the block size is now 16 at 100Hz

With this setting, DasyLab runs, but only for around 12 hours.

The following error occurs:

"Read date module name" / The data flow is blocked by one of the following modules.

Followed by:

Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

Is there something else I have to care? Could it be problematic to send signals from different modules to the same Chart Recorder module? I use DasyLab version 11.

Samuel

[CJ_Butler__DASYLab_Pro]

So now you go from overrun on the Analog input to underrun on the Analog output.

The Chart Recorders are fine... they handle dissimiliar data with no problem. 

The problem is the Read -> AO.

Try running again, this time with the View menu/Animation - Fifo filling status checked.

Watch the output of the Read module and see if it fills up with red, and how quickly.  That's the data flow is blocked message.

Try twiddling the AO settings -- run a bit slower? 

[sbruetsc]

Ok, thank you. I have checked the FIFO state. The red bar has around a speed of 19 times each 60 seconds.

Attached the FIFO parameters of the module Data read, channel 2. Do you see any abnormality?

I'm going to run DasyLab over night, to see if the problem appears again, this with AO rate of 80Hz instead 100Hz.

I have also deleted the corresponding layout. Do you think it could have any influence?

Regards Samuel

[CJ_Butler__DASYLab_Pro]

The fifo state looks good... you're looking at the big green block, not the smaller one. It will fill up with red when the AO stops responding ... so, watch for that. 

[sbruetsc]

The FIFO states, those who are connected with the AO module, are red when the error occurs (runs for around nine hours).

Is there anything else I could change?

Thank you

[CJ_Butler__DASYLab_Pro]

That indicates that there is some mismatch between the AO task and the modules that are feeding it. 

In this case, the AO module cannot process data as fast as it's getting it, and eventually the internal dasylab buffer (the fifo) for the wire is filled up. Then it stops giving data to the AO, which sees an underrun. 

[sbruetsc]

I have tried many different parameter configurations, but DasyLab stops in each case after a while.

Right now, I experiment in a different way:

• Analog input task, continous, 10 samples, rate 100Hz, driver buffer 30, -> RTSI Slave
• Analog output task, continous, 10 samples, rate 100Hz, driver buffer 30, output start after 30, -> RTSI Master
• In the "Data read" module synchronized by Sound card Driver (100Hz, 10 samples)

I'm sure this is not a professional solution. Also because "Data read" and AO have a different time base. Sadly it cannot be synchronized. However it still runs (17 hours).

Do you have an idea, how to output the ascii data to the AO using a complete different method?

Thanks a lot

Regards Samuel

[CJ_Butler__DASYLab_Pro]

Now we start to question if something is happening on your computer that is taking CPU time away from DASYLab and the NI drivers.

Turn off power management (I'm sure you did this already to run 17 hours). The monitor can sleep, but nothing else can.

Turn off Windows Updates. Turn off the on-access virusscan software. Check your Windows Task Scheduler to see if other tasks run (all sorts of programs have scheduled updates). 

One customer had success with increasing the priority of the DASYLab task in the task manager.