TestStand hang, Execution with Event-Callback-VI

[TPoint]

Hello there,

I try to build a UI in TestStand 3.1 and LabView 7.1. I don't want to use Application-, Execution and SequenceView- Manager because you must use the SequenceView-Control to display some Details of Execution..
While executing a Sequencefile I want to show StepName, StepIndex.. on Front Panel with normal String- or Numeric-indicators.
To get a high Execution-Speed I don't use MessagePolling and create a UIMessageEvent-Callback-VI.
At first I tried to update my Indicators by using the References of it. But the UI hangs by trying to open a VI-Reference per Path. Open a VI-Reference by String works, but sometimes it hangs by closing this Reference. This effect occurred at my PC (Pentium 4 2,8 GHz 1GB Ram) after 20 minutes up to 9 hours. At a Pentium (Hyper-Threading) 3,2 Ghz, 512 MB Ram it hangs after a view minutes. On an old Pentium (200Mhz, 256KB) it works fine for a Week!?

So I changed the updating Indicators to Global Variables, with the same effect.

At last I removed all these to run a Sequencefile without any information about the status of the execution and again the UI hangs.

So I don't know what to do... What's Wrong?.

Please answer me.

Best Regards TPoint!

Message Edited by TPoint on 04-14-2005 04:09 AM

[Scott_Richardson]

TPoint -
I just noticed your posting today, so I appologize for not seeing it sooner. Have you gotten around the problem yet?

You stated that you don't want to use the UI control because you must use the SequenceView control to display some details of execution. I should point out that you can use the Application Manager control without the view controls. The Application Manager control has the ability to manage a lot more with the engine then trying to do it yourself using the TestStand API. You can use the events of the manager control instead of trying to get them from the engine directly, for example AppMgr_UIMessageEvent. This is the recommended way of doing things instead of using the TestStand API only. Mixing ActiveX event handling with UI event handling can result in hang conditions. The application Manager is written to work around some of these issues.

We will try to reproduce the hang with the code that you provided, and if we can, we will investigate the underlying cause.

[TPoint]

Hello,

thanks for answering.

I still have the problem yet. Ok, I use the much slower UI-Message-Event-Loop like TS2..

You are right that to use the Application-Manager is the safest way. I not only write a Simple UI. I create a own Editor. So I have much more to handle then the Application-Manager can do. For example have you tried to create StepTypes from LV with the AppMan?
Another problem is, that I started to write my Application with TS2 an I don't want to replace my working code with once from AppMan.
I don't understand the problem with the event-callback-vi, because I do nothing else like I would do in a ui-message-event-loop. What have ActiveX-Events to do with open a VI-Reference??? By the way in my example I only handle the ActiveX-Event and no other events.
So I don't think that there is an solution. The German-Support knows this problem for long time, but I get no response..

TPoint

[Scott_Richardson]

TPoint -
You are correct that the App Mgr only does the basic stuff for handling the engine, login, etc, but when used in with the other view manager control, it does a lot for you. I do not know if you want to consider using an existing full OI source that uses a SeqView Mgrs and build off of that. I do not know what you want your final application to look like, but this might be easier that starting from an "empty" plate. You should be able to add edit commands to the context menu for the sequence view control using the CreateContextMenu Event. Step type development will have to be done from the ground up.

Regarding the hang, a coworker has not been able to reproduce the problem. I will try to reproduce the problem this week.

[TPoint]

Hello,

The best way to reproduce the hang is to use a pentium with Hyper-Threading-technologies. If you use a PC with an other processor, it takes to much time.
I can not start with an "empty" plate because I'm nearly ready. (See the picture of the Main-Application Window in Debug-Mode) Of course my Application is much easier then the Sequence Editor. But our customers don't want to use such a complicate Editor. An Application-engineer don't want to define C- or BASIC- like Expression-Strings. They want to parameterize a Test-Step and create Test-programs and own Steps on a much easier way. They don't want to create a StepType with SubProperties and one VI for Editing and one for execution, they get once for both and the necessary StepType will created unconsciously and so on...

TPoint

[Scott_Richardson]

TPoint -
Your OI layout looks nice. We were finally able to reproduce the problem, and as you thought it does appear to be a hang somewhere in the Open Reference call that you were doing. We tried to attach a debugger to the process but the problem would not reproduce, so we will have to try to work more on this to figure out the exact cause and determine if we can prevent the issue internally. Since it appears to be hanging inside the LabVIEW call, it is unlikely that a fix is in the near future, so if we can workaround this in anyway this would be the easiest solution.

I was able to prevent the senario that you posted by serializing the calls in the sequence case by wiring the error out from the Close Reference to the Property Node call for UIMessagePollingEnabled. I do not know if this type of fix will apply to your complete OI code base.

You should also be aware of a general issue that is documented in the Using LabVIEW with TestStand manual in Appendix B - Using the TestStand ActiveX APIs in LabVIEW.

Setting the Preferred Execution System for LabVIEW VIs
If your VI calls synchronous methods of the TestStand API, you may need to correctly set the LabVIEW Preferred Execution System for your VIs. If you call synchronous methods that will not return until the LabVIEW server executes a VI on behalf of TestStand, the VI that calls these methods and the VI that TestStand is attempting to run using the LabVIEW VI Server cannot be set to run in the same LabVIEW execution system. If the VIs are set to run in the same execution system, you will experience a deadlock since the execution system that the VI needs to run in will be consumed by the execution of the synchronous TestStand method. In addition, since LabVIEW handles ActiveX communication through its user interface execution system, neither of the VIs in this scenario may be set to run in the user interface execution system.

For example, you can have a LabVIEW code module that calls the Engine.NewExecution method followed by the Engine.WaitForEnd method, and a new execution that calls LabVIEW code modules. Deadlock can occur if either of the VIs in this scenario use Same As Caller or User Interface as its preferred execution system. In addition, both VIs in this scenario must use different preferred execution system settings. The LabVIEW execution system is configured in the VI Properties dialog box for each individual VI.

Sincerely,

[TPoint]

Hi Scott,

Thank you for answering me. It's interesting that the problem will not reproduce if you use a debugger..

I can't believe, that serializing the calls should help. The Open VI-Reference is only a indicator for the Problem. You can delete it in the main.vi and it will not hang there, but the problem although occurred (in the background) and you don't recognize it. The problem will be visible if you try to open a VI-Reference any later (somewhere in the your application). If I right remember you can't also open a VI from the explorer if the problem occurred)
Another thing is, that it will not hang if you open the Vi-Reference by name-string.. But this isn't a workaround because in my Library-Editor I have to open references of not opened VI's...

I really tried every thing. I set the Callback-VI to Lock Panel Unitl Handler Completes - causes a LabVIEW-Runtime-Error. I tested it with making the Callback-VI non-reentrant. I tried it with semaphores and changed the execution system to other 1 and so on, but always the same...

It's frustrating to wait until the problem occurred. So I changed something and let them run over the night, but every morning the same procedure...

I don't understand it, but it's something with the VI-Server. What is the difference between open a Vi-Reference by String or by Path when the VI is already loaded in memory?

Regards,

TPoint!

[SAS]

Hi Scott,

I am very much interested to know the solution of this OI hanging issue. Even i am facing the issue. In my case, the OI hangs when we select all and execute the selected steps of the client file being loaded from the custom OI. The "Scan Module" execution entry point (to find the client sequence file) always runs fine. It only hangs for the "Run Selected Test" Execution entry point. The hanging occurs randomly (not always). We have logged the callback events' occurrence to find the cause.

After a UI message event callback is called no other events were registered in the log file. But i am sure that the test is running in the back ground as the hardware is powered and the connected module LED is glowing. But some how LV couldn’t get the callback events sent by TS and process further. we are using LV 7.0 and TS 3.0.

I would like to know what execution system is preferred for the callback vis!

Regarding Tpoint's case,

The slower PC running fine without hanging, can be due to the reason that the OI needs some time delay between some processes!!! (Just a guess!)

Thank you,
Sasi

[TPoint]

Hi Sasi,

It could be that the UI need some time between processes for whatever. It sounds like the same if Scott uses the Debugger..

I suppose that TestStand (or maybe Windows) sometimes does something in a wrong order causes of the parallel processes. That could be the reason why I only can force the hang (nearly) directly by using a multiprocessor-environment (meaning a Pentium with HT-Technologie)

Ciao TPoint!

[dug9000]

Hi TPoint,

I'm currently trying to diagnose the hang problem and have a question for you. Why are you setting the UIMessagePollingEnabled property to false inside of your loop? Setting UIMessagePollingEnabled to false is something that you only need to do once at the beginning of your program. Everytime you set that property to false it will destroy and recreate a Window that is used for UIMessage processing.

Also, we were able to cause a hang with a modified version of your code and we were able to fix it by wiring the error out from the vi close reference in the section you marked (Here it hangs) to the engine property invoke node to ensure that those sections of the code do not execute in parallel, but really there is no need to be repeatedly setting that property anyway so it would be best to move it outside of the loop and only set it once before the loop starts running. We will continue to look into this further, but let me know if this solves the problem for you on your end as I haven't been able to reproduce the hang in an unmodified version of your code yet.

Hope this helps,
-Doug