Unresponsive LabView GUI during executions

[CIM1]

LabView 8.51 TestStand Custom Operator Interface - I have an intermittent problem with executionswhere the front panel sometimes becomes unresponsive and objects do not get updated. This can happen when dragging splitter bars or when objects are being changed programmatically (e.g. button states or visibilities) during an execution.  The execution view still updates and indicators are getting updated but regular non-teststand control objects do not respond to user input (e.g. splitter bar drag, select tab, click button).

However if I open another non LabView window (e.g. windows explorer) over the front panel and then close it, the front panel becomes responsive again - an instant fix but not very convenient.

I have tried messing with execution priorities and also reducing the amount of background processing going on in the GUI (which has an asynchronous while loop for background tasks) but it still sometimes happens, for example when clicking an Abort button to terminate the execution. 

Putting a delay in the timout event of my main event loop seems to help reduce the chance of lockup but I am concerned it may still occur occasionally.

Is there a means of pinging the operator interface programmatically somehow to refresh it in the same way as opening and closing another window on top of it - or any other ideas how to fix this?

[RayFarmer]

Hi,

What TestStand version are you using?

Regards

Ray Farmer

[CIM1]

I'm using TestStand 4.1

[Hillman]

Hi CIM1

I hope your well.

In general, maybe look at this link on teststand performance, maybe your application is rather large and therefore it will take time for some of your elements to load.

So is it just the ActiveX controls which dont freeze? Because this would seem to be a CPU useage issue - even though, you seem to have looked at this.

However, it would seem its more of an issue with your vi performance. I would normally suggest the improvements you have tried, so this is interesting.

Is it possible you could send me some code that generates this behaviour? and is your teststand application particularly large?

Also, until I see some code maybe I can suggest looking at the examples and good GUI programming technqiues.

ps Another question - what else do you have running on the machine?

Regards,

[CIM1]

Hi, thanks for the reply.

In general, maybe look at this link on teststand performance, maybe your application is rather large and therefore it will take time for some of your elements to load.

Not sure about loading - I expected most objects should be loaded by the time the freeze happens midway through an execution while I drag a splitter bar or hit the abort button?

So is it just the ActiveX controls which dont freeze?

Hard to say as most of the FP input is disabled by design during execution anyway - but various non-activeX indicators still update (updating execution progress etc).

Because this would seem to be a CPU useage issue - even though, you seem to have looked at this.

Well the CPU cores are ticking along at only around 20% average loading with no obvious blips in Task Manager when the lockup happens. 

However, it would seem its more of an issue with your vi performance. I would normally suggest the improvements you have tried, so this is interesting. Is it possible you could send me some code that generates this behaviour?

Thanks, I would need to do some work to condense an example of the problem before sending anything...

and is your teststand application particularly large?  

the actual sequence? not particularly large - maybe 100 steps. I have removed all instrument calls for testing offline.

Also, until I see some code maybe I can suggest looking at the examples and good GUI programming technqiues. ps Another question - what else do you have running on the machine?

Thanks for the tips.

I have not much else running normally. It has happened on two different systems with different software. I have also built an executable and had it occurs with that also.

One other thing - when it freezes during execution while running the VI (not the exe) - if I access the VI block diagram, that is frozen too - I can't raise that on top of the FP to unfreeze it. Whereas when it is not frozen I can bring the .fp to the front while the GUI is running.

[Hillman]

Hi.

Could you then just send us your code then, and maybe I can spot something.. are you using event structures?

I am also looking into how you could control the refresh rate.

Regards,

[Hillman]

Hi CIM1,

Hope your well.

You haven't responded if awhile - so I was wondering what the news is on the problems with teststand.

Regards,

[CIM1]

You haven't responded if awhile - so I was wondering what the news is on the problems with teststand.

Hi, sorry for delay in response, I was out of office for a couple of days. No further progress on a fix here alas.

I still need to clean up an example to send but can you tell me what is the protocol for sending such things? I can't post the code on the forum.

Many thanks.

[Hillman]

Hi.

If you could send the code to National Instruments Tech Support UK, I will (this once) allow you email support - unless you own SSP with NI? If you could tell me your email address I can also send you an email to send you code in.

It would seem to me that in your code somewhere you have deffered panel updates somehow.

There is a property node which defers panel updates, and if you bring up a screen across it - it does indeed force a refresh (an update) - this is what your seeing!

Also, activeX objects run in a different thread to LV, which is why only some of your objects are freezing. 

Regards,

[CIM1]

Hi again, 

If you could send the code to National Instruments Tech Support UK, I will (this once) allow you email support - unless you own SSP with NI? If you could tell me your email address I can also send you an email to send you code in.

Sorry to be a pain but do we have a means of emailing forum members without publishing emails on the forum? I looked for a method to send a private message but couldn't find one.

I do have an SSP (well actually I just found out it expired 3 days ago and have just requested a renewal) and have used those good fellows in UK support in the past. I am not at all averse to doing so again, but sometimes a question to a well supported forum like this can get a quick answer.

It would seem to me that in your code somewhere you have deffered panel updates somehow.

There is a property node which defers panel updates, and if you bring up a screen across it - it does indeed force a refresh (an update) - this is what your seeing!

Yes, I found some references to that property and in fact I did create a vi last week and tried resetting the panel to 'underfer' periodically but did not seem to release it.

Thanks again for your help.