Jump to content

Remote window with scrolling text


Recommended Posts

This set of VIs demonstrates how to setup an independant VI that displays text sent from anywhere in you application and also appends the text to the bottom of the window and autoscrolls up.

I used VI server to implement the independant display VI and control it. You could adapt this code easily to direct the data to a FP display on another VI by passing it's reference around. You would still need to implement a parallel loop in you VI with the display to handle the scrolling of the indicator.

I hope this is useful to some of you.

-John

Download File:post-2411-1144691172.zip

Link to comment

Nice... I use a similar approach for execution log while debugging applications.

If I'm allowed: In your "Write to Text display.vi" you should close the references (panel & controls[]), or your memory consumption might become bigger and bigger (especially if you use this tool quite often). Each call from this vi creates new instances of the references.

Didier

Link to comment
If I'm allowed: In your "Write to Text display.vi" you should close the references (panel & controls[]), or your memory consumption might become bigger and bigger (especially if you use this tool quite often). Each call from this vi creates new instances of the references.

Didier

Hmmm.... If I close the only open reference to the VI, won't it be unloaded from memory? :question:

Besides that, by only opening the reference on 'first call' and then storing it in a global (which is used on subsequent calls), there never should be more than one open reference, right?

-John

Link to comment
Hmmm.... If I close the only open reference to the VI, won't it be unloaded from memory? :question:

Besides that, by only opening the reference on 'first call' and then storing it in a global (which is used on subsequent calls), there never should be more than one open reference, right?

1. If you close the only reference, then yes the vi will be unloaded. But you store the ref into a global, therefore it never unloads.

2. I didn't meant the ref to the vi you should close, but the subsequent refs. The one to the panel and the ones to all the ctrls on this panel (see picture).

post-253-1144821285.png?width=400

Link to comment
1. If you close the only reference, then yes the vi will be unloaded. But you store the ref into a global, therefore it never unloads.

2. I didn't meant the ref to the vi you should close, but the subsequent refs. The one to the panel and the ones to all the ctrls on this panel (see picture).

post-253-1144821285.png?width=400

Yes, I store the ref in a global. In the example code, I do close that ref when the user exits.

With regards to the references to the controls accessed via property nodes, since these 'references' were never opened, there is no need to 'close' them. They exist in memory as long as the VI that they belong to exists. They are really just pointers or 'sub-references' of the VI and not independant instances of the control in question.

A good experiment would be to open several instances to a single VI, then close them one at a time and test your references after each close to see if they are still valid. You should see that the references not closed are still valid, since the VI is still in memory until the last reference to it is closed.

Now, open a single reference to a VI and then access the references to the controls on that VI's front panel. Test each of these control references to see if they are vaild. Now, close the reference to the VI and re-test the control references, you should see that they are now invalid, since the VI is no longer in memory, even though you never 'closed' the references to the controls.

A reference to a VI adds 1 to the # of callers list and causes it to stay in memory as long as the callers list is >1. This is the same way Windows works with DLLs.

A reference to a control is neither opened or closed and is just a 'far pointer' to a data/display element of a VI in memory.

I hope that clears things up a bit. See the attached VI as a demonstration of this.

-John

Download File:post-2411-1145311174.vi

Link to comment
Yes, I store the ref in a global. In the example code, I do close that ref when the user exits.

With regards to the references to the controls accessed via property nodes, since these 'references' were never opened, there is no need to 'close' them. They exist in memory as long as the VI that they belong to exists. They are really just pointers or 'sub-references' of the VI and not independant instances of the control in question.

A good experiment would be to open several instances to a single VI, then close them one at a time and test your references after each close to see if they are still valid. You should see that the references not closed are still valid, since the VI is still in memory until the last reference to it is closed.

Now, open a single reference to a VI and then access the references to the controls on that VI's front panel. Test each of these control references to see if they are vaild. Now, close the reference to the VI and re-test the control references, you should see that they are now invalid, since the VI is no longer in memory, even though you never 'closed' the references to the controls.

A reference to a VI adds 1 to the # of callers list and causes it to stay in memory as long as the callers list is >1. This is the same way Windows works with DLLs.

A reference to a control is neither opened or closed and is just a 'far pointer' to a data/display element of a VI in memory.

I hope that clears things up a bit. See the attached VI as a demonstration of this.

That's all right. I absolutely agree with you. :thumbup:

...but, what I tried to say is shown in the attached picture. The snapshots in the profiler were taken after 1,100,200,400 calls of your vi. I have seen applications where people wanted to run an app for long term experiments and somewhere in the middle of the night it crashed, just because of a single forgotten "close ref" and therefore the computer running out of memory.

post-253-1145342916.png?width=400

Link to comment
That's all right. I absolutely agree with you. :thumbup:

...but, what I tried to say is shown in the attached picture. The snapshots in the profiler were taken after 1,100,200,400 calls of your vi. I have seen applications where people wanted to run an app for long term experiments and somewhere in the middle of the night it crashed, just because of a single forgotten "close ref" and therefore the computer running out of memory.

post-253-1145342916.png?width=400

It all depends on LabVIEW versions too. Before 7.0 (or 7.1 I'm not exactly sure at the moment) it was imperative to close all references always no matter how you got them. Since then you need to close explicitedly opened references only but as a matter of good style closing all references anyhow properly is always a good idea. LabVIEW will know about those that don't need to be closed explicitedly and just execute a NOP instead of the close operation. This saves you the headache of remembering (or experimenting) what needs to be closed and what not.

Rolf Kalbermatter

Link to comment
It must be 7.1, since it's the version I used to make the test.

I said BEFORE :laugh: and I verified it's before 7.0.

So what you were experiencing is probably anothere issue. You can check the issue by typecasting the refnums into int32. If the value of a refnum changes between repetitive executes of the VI then it is a refnum that needs to be closed explicitedly in order to avoid memory leaks during execution of the VI. Note that LabVIEW does dispose of refnums anyhow as soon as the top level VI goes idle so if you are not creating refnums over and over again in a loop you are not exactly in deep shit, it's just not a nice and welbehaved application.

Rolf Kalbermatter

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.