10-09-2023 09:55 AM
Greetings,
i confess that i'm new with the programming on LabVIEW. I'm currently using a cRIO-9054 and I want to use it to generate an excitation with an 9263 module and acquire the result with a9234 module by means of NI-DAQmx. I've been generating a project to log data and my final goal is to plot a FRF of such acquisition.
I have several problem that I'm going to list below:
1) So far, I'm not able to use the FRF box because it always displays the following warning
Error -20306 occurred at NI_MAPro.lvlib:Frequency Response Function (Mag-Phase) 1-1.vi:3160001
Possible reason(s):
Analysis: (Hex 0xFFFFB0AE) The two time signal waveforms contain different dt.
This warning basically says that I'm using waveform with different sample rates, which is correct. The problem here is that I'm not able to set the same sample rate on the INPUT and OUTPUT signal. For example, I have tried to set the sample rate in the DAQmx Timing on 2000 S/s but by giving a look at the effective sample rate (as reported in the pic attached), I have found out a dt slightly different from the theoretical one.
2) During my previous tests, the cRIO system has often runned into the sudden disconnection and everytime this happened I had to restart the system (i attacched a pic of the warning). Can you figure out why this happened? Is it related to my problems with the acquisition?
3) Sometimes, while I was tuning the sample rate and number of samples of the Input Voltage I runned into this warning:
Error -200279 occurred at Acquisition_and_generation.vi
Possible reason(s):
The application is not able to keep up with the hardware acquisition.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.
Property: RelativeTo
Requested Value: Current Read Position
Property: Offset
Requested Value: 0
I'm not sure to understand the definition of application and hardware acquisition and all I could do was to increase the number of samples for channel in the DAQ read block.
Thanks you so much!
10-09-2023 12:55 PM
Hi S3Lab,
@S3Lab wrote:
1) The problem here is that I'm not able to set the same sample rate on the INPUT and OUTPUT signal. For example, I have tried to set the sample rate in the DAQmx Timing on 2000 S/s but by giving a look at the effective sample rate (as reported in the pic attached), I have found out a dt slightly different from the theoretical one.
Did you verify your two modules support that sampling frequency? (I'm quite sure they do not support exactly 2kS/s…)
Please read the manual for both modules!
@S3Lab wrote:
2) During my previous tests, the cRIO system has often runned into the sudden disconnection and everytime this happened I had to restart the system (i attacched a pic of the warning). Can you figure out why this happened? Is it related to my problems with the acquisition?
This usually happens when the CPU runs at ~100% usage on your cRIO.
Does it?
@S3Lab wrote:
3) Sometimes, while I was tuning the sample rate and number of samples of the Input Voltage I runned into this warning:
Error -200279 occurred at Acquisition_and_generation.vi
Possible reason(s):
The application is not able to keep up with the hardware acquisition.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.Property: RelativeTo
Requested Value: Current Read PositionProperty: Offset
Requested Value: 0
I'm not sure to understand the definition of application and hardware acquisition and all I could do was to increase the number of samples for channel in the DAQ read block.
You need to read more samples or more often!
It may help to handle each module in its own loop. (And it probably is related to question 1: set the sampling rate correctly for both modules.)
10-10-2023 04:26 AM
Hi GerdW,
thanks for your answer.
I've read in the TDS of the NI 9234 module that using internal master timebase, the module supports a frequency that goes from 1.652 kS/s up to 51.2 kS/s. I'm not sure if I'm allowed to pick every value in this gap or just some discrete values. The TDS of the NI 9263 states that it can reach 100 kS/sfor each channel.
I've read that the issue related to the disconnection is due to the overload of the CPU but how can I avoid to overload it?
Eventually, I want to ask you if there's some thumb rule to adopt to correctly tune a proper number of samples fitting with the sampling rate.
Thank you so much for your advices!
Best regards
10-10-2023 04:44 AM - edited 10-10-2023 04:46 AM
Hi S3Lab,
@S3Lab wrote:
I've read in the TDS of the NI 9234 module that using internal master timebase, the module supports a frequency that goes from 1.652 kS/s up to 51.2 kS/s. I'm not sure if I'm allowed to pick every value in this gap or just some discrete values.
Read the datasheet more carefully, all that is explained even with formulas.
(The data rate definition is given in the "External timebase" section, but is also valid for internal timebase!)
There also is a DAQmx property that you can use the read the actual samplerate after setting it using DAQmxTiming…
@S3Lab wrote:
I've read that the issue related to the disconnection is due to the overload of the CPU but how can I avoid to overload it?
By carefully avoiding loops that just burn CPU cores (and by debugging)…
@S3Lab wrote:
Eventually, I want to ask you if there's some thumb rule to adopt to correctly tune a proper number of samples fitting with the sampling rate.
Rule of thumb: set the number of samples to about 1/10th of the sample rate.
This will result in a reading loop iterating at ~10Hz, sufficient for usual monitoring tasks and fast enough for humans watching the graphs…
10-10-2023 05:16 AM
I see what you're saying.
In the datasheet it says that the data rate is given by a formula ((f_M ÷ 256)/n, n = 1, 2, ..., 31), so I must assume that it's not possible to set such value as I prefer.
Do you think that it's a good idea to measure the actual data rate of the acquition system and enter it in the generation of the signal with the 9263 module or there's no way I can get an FRF with such modules? In the 9263 module TDS I see no formulas like in the 9234 module so I suppose that I can set a frquency freely.
Many thanks
10-10-2023 05:46 AM
Hi S3Lab,
@S3Lab wrote:
In the datasheet it says that the data rate is given by a formula ((f_M ÷ 256)/n, n = 1, 2, ..., 31), so I must assume that it's not possible to set such value as I prefer.
This is what you get with F_M = 13.1072MHz:
f_26 = f_M/256/26 = 1.969kHz
f_25 = f_M/256/25 = 2.048kHz
@S3Lab wrote:
Do you think that it's a good idea to measure the actual data rate of the acquition system and enter it in the generation of the signal with the 9263 module or there's no way I can get an FRF with such modules? In the 9263 module TDS I see no formulas like in the 9234 module so I suppose that I can set a frquency freely.
The 9263 module uses a different timing engine, so you can choose samplerates more freely. There will be limitations by the resolution of that timing source: again you could read the samplerate using a DAQmx property!
(The NI9234 will use 1969.2307… Hz (with 692307 repeating forever for an ideal 13.1072MHz clock) and your NI9263 will not be able to exactly use the very same samplerate due to its timing clock resolution.)
So the question is: Do you really need exactly the same samplerate for AI and AO channels? Then you should stick with samplerates of (several) multiples of 2.56kHz upto 51.2kHz…
10-10-2023 06:32 AM
I totally understand what you say and also the perplexity about if this is necessary or not. The reason why I'm trying to set the same data rate in both the modules is that in order to use the FRF block since everytime I enter the teo waveform signals it return me the error I showed in the first message that I sent.
Of course, if there would be a way to workaround this problem I would take it with no hesitation.
Best regards,
S3Lab