10-28-2009 01:29 PM
Winther,
The TestStand 4.2 Known Issue (ID# 148697) that you mention in your last post has been fixed in LabVIEW 2009.
The behavior that you are experiencing and originally posted has been reported to R&D for further investigation. Your previously mentioned solution is the current workaround for this behavior.
12-09-2009 04:13 AM
Is there any news on this matter?
We have a production PC which also runs Windows XP SP2. This PC only has the runtime enviroment installed and on this PC the problem remains even though the previously mentioned workaround has been applied.
The production PC is slower and has less memory, but it should be enough. It is a Pentium 4 2.6GHz with 512MB memory.
12-09-2009 10:33 AM
Winther,
I'm not sure if this applies or not; but since you mentioned you had to change your preferred execution system and I'm re-reading Using LabVIEW with TestStand I ran across this information.
Note When you place a TestStand UI Control on the front panel of a VI, you must set thePreferred Execution System to user interface for the VI. In addition, National Instruments
recommends that when a TestStand User Interface performs ActiveX operations that can
process messages or performs TestStand operations that can call back into LabVIEW, the
application must perform these operations in a LabVIEW execution system other than userinterface, such as standard or other 2. Performing these operations in the user interfaceexecution system can result in hang conditions.
Hope this helps.
12-09-2009 02:40 PM
Winther -
As mentioned before, R&D has been notified of this issue (191753) and is working on correcting it in a future release of LabVIEW. You can use the number provided (191753) to check the LabVIEW Known Issues List and Bug Fix List in future releases so that you know when it has been resolved.
What are the differences between the User Interface on this machine and those on other machines which seem to work fine with the previously mentioned workaround?