LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error-200077 occured at Property Node DAQmx Timing (arg 2)

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?

0 Kudos
Message 1 of 5
(1,354 Views)

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

Message 2 of 5
(1,334 Views)

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?

0 Kudos
Message 3 of 5
(1,293 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



Message 4 of 5
(1,252 Views)

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

0 Kudos
Message 5 of 5
(1,242 Views)