DAQmx bug?

With DAQmx 8.8 and LabVIEW 8.6.1

'DAQmx reading (analog 2D DBL NChan NSample.vi)'

Asking a finite number of samples let the current task execution until the task has been stopped with DAQmx stop Task.vi.  This seems contrary to the help file "property Start Auto var L_helpType = 'STD_ENG ';

Auto Start, property

Short name: AutoStart

Read DAQmx property

Specifies if the DAQmx reading starts automatically if you have not started the task explicitly using DAQmx Start Task. The default value is TRUE. A finished task acquisition DAQmx Read getting started, it also stops the task after reading the last sample.

Hi Jeff,

You use reference trigger? I don't have a handy USB-621 x but reference trigger on a PCIe-6259 seems to keep the task reserved during the use of auto start. I have just tabled CAR #185781 on this subject.

Brad

Tags: NI Software

Similar Questions

  • Possible bug: DAQmx create channel w/o specified in task

    The VI DAQmx 'DAQmx create channel (I-voltage-Basic) .vi' requires no task should be connected, and claims his detailed help "" task in specifies the task to add virtual channels, this VI creates. "." If you do not specify a task, NOR-DAQmx creates a task for you and adds the virtual channels that this VI creates to this task. »

    My recent experience, I think that there is a problem with this feature. If no job is specified, sometimes this VI will create a new task without problems, but other times it will overwrite an existing task, causing errors later when you try to reference the crushed tasks.

    In my code, I have 7 tasks, two digital (DIO), an analog to (HAVE) and four analog out (AO). One of the AO and the tasks of the AI does not use a task VI before the channel VI create. I recently added this AO task without creating a new task manually, based on the reproduction of legacy code for the channel of AI that also not create a new task. With two spots missing the task of creating VI, I found it fairly common (20% of the tracks) a further task would be crushed, causing errors when the task has been used, either be the wrong type IO, a wrong number of channels, etc. I think I saw this error until I added the second task without creating a task, but it's so rare that he didn't pay much mind, and I would just restart my VI. Now that was occurring more often, I've been tracking it. Simply by adding 'DAQmx create Task.vi' before calling Create Channel and the new task of wiring in the task, the problem seems fixed.

    It is easy to add to create a task to avoid this problem, but it seems to me that the detailed help for Create Channel indicates that it is an unnecessary step. Thank you.

    Hi MDI - AJT.

    This looks like a problem with the code you posted, by suggestion of Norbert. When you create the task handles, you should do this only at the beginning of your code outside the loop, otherwise you will create errors that you overwrite memory locations at each iteration. If you move your virtual channel calls create outside of your loops, and does not call the handle of the task to be authorized beforehand (and implicitly create the task rather than explicitly), then this behavior must stop.

    I recommend to try this with a single line, and not 7 DAQmx calls and follow the DAQmx architecture as seen in the examples under 'Help' "'find examples' and see if this behavior persists. Later architecture, I was not able to re-create this behavior.

    BeenCoughin

  • my channel DAQmx property node missing RTD?

    RTD may be available in the menu shown? I do not have a RTD hung right now; could be the problem? However, I don't have a thermistor or thermocouple and these options appear. I'm putting A, B, C, and R0 by program.

    Hi Greg,.

    By default, DAQmx filter properties that are not supported on the devices installed. So if your device does not support the RTD channels, then this is quite normal.

    However, one of your previous discussions spoke the USB-6009 case, so I tried with it. The 6009 supports channel RTD but the property for the 6009 filtering info missing properties of RTD, which is a bug. I dropped the CAR #295521 on this subject.

    The workaround is to set the property filtering node to "Show all attributes": lack of properties in the property DAQmx nodes

    Brad

  • Port USB USB-6009 bug

    Hello

    I would ask for advice. This is the scenario in a few words:

    We have a new project already written in LabView to control a mass of a machine from K - Ar spectrometer and record two analog channels of an NI USB-6009 device data. Rate is the maximum: 24 kHz per channel.

    After deployment, we started to get a DAQmx driver strange error, but only when we used a certain port on a DELL laptop (this port was a 2.0, the other SS 3.0). USB ports did not create this error. After several days, when we realized, the error is not in our LabView code, we found this conversation in the forum:

    http://forums.NI.com/T5/Multifunction-DAQ/USB-6009-overflow-error-on-continuous-mode-after-restart-o...

    We believe that it would be strange to tell the client that "Please do not use this device ON this port, because it's a little bug...". ", then

    We were very happy, because this DAQmx property through the property node solved the error of USB port (see attachment file).

    However, a few days ago, we got an unexpected behavior: our program during a mode over DAQ completed the acquisition of a few seconds earlier, then he should have done. There was no signal error, but only this strange behavior, like in the "task done? VI DAQmx reported "too early."

    Since this 'error', we could not reproduce it yet (so far), we have used the program several times without problems via this "slow" USB 2.0 laptop port.

    Well, I'm always interested in a definitive solution of OR to fix this in their products and in the DAQmx driver. I heard many colleagues that they run into this bug of USB port several times when they use NI HWs, and this problem is very annoying. I know that the solution usually easy: plug the device into a different port. But I think that these materials should run flawlessly on the USB ports on all THE...

    Hi man,

    If you found your own workaround by plugging the USB module to another USB port.

    You said the accures only mistake on the special USB computer ports. This can be caused by an internal hub used in the computer. USB hubs may cause difficulties with hardware OR.

    Do you have other questions?

    Kind regards

    Melanie

  • Close task DAQmx freezes

    Hi all

    I've been struggling for some time with the following problem, no relevant answers to it. Maybe someone here have met it before.

    I wrote a program in 2011 Labview data acquisition, using daqmx 9.3 + acquires data from a card NI 6008. The program works very well at all works with my laptop, but crashes during like every third performance on another laptop. Both have win7, the other is 64-bit (I'm not sure that matters).

    The program itself is quite complicated, so here I PASE a image of one of the parts he tends to freeze at (there are many other acquisition tasks, where it delimits to freeze, but every time that the structure of the block diagram is basically the same, with the creation and closing of the task). It is freezing more often when there is continuous sampling frequency of 1000 Hz and simultaneous treatment (trace, fft, etc.), in a regime of producer/consumer. The interesting thing is that it does not ALWAYS freeze.

    Whenever I check if the program hangs at the TASK.vi STOP without sending an error message. I can produce the same error with the simple example, I have insert below, if I run the program several times (it takes 10-20 tracks of stick to stop task.vi)

    Please, send any suggestions on what could be the problem.
    Another tip is the MAX itself gives an error of "embedded memory overflow", several times at startup. However, I tried the solution with the property node - without success.

    Dear Buadam,

    The workaround you mentioned has been implemented in NOR-DAQmx 9.4 and should be available from this version. The default value of value certainly not 1, since that would limit USB flow considerably, especially on faster devices.

    To explain more in detail: this property ("Analog Input" General Properties"Advanced" transfer of data and memory"County transfer USB) is responsible for defining the size of a USB transfer burst. The default USB transfer size is 32 KB. For a very fast channel or high County applications increases the size of USB transfer request are likely to increase flow. In this case however, we are voluntarily reducing the size of the transfer, to be absolutely sure that the bug in Windows 7 (how the system handles applicants on USB 2.0, specifically, how the packages are split) does affect us, resulting in deadlock as you packages known. So the idea here is to small enough packages to ensure that the USB driver is unable to divide, this prevents in turn also USB performance, but since the 6008 is a relatively slow, low peripheral County channel, we always have more than enough bandwidth.

    So, to summarize:

    • Please update on DAQmx 9.4 or more if you can (LabVIEW 2011 is supported up to the most recent, version 9.8)

    • I also recommend to upgrade the USB drivers from the laptop from the website of the provider as appropriate.

    • Set the AI. UsbXferReqSize to 1 once available. If you don't find it, try right-clicking on the property node, select filter... > display all attributes

    crossrulz: you have effectively reason that a finite measure stops the task once all samples have been read, so a wait until I recommended is redundant here, as it is expected to return with fact = True. The reasons why I suggested to use are:

    1. To refresh the status of the task, "check" that he has been arrested properly.

    2. To give the device of the extra time before the command stop the task/Clear task is sent.

    3. To catch errors that are stored in the DAQmx object, but not covered by the read operation, before attempting to stop/clear.

    Hope is makes sense.

    Kind regards:

    Andrew Valko

    NIH

  • Cannot undo the Trigger on DAQmx task configuration

    Hello

    I'm running into a DAQmx problem where the type of trigger for departure does not properly get sent to the material in the case following (using X with DAQmx 9.5.1 series):

    1 set up and run an output meter task finished with a trigger digital start (I have not tested other channel or other types of triggers).

    2. stop the task before a trigger is sent to hardware (I have not tested what happens that if you send the trigger first - hardware in my real application, the task is redeclenchables anyway).

    3 try to configure the task to use no trigger to start and start the task.

    4 do the trigger type queries in the software at this point says 'none', but the material is still configured to use the trigger to start.  It seems to be a way to configure the hardware to do not use the trigger at this point.

    It is an embarrassment to me because I would have liked to keep the same task autour handle, but in order to switch between the modes of trigger and no trigger I have to erase the task completely and re - initialize everything that's embarrassing for me since in my application, I have at least 2 son can stop the task and I can provide is no longer simply the task manage for each thread during the launch it.

    A simple way to reproduce the problem, just try to start the VI below:

    You can tell that the trigger is always configured as none pulse is generated, and the loop is not closed until a trigger is provided on PFI0.  Re-reading the trigger type using a property node you find it inconsistent with what really material.

    I don't need really workaround (I should be able to lead a myself who is to clear the task each time that trigger properties are task parameters changed and storage myself rather than relying on DAQmx) but I wanted to just report it as a bug.  The solution is, but it adds a lot of complexity to my request and is as ineffective as it is clearing unnecessarily and re-creating a task.

    Best regards

    Hey John,

    Good to hear from you.

    I've reproduced the problem and filed the application of Corrective Action (365307) to follow up the matter.

    Thank you.

  • Why using the driver NOR-DAQmx ANSI C functions in a thread causes a deadlock?

    Firstly, apologies if this is bad advice, but it seemed the closest fit.

    I use MSVC 2008 Express with the library in ANSI C NI DAQmx for some analog output with a box USB-6009. I create a thread to handle the signal generation is based on fixed time. My main thread running the user interface. I found that I get intermittent blockages in release, so that libraries mode NOR are responsible (in the second thread) and I use MSVCRT features (on the main thread). My test code is attached as "deadlock2.cpp".

    I used WinDbg to try to find the cause of the deadlock. Traces of the battery of my two sons are attached as t1_stack.txt and t2_stack.txt.

    It seems that the MSVCRT localtime() function uses a lock when it is called for the first time and then went to lock the Windows DLL loader lock. At the same time libraries NOR (or less libraries mxs) are responsible for locking the charger DLL is being held. The mxsutils library uses getcwd() which seems to try to block something the MSVCRT and therefore my two sons are now deadlocked.

    I can probably work around this by calling the localtime() and the NOR-DAQmx functions before I spawn my second thread so that the DLLs are already loaded in the process. However, I have no guarantee of this to continue working if something changes in the future, and if there are any locks going on finally having the DllMain() calls for a thread hanging may still cause a deadlock. If my results are correct, is it likely that NEITHER would fix the dll for not trying to make something complex in their DllMain()?

    According to NI Measurement and Automation Explorer, I'm under DAQmx libraries v9.3.5f2. I download the latest version now to try, but it will take time.

    Hi dmcminn,

    Thank you for the comprehensive and detailed bug report. I was able to reproduce the problem with NOR-DAQmx 9.6 using the code you posted. I reported it to the R & D team suitable as CAR #366538.

    I agree with your analysis of the problem. Getcwd() so the first call to __tzset() acquired _ENV_LOCK, which Microsoft has documented as the "lock for environment variables. __tzset() also called GetTimeZoneInformation(), which can load additional libraries, that you have demonstrated.

    Here are a couple more possible solutions, but they are not great:

    • Link to the static version of the CRT (/ MT instead of /MD). This would bind a separate copy of the lock of the CRT table in your program, and DAQmx would continue to use the lock to MSVCR90.dll table. They use more of the same _ENV_LOCK.
    • Build using a different version of Microsoft Visual C++ (for example 2005 or 2010). MSVCR80.dll MSVCR90.dll and MSVCR100.dll own separate copies of the lock of the CRT table.

    Whatever it is, it does not eliminate the fact that mxsutils called the CRT while now the loader lock, and this function CRT acquires another lock.

    Furthermore, the forum Multifunction DAQ is a better place to ask questions DAQmx.

    Brad

  • 6036E DAQ works do not at the same time - OR-MAX-Bug?

    Hi all

    I'm stuck with a strange question with two cards PCMCIA-6036E running on the adapters on a W7 32-bit desktop machine.

    The adapters are two Texas Instruments PCMCIA adapters PCI-slots (show different IRQ in windows device manager).

    But NEITHER MAX (5.6.0f0) doesn't recognize only one card, no matter what I do.

    Only 1 card works in both slots adapter

    Card 2 working alone in both slots adapter

    But as soon as I place the second card in the other slot (any combo of it), it does not appear in the NOT-MAX Device Manager (itshows upward in the windows Device Manager, however).

    I noticed that the serial number of the map displayed on the NOT-MAX preview is not updated tab if I switch cards - although I can see the serial number valid in the tab 'attributes', respectively.

    Name change (Dev1--> Dev2) is not the case.

    I suspect some sort of software problem; may be connected with the same serial number. It seems as if NEITHER-MAX is unaware of the second card, although they (or adaptors) seem to be clearly distinguished by windows. Maybe a problem of updating internal?

    Another symptom: I plug in map 1 and test (work), I also connect card 2 (not recognized) then I remove the card 1 and NOR-MAX always tells me that a card is installed. But the serial number is not updated and tests/self-calibration fails.

    I have not found any mention of such behavior. I now have to work with two separate computers that is terribly boring.

    Any suggestions? This has been filed as a bug, or is there compatibility problems with PCMCIA adapters?

    Thanks for reading!

    Okay, so I got an adapter PCMCIA alternative (different chipset), until the last DAQMX-improved version but no change - it is one or none.

    According to me, it's rather a problem in NI MAX Panel and not driver related - but since there is no real prospect of a solution, I give up.

    I'll mark this issue "resolved", even if it is not in a technical sense. It does not work as I want.

    Thanks for your suggestions!

  • Bug: DAQmxReadAnalogF64 (DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely) sometimes overruns or inadequate returns of samples, loop

    When you use: DAQmxReadAnalogF64 (DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely).

    set in over (and), sampling mode

    This is supposed to:

    -block forever, until the selected number of samples is available

    -return exactly what a lot of samples.

    I then run in a redeclenchables loop (some parameters omitted for clarity):

    -----------------------------

    DAQmxCreateTask()

    DAQmxCreateAIVoltageChan()

    DAQmxCfgDigEdgeStartTrig ("PFI0", DAQmx_Val_Falling);
    DAQmxCfgSampClkTiming (OnboardClock, 100_Hz, DAQmx_Val_FiniteSamps, 100_samples)

    DAQmxSetReadReadAllAvailSamp (FALSE);

    DAQmxTaskControl (DAQmx_Val_Task_Commit)

    While (1) {}

    DAQmxStartTask()
    DAQmxReadAnalogF64 (DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely, & samples_read);

    / * samples_read should be 100. process the data * /.
    DAQmxStopTask (taskHandle);
    }

    --------------------------

    What he must do, is give me exactly 100 samples, every time that happens the external trigger.

    This does not work most of the time. But there is about a 10% chance on an iteration of the loop either:

    samples_read<>

    or

    I get error - 200278, indicating that the task has stopped prematurely.

    I think that it is a bug in DAQmx, in the case of the NI 4462.

    How should I proceed? (OR does not have a public bugzilla, and I can't continue the investigation myself without the libnidaqmx.so.1.6.0 source)

    Thanks for your help - Richard

    P.S. I have set a complete program (in C) that illustrates the problem. This is essentially the code snippet above, but in an executable form.

    P.P.S. initially started in this thread, it deviates so much from the original title, it seems useful to create a new thread:

    http://forums.NI.com/T5/Multifunction-DAQ/how-can-I-detect-a-missed-trigger-i-e-2nd-trigger-arrives-...

    Hi Richard,

    I was able to reproduce the - error on my machine Windows using C 200278. What happens if you delete the validation task? That seems to prevent the error from happening. If this is the case on your machine so, I drop a request for Corrective Action for this question.

  • frequency of generation of impulses or daqmx 9.6.1

    Hello!

    I am using an NI USB-6211 to control a stepper motor. I need to generate a pulse train with the right frequency to an angular displacement of the desired speed. For this, I wrote an application in c# (.NET 3.5) using the NI DAQmx 8.8 library, and the application worked well. However, when I updated the driver for the 9.6.1 version, the same application (recompiled with the new dll) took exactly half the time to accomplish the same task. I didn't measure the output of the counter, but I guess that the generated frequency is twice more as configured.

    Is there a bug known in this version of the driver or maybe I did something wrong?

    Thank you!

    You can reach the exit?  Which of the following describes your situation?

    1. You get the desired number of pulses to twice the desired frequency.  I still think it's unlikely.
    2. You get less than the desired number of pulses to the desired frequency.  If this is the case, I'd be willing to bet WaitUntilDone wait not long enough for some reason any (check this by adding an additional wait time after waiting, but before you stop the task).
    3. You get the total number of pulses desired to the desired frequency.  If this is the case, then it seems that the software runs just as soon that he had done before (which shouldn't be a problem, should it?).

    Best regards

  • Convert DAQmx task IDS in a string

    I'm using LabVIEW to perform a generation analog DAQmx and I call my LabVIEW of CVI code via a dll.  I want to make two separate calls, one to start a task DAQmx and one to stop the task, so I need to either:

    (1) move a task ID DAQmx CVI and then again to LV

    or

    (2) convert a string of the ID for the task, pass it to CVI and then back to LV and then convert back to a task ID in LabVIEW.

    I'm sure that option 2 is the easiest option, but I don't know how to convert back and forth between a string and a task ID DAQmx.  Can anyone help with this?

    Thank you

    Joe

    Nathand is correct, it's pretty easy convert from/to the task DAQMX and String.  The two below

    Hmmmm is note expected or a bug?

    Feedback probably need an expert of DAQmx to answer that - I think it might be related to level DAQmx tasks

  • CompactRIO Variable and IO naming channel order Bug

    Hi all

    I found a bug related to named e / s and the illogical way to access their fast table according to methods. It creates a lot of work around hackery & trick to mitigate. Fix this bug would be more appreciated to a permanence of code and maintenance perspective.

    Deployment looks like this (note the scale indicated in the name):

    Yields of running code (with scaling mentioned previously):'

    It's a little too weird for the engineers used for normal operation for example in the implementation of the class outstanding world DAQmx to access I/o table based.

    Home is at the origin of the project.

    BR,

    / Roger

    Hey Roger,

    Sorry for not not follow up with you on this issue before.

    In discussions with my colleagues at the time, I think that we have determined that this is the expected behavior and that it was the order of naming of the LabVIEW project which was weird.

    In any case I've looked back at it today and ended up filing CAR 401856 on this topic for the sake of documenting this.

    Think of it as a feature for now

    Kind regards

  • Traditional DAQ and DAQmx data representation

    Hello

    I use a card PCI-6013-NOR and used DAQ_Op and DAQ_Start to acquire the data of the device (with game 1 win), who have a CCD camera to acquire data.

    I migrated the DAQmx application, it works fine, but the intensity of the curve drawn using data is lower than expected.

    During the migration of the old code, I replaced the logic below DAQ_Op

    /*------------------------------------------------------------------------------------------------*/

    TaskHandle ulTaskHandle = 0;

    DAQmxCreateTask ("", & ulTaskHandle);

    Double dMaxVolt = 5.0;
    Double dMinVolt = - 5.0;

    DAQmxCreateAIVoltageChan (ulTaskHandle, "Dev1/ai0", "", DAQmx_Val_Cfg_Default, dMinVolt, dMaxVolt, DAQmx_Val_Volts, NULL);

    / * This function handles various combinations to select the signal.
    * - Select_Signal (1, ND_PFI_2, ND_IN_CONVERT, ND_HIGH_TO_LOW)
    * - Select_Signal (1, ND_SCANCLK_LINE, ND_SCANCLK, ND_LOW_TO_HIGH)

    */

    RouteSignal();

    DAQmxCfgSampClkTiming (ulTaskHandle, NULL, dSampleRate, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, ul64SamplePerChan);

    DAQmxStartTask (ulTaskHandle);

    / * Allocation of memory for data acquisition. */
    Double * pDataBuf = new double [ulCount + 1];

    long lSamplesToRead = (long) ulCount;
    long lSampsPerChanRead = 0;

    DAQmxReadAnalogF64 (ulTaskHandle, DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely, DAQmx_Val_GroupByChannel, pDataBuf, lSamplesToRead, & lSampsPerChanRead, NULL);

    If (ulCount! = (unsigned long) lSampsPerChanRead)
    {
    }
    on the other
    {
    for (unsigned long ulIdx = 0; ulIdx)< ulcount;="">
    {

    / * psBuffer is a short table.

    * Here, I'm trying to convert and copy the new buffer (double value)

    * to the old buffer (short values)

    *

    * I guess that old values will be in the millivolts range.

    * To convert the values of v of the buffer in millivolt I am multiplying by 1000

    *

    * I don't know if it is true.

    *(psBuffer+ulIdx) = static_cast((*(pDataBuf+ulIdx) * 1000));
    }
    }

    I'm not sure whether the conversion I did new buffer for old buffer is true. I need to create a DAQmx_Val_FromCustomScale to get the same value DAQ_Op returned?

    Could you find something wrong with the logic? How can I get the same DAQ_Op value returned by the double buffer returned by DAQmxReadAnalogF64() is there any best mechanism available?

    concerning

    Praveen.DA

    The reason for your bug is that you apparently did not understand what does the DAQ_Op function. In help for this, it is clearly stated that the data returned is I16. Your choice of data F64 was an obvious conflict with how you have porgrammed traditional in DAQ board. The Council resolution doesn't really matter. The big difference is set to scale and without scales.

  • macOS bug Sierra - Possible? (Terminal)

    I use the Terminal Df-h command to find the percentage of used space on the hard drive of my Mac, and I've noticed that since the upgrade to Mac OS Sierra; It came out that I used 0% (which may not be true); I was wondering could this be a bug and this is the case with anyone else?

    In fact, it is show you used 6% of disk space. 0 percent at the end relates the number of inodes that are used (data structures that manage the different metadata). Because you have so few files you are not yet using 1% of inodes, so he says always 0% are used.

    So, no, no bug

  • Calendar Apple App Bug frozen works only with iOS 10 update grrr

    Since I updated to iOS 10 (more more later than 10.2, etc.), everything was not too bad except THE APPLE CALENDAR app, its deiving me crazy when I click on the app it's like it freezes and past shift x 50 mode still something to do with the calendar app will cause either a frozen or a black screen or white and then crashed ack to main menu. Sometimes it will allow me to create but will be trolling with typing and finally crashed or not even save it... Please HELP I am sure what else to do, I tried to download google calendar and which seemed to have something of bug he loves too then something happens. And I tried to delete it and download it again, / force delivery, nothing has changed

    Hi there calsparks!

    Thank you for bringing your question on the calendar of freezing and trolling since the update to iOS 10 on your iPhone for Apple Support communities.  I rely on the calendar to keep my life organized, so I'm happy to help you resolve this issue today.

    Looks like you did a few good troubleshooting by force to leave the app, force to restart the iPhone and deleting and reinstalling the application calendar.  At this stage my next recommendation would be to backup your iPhone, then erase and restore your iPhone as a new device, then test calendar to see if it behaves correctly, and then restore your backup.

    The backup of your iPhone, iPad and iPod touch

    Use iTunes on your Mac or PC to restore your iPhone, iPad or iPod to factory settings

    Restore your iPhone, iPad or iPod touch from a backup

    Have a great day!

Maybe you are looking for