LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event structure freezing when short delay inserted

Well, the simple stuff in LabVIEW I can do, but I'm still struggling to get my head around the concept of "Events" and how LabVIEW handles them. If I only have one type of event (i.e., pushing a button out of several on the UI, or reading a serial input and handling it programatically), I think I'm good. But my application requires me to be able to handle either of these at the front panel.

 

Going through the LV Knowledgebase got me this link (it's a little old - LV8.6, but seemed to handle the basics), from which I downloaded "events.vi" (attached). My situation is a little different, so I modified it a bit to "EventExperiment.vi" (also attached) to have a bare-bones template I could use for my application. If I run it as shown, it seems to run fine (with a serial input, the "1" and "2" lights turn off, but the Bytes at Serial Input indicator always shows "0" and the "Serial Indicator" light never lights - I am assuming that these change and revert too quickly to see in the UI). My concerns with my VI are:

 

If you add a short delay in the processing of the serial input event (say 1 second delay in that event case, or even a 1 second delay subVI after the serial flush connected through the error line), the VI accepts no further UI input after the first serial event.

 

If you add an error wire through all the events subVIs (whether you merge this wire with the one going through the serial subVIs, the program just hangs up.

 

 

And, one little bothering thing is that the original "events.vi" takes three presses on the "stop" button to close. I'm figuring here that it's because of those local variables being passed between loops, but it hasn't been enough of a bother to worry about.

 

Your help is greatly appreciated,

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
Download All
0 Kudos
Message 1 of 6
(2,957 Views)

I do not think this will solve all your problems, but I would move the external loop (check port section) into the event structure.

The obvious place to do this would be in a timeout state.  This also gets rid of all of your stop local variables.

Also it is probably not healthy to constantly poll the serial port for the number of bytes available without a pause...

0 Kudos
Message 2 of 6
(2,954 Views)

When you have a byte at serial port your while loop keeps generating events at a tremendous rate.

This is even more critical if you put a delay in the event case with the flush serial buffer vi...

What happens if a byte is received at the serial port while your event case is waiting?

 

How many events are fired and need to be processed? For each of them you will wait 1s... and that's why (in my opinion) your software hangs...

 

 

Marco

 

 

 

 

0 Kudos
Message 3 of 6
(2,950 Views)

Something more like this

 

2013-07-18 10_28_58-EventExperiment.vi Block Diagram.png

 

 

Message 4 of 6
(2,944 Views)

Well, I thought I'd add a final post for some closure to this one.

 

To summarize what I was trying to accomplish: I wanted to have some kind of an event structure where you could use both regular User Events (button pushes, numerical control changes, etc.) and an outside (non-keyboard/mouse/touchscreen) event, like a serial character coming into a COM port, to initiate an action. This was to eliminate a loop where the computer would be polling the COM port continually at a pretty fast rate. (I must have read a hundred times in the past month that you don't want to run a While loop for polling if you can help it.)

 

It turns out (after a couple of confusing days, I talked with the NI service engineers) that you can't do this. In order to detect a character at a COM port, you have to be polling the port periodically with a Read and look for a change in the bytes available or another parameter. You can do this through a timed loop separate from your Event loop or through a Timeout event case inside the loop, like Don_Phillips suggested.

 

However, I believe I'll go the separate loop route, since my head's actually more comfortable with it than the Timeout route.

 

Thanks, folks, for your help,

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
0 Kudos
Message 5 of 6
(2,900 Views)

In general I would neve place code in an event structure (that also handles UI events) that would read from any interface. The reason why is because it has the potential of inducing lag for responding to UI events. For example, if you are reading a large number of bytes from the serial port and the user clicks a button, the UI event won't be handle unil the read completes. A good rule of thumb is to keep any processing within an event structure to have an execution time of about 100ms or less.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 6
(2,883 Views)