slowing down of the acquisition loops during a window movement

[Francois Aujard]

Hello,

I put a spy that calculates the duration of my acquisition loops. When I move quickly the window of my spy (or another window), I have 3 Vi that slow down. There must be a difference between the Vi but I can't see it. Whether I am compiled or not, it does not change anything.

I also had this when I put a path command in a new Vi. When I click on the browse button, my 3 loops slow down... I don't understand... 

It's very annoying because I can't develop a new Vi with my current program running, without slowing down... Even when I want to debug my program, it's the same....  

- What could cause a slowdown of some of my Vi? It's as if it was Windows that decided.
- I tried to change the priorities of the VI's but nothing works. I never understood how these parameters worked... 

 

 

 

Thanks for your help.

 

 

 

[ensegre]

Seems like your slowing VIs have parts which force them, maybe for no reason, to run in UI thread?

[Francois Aujard]

@ensegre thank ou for your reply. I don't know. "UI thread" and "Root loop" are new notions for me, since your message last night. And how can we tell a VI not to run in the UI thread?

[ensegre]

Don't use control/indicator properties, and events in it, for example. Or defer all FP updates you can. All these have to compete, in a single thread, with the updates your "spy" (if I got you right) panel is doing, with all its timeseries plots.

[Francois Aujard]

Ok @ensegre but I use the Dynamical Events (shutdown for exemple), is it necessarry to delete the events structure? I have the same base for the Vi that are in loops that do not slow down...  

I look what is possible to arrive in the VI. Is it possible to have a problem with strict type definitions (in constant)? 

[ensegre]

AFAIU User events don't need the UI thread, in contrast to events bound to e.g. a value change or a mouse interaction in a FP control or indicator. So unless you implement your shutdown as, say, the response to a value change of your FP stop button, there should be no constraint. Other parts of your code may dictate UI thread though. CLFN configured for UI thread, for instance. The blog I linked above for example mentions that Open VI reference goes root loop if it is connected to a Path wire rather to a string wire; one would not suspect that. (You mentioned in earlier posts that you you call dynamically VIs, didn't you?)

(Strict) typedefs, I don't see why should they be related.

[Francois Aujard]

@ensegre I have found my problem 🙂. The initialisation of a FGV use property node. I put it in other VI and this solve my problem :

 

I use this VI a lot of years, with windows 7 and with labview 2017 and labview 2013. It's strange I have problem now. Never see the problem before, and I think that I have no visible problem before. 🤔

For information I use Dynamic call like that : 

Is it good according you? I am not sure I understand well the "root loop" signification... 

 

What is "CLFN" in your sentence : "CLFN configured for UI thread, for instance"

 

Thank you for your help 🙏

[Rolf Kalbermatter]

17 hours ago, Francois Aujard said:

@ensegre I have found my problem 🙂. The initialisation of a FGV use property node. I put it in other VI and this solve my problem :

 

I use this VI a lot of years, with windows 7 and with labview 2017 and labview 2013. It's strange I have problem now. Never see the problem before, and I think that I have no visible problem before. 🤔

What is "CLFN" in your sentence : "CLFN configured for UI thread, for instance"

UI Element Property Nodes ALWAYS execute in the UI thread. This applies to VI server nodes operating on front panel and control refnums (and almost certainly on diagram refnums too, but this would be pure scripting so if you do anything time critical here, you are definitely operating in very strange territory).

CLFN is Call Library Function Node. These calls can be configured to run either reentrant or in the UI thread. If set to run in UI thread and it is a lengthy function (for instance waiting for some event in the external code) it will consume the UI thread and block it for anybody else including your nice happy property nodes!

Now don't run and change all CLFN to run reentrant! If the underlaying DLL is not programmed in a way that it is multithreading safe (and quite some are not) you can end up getting all sorts of weird results from totally wrong computations to outright crashes!

So your VI may have worked for many years by chance. But as we all had to learn for those to nice to be true earnings from investments, results from the past are no guarantee for the future! 🙂 

[Francois Aujard]

@ensegre and @Rolf Kalbermatter Thank you for yours replies ! I love this forum, I learn a lot of interesting things! 🙏