Daqmx write offset property

Hi all,
Been stuck at trying to figure out how to write/output at specific locations in an analog out buffer (seems like a simple task). I've set up a very simple test VI to play a sound file made up of consecutive 0.1s chunks of 500Hz and 5000Hz. The daqmx write offset option should be able to point to where the writing should take place so as to play just the 500Hz or 5000Hz tone.
The ultimate aim is to be able to control two analog outputs. Since the two outputs cannot be controlled independently in Labview hardware, our main VI will produce a trigger that will specify the offset locations to write from. We'll have a stereo wave file such that if we want to produce a sound in one analog out channel, the other channel will just play zeros in the 2nd column of the wave file (play nothing). The offset pointer will allow us to do the reverse (sound in one channel, zeros in another) when the wavefile is played from another offset.
Appreciate any help and comments on how exactly to place the daqmx write offset property. I'm using the PCIe 6251 board that should be able to set this offset property when task is running.
Thanks.
FA
Attachments:
test buffer for v2009.zip ‏39 KB

Hi h_Baker,
Happy Labor Day!
Really appreciate the help, but I think it wasn’t clear what I was hoping to do. I’ll be more concrete now. I have a VI that samples the singing of two birds independently. It’s done very quickly with input buffer of 5ms. I would then give each bird a white noise jam depending on whether its pitch within the 5ms buffer was below or above a threshold. The VI works fine on 1 bird and my task is now to scale it up to monitor two birds in parallel within one VI.
The issue I’m encountering is to output noise jam in one analog out channel for example for bird 1, while the other output channel for bird 2 does not do anything. But I understand that labview’s hardware cannot do this. The other channel for bird 2 cannot remain ‘silent’, but must instead play a waveform of zeros to create silence in the other channel, so that the other bird does not hear anything. Another issue is that the while loop to monitor the bird’s song and to produce a Boolean true for my counter is very quick (5ms), so my tasks to produce the white noise jam are placed outside the while loop (I tried placing the task inside; the VI runs but will just freeze and not do anything not even sample the inputs).
I’ve been trying to solve this problem for weeks without much success, and would appreciate your help. I tried implementing your case selector idea for a task (“white noise jam”) with two analog output channels. The idea is that I have 3 different stereo sound files. One stereo file has all zeros (all silence) as default when no bird is to be jammed. The second file has column 1 with white noise and column 2 with zeros (silence). When bird 1 should get jammed, I will use this waveform so that AO0 will play the white noise, while AO1 plays zeros. The third file is reversed: has zeros (silence) in column 1 for AO0, and white noise in column 2 for AO1, and should be played when bird 2 should get jammed.
I’m attaching the VI for any advice. The while loop has lots of stuff to monitor the song, but if you do a ctrl+f for COMMENT, I’ve placed comments where necessary to solve this output issue. The problem I am having is that the correct jamming on the correct channels depends on the initial value of variable “trigger”. If I set it to 1 when I start the VI, all jamming output from both bird’s singing will be to AO0, and if I set if to 2 when I stat the VI, all the outputs will instead be from AO1. I am not sure what’s going on. I suspect it’s due to the fact that my jamming task is outside the while loop and the initialization affects the output channel set?
Thanks.
FA
Attachments:
case selector.vi ‏123 KB

Similar Messages

  • Error -200609 occurred at DAQmx Write: Selected Buffer Size Too Small

    Hello, I'm writing some simple test VI's that I will eventually build upon to make an externally clocked analog output VI. I started with a very simple program to output finite samples using the onboard clock with the DAQmx Timing.VI. When I run the program, I almost immediately get an error. The error message is below.
    Error -200609 occurred at DAQmx Write (Analog DBL 1Chan 1Samp).vi:1
    Possible reason(s):
    Generation cannot be started, because the selected buffer size is too small.
    Increase the buffer size.
    Conflicting Property
    Property: Output.BufSize
    Corresponding Value: 1
    Minimum Supported Value: 2
    Task Name: _unnamedTask<1C>
    I have used DAQmx VI's before in similar applications and never encountered this error. Additionally, I read at the link below that DAQmx Timing.VI should be generating the buffer automatically. Any ideas as what could be causing this?
    Specs:
    Windows 7
    Labview 2012
    PCIe-6353 as DAQ board
    Below is a picture of my block diagram and the VI is attached.
    Solved!
    Go to Solution.
    Attachments:
    FiniteSamplesTest.vi ‏18 KB

    Oops. Just realized my very silly mistake: I forgot to add the Start Task VI. I did so and it works as designed.

  • Use virtual channel name as input to DAQmx Write? LV8 and DAQmx

    I've created a task for digital output that contains 8 named channels using the DAQmx Create Channel VI in Labview. Is it possible to use the channel name as an input to the DAQmx Write VI to reference the desired channel? I tried wiring a string with the channel name to the "task/channels in" input but I get a -200428 error that says the Value passed to the Task/Channels In control is invalid.
    The help "name to assign" input for the DAQmx Create Channel VI says
       If you use this input to provide your own names for the virtual channels, you must use the names when you refer to these channels
       in other NI-DAQmx VIs and Property Nodes
    OK, so how do you use the name assigned in other VIs?
    George

    George,
    I think that there may be some confusion here about the difference between local and global virtual channels.  First of all, please take a look at the following knowledge base:
    Physical Channels, Virtual Channels, and Tasks in NI-DAQmx
    As discussed in this KB, local global channels are created inside a task, and they only apply to that task.  In the help file for the DAQmx Write VI, the "task/channels in" description says "if you provide a list of virtual channels, NI-DAQmx creates a task automatically."  When you wire a string to this input, a new task is being created, and unless the channel name that you wire in is a global virtual channel (listed in MAX), you will get the error 200428 that you mentioned.  This is because that virtual channel that you are specifying is local to another task and is not associated with this new task. 
    One solution to this issue is to use the DAQmx Save Global Channel VI to save your local virtual channel as a global virtual channel before calling DAQmx Write.  Once this is done, you can then wire the same string constant to the "task/channels in" input of DAQmx Write or other DAQmx VI's. 
    The help text is still correct, but is only applicable in certain situations.  For example, if you create and name an analog input local virtual channel with DAQmx Create Channel, you could then use this channel name as the source input to a DAQmx Trigger VI configured for an analog edge start trigger.  You could also use that channel name as the input to the "ActiveChans" DAQmx Channel Property, which would enable you to modify the properties of that particular channel. 
    Hopefully this information is helpful to you.

  • DAQmx Write - Append samples to buffer

    I'm developing a program to play back a waveform from a large file on disk. This is 72 hours of 1kHz data on 4 channels. I can't load the entire waveform into memory, so I wanted to feed the DAQ task 1 minute at a time. I figured that I would read in a minute of file data, convert it to a waveform, and then write it to the DAQ task. While that one minute is being sent out, I can read in the next minute and convert it and have it ready to load into the DAQ task.
    The problem is that the DAQmx Write function has two "Relative To"  options, "First Sample" and "Current Sample". Given my idea above, I'd expect that there would be a "Last Sample" option as well so I could just tack on the next block of data to the end of the currently playing sample.
    I need to avoid any glitching on the line. I'm not sure if a simple write in a loop will be fast enough to copy the new data to the DAQ buffer. I don't have my hardware yet, but I'd like to have the basics of my application set up so I can plug in the hardware on the day it gets here. But I don't want any nasty suprises that would cause me to completely restructure my software.
    Are there any other functions that I could look at in order to accomplish my goal?
    Brian Rose

    Hi Brian,
    I am not sure what devices you are using, version of DAQmx and LabVIEW you are using but I have some ideas that hopefully will help you out.  First off, I wanted to reference you to an example in the NI Example Finder that I was using for testing.  The example is called "Cont Gen Voltage Wfm-Int Clk-Non Regeneration.vi" and can be found by Help>>Find Examples>>Hardware Input and Output>>DAQmx>>Analog Generation>>Voltage.  This example is what you should base your code off of because it continually writes samples to the buffer every iteration.  Make sure though to set the "Relative To" DAQmx write vi to "current write position".  This needs to be added when you are setting up the generation in the DAQmx write property node.  This setting will write the data to the end of the buffer and not overwrite your waveform.  Also, you will need to change your waveform you are writing to the DAQmx Write vi to the waveform you are reading from the file.  It sounds though that you already have this portion set up.   
    Regards,
    Jordan F
    National Instruments

  • Can DAQmx write (Digital Wfm 1Chan NSamp) output to physical channels on multiple ports?

    I'm writing some code to manage waveform outputs across multiple devices. All of the hardware presently at my disposal has at most one port of timed digital output. However, this might change in the future, and I want to make my program as general as possible. Is it possible to build a virtual channel containing lines on multiple output ports and then write to all lines of this virtual channel using a single DAQmx Write (Digital Wfm 1Chan NSamp) call? Is DAQmx Write (digital Wfm 1Chan NSamp) restricted only to lines on the same port? Do I need to use a separate virtual channel for each output port? Thanks.
    Jason Rolfe

    Hello Jason,
    You can create a task that contains lines from different ports of one same device. You can also define the "lines" input of your Digital Output DAQmx Create Channel vi to be for example Dev1/port0/line0, Dev1/port1/line0. DAQmx Write (digital Wfm 1Chan NSamp) is not restricted only to lines on the same port as long as it's from the same device. No, you don't need to use a separate virtual channel for each output port.
    Hope this helps,
    LA

  • Warning 200015 occurred at DAQmx Write (Digital Wfm 1Chan NSamp).vi:4

    Hi,
    Attached is the VI I write. But there is a warning: Warning 200015 occurred at DAQmx Write (Digital Wfm 1Chan NSamp).vi:4
    I want to use digital channel to create an output. The duty cycle change from 30% to 50% to 70%. At the same time, measure the input of another 2 channels.
    Do you have any idea about this?
    Thanks.
    Attachments:
    Digital pulse_DO Channel-1_mod2.vi ‏39 KB

    Hello,
    The situation that you are seeing here can be identified as 'glitching'.  Glitching occurs where there is potential for previous samples in a buffer to be mixed in with newer samples written into the buffer, causing a signal output that is a mix between the old and new data you are trying to output.  In the DAQmx Help document, search for 'glitching' and you will be directed to an article which explains glitching, mentions Warning 200015 is thrown where there is a potential for this to happen, and then offers suggestions on how to work around this issue, as well as two pictures that clarifies what could happen with glitching.
    This warning pops up in your application since you are writing one set of data and then writing a second set of data afterwards.  If you do not see glitching on your signal, you can modify your code to ignore this warning.  Read through the help document for suggestions on modifications that will work for your application.
    Kyle A.
    National Instruments
    High Speed Digital I/O Product Support Engineer - R&D

  • DAQmx write shown as broken, read fine

    I'm trying to bring a test up-to-date, it was originally in 8.6 and I've brought it into 11, also I can't work on it on the system where it runs. (it's heavily utilized)
    I've exported and imported the MAX settings from the old system to my system
    the VI shows the broken arrow and says the DAQmx write is broken, however if I open the DAQmx write it doesn't show the broken arrow and works fine, no errors.
    I tried deleting and reapplying the call to the DAQmx but I get the same error, reads don't have the problem.
    I also tried opening a new project, same results, VI with DAQmx write shows the broken arrow, DAQmx doesn't
    the original app writes to a NI PCI-6250 which I don't have in the my system, If I do a DAQ Assit the 6250 shows up, which in my mind means the import of the MAX settign has worked, device also shows up in MAX, but the DAQ assit VI is also marked as broken by the VI.
    using LabView 2011 SP1 and DAQmx 9.4, win 7 is the OS
    anyone have a idea of what I'm doing wrong?
    Solved!
    Go to Solution.

    Try right-clicking on the DAQmx write VI on the block diagram and select Open Polymorphic VI. This will show you all the instance VIs and flag the ones that are broken.
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • Recording what is sent to DAQmx Write

    Hi all,
    Would appreciate some advice:  I want to record and display every datapoint written as my analog output.  At the most basic level, I'm writing a waveform continuously to my analog output channel (Sample Clock with continuous samples --> DAQmx Write with analog waveform, 1 channel, Nsamples).  At some point, the user hits a "stop" button within the VI, and the signal being sent immediately stops.
    I need a way of recording what was actually written to the DAQ, and only that.  Obviously I have an array containing the voltages sent, but this is a single waveform that is being repeated over and over via hardware timing.  I need a record of how many times this waveform was actually written to the DAQ, and what the last value sent was before the DAQmx Write task was halted.
    If I were to do this with hardware, I would just connect a wire from my analog output straight to the analog input.  It seems like this should be simple to do in LabVIEW though...
    Many thanks in advance,
    Tracy

    Found a workable solution, on the last post in this thread: http://forums.ni.com/t5/LabVIEW/Is-it-possible-to-generate-a-finite-number-of-output-buffer/td-p/153...
    I've attached a very stripped-down version of my code.  The main change here is the very simple subVI FindLastVoltageSent.  I have a relatively wide tolerance on exact ending voltage sent, so this might prove problematic for an application that needed a perfect fix on the buffer location (there is obviously a slight delay between when "TotalSampPerChanGenerated" is spit out and when the task actually stops).
    Attachments:
    SimplifiedMakeWaves.vi ‏15 KB
    FindLastVoltageSent.vi ‏20 KB

  • Error-50150 occured at DAQmx Write

    Hello,
        I am experiencing a seemingly random error in a large program. The error occurs in a part of the program that simulates tach signals to a CPLD. I have not been able to find out what conditions cause this error, it seems to be random in nature.
    The full error reads this:
    Error - 50150 occurred at DAQmx Write(Digital 1D U16 1Chan Nsamp).vi
    Possible Reasons:
    The software has entered an unknown state-usually as a result of a cascade failure induced by an unexpected series of state inputs. The operation could not be completed as specified and you should immediately terminate all further transactions if you are able to do so.
    Task Name:TackABC_Write Port0 U16
    The device we are using is a PCI-DIO-32HS, with Labview 7.1, NI-MAX 4.1, and DAQmx drivers 8.3.1. The task writes 3 signals to the CPLD, and it works most of the time, but every so often this error will occur. I was wondering what could be the cause of an error like this?
    Thanks, Steve

    Hello Brian, thanks for the response.
    I made a mistake in my last post, it is actually a DAQmx clear task in place of the stop task vi i mentioned. When we first received this error it had no clear task at the end, but I added one. Even with this the error has still shown up from time to time. Would it help at all to add a reset device vi afte the clear task vi?
    I took some screenshots for you as well. The first shot is of the function in question, the second is the same shot with the case turned to false, and the third is the inside of the main subvi. When the error occurs it focuses on the write vi that is inside the subvi. Let me know if there is more info I could grab that would make things mroe clear.
    Thanks,
    Steve
    Attachments:
    SS3.JPG ‏160 KB
    SS1.JPG ‏189 KB
    SS2.JPG ‏181 KB

  • Error -200428 on DAQmx Write

    Hello,
     I am new to DAQmx, so please forgive me if this is a trivial question. I created several DAQmx tasks in LabVIEW, then wrote my vi automatically generating the configuration code by right-clicking a DAQmx Task constant and selecting generate code. When I run the Standalone Solenoid Controller.vi in the Standalone Modules folder, I get a Error -200428 during the first call of DAQmx Write.vi.
    What is going on? Please advise. Thank you.
    Best regards,
    Peter
    Attachments:
    Solenoid Controller.zip ‏657 KB

    The problem with having a single task is that you have designated those channels to be used for that task.  Once that has been done, you shouldn't be able to put those channels into another task or use them on their own.
    When wiring the channel into the DAQmx Write, a task is created.  That task is what is passed out.  So by having that channel already designated for a task, you can't put it into another one.  You need to either write to everything with a single task or separate them into multiple tasks.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Erreur -200245 s'est produite à DAQmx Write

    Bonjour,
    J'ai un système PXI-1042 avec plusieurs cartes (PXI-6221, PXI-6533...) et surtout 2 cartes de generation analogique PXI-6713. Le chassis est piloté via controleur MXI-4 déporté dans un PC.
    Nous creons des sequences qui durent 2-3sec avec echantillonage de 1ms et nous générons ces sequences en boucle. Nous stoppons la génération, changeons un paramètre et relancons l'execution de la sequence. De temps en temps, nous avons le message d'erreur suivant : "L'erreur -200245 s'est produite à : DAQmx Write. Raisons possibles : Measurements : La PLL a perdu son verrouillage par rapport à l'horloge de référence externe.... "
    Je vous ai mis en doc attaché une image de la capture d'ecran avec le message d'erreur.
    Je dois alors arreter le VI puis le relancer pour que la sequence soit lancée sans message d'erreur. Cette erreur arrive aléatoirement, parfois rien pendant plusieurs jours et parfois plusieurs fois par jour...
    Quelqu'un pourrait il me donner quelques explications concernant ce message d'erreur afin d'optimiser mon application.
    Merci d'avance
    Attachments:
    bug1.jpg ‏421 KB

    Bonjour,
    Merci pour votre réponse, je n'avais pas trouvé le premier lien sur le site de NI qui me semble correspondre à mon problème.
    >> Why do I receive Error -200245 with my X Series Card?
    Nous n'utilisons pas d'horloge externe donc j'aurais tendance à croire que l'erreur vient de cette remarque : Signal generation: The reference clock signal should be active before calling starting any DAQmx task that will attempt to use the reference clock.  Ensure that your reference clock source is generating the clock prior to DAQmx Start Task being called.
    Si je comprends bien,  il semblerait que ce soit du à une erreur de synchronisation de l'horloge PLL. C'est à dire que quand on lance l'acqui, il y a une horloge qui est créée pour synchroniser les cartes d'acqui, et pour cela, elle utilise l'horloge du fond de panier du châssis PXI. (on n'utilise pas d'horloge externe). Cette horloge référence est créée à chaque fois qu'on lance la génération et est libérée à chaque arrêt. Il semblerait qu'on lance la tache avant que l'horloge soit prête.
    Il est possible que ce soit dû au fait que l'on va trop rapidement entre arrêter une séquence et lancer la suivante.
    Je vais voir si il y a des astuces de prog pour interdire le lancement du DAQmx Start Task tant que le PLL n'est pas prêt, peut etre avez vous des infos à ce niveau? Validez vous mes hypothèses précédentes?
    Merci beaucoup pour votre aide.

  • [svn:fx-trunk] 7891: Fixed bug in effects  that was fallout from renaming offsets property to postLayoutTransformOffsets .

    Revision: 7891
    Author:   [email protected]
    Date:     2009-06-16 13:38:37 -0700 (Tue, 16 Jun 2009)
    Log Message:
    Fixed bug in effects  that was fallout from renaming offsets property to postLayoutTransformOffsets.
    QE Notes: none
    Doc Notes: None
    Bugs: SDK-21839
    Reviewer: Evtim
    Tests: checkintests
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-21839
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/flex4/src/spark/effects/supportClasses/AnimateTransfor mInstance.as

    Lots to be excited about. BUT...Just updated to 8.1 on one of my computers to test it out...
    Sadly, the following issue is NOT fixed for me. Is it with new projects only?  I haven't started a new project on 8.1 I've only opened an old project but the issue that I'm referring to which involves also a delay/freeze of anywhere from a few seconds to a MINUTE while the render bar goes from yellow to red and then back to yellow is still there. Boo.
    On the list above...
    Switching between sequences can turn the render bar red.
    This issue is incredibly easy to replicate. I really do hope it gets fixed. Here are the steps:
    1) Create two sequences with multiple short clips (the more clips the better)
    2) Make sure GPU acceleration is enabled.
    3) Add warp stabilizer to the clips in both sequences. Again, the more clips the longer the delay/freeze will be as the render bar goes from YELLOW to RED and then eventually back to YELLOW again.
    4) Hit SAVE.
    5) Now, toggle between sequences. You'll hit a short delay with a few clips stabilized and a LONG delay with lots stabilized. In my case this delay is around a full minute. The render bar will go from YELLOW to RED and then back to yellow...eventually.
    6) Toggle back to the original sequence and the delay occurs again.
    7) Once you've toggled between sequences and have gone through this delay, that's it, there is no longer a delay...UNTIL...(and here's the big kicker)...until the project is SAVED again. After that the issue returns when you toggle between sequences. Both saving manually and AUTOSAVING cause this issue. No way around it except not editing with GPU acceleration.
    Not sure what the issue is...caching issue when saving maybe? Either way, it stinks and it's still there in 8.1. Big bummer.
    Again, lots to be excited about with this release but I really was hopefully this specific issue was resolved.
    Sigh.

  • Error -200685 DAQmx Write Counter Frequency

    I have to generate 4 finite pulse trains with Counter Output and a X-series board (NI PCIe-6321). I know that with X-series boards only one counter is used to generate finite pulse train. I use LabVIEW 2010 sp1 and DAQmx 9.3.5.
    One task for each counter is created.
    When only one task runs, everything is ok, but, when more than one task runs, i receive "error -200685: Pulse frequency specified is not supported for this device given the Counter Timebase Rate." from DAQmx Write Counter Frequency. Error reports invalid data&colon; 0,000000
    I have checked data supplied and no zero frequency is passed to the VI. In fact, counter frequencies lower than 100 are forced to be 100 through a previous VI.
    Thanks for the help
    Attachments:
    Error.PNG ‏42 KB
    Zero frequencies avoided.PNG ‏7 KB

    OriginalP ha scritto:
     I payed attention to write non null frequencies and this is why this error sounds so strange to me.
    My last words... i found that two null frequencies (1018 and 1019 array indexes) were passed to Counter Output (see attached images "Counter Output Front Panel Data.PNG" and "Counter Output Block Diagram Data.PNG").
    It's quite strange, because VIs generating pulse train frequency data don't output these two null frequencies (see attached image "Array Output Data.png").
    This pair of null frequencies is random, but definetively the error is not in Counter Output DAQmx Write VI.
    Attachments:
    Counter Output Front Panel Data.png ‏33 KB
    Counter Output Block Diagram Data.PNG ‏21 KB
    Array Output Data.png ‏21 KB

  • DAQmx write problem

    Hi,
    I've designed a VI to send a ramp signal to a DA-converter but having difficulties executing it. The VI was designed and tested succesfully on a different system, but attempting to run it on my new system it does not work. The program simply won't finish. Using the highlight execution tool I see that the execution does not proceed from the "DAQmx write" box. Certainly this must be a problem related to settings or the software installed on my computer, but what might be missing? My system runs LabVIEW 2011 on Windows 7. I'd be very grateful if anyone out there could provide me with a helping hand.
    Attachments:
    VoltageRamp_ao0.vi ‏55 KB

    The vi will wait for 10 seconds and through an error if it is having an invalid task. Check the device name specified in the physical channel in the code and the MAX. Apart from that I don't see any problem with your code and it ran fine in my PC.
    The best solution is the one you find it by yourself

  • Need Regeneration in DAQmx write similar to AO write in NI-DAQ

    Actually i'm transiting my code from NI-DAQ to DAQmx almost everything working fine with new code in DAQmx.
    But i saw an option in AO write that one of its input is a boolean(Allow Regeneration). Now i transitted all my code to DAQmx i need allow regenration boolen option in daqmx so that i can trigger from a subvi to alloow generation to DAQmx write
    I'm attaching both the VI's NI-DAQ and DAQmx for reference.Please have look and help me with a solution as early as possible.
    Attachments:
    Analogwrite.vi ‏24 KB
    Analog write.vi ‏67 KB

    What's wrong with the solution you got in your other thread?
    http://forums.ni.com/t5/LabVIEW/Regeneration-based-on-Boolean-Condition/m-p/2889288
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

Maybe you are looking for