DAQ Occurrence Config

I am trying to upgrade the Traditional NI-DAQ in my project to NI-DAQmx. I am running into the problem with the DAQ Occurrence Config.vi . There doesn't seem to be an equivalent VI in NI-DAQmx. All the reading that I have done says that I should use a Timed Loop instead, but I just don't know how to fit a Timed Loop into this VI so that it works the same as before. The True/False Case Structure, the Stacked Sequence Structure, and the location of the Wait on Occurence function being outside the Case Structure all make this a difficult upgrade.
I am at a complete loss and have been pulling my hair out over this. Please somebody show me how to upgrade this project.
Thank you very much in advance.
Attachments:
DAQ.png ‏193 KB

Hi Jeff,
Thank you for your excellent question. I will do my best to answer it.
I am still very new to LabVIEW. Everything that I know has been self taught by reading the book LabVIEW for Everyone by Jeff Travis and Jim Kring plus reading the help files. I have taken over the maintenance of several programs that were written by someone who left the company 7 years ago. No one else in our company knows how to write LabVIEW code and everything that I have learned, I learned while on the job.
My task is to upgrade the programs that are using Traditional NI-DAQ to NI-DAQmx making everything 64-bit compatible. I have successfully done this with one project:
     http://forums.ni.com/t5/LabVIEW/Traditional-NI-DAQ-to-NI-DAQmx/m-p/2944596#M850161
That project was a little easier because everything had an equivalent function plus there were some great examples to be found.
For this current project what the program does is the researcher has some muscle tissue in a bath solution. A current stimulus is applied to the muscle tissue at different times and different intensities/lengths.  The program needs to record the expansions and contractions of the muscle tissue 1s before, during, and 1s after the stimulus.
     http://www.catamountresearch.com/products/myograph.htm
It is very important for the program to be recording the data at the right times.
The program itself is huge containing about 50+ VIs. The myoCMD.vi is the top most VI. There are three other sub VIs that also have Traditional NI-DAQ in them, but I figured I should start at the top.
The truth is that I don't fully know why the DAQ Occurrence Config.vi was used. I believe that it was used to synchronize with a different portion of the program. So I am trying to just duplicate the code in NI-DAQmx and hope that I don't break something.
Looking at the code the DAQ Occurrence Config.vi is inside a Stacked Sequence which is inside a Case Structure and the Wait on Occurrence is outside all of that. I don't see how I could use the recommended Timed Loop to replace it.
Sorry if this answer was long winded. I looking forward to any help that you can provide.
Gary

Similar Messages

Using DAQ occurrence to wait for start trigger

Hi,
I'm trying to use digital triggers to start and stop datalogging. Every time start trigger appears, new file is created and data is acquired to file until stop trigger occurs. Now I'm using set DAQ occurrence and wait for occurrence functions to wait for start trigger before creating a new file. The problem is that after first stop trigger this occurrence method doesn't work. I believe it's because AI is not cleared and configured before calling DAQ occurrence again. Number of scans acquired is not zero, if I don't clear and configure AI again? Am I right?
Do I have to clear and init AI everytime before occurrence config or is there a better way to make program wait for start trigger?
Thanks in advance,
Jakke

Hi Matt99eo,
Have you configured your device for triggering? Although you have not mentioned your device specifically, the M series user manual provides a great explanation of digital triggering. Using the DAQ Assistant, this can be configured from the triggering tab. Hopefully this helps!
Regards,
h_baker
National Instruments
Applications Engineer
Digital Multimeter Resources

Hi speed non-regen AO with LV DAQ Occurrences

Hi
I need to output 6 non-repeating patterns to 3 PCI-6111's @ 150kHz.
Can anyone explain to me why the attached LV7 Development Library example, with modified defaults and utilizing DAQ occurrences, will not work when more than one copy is run? When I try to run a second copy (with the device number different) the first copy produces a -10803 error.
Another example (also attached) will successfully allow 3 copies to run simultaneously. While it can get the job done, I was wanting to use the DAQ occurences, because I thought that would allow the minimum amount of CPU usage. This is the first time I've had to do anything more with AO than state levels. Am I missing something basic here?
Thanx.
Attachments:
Generate_Continuous_Sinewave_Occurences_dev1.vi ‏117 KB
Generate_Continuous_Output1.vi ‏451 KB

Hi,
I believe what is happening is that your first VI is using DAQ occurrences and locking the driver. This is because traditional NI-DAQ (before DAQmx) is single threaded meaning it can only execute one DAQ process at once. When you try to start another VI with occurrences it times out (error -10803) because it cannot access the part of the driver that does occurrences.
Since DAQmx is multi-threaded it is able to run multiple VI's and can actually trigger on multiple boards. DAQmx will support the PCI-6111 in NI-DAQ version 7.2. Until this is released I would suggest using continuous generation without occurrences when using multiple boards.

How do I set up a 6534 buffer read to just return if the buffer is not full yet?

I would like my 6534 buffer read and data analysis to run asynchronosly with other data acquisition tasks. The problem is that it waits until the buffer is done before returning and everything else is stopped. I have tried several techniques to program a continuous buffer read and monitor the state of the buffer immediately so I can skip my data analysis unless the buffer is full but nothing works.
I have tried:
Setting number of scans to acquire to zero and monitoring the scan backlog.
Setting number of scans to acquire to zero and monitoring the acquisition state in mark locations.
Setting number of scans to acquire to the previous scan backlog. This method requires a second circula
r buffer that I must manage.
Of course, with all of these attempts, the DIO start was set to 0 number of scans to acquire to make it continuous.
Is there an example of this?

Although I haven't tried this for buffered digital channels, it works for analog input channels, so give it a shot.
When using analog channels, before you call the AI Start VI, you can wire a vi located in Data Acquisition -> Calibration & Configuration called DAQ Occurrence Config vi. This VI will set an occurrence (like an interrupt) when the buffer reaches a certain size, and then you can perform your read of the buffer accordingly.
The best way to see an example of this VI is to go to LabVIEW/examples/DAQ/anlogin/anlogin.llb/Cont Acq&Chart (Asynch Occurrence). The occurrence will allow the data acquisition thread to still be open, and allow the CPU to perform other tasks while waiting for the occurrence to be set. This sounds exactly like what
you want.
I just checked the examples/DAQ/digital directory, and there is an example with continuous digital input which uses the DAQ occurrence VI as well, so this should work for you.
Mark

[svn] 779: set build.number to 0 if build.number is not set before building .

Revision: 779
Author: [email protected]
Date: 2008-03-11 11:21:05 -0700 (Tue, 11 Mar 2008)
Log Message:
set build.number to 0 if build.number is not set before building. Using the default as "Workspace" breaks builder.
Modified Paths:
flex/sdk/branches/3.0.x/build.xml

Although I haven't tried this for buffered digital channels, it works for analog input channels, so give it a shot.
When using analog channels, before you call the AI Start VI, you can wire a vi located in Data Acquisition -> Calibration & Configuration called DAQ Occurrence Config vi. This VI will set an occurrence (like an interrupt) when the buffer reaches a certain size, and then you can perform your read of the buffer accordingly.
The best way to see an example of this VI is to go to LabVIEW/examples/DAQ/anlogin/anlogin.llb/Cont Acq&Chart (Asynch Occurrence). The occurrence will allow the data acquisition thread to still be open, and allow the CPU to perform other tasks while waiting for the occurrence to be set. This sounds exactly like what
you want.
I just checked the examples/DAQ/digital directory, and there is an example with continuous digital input which uses the DAQ occurrence VI as well, so this should work for you.
Mark

[svn] 778: set build.number to 0 if build.number is not set before building .

Revision: 778
Author: [email protected]
Date: 2008-03-11 11:20:14 -0700 (Tue, 11 Mar 2008)
Log Message:
set build.number to 0 if build.number is not set before building. Using the default as "Workspace" breaks builder.
Modified Paths:
flex/sdk/trunk/build.xml

Although I haven't tried this for buffered digital channels, it works for analog input channels, so give it a shot.
When using analog channels, before you call the AI Start VI, you can wire a vi located in Data Acquisition -> Calibration & Configuration called DAQ Occurrence Config vi. This VI will set an occurrence (like an interrupt) when the buffer reaches a certain size, and then you can perform your read of the buffer accordingly.
The best way to see an example of this VI is to go to LabVIEW/examples/DAQ/anlogin/anlogin.llb/Cont Acq&Chart (Asynch Occurrence). The occurrence will allow the data acquisition thread to still be open, and allow the CPU to perform other tasks while waiting for the occurrence to be set. This sounds exactly like what
you want.
I just checked the examples/DAQ/digital directory, and there is an example with continuous digital input which uses the DAQ occurrence VI as well, so this should work for you.
Mark

IMAQ IEEE 1394 Occurrence

Hi,
I am trying to get �IMAQ1394 Occurrence Config� to work for some time, and I don�t seem to have any success.
I am using a triggered acquisition, and although the �Frame Done� event has definitively happened (I can get and display the image using �get image�), my �wait on occurrence� does nothing but timing out.
I am using the 1.5 driver.
Has anyone managed to get this working on 1394? If so, could anyone be so kind to please post some sort of simple description or some simple example on this?
I have spent already too much time on trying to get this to work, and it is getting frustrating by now . I am starting to feel that I should have bought a camera with hardware �frame done� signal instead on trusting software to do-it...
Thanks a lot,
Sorin

Hi Phil,
Thanks a lot for your help. Your example does work, however I am still a bit confused over the occurrence functionality. I�ll explain first what I am trying to achieve:
My application involves Motion synchronised with Vision. Every time a sample is positioned in the right place, a trigger signal is received, which triggers the lighting and the firewire camera. I have a 10 ms exposure time, and after that it is safe to move again. One of the requirements for the application is guaranteed no missed frames; therefore I need to chain the imaging part with the motion part, instead of having a free run motion that just sends triggering signals.
Therefore what I wanted to do is:
1.Move
2.Wait on Frame done
3 On frame done get from a queue where to go next and start motion again
4 Get image and repeat.
The point of using occurrence for this was so that motion does not wait for the frame to be transferred in the PC memory, only waits for the exposure time, which is short (around 10 ms), where the total time is 133 ms / frame. Combining this with the chained motion/vision would imply that, in the case that the CPU is free and can process images faster that the motion, than everything would run at the maximum speed, while as soon as the processing part slows down for whatever reason, the whole system slows down. Just using buffers would not help in my case, because the system is being used on a factory floor and, no matter the buffer size, it will eventually get full.
However, if I am timing the time to �get image�, as I have shown in the attached example (your example with the timing code in it) I am getting values of 1 to 3 ms, which looks to me like the time to make an image copy in the memory, and nothing like the time to transfer an image over the firewire bus. If this is the case, it looks like using firewire cameras with the NI 1394 driver would lead to an unnecessary delay of 120 ms/part, and if you consider using this on the factory floor, and making many of these parts, it will soon ad up to a lot�
Please let me know if my understanding of the 1394 occurrence functionality is right or I am missing something. Also any suggestions on how this application could be optimised are very much welcomed.
Thanks a lot.
Best regards,
Sorin
Attachments:
IMAQ1394RingWithTiming.vi ‏99 KB

Why does DAQ cause full CPU usage?

i have set up my vi to acquire a buffer of 360 data points, it acquires one point every time there is a pulse on an external channel. however whilst it is waiting for all the points it uses 100% cpu. can i stop it doing this?
Attachments:
set_up_acquire.vi ‏95 KB

Hello,
The short answer is yes. You can keep it from using 100% CPU while waiting for points. I took a look at your code. One approach would be to put AI Read.vi in a loop, read a portion of your data at a time, then accumulate all the data at the end. A way to accomplish this would be to set "number of scans to read" input of AI Read.vi to zero, watch the "scan backlog" output, then do an actual read when the backlog has the number of scans you want. This allows the program to sleep between reads. Be sure to put a small wait in the read loop.
Another approach is to use DAQ Occurrences. In this case your program sleeps at the driver level. You can find an example of this by searching on "occurrences" in the NI Example Finder.
Best Regards,
Dou
g Norman

Occurrence for digital acquisition on DAQCard

I have to count events on a digital line on a DAQCard-AI-16XE-50.
How can I do for generate occurrence when the digital line state change?
I tried with "Set DAQ Occurrence.VI" but without results.
Thank you for any help you can give me,Andrea.

Mike Manzheliy wrote in message
[email protected]..
> Hi Andrea,
> you can see an example called Count Edges (Daq-STC).vi
> from Daq Examples
> hope it will help you.
> Mike
>
Hi Mike,
thank you for the help.
An example is that I need but I don't have this on my version (5.1) of
LabVIEW.
I searched it online but I haven't find an example with the name Count
Edges.VI for DAQ-STC.
In all the similar VI examples that I have found, it's necessary to use a
counter.
Thank again, Andrea.

While loop doing AO/AI ... Performance?

Hi!
I have been trying to get a VI to do concurrent Analog
data in and out and both the input and output rates and
waveforms can change while the VI is running. My problem
is this:
(a) If I try putting the read and write operations in
separate while loops, one or the other loop will
die in a buffer over/underrun.
(b) If I put both into the same loop, then this works
but I am limited in the choice of data-rate parameters
because eventually one or the other DAQ VI will take
too long.
At this point I have only one loop and the buffers are big
enough to hold 10 iteration. Every time one of the loops
dies I reset it. Still this seems awkward. Is there a
way of improving on the loop overhead and putting t
he
input and output in separate loops? Or any other way to
improve performance?
Rudolf

Ok, I knew that ocurences did something useful but I am
still a bit confused:
* Can you set an occurrence for an output event. None
of the examples I've seen say so but it looks like
it should work
* How do occurrences actually help with the "hanging"
problem. Does the compiler see the occurrence in
a loop and change the wait parameters?
I looked at devzone but most of the stuff I found there,
even the promising looking stuff was all about
synchronizing and triggering, not about occurrences.
Rudolf
JB wrote:
: Once in the read function, the program "hangs" until the number of
: data points is in the buffer. The same applies to the write function.
: This means that most of the time, your program is waiting.
: To sol
ve this problem, you must use DAQ occurrences (--> hardware
: events).
: For examples for using daq occurrences, type "daq occurrence" in the
: search of the LabVIEW help or even better, at
: http://zone.ni.com/devzone/devzoneweb.nsf
: Hope this helps

Why doesn't my interrupt routine run when it should?

I'm performing continuous buffered analog input using a DAQ occurrence 1 (after every N scans) to read the buffer. I also use every other occurrence to time one reading from the DAQ-STC counter. Both the array from the analog buffer and the counter reading are then queued for reading in my display routine. If the user doesn't interact with the display window, the data acquisition and display routines work fine. However, if there is activity (movement of the display window or scale changes on the displayed graph, e.g.) the Wait on DAQ Occurrence vi in the data acquisition routine does not wake up and run in time to read the counter when it must (at the end of every other N analog readings) resulting in bad counter da
ta. I have tried running the data acquisition routine and the display routine in the same and different threads and I have tried giving the highest priority to the data acquisition routine, but the problem persists. This is not a matter of microseconds. The counter is supposed to be read every 40 milliseconds and can be read properly for about 20 milliseconds. Is there any way to guarantee a Wait on DAQ occurrence handler will wake up and run within this time frame? I cannot use buffered counter measurements because there are glitches in the gate signal that would cause erroneous readings to be taken.

For this reason, DAQ Events can be unreliable compared to buffered acquisitions. Simply put, if another DAQ event is flagged before your program finishes handling the previous event, you might miss the next event. It sounds like you are close to the threshold as user interface interaction causes just enough of a delay. You may have too much code in your event handler.
Russell

Multiple applications on Same PC

I am trying to run 2 applications which access different cards at the same time. One is doing a continuous analog input, the other is doing a finite analog acquisition. In that scenario, I am getting messages that either say "Acquisition already in progress" or "Unable to access Nidaq, load the driver".
I tried making a simple program that did constant reads and running them against separate cards at the same time. That worked without error, but when I shut them down and went back to the original app., it gives me "transfer is already in progress for the specified resource, or the operation is not allowed because the device is in the process of performing transfers, possibly with differn"
To answer the obvious question, yes, I
did verify that each application ws talking to a separate card.
Have you had any experience with different applications interfering with each other? This is going to be a major issue for me.
My environment is: Windows 2000, Nidaq 6.9.2, ComponentWorks 3.01, VB 6.0

Derek;
That is happening because you are probably doing a synchronous acquisition. When setting up a synchronous acquisition, the execution of the VI get stuck inside the AI Read.vi till the buffer of data is ready to be read.
The way to go about that is to set up two asynchronous acquisition tasks. You can get examples on that at Search Examples->I/O Interfaces->Data Acquisition->Analog Input->DAQ Occurrences.
Hope this helps.
Filipe

How can I use a TTL signal at my PFI to start a VI

Hello,
I am writing a VI to controll a motor with Digital Output, this is working. But this Vi has to start after the first (second, third or fourth) TTl pulse. How can I do that? I see some trigger options by AI and AO Vi's. But these Vi's are for different purposes.
Is there a simple way to "receive a pulse and than start a VI?
Thank you.

Hi wilco,
If you don't mind a slight delay on the order of a couple ms then you could simply poll that bit in software and start your sub-block when that line becomes true.
If you require more precise timing, you could use a counter and configure an interrupt to fire on the output of the counter. You would need to setup the counter for pulse generation and then configure the "pulse spec 1" register with the number of pulses you want to wait before you output (will have to be more than 1 on a counter though). DAQ Occurrence 4 will be the one you want to configure an interrupt for rising edge of a counter output. The LabVIEW help file describes these occurrences and you should also be able to find some examples using occurrences in the shipping examples.
None of them use event 4 but you can get the basic programming concept by looking at the examples.
Anyway, hope that helps. Have a good day.
Ron

How to generate an Event on Digitalnput-ValueChange?!

Guten Tag and best wishes from Berlin!
I use an EventStructure (ES) with no Timeout. One Event that is handled
by that ES is the "Control1-ValueChange"-Event generated when the user
clicks the Control1. That's easy.
Now I have a DAQ-Card with Digital Inputs and I also want the
EventStructure to react on the Change of the value of one digital input
line.
I know I could set the timeout of the EventStructure to some ms and
check the DI after Timeout and then start the ES again and so on...
But well, I dont like this.
Is there another possibility?
Thanx a lot for your replays,
Stefan

Hi Anonymous,
You might want to check-out the DIO Change occurrence VIs (DIO\Advanced.) I've never used them, but it sounds promising. Hey!, occurrences are Events too!
There's the "DAQ Occurrence", a "DIO Change Occurrence", VISA Offers it's brand of "Events", we can register the Event-case for a range of [user] events. It would be nice to see NI "normalize" event-posting across different "systems" so that a single event handler could monitor everything.
Cheers.
Message Edited by Dynamik on 03-01-2006 05:31 PM
Message Edited by Dynamik on 03-01-2006 05:32 PM
When they give imbeciles handicap-parking, I won't have so far to walk!

How to save the data from AI Read.vi?

Hi,
The main target is that testing the strength of a object which is extended by a force. The desired results are
1. The strength of object under the force(main target, I am trying now);
2. Displacement of object being extended(I have mimicly done);
3. Images of deformation of the object extended(I have mimicly done).
4. The sub procedure will stop when the object under testing is broken. I intend to use the big pulse from force sensor by analizing the data acquired.( it is more difficult if using machine vision).
What I am mainly trying to do now is implementation of a sub vi to collect the data which is acquired from channel 0 of PCI-6052E which is connected to a force sensor. I have tried to use an existing exam
ple as attached with some modifications. I have tested the data from the sensor by comparing to measurement by multimeter and it takes sense. But
1. I still don't know how to save data displayed by AI Read.vi? And use what kind data type could save more memory?
2. I think that memory management is very important because each points of the result includes its strength, image and displacement. How can I acquire enough significant points for the final results being reliable and save these data down to an array or cluster synchronously? (each sub procedure has no time limited)
3.Because I think that a continuous data acquisition would occupy ALL CPU TIME and their related images and displacements would have no chance to be taken down by CPU at the same moment. Am I right?--I am sure that it is not very difficult problem but my mind is still in caose and the time is quite limited to me now.
I am looking for your sugguestion or solution or control philosophy too. You can modify the fi
le attached if you can. I will learn from your idea.
Thank you very much for your time and energy!
Your
Swedlin
Attachments:
Acquire_N_Scans_1_10.vi ‏75 KB

Hello;
Regarding your question on the data type that would use less storage space, the answer is binary type. Actually, you can use another shipping example as start point of your application. The example I'm mentioning is a data logger, that saves binary data to a file on your hard drive. You can find that example at Search Examples->I/O Interfaces->Data Acquisition->Data Logger->High Speed Data Logger.
Regarding your question about the CPU time, the statement is valid. In case you use a synchronous AI task, the CPU execution will get stuck inside the AI Read.vi untill the buffer is ready to be read. One thing you can do about that is to change the acquisition task to be asynchronous. There is a good example in Labview showing how you can accomplish that.
You can find the example at Search Examples->I/O Interfaces->Data Acquisition->Analog Input->DAQ Occurrences.
You can combine both examples to accomplish the task you need.
Hope this helps.
Filipe A.
Applications Engineer
National Instruments

DAQ Occurrence Config

Similar Messages

Maybe you are looking for