Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

Error 200019

I found many posts about this problem here but can't find solution. I have NI X USB 6343 ( 32 - channels, max rate 1-channel - 500 kS/s). I'm using only one channel, I trying to set rate about 10000-50000 and i get this error. Also i found one useful message i guess - "Calling a signal "noisy" is all relative.  There isn't any built-in hysteresis on the PFI lines so if there is even a small glitch around the transition point the DAQ card might pick it up as two edges which are very close together.". Maybe that is the problem ?

Thank you,



0 Kudos
Message 1 of 13

Hello Nilukas,


I saw your VI and I have some questions for you. The first one is: why are you using a while loop if you are trying to do a finite sample? If you use a finite sample you do not have to use while loop. You use the while loop when you want to do a continuous sample.


2- Why are not you wire the error wire through all the functions VIs? and Why do not you use a simple error handler?


I run your VI with some modification that I did (practically the suggestions/questions that I did above) and it runs fine, I just removed the trigger and the retriggerable option because I used a simulated device.


So here is the VI set for been a finite sample and for future applications please use the wire the error input and output and use a simple error handler, it is a good programming practice.


Also if what you want to do is a continuous sample, please use an "OR" and wire there the error and the Boolean button that you create.


Please refer to this white paper and take a look to the point 9 of the title "Manipulating the Conditional Terminal"


So give it try and let me know how it goes





0 Kudos
Message 2 of 13

Hello keroba, thx very much. I'll try it.

0 Kudos
Message 3 of 13

Hello again, thx for advices, now all works fine, BUT how can I do triggering digital signal everytime  but not just once at start programm

0 Kudos
Message 4 of 13



What's the nature of your trigger signal?  I wonder if you are seeing this error because you are getting a trigger basically at the same time the previous acquisition ends.  In this case, I think your device would begin a new acquisition, but perhaps with a turn-around short enough to violate the ADC's timing requirements.


If this is indeed the case, you can work around this condition by setting a start trigger delay of the min sample period for your device (2 uS for USB-6343).  To do this, you'd insert the DAQmx Trigger Property Node, and write to the Start->More->Delay and Start->More->Delay Units property.  You'd set Delay to .000002, and Delay Units to Seconds.  With this setting, your device will start acquisition 2 microseconds after the start trigger, however, it should ensure that you have ample time between then end of one acquisition to the start of the next for the ADC to settle.


Hope that helps,


0 Kudos
Message 5 of 13

My trigger signal 200ns but i don't understand. My trigger works just one time, when I start the program. Because when I disconnect the wire when program is runnig nothing happens, but when I disconnect the wire before I run program, program doesn't work and without error. And my question how can I use this trigger on all acquisition ?

0 Kudos
Message 6 of 13

Let me make sure I understand what you're seeing:


With wire connected (I assume from trigger source to PFI0), you see one successful iteration of the while loop.  After this, either then second iteration of the loop, or some iteration which follows errors with code -200019.  Do I understand this correctly?  If so, here is my explanation:


My thought was that if you were using a fast, periodic signal as a trigger, then there would be a chance that by virtue of starting your second acquisition (when you receive another trigger signal on PFI0).  I'll try to demonstrate with ASCII art below:


Trigger:                                                           _            

                              __________________|  |______

Sample Clock:            _                    _              _

                               ___| |________| |______| |_____  <- Assume 1st two sample clocks are the last clocks of 1st acquisition.  Third is result of of trigger (since you have retrigger enabled).

Convert Clock:                _                    _             _

                               _____| |________|  |_____| |___  <- Error here (3rd clock)... notice the short period between the 2nd and 3rd clocks:


In this case, we've enabled retriggering, and the trigger signal arrives just after the end of the first acquisition (2nd convert clock drawn).  It immediately begins a new acquisition.  By default, DAQmx will program the hardware to  sample as quickly as possible after a start trigger (I believe time from trigger to first convert clock should be on the order of 40 nS).  As such, this leaves a window of time after hardware has completed its last acquisition where a trigger will cause it to restart a new acquisition before enough time has elapsed to satisfy the ADC's settling requirement (in your case 2 uS).  When we set the Start.Delay property, we for hardware to wait between receiving a start trigger and issuing clocks.  I will attempt to demonstrate this below:

Trigger:                                                           _            

                              __________________|  |______________

Sample Clock:            _                    _                                 _

                               ___| |________| |______________| |_____  <- Here we've programmed hardware for a 2 uS Start.Delay, so our sample clock is delayed by 2 uS.

Convert Clock:                _                    _                                _

                               _____| |________|  |_____________| |___  <- The above delay pushes out the convert clock, and we no longer receive error -200019.


I hope I'm understanding the issue that you are seeing correctly.  If I am, then I think that the Start.Delay property should fix the error you are seeing after the first iteration of your loop.  If I don't understand your issue, please let me know where I have misunderstood.


Hope that helps,


0 Kudos
Message 7 of 13

Dan, a little bit wrong, now error is disappeared, after first iteration nothing happens with trigger i.e first iteration works correct but second and other iterations just works with no trigger even I disconnect wire, acquisition continue without changes. I think it's wrong , right ? I think when I disconnect wire trigger while program  is running it should stop all, because signal passes through the trigger.

0 Kudos
Message 8 of 13

Schematically, I hope this is understandable Smiley Happy

0 Kudos
Message 9 of 13

I'm confused now... In the first VI attached, you were using retriggering.  In the png from your last post, you had removed retriggering.  What is your desired setup?


I've taken your VI and modified and done some testing with my PXIe-6361.  Here's what I tested:


*note: I set DAQmx Read->OverWrite property to 'Do Not Overwrite Unread Samples'


1) Retrigger enabled - No Start Delay - 10 MHz trigger signal:

           - Receive error -200019.

2) Retrigger enabled - Start Delay - 10 MHz trigger signal - 10 MS buffer:

           - With trigger signal enabled, everything works as expected.

3) Retrigger enabled - Start Delay - 10 MHz trigger signal - 10 MS buffer - put 5 ms delay in loop - this would approximate some amount of processing delay

           - Appears to work as expected, however when I stop the trigger signal, the loop continues to iterate for some time.  This makes sense.  Since our buffer is huge, and our acquisition takes only 400 microseconds, we queue up multiple acquisitions in the buffer which we read through after triggering has stopped.  Is this what you're seeing?

4) Retrigger enabled - Start Delay - 10 MHz trigger signal - 200 sample buffer - 1 ms delay in loop

           - Error -200222 - input buffer overwrite after a few iterations of loop.

5) Retrigger disabled

          - Valid read on first iteration, followed by error -200278 (attempted to read beyond final sample acquired) on second.


All of these behaviors make sense to me, and seem correct.  Based on what's been written here, I think I've tested the possible configurations you have tried.  Are there any of these that you have tried, and seen different results?  I'll post the VI I used for this, and maybe you can try it on your device and see if you get the same results.  Note: for my trigger source, I just used a counter from my device which I controlled with a test panel.






0 Kudos
Message 10 of 13