Event Trigger issue

[try_guy90]

Hello,

I have a VI that is supposed to display the acceleration and load values taken from a DAQmx. It will record 1 second before and after a trigger, which is the value of one of the waveforms on the top display crossing a certain threshold. My VI runs smoothly and displays what it is supposed to when I have it in the normal execution mode, but when I switch on Highlight Execution, an error appears that tells me i need to increase my sample rate. I know the rate I have is fine, because I have used the same rate on the same DAQmx on many projects in the past, and it only appears when the Highlight Execution mode is enabled. Additionally, it appears that the event I have chosen does not trigger a case switch, even though placing a node on the wire connected to the indicator handling the event shows that it changes value during a test run. 

Attached is my VI, I am really scratching my head on this one. Thanks is anyone can help me out. 

Guy

P.S., Here is what my test run looked like

 

Before and after crossing the threshold. Clearly the indicator is changing value, but the event structure is behaving strangely. 

[Bob_Schor]

Your DAQmx Reads are acting like a "clock" -- you've told it to continuously sample at 1KHz for some number of points (say 1000, for the sake of argument).  You do other things, but under normal execution, they finish before the second is up, so when you come back to the DAQmx Read, it is "waiting" for the next batch of points, and when the second is up, it delivers them.

Now you turn on highlight execution, and slow everything (except the DAQ device) down.  You do a Read, it gives you the 1000 points, but it now takes >1 second to get back to the next Read, so you get an error.  The Error Message says to increase your sample rate, but what it really means is that you need to decrease the time it takes to acquire (and process) the data.  Here it is not the acquisition that is causing the problem, it is the processing, which you have slowed way down.

Note that if you were using a Producer/Consumer Design, you might have been able to avoid this error, at the cost of your Queue getting extremely full (as you'd enqueue at 1000 points/second, but might be dequeuing at the equivalent of 1 point/sec).

Bob Schor

[try_guy90]

That is good to know, but is there anything I can do about that? I'm not sure how to speed up the process... 

Also, could the issue with the event trigger be due to the indicator being outside of the event structure? That has been my issue in the past, but I can't keep it inside of the value change case because it would not be accessed during the regular running case. 

Guy

[Bob_Schor]

The way you "speed up the process" is by not "slowing down the process" with Highlight Execution.  It's a Double-Negative.

Bob Schor

[try_guy90]

Simple enough, but then I am at a loss as far as debugging the event trigger issue. I tried moving it inside the Timeout case, but it still refuses to switch. 

Is there anywhere (excluding the official NI info) where I could find some examples and information on how to properly use event structures? I feel like I'm mostly guessing on how they work the majority of the time. 

Guy

[James.M]

Your problem is that a Value Change event only gets triggered when you use a property node and the "Value (signaling)" property. Local variables and indicator terminals don't trigger the event. Careful with that, though, because a False value to that property will also trigger it, so put the property node within a case structure.

Now, to address your program as a whole. This is not the way to do your simple state change. You should look in to a State Machine architecture, where you can tell the program to go to a spwcific state in a case structure, instead of triggering an event.

The Simple State Machine template that ships with LabVIEW is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

[try_guy90]

Thank you so much! I am currently working on putting my project into the simple state machine format. I do have a question about that, however: 

If my wait for event case needs to be running/displaying waveforms, where can I put my code for this that will not cause an event trigger? I had it in the timeout case on my old version, but that was a band-aid I slapped on to make it work at least a little. Is there a way to bypass the event structure altogether in the wait case?

Guy

[James.M]

The Wait for Event case contains an event structure, within which you can include a Timeout case. If you want to implement some complicated timeout code, you can create a "Timeout" state that handles that code. Using periodic timeout events with the state machine is the only way to loop continuously really, so it is a bit of a band-aid, but still simple.

A Timeout case won't run at a known interval because if you click or do some other action, the state machine will take a little bit longer to get back to the timeout state. If you need a specific loop rate, then look in to the Queue'd Message Handler architecture. But I think you cna make due with the timeout case here.