DAQMX error 200452

I am getting error 200452 on a channel that is not active. The DAQMX task includes channels from three different devices, I specify only channels from one device as active and it is returning the 200452 error on a channel that was not selected. Que tal?

Hi,
My 200452 doesn't seem related to the original post, but it seems better to post here than start a new discussion.
I am using LabVIEW 7.0 with a PCI-6071E. I want to output a single rising edge triggered by the first edge of a finite pulse train to a counter (top part of attached jpg). I am trying to trigger using 'Start Digital Edge' and "TTLtrigger" is created as a digital output task in Measurement & Automation Explorer. The error occurs at 'Start Digital Edge'. If don't wire up the error line between 'Start Digital Edge' and 'Digital Bool' and turn off the error messaging, it actually seems to work okay but I get other problems when I try to add more features (a user-specified delay between pulse train first edge and single edge, where the timing is critical).
As well, I tried a 1-pulse train instead of the write digital bool, but I only have 2 counters which I think are being used by the finite pulse train. VI is attached.
Hope someone can be of assistance. Cheers, Will.
Attachments:
200452.JPG ‏84 KB
Gate control.vi ‏326 KB

Similar Messages

DAQmx error 200452 with PCI6024E

I successfully tested my Application with DAQmx and the PCI 6221 (LV 7.1, WinXP). I tried the same Appllication with the (legacy) PCI6024E which should be compatible to DAQmx regarding the NI compatibility list. After starting the App. the following error message appears: 200452 occured at DAQmx Channel(arg1).Possible reason: specified property is not supported by the device or is not applicable to the task. Property CI.DupCountPrevention. ChannelNameDev1/ctr0. When I delete this property all seems to be fine.
Jörn HeitlandMessage Edited by JoernHeitland on 04-20-2005 07:24 AM

Duplicate count prevention is not supported by E Series devices. You should not need this property when running on an E Series device.
I hope this helps!
gus....

Getting error -200452 using DAQmx Base Trigger (Digital Edge).

I'm trying to set up AI and counter output, and I'm using digital output as trigger for to start AI and counter at the same time. I get error 200452 "Specified property is not supported by the devise..." not consistently, but around 5 runs out of 100. Below the error description, the error box shows "This error code is undefined. No one has provided a description for this code..." If I "Retain Wire Values" in Block Diagram, the error first appears after 'Start Digital Edge' block in top counter output line.
Using LabView 8.5 on MAC OS X and DAQmxBase 3.2
The MAC I have is not Intel base, so I can't upgrade LabView and DAQmxBase to latest version
Note: The file contains just a small portion of the program, but the rest of the program does not have any other DAQmxBase blocks accessing the channels used here in code attached.
Attachments:
Combined V 1.5.41_sm.vi ‏98 KB

Hi Azotov,
It looks like the DAQmx Base driver readme includes Mac OS X support for LabVIEW 8.5. Could you specify what hardware you are using?
I found one KnowledgeBase specifying that error code occurs when you try to use certain properties with certain devices. Of course, this would most likely occur every time you run the task, not 5% of the time.
Since I'm running Windows, it's a little difficult to see if you have DAQmx Base "Reset Device" functionality with that version of the driver. You might check if you can run that functionality before using your device, though.
National Instruments

Error -200452

I am trying to synchronize a 4472 analog input card with a 6731 output card. I am getting the error:
Error -200452 occurred at Property Node DAQmx Timing (arg 1) in Gen Mult Volt Updates.vi
Possible reason(s):
Specified property is not supported by the device or is not applicable to the task.
Property: MasterTimebase.Src
Task Name: _unnamedTask<1>
If this operation is not supported by the 6731, then how do I synchronize these two boards?
I am attaching my vi.

The problem here isn't the 6731 but the 4472. The 4472 uses a different timing/synchronization model than the 6731 and doesn't support the master timebase property. Instead, it uses a sample timebase signal which is roughly the equivalent of the master timebase on the 6731. To get at the sample timebase signal, you normally use the SampClk.Timebase.Rate and SampClk.Timebase.Src properties in the Timing Property node. However, the problem here is the sample timebase signal for the 4472 can only be imported/exported on RTSI 8, and the master timebase signal on the 6731 can only be imported/exported on RTSI 7. You can verify this by looking at the routing tables in MAX. This means you can't share these signals between the two devices on PCI. I'm assuming you're using PCI because you mentioned a RTSI cable on your other post. If you're using PXI, there are a couple of other options available for sharing these signals by placing the 4472 in slot 2 of the chassis. If this is the case, let me know and we can explore this option further.
With all of that being said, there are still some options for synchronization that are illustrated in the attached example (the example is based off of the VI you originally provided). First, if you want to start the generation and acquisition at the same time and have them sample at the same rate, set the Synchronized Sample Clocks boolean control to true on the front panel. Using this method, the two tasks will share the same sample clock and start trigger. With this synchronization method, there may be some small phase offset between when the two tasks start, but the offset should remain constant throughout time. If you want to have different sample rates for the AI and AO tasks, you can set the Synchronized Sample Clocks boolean control to false, and the tasks will only share a start trigger. Using this method, the two tasks may have a small phase offset when they start, and the tasks will gradually fall farther out of phase as the task runs. The rate at which the tasks fall out of phase depends on the accuracy and drift of the oscillators used on the devices. The 20 MHz oscillator is typically accurate up to +/- 0.01% and the DDS on the 4472 is accurate up to +/- 25 ppm. If you're only performing finite operations and your sample set is small, this may not even become an issue. However, if you're running long continuous generations/acquisitions, you will likely notice the phase drift over time. To run this example on PCI, don't forget to first create a RTSI cable in MAX and add the two devices to the RTSI cable. Without this step, the driver won't know that it's possible to route signals between the two devices.
Finally, I should mention there is an intrinsic filter delay in the ADC's used on the 4472. This filter delay is 38.8 samples for the 4472. If this delay is causing problems with the synchronization, you should be able to use a counter on the 6731 to delay the start trigger and compensate for it. However, I won't go any farther into this unless you find it's a problem. Anyway, give the VI a try and let me know if there are any other problems. Good luck!

Daqmx error num: -50103 with message: The specified resource is reserved. The operation could not be completed as specified.

Hi, I am running a program where I have 4 nidaq cards on a single machine, all connected. I am trying to start a counter and keep getting that error (daqmx error num: -50103 with message: The specified resource is reserved. The operation could not be completed as specified.) in two places in my code. I understand what the error means (you can only have one task of a type per card), but I don't see where that is occuring in my code.
See below for code. I noted the two places where the error is occuring. I am debugging someone else's code, which is part of the problem.
Thanks!
counterTask = 0;
daq_err_check( DAQmxCreateTask( "counter_generation_task",
&(counter_generation_task) ));
daq_err_check( DAQmxCreateTask("counter_count_task",
&(counter_count_task) ));
char co_chan_name[40];
char ci_chan_name[40];
char ci_trig_chan_name[40];
sprintf( co_chan_name, "%s/ctr0", niDev);
sprintf( ci_chan_name, "%s/ctr1", niDev);
sprintf( ci_trig_chan_name, "/%s/PFI9", niDev);
printf("OK1");fflush(stdout);
daq_err_check( DAQmxCreateCOPulseChanTicks( counter_generation_task,
co_chan_name, "", "ai/SampleClock",
DAQmx_Val_Low, 32,16,16) );
daq_err_check( DAQmxCfgImplicitTiming( counter_generation_task,
DAQmx_Val_ContSamps, 1000) );
daq_err_check( DAQmxCreateCICountEdgesChan( counter_count_task,
ci_chan_name, "",
DAQmx_Val_Rising, 0, DAQmx_Val_CountUp) );
daq_err_check( DAQmxCfgSampClkTiming( counter_count_task,
"Ctr0InternalOutput", 1000.0, DAQmx_Val_Rising,
DAQmx_Val_ContSamps, 1000) );
daq_err_check( DAQmxSetRefClkSrc( counter_generation_task, "OnboardClock") );
daq_err_check( DAQmxSetRefClkSrc( counter_count_task, "OnboardClock") );
printf("abt to start counter_count\n"); fflush(stdout);
daq_err_check ( DAQmxStartTask( counter_count_task ) ); // ERROR OCCURS HERE
printf("abt to start counter_gen\n"); fflush(stdout);
daq_err_check ( DAQmxStartTask( counter_generation_task ) ); // ERROR OCCURS HERE
fflush(stdout);
Thanks again for your patience!

I get it when capturing from my mini DV cam (which is not controllable by FCP). To resolve, I have to click Capture Now a split second after I start the DV tape rolling.

Error -200452 depends on channel order

LV 2010, NI-DAQ 9.2.2, Win Vista, cDAQ 9172 chassis, NI-9211, NI-9219.
My client has the same issue with LV 8.6.1, NI-DAQ 9.1.5, Win XP, same hardware.
I am getting an error -200452 (Property not applicable) in a case where I don't understand why.
I'm assigning the user's channels to tasks in preparation for DAQ.
Chan A: is Device 1, module 1 (NI-9211), channel 1, in TC mode
Chan B is Device 1, module 6( NI-9219), channel 1, in RTD mode.
Since these are on the same DEVICE, they are being assigned to the same TASK.
I am using the property ADC TIMING MODE to get rid of 60 Hz powerline variations in the signal (even sampling at a multiple of 60 Hz doesn't reject it as well as this property does.
The error occurs at the PROPERTY NODE function.
The thing is, if I assign chan A to the task -->BEFORE<--- channel B, then the error occurs.
If I assign chan B --> BEFORE<-- chan A, the error does NOT occur, and all seems well.
I have never imposed any restrictions on my client about having to configure things in a certain order, I don't want to start now.
Why is the order being imposed on me?
The error:
The TC code on 9211:
The RTD code on 9219:
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

I think the problem stems from the fact that the 9211 does not support the ADC timing property
--- I just found that out when I added the property to the 9211 case, thinking that it was the CHANGE in property value that was triggering the complaint.
and when you are using that property you are assigning it to all of the channels in the task.
--- I'm not sure I understand that. If I use the property when the task contains A, then B, I get the error.
If I use the property when the task contains B (9219), and then add channel A (9211), I get no error.
Perhaps a clearer way to state it would be:
when you are using that property you are assigning it to all of the channels ALREADY CONFIGURED in the task.
If THAT is the rule, then that would explain it. If A(9211) is ALREADY in the task when I use the property, then it's trying to apply the property to all channels already in the task, and failing. If B(9219) is the ONLY one in the task, then the property is legal. Adding the 9211 later does NOT try to apply the property to it.
Does that sound right?
Why don't you trying using the 'ActiveChans' property node to specify what channel you need:
--- I was hoping to be done with each channel as I process it. (I am processing a list of channels that the user has specified, in no particular order, and I have to configure NI-DAQ from that list).
I suppose I can add each non 9211 channel to a list, and then use the ACTIVE CHANS along with ADC TIMING MODE to specify.
Or maybe I can use the ACTIVE CHANS list AS I APPLY IT. That would mean several calls to the TIMING MODE property, one for each non-9211 channel.
What's confusing me is the statement "You must use the same ADC timing mode for all channels on a device" from the HELP for ADC TIMING MODE.
If one of those channels is a 9211 and another is not, then that statement is obviously not true.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

DAQmx Error: Non-buffered hardware-timed operations are not supported for this d evice and Channel Type.

Hello,
I am new to NI and to data acuasition cards in general. I am trying to put an application togather that would play large audio file using NI9263.
And i am getting the following error.
DAQmx Error: Non-buffered hardware-timed operations are not supported for this device and Channel Type.
Status Code: -201025
Does my hardware support buffering ?
can i use the EveryNSamplesCallbackAO function ?
Any sample code, will be helpful at this time. Thanks.

Hi yma200,
Are you using a USB 9263? If so, this might be of help:
http://digital.ni.com/public.nsf/allkb/EC1968728E660B288625780700570D06?OpenDocument
If it doesn't help, can you please post the code that you have that is causing your error?
Regards,
Bogdan Buricea
Applications Engineer
National Instruments

DAQmx Error -200550

Currently I have a PXI-1000B, and I have opnly ever used the same card in the same slot. I have a much faster sampling card and I'd like to try it out but I receive this error message when trying to use it. The interesting problem is that there is a exact duplicate of the card that I am using right now in another slot and it also does not work, giving the same error message. I did not setup the lab so I don't know if there was a procedure to make the one slot operational that the other haven't recieved. Do I need to set up the clock somehow?
DAQmx Error -200550 occurred:
Hardware clocking error occurred.
If you are using an external reference or sample clock, make sure it is connected and within the jitter and voltage level specifications. Also, verify that its rate matches the specified clock rate. If you are generating your clock internally, please contact National Instruments Technical Support.
Status Code: -200550
Thanks

Hopefully this covers everything:
We have a NI PXI-1000B crate & several digitizer modules (2 PXI-5122 and 1 PXI-5152) in our lab. We have been heavily using one of the PXI-5122 with no problems, but need to move on to using the faster PXI-5152.
We find that we cannot read out either the 2nd 5122 or the 5152. They both consistently fail with "hardware clocking - error 200550". This occurs both while attempting to test the cards in MAX as well as while trying to sample with them. There is one difference between the errors, when rebooting the system, when the drivers access the cards the 5122 cards behave in the same way with green lights, however the 5152 flashes a red light before resuming a green light for access.
We have swapped modules and slots. Both the bad 5122 and the 5152 produce the same error in different slots, including the one the good 5122 normally operates in. We have also moved the good 5122 and it works fine in different slots, including the ones the bad modules fail in.
The bad 5122 was once repaired (replaced fuse) at NI for the same problem, but we have no history of repairs to the 5152. We "inherited" this setup from a technician who is now in another lab but reachable, so we don't know the exact history of the set-up.
It seems strange that both bad modules exhibit the same error. We're happy to try any other suggested tests here before sending them for repair. Any suggestions would be much appreciated.

DAQmx error 200279

Here's a link to a thread on the Measurement Studio discussion board dealing with DAQmx error 200279 (trying to read data buffer that has been overwritten while running continuous aquisition):
http://forums.ni.com/ni/board/message?board.id=232&message.id=2926&query.id=12659#M2926
These errors can be dealt with by modifying the RelativeTo and Offset properties of DAQmx Read. The same thing applies when using DAQmx in LabVIEW, so I thought this may be useful here.
Zador

Update:
Changing the priority under VI properties to a higher or time sensitive setting has helped decrease the build up of samples in the task and increase performance of the loop, but it seems that there are more issues possibly related to the number of visible items on a VI front panel. I have a number of objects that toggle their visibility based on which item is selected in a menu, and when objects with graphs are displayed, I notice performance dropping and samples accumulating. No solution yet.

DAQmx Error 88709

I'm running TestStand in conjunction with LabVIEW on a PXI/SCXI system. I experience DAQmx Error 88709 only when running my TestStand sequence file the first time after all equipment has been powered down. For all subsequent executions of the TestStand sequence file, I don't experience the error (everything runs fine). I can reboot the controller and I don't get the error. I only get the error after a complete power-down (all PXI and SCXI equipment).
In my attachment, the VI that causes the error is Output_Drive.vi. In this VI, I'm acquiring data from two PXI-5114 Digitizers. When the error occurs, data from the first digitizer is displayed on the front panel graph, but before the data from the second digitizer is displayed, the error occurs. Data from the second digitizer is coming from a PXI-6711 Analog Out card.
In my attachment, Error Report.bmp shows the error report that I get.
Any ideas will be greatly appreciated.
Attachments:
DAQmx Error 88709.zip ‏225 KB

Hello,
Do you get this error if you just run the VI in LabVIEW and not in TestStand?
Best Regards,
Adam G
National Instruments
Applications Engineer

An issue with DAQmx Error messages

Greetings,
I'm using a 6602 counter board with DAQmx 7.4, ANSI C API. A strange issue concerning the errors due to faulty attribute values keeps occuring, that being no error is reported when the (faulty) attribute value is set but only when it is read back afterwards. Shouldn't the faulty value be reported by the Set function?
To be specific, I'm creating a period measurement counter input channel with implicit timing, sample mode = finite, then setting the number of samples per channel to 0 (bear with me, I know the 0 value makes no sense here, the point is how the errors are being reported so that they can be handled in a reliable and consistent way). While DAQmxSetSampQuantSampPerChan(taskHandle, 0) does not produce an error, calling DAQmxGetSampQuantSampPerChan(taskHandle, &SampPerChan) for verification on the very next line returns Error -200077 : "Requested value is not a supported value for this property". So, my question is why the error is reported by the Getter instead of the Setter? Is this normal behavior (if so why?) or is something amiss here?
Jeff

This is the expected behavior. Validating attributes is tricky when attributes are dependent upon other attributes. There are two main approaches that can be taken by NI-DAQmx.
One, when every attribute is set, NI-DAQmx could verify the value of that attribute in the context of the task (i.e., in the context of all other attributes). This is problematic for at least a couple of reasons. One, validating the task after every attribute is set is time consuming and not efficient. Two, validating the task after every attribute is set requires that customers set attributes in a specific order such that dependent attributes are set after their dependencies. This would dramatically decrease the usability of NI-DAQmx. In fact, if attributes are mutually dependent, this approach is impossible.
The second approach is that NI-DAQmx doesn't verify the task until it is forced to do so. Starting a task forces it to be validated. Querying an attribute also forces the task to be verified since the value of an attribute may be dependent upon the value of another attribute.
As you've noticed, we've taken the second approach with NI-DAQmx. This approach leads to a more efficient execution as well as allow customers to set attributes in an arbitrary order. If you want to force the task to be verified in order to check for errors, you can do so explicitly at the desired time. However, the need to check attributes for errors is most often needed when the application is under development and the NI-DAQmx error reporting features makes it easy to determine which attribute has been set to an invalid value even when that error is not reported immediately.
Now, in reality, the way NI-DAQmx handles attributes is a bit more complicated than what I just described. Since some attributes are not dependent on other attributes or, since some attribute values can never be valid regardless of the values of other attributes, these attributes are verified when they are set and errors are returned immediately. We refer to this as coarse attribute verification. For example, if you set the sample rate to 100 MHz on an E-Series device you will immediately get an error.
Hope this helps clarify the behavior.
geoff
Geoffrey Schmit
Fermi National Accelerator Laborary

DAQmx error code -200452

I cannot find any detailed information on this error code.
I created a task with 2 counters. One Channel (Fuel_Press_Ctrl) is running at 100hz and the other (TachOut)is at 1000Hz. During the program they work fine. When I try to clear the task I get this error.
Property: CO.Pulse.Freq
Channel: TachOut
I did not have this problem until I added the 2nd channel (TachOut).

Are you trying to generate two finite pulse trains, or are you trying to generate two continuous pulse trains? Which board are you using?
If you are doing finite on an MIO board, then you will run into errors because a finite pulse train actually requires both counters.
"Finite pulse trains are produced in the same manner as continuous pulse trains, except that the counter is gated so that the gate is high for exactly the length of time it takes to generate the required number of pulses, then the gate falls low and no pulses are generated. Finite pulse trains require a second counter"
Taken from Generating a Pulse Train with a Counter
However, if you are just doing two continuous pulse trains you shouldn't have a problem from a hardware standpoint.
Otis
Training and Certification
Product Support Engineer
National Instruments

Constructor NationalInstruments.DAQmx error in C#

Hello everyone,
I have been struggeling with the following problem. I am trying to execute a selfcalibration within a visual studio .net 2005 program. When I create a Device object an error appears which tells me that :
The type 'NationalInstruments.DAQmx.Device' has no constructors defined.
Can anyone help me with this problem.
Thanks in advance,
Souza

Good stuff. But the link talks about xcopy and including. Including and copying the needed drivers to where? The location they are found the development machine so that would mean making a new directory on the target machine as 'C:\Program Files (x86)\National Instruments\MeasurementStudioVS2008\DotNET\Assemblies\Current' or copying the needed dlls to the same location that the .exe is copied too?
Thanks

DAQmx error -51030 when using SCXI

I'm building a test system that is using a PCI-6040E with a SCXI chassis. In the SCXI chassis my customer has a number of boards to do AI, AO and some digital control. I configured DAQmx tasks for the various divisions (one SCXI has TC, another is measuring DC voltages, another is output some DC voltages). I created some "action engines" that perform initializations, placing the "DAQmx task name" into an uninitialized SR, to be used on subsequent calls. What happens is that if I configure each of the DAQmx tasks as a single event "when called" (I can't remember the exact wording) vs HW timed, multiple or continuous) this scheme works, but relatively slowly, pausing a good second in each of the acquisitions sub-vi's, resulting in a 6+ second loop time. If I try any of the other modes I get the -51030 error on the second vi executed (they are in a while loop connected with the error cluster chain). Some of what I'm reading almost sounds like I should open each task, acquired, close task, open next, etc., loop. If so does anyone have any idea of the overhead timewise. This system doesn't need to be terribly fast, but I'm measuring currents that I would like to know within a 100ms if they go way out of limits so I can shut down the offending unit.
As always, thanks in advance for your help
Putnam Monroe
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Good morning all,
Essentially I have done what LYu is doing, with a "create a channel" for each the "task types" that are on the Analog In. This allows me to have an idea of where in the returned array each group's data will reside and also to perform the appropriate configuration (Thermocouple, current, voltage and frequency measurements) as I create the "groups", they are all, strictly speaking, the same task, but I wasn't able to find a way to easily build the task in MAX, it starts by having you determine which kind of task (Analog in, out, etc.) and then what type (temperature, current, etc.) which precludes having multiple types in the task. You can do this in LabVIEW, as described above. Part of my problem is that without the DAQ hardware installed on the machine that you are using to develop you can't set up any of the settings in MAX and unfortunately time on the target system is really at a premium. On my wish list (for quite a while) is the ability to tell MAX what hardware _WILL_ be installed, and have it let you do the configuration stuff. It has all the data for the supported National Instruments HW in its database. I'm not asking for the ability to simulate the HW, just to be able to do some of the configuration stuff. Many of us develop on systems other than the target one, frequently not being able to get on the target until we are ready to integrate the HW and SW. Oh well, maybe in MAX 5.0 and LabVIEW 9.1 ...
Thanks for all the helpful suggestions,
Putnam Monroe
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

DAQmx Error 89137 When trying to make a high frequency measurement.

I am using a PCI-6602 Timer/Counter for multiple measurements on a serial interface...
I have the clock line connected to Gate0, the enable line to Aux0 because I need to make a two-Edge seperation measurement between the two later...
But I also want to make a "Period/Frequency Measurement (High Frequency with Two Counters)" measurement...
This requires that the signal to be measured is on Source0...
I implimented the following Code:
void meas_FP_Freq(float64 *Freq0, float64 *Freq1)
TaskHandle CLK0_Freq, CLK1_Freq;
DAQmxCreateTask ("FP_CLK0_Freq", &CLK0_Freq);
DAQmxCreateTask ("FP_CLK1_Freq", &CLK1_Freq);
DAQmxConnectTerms ("/Dev3/PFI38", "/Dev3/Ctr0Source", DAQmx_Val_DoNotInvertPolarity); // Gate0 to Source0, No Error....
DAQmxConnectTerms ("/Dev3/80MHzTimebase", "/Dev3/Ctr1Source", DAQmx_Val_DoNotInvertPolarity);
DAQmxCreateCIFreqChan (CLK0_Freq, "Dev3/ctr0", "", 6000000, 6500000, DAQmx_Val_Hz, DAQmx_Val_Rising, DAQmx_Val_HighFreq2Ctr, 0.001, 4, ""); // High freq measurement
DAQmxCreateCIFreqChan (CLK1_Freq, "Dev3/ctr1", "", 6000000, 6500000, DAQmx_Val_Hz, DAQmx_Val_Rising, DAQmx_Val_LowFreq1Ctr, 0.001, 4, "");
DAQmxReadCounterScalarF64 (CLK0_Freq, 3.0, Freq0, 0); // Run-Time Error -89137 Specified Route cannot be satisfied..etc
DAQmxReadCounterScalarF64 (CLK1_Freq, 3.0, Freq1, 0);
DAQmxDisconnectTerms ("/Dev3/80MHzTimebase", "/Dev3/Ctr0Source");
DAQmxDisconnectTerms ("/Dev3/80MHzTimebase", "/Dev3/Ctr1Source");
DAQmxClearTask (CLK0_Freq);
DAQmxClearTask (CLK1_Freq);
The "Low Frequency" method works fine, but the resolution is too low...
Every help file I've read indicates I can use different PFI inputs for measurements... What am I missing?

Hi,
The reason that you are getting the error is the PFI lines are being reserved twice. You don't need the DAQmx Connect Terms functions in your code because the DAQmx driver does this for you automatically. If you still receive an error after doing this, try to changing the low frequency counter number. I hope this helps you with your application.
Regards,
Hal L.

DAQMX error 200452

Similar Messages

Maybe you are looking for