From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Test stand operator interface crashes labview (workaround & investigation)

Hi all, 

 

I'm having a problem with random LabVIEW (LV) crashes and am posting details in the hopes that somebody else can explain why my workaround seems to fix the problem.  The crash is not graceful and when LV is restarted there is no explanation of what happened. 

 

Problem 

LabVIEW adapter steps crash at seemingly random places in the sequence when called via a TestStand Operator Inteface (OI) that is running as source code. If I compile the TestStand OI and run as a executable then (so far!!) it has not crashed. If I run the TestStand OI through LV then it will always crash at some random place (Crash dump is attached to this post). 

LV crash exampleLV crash example

Workaround

Compile the operator interface to executable. 

 

What was tried and failed while debugging before finding the workaround

- Turn off multithreading by adding 'ESys.StdNParallel=0' to LV ini file

- Setting all test steps VI's to use a different execution system ('Other 1') instead of 'User Interface'

- Mass compiling

- Updating LV14 to LV16, updating to latest service packs etc

- Running shipping examples of operator interfaces

- Watching execution with Desktop Execution Trace Toolkit, while interesting was waste of time

- Watching memory & processor usage while sequence executed. 

- All code is loaded from local hard drive, no network outage to explain this

- I moved VI's that call a DLL into the same directory as DLL

 

What I think is happening

The main difference (in my mind) is that the OI executable is completely seperate thread than the labview.exe code and teststand.exe code. 

 

Has anybody seen documentation that explains this? Has anybody seen same behaviour? 

 

Thanks! 

 

Sr Test Engineer at American Innovations - LabVIEW CLA - Kudo's are appreciated!!
0 Kudos
Message 1 of 5
(2,789 Views)

[UPDATE]

I have been running in dev for a couple weeks with the compiled operator interface and have seen 1 crash that looked similar. 

 

Still looking for any other theories or answers, I would like to understand why the operator interface cannot be run from Labview development environment. 

 

regards!! 

 

Sr Test Engineer at American Innovations - LabVIEW CLA - Kudo's are appreciated!!
0 Kudos
Message 2 of 5
(2,683 Views)

What is AtUsbHid.dll and is it compatible with labVIEW2016 and the OS you are using?

 

It not clear but are you using the default LabVIEW OI without any changes either as code or EXE?

 

 

Regards
Ray Farmer
0 Kudos
Message 3 of 5
(2,676 Views)

 

Hi RayFarmer, 

 

Thanks for the helpful questions. 

 

AtUSBHid.dll is a Atmel provided dll that is being called by a instrument & the DUT. If it was incompatible with LV or OS I think it would not work in development environment. 

 

I have tried the default LabVIEW OI without any changes, in development environment it will occasionally crash, as EXE it is way more stable. 

 

I will try seperating all of the DLL calls into a seperate execution system (thread) and see if that helps. 

 

regards

Sr Test Engineer at American Innovations - LabVIEW CLA - Kudo's are appreciated!!
0 Kudos
Message 5 of 5
(2,646 Views)