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

Similar Messages

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.

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.

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

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 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....

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

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 -200428 occurred at Write Dig Chan.vi

Hello,
I am trying to read the task name, channel name, and physical channel from a configuration file and using this information create a DAQmx task and two global virtual channels. Everything seems to be working ok (no error) until I am trying to write to one of the channels, then I get an "Error -200428 occurred at Write Dig Chan.vi". What am I doing wrong? Thanks for your help.
Peter
Attachments:
Write Dig Chan.vi ‏37 KB

Hello Corey,
I tried it out for both the Write Dig Chan.vi and the Write Dig Chan (modified).vi, but in both cases, I get the same errors as before.
Write Dig Chan.vi Error -200428
Write Dig Chan (modified).vi Error -200587
Attachments:
Write Dig Chan.vi ‏38 KB
Write Dig Chan (modified).vi ‏44 KB

Handshaking DMM with multiple Switch devices - DAQmx error

Hi.
I'm trying to create a handshaking loop with DMM (PXI-4071), SWITCH (PXI-2569) and MUX (PXI-2575). All three instruments are in segment 2 of PXI-1045 chassis (slots 8, 9 and 10) and I am using PXI trigger lanes to route triggers.
I followed the NI article 'Multi-module Scanning with National Instruments Switches' - I modified the NI SWITCH example 'niSwitchDMMSwitchHandshaking' to configure the other SWITCH but when I tried to run the example, I got an error:
0xbffa6b9a - No registered lines could be found between the device in the route. (pop-up screenshot is in the attachment). It is the niSwitch_InitiateScan function for the second Switch that returned the error.
Changing PIX trigger lanes has no effect.
I tried both CVI and LabVIEW examples with the same result.
I even tried to use two 2575 MUXes - same result.
Can anybody tell me what am I doing wrong?
Solved!
Go to Solution.
Attachments:
errror1.JPG ‏26 KB

Hi Pavel,
For the purposes of this post, I'll define
the measurement complete signal (sent by the DMM to the switch modules
after each measurement) as 'MC' and place it on TTL0.
For the
purposes of this post, I'll define the scan advanced signal (sent by the
switch module(s) to the DMM once the relays have settled) as 'SA' and place
it on TTL1.
You mentioned you're using NI-Switch, which is NI's IVI
compliant switch API. Since the IVI Foundation regulates the behavior
of IVI compliant software, we must adhere to their rules when
implementing our API. Unfortunately, the IVI switch standard doesn't
provide a method to control arbiting of triggers between multiple switch modules
simultaneously.
Let's
look at what happens when we setup a system with multiple switch
modules handshaking with a single DMM. The DMM is going to take a
measurement and then send MC on TTL0. Meanwhile, each switch is listening to TTL0,
waiting for the MC pulse. When the MC pulse is received, each switch sets
the relays according to its next scan list entry, waits for debounce,
and then sends SA on TTL1. The problem we run into here is that depending on the switch module, number of relays connected simultaneously, jitter, etc, it's possible that one module will send the SA trigger on TTL1 before the other. Since the IVI spec doesn't provide any way to implement a 'master' switch or an arbitor, it's impossible to implement a system such that only the last switch that settles sends a trigger. Therefore, what happens is we get a whole bunch of switch modules sending triggers at slightly different times onto TTL1. If one switch is driving TTL1 high while the others are driving TTL1 lo, it's remotely possible that we could damage the TTL circuitry on the PXI backplane.
To date, NI hasn't seen any failures due to simultaneously driving the TTL lines high and low at the same time with NI switch hardware, but it is theoretically possible that damage could occur. For this reason, NI implemented a change in DAQmx
9.0.0, 9.0.1, and
9.0.2 that prevents a user from setting up handshaking with multiple switch modules while using NI-Switch. What does DAQmx have to do with this, you might ask? A component installed with DAQmx is responsible for verifying the triggers are valid.
Customers with existing NI-Switch multi-module handshaking applications will find that upon upgrading to any of the above three versions of DAQmx, the error you observed will occur. We've evaluated this customer feedback and have decided to revert to the previous functionality in a yet-to-be released version of DAQmx. Please note that NI does not advise driving the same TTL line with multiple sources due to the chance that we'll double-drive the line. Therefore, it goes with out saying that NI does not advise using NI-Switch in multi-module handshaking applications. We do, however, still recommend NI-Switch for Syncrhonous triggering because the switches never send triggers (in synchronous mode, the DMM just waits a predefined amount of time before switching).
Note that if you use the DAQmx Switch API, we're no longer bound to the IVI spec, which means we have an arbitor that ensures only one switch module drives the SA trigger on TTL1. NI highly recommends that customers evaluate using the DAQmx switching API for multi-switch handshaking applications. An example DAQmx handshaking application for the DAQmx Switch API is located in Example Finder»Hardware Input and Output»DAQmx»Switches»Switch Scanning with DMM - Handshaking.vi.
Note that in DAQmx, we'll only have one scan list, regardless of the number of switches we have. Note that the syntax in DAQmx scanning is different than NI-Switch. I'll defer a detailed explanation of the differences to the DAQmx and NI-Switch Help (search for 'scan list'), but in short, we'll need to include the DAQmx Device name prior to each connection. For example, in NI-Switch, if we want to connect CH1 to Com1:
CH1->Com1;
In DAQmx, we'll need to include the Device name:
Dev1\CH1->Com1;
Note that to add additional switch modules in the DAQmx API, we simply
call the Set Topology and Reset VI multiple times:
DAQmx keeps the
session loaded in memory and as I noted above; we define which switch
does the action as part of the scan list entry.
If you'd still like to use NI-Switch, you could roll back to DAQmx 8.9.5 or previous, or if you want to stick with 9.0.x, I highly recommend that we daisy chain the triggers as follows:
DMM Measurement Complete to Advance Trigger on Switch1 via TTL0
Scan Advance from Switch1 to Advance Trigger on Switch2 via TTL1
Scan Advance from Switch2 to Trigger Source on DMM via TTL2
Note that we'll need an additional TTL line for each switch module. Also note that some switch modules allow front panel triggers, which reduces the number of TTL lines we'll need on the backplane, but which requires external wiring between switch modules.
Message Edited by Knights Who Say NI on 06-11-2010 05:25 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:30 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:30 PM
Message Edited by Knights Who Say NI on 06-11-2010 05:31 PM
-John Sullivan
Analog Engineer

Daqmx error 200547 and 500247

Hi all,
Iam working on the pci-6723 and labview7.1 and daqmx 7.3 version software,when iam running the following attached programme iam getting 2 errors
1.200547 daqmx write fails
2.500547 transfer didnot complete within the specified timeout period
actually iam generating 2 dynamic sine wave on 2 channels and 2channel dc voltages and one digital 8 line and iam using visa for serial acquiring data
since the project is black box for the aerospace applications iam receiving serial data of 130 bytes/sec
continuously iam sending the generated voltages to my black box and receiving back and displaying on the front pannel during this time iam getting error
kindly help me , when i start running the programme continuously for 30min t
hen this error flags how to overcome this error.
if i restarted the nidevldu and nipxmru dlls of windows 2000 then its working again the problem persists , whether my hardware gone bad kindly suggest me
regards
rajesh
Attachments:
pci-6723 ‏320 KB

Hello Rajesh,
I took a look at the code you sent me, and noted a couple of things on the DAQ part of your code. The first thing is that in the DAQmx Write VI, you have the auto start terminal set to True (Is there any reason for this?) For multiple sample output, the auto start terminal should preferably be set to false. This is because additional timing must be configured when outputting multiple with the DAQmx Timing VI and the DAQmx Start Task VI and the DAQmx Stop Task VI myst also be used.
The second thing I noted is that you have your DAQmx Write inside a while loop. Are you doing this because you want to write new data to the buffer with each loop iteration? If so, use a Write property node and select the Regeneration Mode property and set it to not allow
regeneration. You need to make sure you generate new data fast enough to prevent the buffer from regenerating old data. This situation is similar to performing a continuous buffer acquisition (You must make sure you read the data out of the buffer fast enough to prevent the data from being overwritten.)
Please let me know if this suggestions helped or if you have any additional questions about them. Have a great day!
LA

DAQmx error 200088

Hi guys, I could use some trouble-shooting advises for this error code '200088'.
Just a brief background, I am using DAQmx 7.4 and Labview 7.1 with PCI 6251. When I tried to run a task VI that I have come up in Data Neighbourhood of MAX, I keep getting this error code " error 200088; task invalid or not exist...". It is quite strange as I did get it to work during the initial few hours before it went down. When I checked back at MAX each time after the error, I could find no mistake with the task name. When I test the task from within MAX, I could see the correct signal value. However, for some reasons, I could not get it to work in Labview. I have since tried it on another PXI station of similar model (PXI 6251) and of same software version, it cannot work either. Hence, I am wondering if there is/are any generic problem with my station setup? I would appreciate it if anyone could get me some advises. Thank you in advance.

Hi Phooi,
I found a knowledge base entry regarding error code -200088 (LabVIEW 7.1 and NI-DAQmx): http://digital.ni.com/public.nsf/allkb/368AE98647EEE86E86256EBE0067B167
Have a look, this should help you.
(Please notice, that if you install the maintenance release, it's very recommended to do a mass compile - this could bother your machine for maybe a couple of hours)
Good luck,
Stefan
Impossible is nothing - nothing is impossible

DAQmx Error 88709

Similar Messages

Maybe you are looking for