Jump to content

slowing down of the acquisition loops during a window movement


Recommended Posts

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... 

 

 

563761136_Tpsboucle.png.82ba906f56cf7bcfffdaabf9faf821b1.png

 

Thanks for your help.

 

 

 

Link to comment

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.

Link to comment

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.

Link to comment

@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 :

 

472847736_AdaptationType.png.8a6eac5bc62208828625e36c86a887f8.png

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

image.png.0966c8929efa6092594c90e363163588.png

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 🙏

Link to comment
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 :

 

472847736_AdaptationType.png.8a6eac5bc62208828625e36c86a887f8.png

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! 🙂 

  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.