Event Structure's TImeout Causing Lag

[Daniel_Novo]

Hello,

My philosophy to structure a user interface is using a "main" VI to launch and control other sub-vis. In the main "VI" typically I have a big'o Event Structure. On its timeout I query the execution status of the sub-vis in order to enable/disable the users options on the "main" VI. 

This basic premiss worked fine in a number of "main" VI. I started another "main" VI recently  and for some reason I can't compreehend I see the Windows processing (turning wheel) every at every timeout execution. In the "good" VIs, see example attached, I perform many and more complex queries and I don't see Windows processing anything. But on the "bad" VI for some reason this happens.

Does anyone have a hint as to why this is happening?  

Thanks.

Daniel 

[GerdW]

Hi Daniel,

---

@Daniel_Novo wrote:

Does anyone have a hint as to why this is happening?

---

Is that VI (or its frontpanel) large or does it need to handle a lot of data (in the frontpanel)?

Which function exactly is slow? Opening the VI ref or reading the ExecState?

Btw. usually it is not recommended to use CurrentVIsPath. Instead using the AppDir constant is promoted…

And why don't you use a subVI to read the ExecState of a VI given by string constant (to reduce code duplication)?

[Daniel_Novo]

Hello GerdW, 

there is almost nothing on the "bad" vi's front panel. A couple of dials and 4x boolean controls to call the sub-vis. In any case a lot less than what I have on the "good" VI. 

I guess I could've optimized the code using a subvi for the queries. On the other hand I had space so it was just a matter of copying and changing the VI reference. I will change the File Constant. 

I just checked the CPU usage. On the good VI I am below 10% on idle state. With the bad VI it is almost 40%. When I remove the query code from the timeout it drops to almost nothing. 

Is there any obvious reason why one VI should work perfectly and the other not? I think I will start the second VI from scratch to see if there is any obvious reason.

BR, 

Daniel  

[Daniel_Novo]

Update.... when I call the sub-vi the "lagging" stops. The spinning wheel goes away. 

[Daniel_Novo]

Newst update... I left the VI running for some minutes and the "strange" behaviour went away. SO... there's that. 

[altenbach]

You talks about event structure timeout and lag, but only show truncated pictures of code that has no obvious relation to any of this. What is a "big'o Event Structure"? What is the timeout?

Why is there so much duplicate code? All you probably need is autoindex over an array of VI names.

[rolfk]

The main difference between good and bad is that good all starts VIs SA_<something>.vi while bad starts a cf_table.vi. My "highly educated" guess is that your cf_table.vi is the culprit as its event handling is sub-optimal.

[Daniel_Novo]

Dear Knights!

Thank you for your constructive inputs. I've posted some updates. I'd guess the issue I faced has something to do with labview as an IDE (if such term applies to it) or how code is compiled by it.

Nevertheless, keep in mind this is the babbling of a mere plebe. 

GSK

[altenbach]

---

@Daniel_Novo wrote:

I've posted some updates.

---

Where?

---

@Daniel_Novo wrote:

I'd guess the issue I faced has something to do with labview as an IDE (if such term applies to it) or how code is compiled by it.

---

I have absolutely no idea what you are trying to say here. 😮

[Yamaeda]

I don't understand what you're trying to do, but i'd use a Static VI ref instead of building paths and opening and closing refs.