06-27-2020 07:23 AM
Hi, I'm newly beginner of labview (2009).
I'm trying to figure out trigger system by NI-DAQ, PCI-6133 and cDAQ-9171(pressure data) with NI TB-9212(temperature data) simultaneously.
Once I get a pressure data by PCI-6133, then start to get pressure and temperature data.
But when I compose this LV program, I've got a problem. (Here is attached vi file below.)
Here is my error message from LV :
Error-200077 occured at Property Node DAQmx Timing (arg 2)
Possible reason(s) :
Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.
Property: SampClk.Rate
Requested Value: 20.0e6
Maximum Value: 10.0e6
Minimum Value: 22.250739e-309
Task Name: _unnamedTask <76>
Note that the sampling rate of both is 2.5MS/s/ch and 96S/s/ch.
Then how can I change the requested value for this situation?
06-27-2020 08:05 AM
Hi Sensor.Kim and welcome to the forums!
As the error message makes clear, you are requesting a sampling rate for the task that is outside the allowed range of your hardware. Assuming that this error occurs at the DAQmx Timing node in the "0, Default" case of the Case Structure, I assume it's because you're trying to use the master timebase frequency from one task as the sampling frequency for another. The master timebase is the clock from which the available sampling frequencies are derived si I would be surprised if this is what you actually intended.
PsyenceFact
06-28-2020 01:51 AM
Yeah, I think that is the problem too but I don't know how to set up the other frequency differently.
Could you let me know how to set up frequency differently?
06-28-2020 07:14 PM
Look, I'm honestly not trying to discourage you, but...
From what I see of the code, I think you're trying to take on more than you're ready for while still new to this as you mentioned. I think you should probably take a couple steps back and then re-approach this thing in much smaller increments.
It looks to me like you've tried to adapt some code that you didn't really understand in the first place and are now trying to figure out why the code you didn't understand combined with the mods you weren't too sure about either aren't working together to achieve the desired results that you haven't clearly defined.
It'll get better, but this stuff generally takes some time to learn about and get used to.
I don't have a clear understanding of your end goal, but am pretty sure there's not a quick fix with minimal changes that'll get you there. It'll take time, patience, and diligence. Here are a few specific observations & suggestions.
1. Make the wiring neater. Keep wires horizontal as much as possible, don't hide them behind things, don't cross them unless necessary. Doing these things greatly improves your (and our) ability to follow the dataflow and understand what we're looking at.
2. Your message says you want to sample at 2.5 MHz and 96 Hz respectively. Your code shows values of 1 MHz and 1000 Hz.
3. Despite these *widely* variant sample rates, you request the same # samples from both tasks. That doesn't really make sense.
4. Despite configuring both tasks as "continuous" you only read from them once and then clear them.
5. Most of the case structure cases aren't relevant for your hardware or task config. Their presence was one of the big clues for why I figured you must have tried modifying code you didn't really understand.
6. I never use the Express vi's you're using for signal processing and file writing. I noticed that several file writing vi's want to write to the same file, but there's no control over the sequence of which data is written in which order. It's likely to vary from one run to the next, which is likely to make trouble for subsequent post-processing of the data file.
7. I guess that's enough stuff for now...
-Kevin P
06-29-2020 02:14 AM
As Kevin said, it's probably better to strip this back and try one step at a time. Have a look at this thread. I posted a snippet showing a very basic method of continuous acquisition and display/processing using a queue to transfer data from producer to consumer loop. The posts following the snippet by Kevin and Henrik suggest a few further additions and things to watch out for. You may be able to use this as your starting point, or at least to help you better understand your existing code.
PsyenceFact