One more thing. I just tested how long it would take the waveform to change scale. With a waveform of 64 values, at about 123 sample/sec with sample size =1, it took ~65-70seconds. This comes close to the 8191 samples that are in the FIFO, which would indicate that this is getting filled with repeats of the waveform.
Thanks for the extra information. The 65-70 second delay makes perfect sense since the FIFO is so large relative to your sample rate (8191 samples / 123 Hz = 66.59 seconds).
The way around this is going to be to control how fast we write data to the buffer so that we don't have to fill the entire FIFO. There are a few ways one might do this. For example...
I added an event structure to the existing code which will block the loop until the next N Samples have been generated from the buffer. This way, we avoid writing new data to the buffer until the same amount of existing data has been generated. The initial loop iteration writes an extra copy of data to ensure that we prime the buffer with enough samples to avoid an underflow. So, you should see an update to your AO data after about 0.5 - 1 second given the file size and update rate you are using.
Thank you once again.
The loop does what I had originally set out to do all those months ago.
I'm going to have to go over the Event Structure in detail since I haven't worked with them before, but I think I understand the general idea of what is going on. This has been quite a lesson in Labview programming!
Glad to help.
Here's a link with a little more information about Event-Driven Programming:
Event-Driven Programming in LabVIEW
In my example, I'm using a DAQmx Dynamic Event (Every N Samples Transferred from Buffer). So, the event structure will execute every time N Samples are transferred to the board. The event structure is a blocking call so you cannot go on to the next loop iteration until it has executed. There is an event for the stop button as well so you may break out of the loop immediately if you need to. The timeout case is there in case there is a problem with your task and no samples are being generated.
Note that you could accomplish the same behavior with a timed loop that is timed off of the Every N Samples Transferred from Buffer event. This might be a bit more intuitive, but since we had the existing code it was a little easier for me to simply add the event structure into the loop.
I just got back from vacation and started incorportaing the Event Structure you created into into my existing code. I found that it doesn't seem to update the changes to the waveform any faster than before. I went back and played with your example. Switching between steady state and "waveform" took about the 66 seconds as before. I tried experimenting with the Event Structure, but quickly found out that the Base package does not have the ability to create or edit Event Structures. Any ideas what may be going on?
Also, is the timed-loop method you mentioned of achieving the same effect also an Event Structure, or something else?
P.S: I also cleaned up the way I extract and pass along the timing parameters from file, now using Local Variables
According to the LabVIEW Help documentation event-driven programming features are available only in the LabVIEW Full and Professional Development Systems. You can run a VI built with these features in the LabVIEW Base Package, but you cannot reconfigure the event-handling components.
The timed loop that John mentions is something completely different from an event structure. You should be able to find the timed loop on the Functions Palette>>Programming>>Structures>>Timed Structures.
Hi Barron, I think I am guilty of poor writing structure. By "Any ideas what may be going on?" I was referring to the Event structure not seeming to limit the FIFO size. In the previous section I was writing that I had learned that the Base package did not allow one to edit or create the Event Structures.
Anyhow, I took a look at the timed structures, a bit confusing still, but will pursue if no solution to the existing VI surfaces.