NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Access Violation Crashes from TestStand

Hi

I have the same problem with spurious crashing of LabView 2011 (32 bit) in one of my programs. The crashes occur either when initiating execution (pressing the white arrow) or, which is more frequent, when closing down LabView. Once one crash has occurred this crashing becomes more frequent until I reboot.

I communicate through 2 FTDI dongles (USB-CAN and USB-RS485) using dll:s provided by the manufactures of the instruments that I use. The crashes seems to be related to the USB-RS485 dongle though, which is connected to a flow sensor form Sensirion and comunicates via a dll. Prototypes are correct it seems. I can run the dll from an executable/cpp test program that came with the sensor with no crashes.

 

Please inform me if your investigation of this matter results in any new findings or if you can point me in any direction to solve this issue.

 

Regards, Per

0 Kudos
Message 21 of 27
(2,479 Views)

@Augustsson wrote:

Hi

I have the same problem with spurious crashing of LabView 2011 (32 bit) in one of my programs. The crashes occur either when initiating execution (pressing the white arrow) or, which is more frequent, when closing down LabView. Once one crash has occurred this crashing becomes more frequent until I reboot.

I communicate through 2 FTDI dongles (USB-CAN and USB-RS485) using dll:s provided by the manufactures of the instruments that I use. The crashes seems to be related to the USB-RS485 dongle though, which is connected to a flow sensor form Sensirion and comunicates via a dll. Prototypes are correct it seems. I can run the dll from an executable/cpp test program that came with the sensor with no crashes.

 

Please inform me if your investigation of this matter results in any new findings or if you can point me in any direction to solve this issue.

 

Regards, Per


 

Did you specify the dll calls from labview code? If the prototypes aren't specified exactly correctly it can lead to subtle problems and crashes. Are the prototypes complicated? Are there structs involved?

 

-Doug

0 Kudos
Message 22 of 27
(2,468 Views)

Thank you for the advice Doug

 

I do not have any structs but when looking through my vi:s I find a few suspicious candidates. For these I have had trouble to find a perfect match between the dll-prototype specified in the manual, and the available options in LabView. They are mostly related to arrays and strings/*chars. Also, one function returns a const *char, and I do not seem to be able to check the "const" check-box when configuring the prototype since this box is disabled. Se the attached list.

 

Regards, Per

 

 

0 Kudos
Message 23 of 27
(2,443 Views)

What do you have the minimum size set to for your strings and arrays? If you don't set these big enough or to the correct value the calls can corrupt memory and/or lead to crashes.

 

-Doug

0 Kudos
Message 24 of 27
(2,436 Views)

That's interesting.  We communicate through a USB to Ethernet dongle and I've always suspected that might be part of the problem.  In our case it's seemless since we're not talking to a dll directly the way I think you are.  

 

Earlier this summer I tried updating the driver to for it, but that didn't help.  Yesterday I put in an order for a different dongle and I will see if this has anything to do with it after it arrives next week. 

0 Kudos
Message 25 of 27
(2,428 Views)

The same problem is caused in my case by "wait on asynchronous call". I attach a part of code that always causes LabVIEW to give this error, no matter if it is run in LabVIEW, or built into EXE.

The queue that can be seen on this picture is giving the called VI a signal to end its work (stop an infinite loop). I am worried that it might actually end the VI before the "wait on asynchronous call" is executed, hence making the reference point to the space where there is no running vi present anymore.

I will try to add some delay and see if it helps.

 

 

EDIT: Whoops, sorry, wrong topic, althought a bit related...

0 Kudos
Message 26 of 27
(2,005 Views)

The issue could be in the adapters in teststand , you can try change from Runtime to Development

 

go to configure>>adapter>>labview>>development

0 Kudos
Message 27 of 27
(1,507 Views)