Event structure causing other code not to run

[rscott9399]

Hi

Another rookie question here.

I have one VI and it is running a while loop that never stops

I have a simple path control and path indicator just tied to each other for no other reason then testing.

When i add an event structure inside the while loop, the path control and indicator will not execute

When i delete the event structure it works just fine

To be clear, there is nothing in the event structure. They simply share the same while loop.

With the event structure, it wont run, without it, it will run

Putting a probe on the path control and i get "not executed"

Anyone can think of a reason why?

 

Edited April 30, 2019 by rscott9399

[Tim_S]

A while loop iterates once everything in the loop has completed. The event structure has a timeout (little blue box in the upper left corner of the structure) that defaults to -1 which is no timeout. So what is going on is the while loop is entered, the input path control is written to the output path indicator, and the event structure waits for something to happen. And waits. And waits. And waits. The while loop never iterates as the first iteration hasn't completed yet.

With the probe, unless you have "Retain Wire Values" selected (icon up in the button bar of the block diagram) then the probe can be misleading. If you don't have it selected, the "not executed" really means not-executed-since-you-created-the-probe. Turning on "Retain Wire Values" before you run a VI changes that to a literal meaning.

[rscott9399]

I thank you for your reply

However , i am a bit confused

You mean to tell me that because the event structure is waiting for an event, it is going to sit there and hose the rest of the system doing nothing until it gets an event?

How are other VI's executing then?

Thanks in advance

 

[smithd]

to convert this into c-style:

while(1) {

pathwire=pathin

waitforinput(timeout=forever)

pathout=pathwire

}

 

you didnt 'hose the rest of the system' but your loop will stop because you told it to wait for input. You generally have many many many loops in a labview program. You can change this loop to a polling style by setting timeout to something besides forever.

also note that the order of operations in the loop is not specified. I wrote one possibility.

Edited May 2, 2019 by smithd

[Tim_S]

To add to what smithd said... The biggest difference with LabVIEW versus other languages is that it is a data-driven language, meaning if something has new data at all of the inputs then it executes. LabVIEW is inherently multi-threaded because of this (there is some exceptions to that when dealing with DLLs and the like).

So, looking at your code... The while loop has no inputs, so it will start immediately. The "input path" control has no data coming in, so it outputs a value that goes to the 'output path' which will display the value as that's the only input. The event structure will start and wait as it's input is some event to occur. The event structure and input/output path will occur 'simultaneously' as there is no data dependency (output of one to input of another) between the two. Similarly, other VIs you have can continue to run the same way if there is no data dependency.

[smithd]

I re-read your (rscott) post and it occurred to me you might be missing something more fundamental wrt labview applications. I don't claim that this code is good or bad, but it can serve as a reasonable example for this conversation: https://forums.ni.com/t5/Example-Program-Drafts/LabVIEW-Real-Time-Sample-Template-Embedded-UI/ta-p/3511679?profile.language=en

 

Note that there is some UI code, but theres also a deterministic control loop and various monitoring loops.This is typical and in fact kind of on the low side. This is why message oriented frameworks like actor framework or drjdp's messenger library or delacor's dqmh are fairly popular as they provide some of the plumbing and structure common to many applications.