06-29-2016 04:06 PM
Hello,
I have a VI written in a simple state machine format with a waiting state that is supposed to display two waveforms on the top chart and four on the bottom chart while populating a queue of 20 read cycles until a chosen waveform crosses a certain threshold. At this point it should run the read cycle ten more times (putting the threshold cross event right in the middle) and then export the data from the queue into a .tdms file. I am not sure how to make the charts display the waveforms before AND after the event triggers, since the post-trigger section is inside a for loop. Additionally, the data will not export to the .tdms file properly, but that may also be an issue with the format of my program.
Thank you if you have anything that may help, with this issue or my program as a whole. I am new to the state machine format, so I'm sure I made a few obvious errors.
Guy
06-30-2016 06:34 AM
I had a look at your VIs. There are some strange things, like using a boolean to trigger an event in the same Event Case. I feel for what you want to do, a proper Producer/Consumer pattern would be more appropriate. You use a timeout of an Event case for DAQ, and a Lossy Queue. For sure you lose data, and many operations and the overall programming style look bad.
First of all, I would decouple the DAQ and the analysis part. So the idea would be that the Producer loop is running and Enqueuing data (lossless) into the Queue. Your Consumer loop can analyze the data packages, and decide what to do. I would also use simple arrays instead of Waveforms for the DAQmx part, since you are only checking if a threshold is reached, yes? It is much easier to deal with arrays than with waveforms...
06-30-2016 08:37 AM
Thank you for your advice, however I think I did a poor job explaining what I am trying to do. The lossy enqueue is there so that I can have a 1-second buffer of data always being populated before a threshold, and then when that threshold is reached, an additional second of data is written behind that. Here is a diagram of what I am trying to do...
I also used the state machine format because I was advised by other member s of the LavBIEW forum community that it would do what I want the best. I think they are right, but I know I am executing it poorly, since I have no experience with the style. I don't want to continuously log data, which would make the most sense for a producer-consumer format, since I will be collecting data at a very high rate for a very short amount of time.
Also, I used waveforms because the Waveform Scalar Limit SubVI separates out the failure waveforms, which I used along with the Delta-T SubVI to display the amount of time that the waveform is across that threshold (Another part of what my VI needs to do).
After further explanation, if this makes more sense let me know, or else I can try to give you more information.
06-30-2016 09:36 AM
I've done some more debugging and I may have found the source of most of my problems. For some reason, the data will only display one second at a time on the waveform charts, even if I rescale the x-axis to show longer. This is causing my waveform duration vi to malfunction, because it shows only 1 second of data. This makes the delta t always 0.999. I probed the failure waveform and saw the first second of data collected, but there should be more, and it should be only from the start to the end of the time it has crossed the threshold.I need more than a second to display on the charts at once (Ideally 2 seconds), updating at the correct frequency/sample rate, and I need to display the duration of the failure after it has happened. I also switched my data collection to 2D arrays, and have attached my updated project. I also see Error 200279 coming out of my DAQmx read subVI when the threshold has been crossed.
My apologies, this has been a rough project.
06-30-2016 12:48 PM
The error code 200279 from the DAQmx Read caused by the fact that you try to acquire data continuously, but your DAQ loop is not decoupled from the data analysis part. So your code cannot "read enough fast" the data from the DAQ hardware ( http://digital.ni.com/public.nsf/allkb/AB7D4CA85967804586257380006F0E62 )
You have in principle two ways to fix this problem: