Frequent but inconsistent error: R6025 pure virtual function call

[deltabot]

Hello,This problem is mostly software related; we are not running any LabView hardware.The application we developed is using LabView to run 4 independent Vision tasks (Dalsa GigE cameras), and the HMI that is communicating with these and with a Beckhoff PLC through an ocx library. The choice we made was to stay as modular as possible so each vision is running its own timed loop in its own VI which is called by the HMI at startup, and we have a couple of more timed loops running the communication with the PLC. So a total of 8 independent VI’s running their timed loops are called by the HMI before entering its own main timed loop. We relay heavily on global variables for communication between all of the VI’s.The error “R6025 pure virtual function call” is showing up in the middle of running the machine, and without any other explanation LabView dies; although in the Task Manager it shows up as running we cannot kill it or do anything to restart the HMI. The only solution is to reboot the computer and then restart the application; this gets us running for a while. Did anybody see this before, or anybody at NI can help us?

[BlueCheese]

Hi deltabot,

Unfortunately it is hard to say what the problem could be. One item that stands out is the PLC communication using the OCX library. Since all the calls into that library are in the same process as LabVIEW, if it is crashing or corrupting LabVIEW's memory it could cause issues such as this. Can you try reducing the variables such as trying just the image acquisition or just the PLC communication?

Eric 

[deltabot]

Hi Eric,

Thanks for your response. I did eliminate the OCX communication, and it proved that is not the reason for the error. After further investigation, I discovered that the subvi's containing the configure, acquire and unconfigure of the camera connection, were having the execution set on "Reentrant execution", so when cameras have to be restarted simultaneously this error would show up. I have corrected that problem and now I will run a test with the camera's over night and see whether this will still show up. There is a second smaller problem, that we thought was caused by the same thing, which is that the camera's get stuck in an acquire state, and although the camera gets triggered there is no image to retrieve. That is when we programmatically reconnect to the camera and get rid of that problem. This problem is somehow aggravated by the analysis subvi's, we run tests without the analysis and cameras are fine. The analysis subvi's are only taking in the image and return some results, although they take a toll on the processor. Any thoughts on this one?

I will come back with the results of the test.

Thanks.

[BlueCheese · Accepted solution]

Hi deltabot,

Thanks for narrowing that down. What version of IMAQdx/Vision Acquisition are you using? You might want to try updating to the latest version 8.61 available here: 

 http://joule.ni.com/nidu/cds/view/p/id/1287/lang/en

There were some issues fixed that would potentially have affected Open/Close of multiple cameras in seperate loops.

Would you be able to share a snippet of code that runs your acquire/reconfigure loops so we might be able to try reproducing it?

Thanks,
Eric 

[deltabot]

Hi Eric,

I am downloading the new version right now, it's going to take a while.

Currently I am using 8.5.

I have prepared a source distribution for the code I am running on one of the cameras, could you give me an email where I can send it to you?

Thanks.

[deltabot]

Hi Eric,

I have installed the new acquisition, and with few changes, I got the code running. I am running now for more than an hour without any kind of issues, the need for restarting the cameras seems to be gone. I will keep running tests, and unless you hear from me again, it looks that installing the new acquisition solved the problem.

Thanks again,

All the best.