GetGrabStatus crashes

General Questions
1

Function GetGrabStatus crashes randomly when called within an aquisition loop.
Context : We are using CVB to acquire 2D monochrome image from two DALSA Nano Genie 1930 cameras . Our application uses two parallel threads, one for each camera. Acquisition is hard-triggered, each loop starts with a Grab2Wait then calls GetGrabStatus to get image timestamp and check the number of lost buffers, then deals with the acquired buffer.

Unfiortunaltely we noticed that the GetGrabStatus sometimes crashes without any notification, freezing the calling thread.

  • Is there any restriction to GetGrabStatus call - for instance within a Grab/Wait loop ?

  • Is GetGrabStatus thread-proof ? Or should we consider a MUTEX to avoid simultaneous call to both cameras ?

  • What workaround can be considered to get image timestamp and buffer status (typically overrun indication ) at each frame ?

Please note tat the same issue occurs with GetInputSatus, used to regularly check a digital input line on the camera, crashing from time to time randomly…

2

Hi @Frederic.EQUOY, nice to have you as a long term CVB user in the forum.

Requesting status values should be safe from several threads. And we do this a lot as well

You did not write which CVB Version you use. It would be probably best to test this with CVB 14. If it also freezes, you can send us a dump to de.support@stemmer-imaging.com
so that we can have a look into it.

Is it possible that the GetInputStatus function is one of your own which actually is accessing the nodemap e.g. via NGetAsInteger? From what I know, we do not have a GetInputStatus function.

3

Hi

  • We use CVB 13. 04.005 64 bits.
    If nothing regarding a bux fix in GetGrabStatus CVB 14. it should not make any difference…

  • I launched a debug session (using CVB LogUI 3.125.430 )
    with CVB + GCVIN + GECTL @ level trace. If a thread freezes again I will save and share the log.

  • P.S. our "GetIputStatus’line) is done as follows :
    CString line_str, status_str;
    line_str.Format(_T(“Line%d”), line);
    HRESULT res;
    res = SetStringNode(_T(“LineSelector”), line_str);
    res = GetStringNode(_T(“LineStatus”), status_str);

    if (status_str.MakeUpper() == _T(“ON”)) return 1;
    if (status_str.MakeUpper() == _T(“1”)) return 1;
    else return 0;

where GetStringNode is using NMGetNode and NGetAsString
Is it not advisable to call NMGetNode everytime I call NGetAsString ?
thx

4

Hi @Frederic.EQUOY,

thanks for the additional information.
The newer the CVB Version is the easier it is to investigate a dump.
Getting a log is always interesting. In case of a crash, it is more important to get a memory dump. So that we can take a look deep into the CVB calls and hopefully see the reason why you got a crash.

If NMGetNode is used frequently, like in your case, it would be more efficient to save the Node in a NODE Handle and release it only when it is not needed any more.
Calling NMGetNode everytime should not result in a crash if this is what you wanted to know.

5

Thanks Sebastian

After cleaning some warnings due to unnecessary accesses to non-readable or non-writable nodes,
we are now running with a “clean” Log (*) , awaiting a potential crash to check is something will then appear in the Log.

I understand Log will not give relevant information in our case, getting a memory dump would be more informative…
and dump is only available from CVB14 - and not wit CVB 13. Is that correct ?

We cannot switch immediately to CVB 14 since the issue occurs on the customer’s PC on which we have limited access.

(*) on our Log by now, one error and two warnings (one per camera)

err “TurboDrive: exception during get/set turbodrive nodes”. in GCVIN Channel 1
(curiously not on Channel 0, although we setup the both channel the same way, without turbodrive ??)

warning “Failure executing test packet mechanism” in GCVIN, while loading the CVB imager, for both channels.

Is it “usual” ? Since this is related to camera, should I contact the support rather than cvb forum ?

Vielen Dank für die Antworte. Beste Grüsse.

logo Gipsvision.png

6

If turbo drive is not activated, this exception does not need our attention.
If you are experience issues beyond this logged internal exception, then we would need more information.

If you have a memory dump with CVB 13 you can send it to us. But I can’t promise that it will help us directly.