Two dll functions and one array

[theycallmedavid]

I have two dll functions, similar to these:

void start_something(uint8_t the_output_array[], uint32_t size_of_the_output_array);

int32_t is_something_finished(void);

The first function saves the pointer to the_output_array and its size, and starts "something". The seconds checks if "something" is finished.

In c code they can be used like:

start_something(array, 100);

while(is_something_finished() != 0);

Then "array" can be used with the result.

The problem is that in LabVIEW the array sometimes is updated and sometimes not. It seems if I put some wait into the loop where is_something_finished() is called, then it is almost always gets updated, but still sometimes not.

Is there a way to make sure that the array always gets updated in LabVIEW (without writing any c code, no dll wrapper dll, no changes in the dll, only from LabVIEW side with these two functions as they are)?

Thank you

Edit:

While writing the question it seems we found a solution:

If the array is wired out of the Call Library Function Node of start_something(), and into a shift register in the loop where is_something_finished() is called, then after the loop, the indicator wired to the output of the shift register, in this case it seems to always update. Now the new question, why is it like that? Is this intentional?

[deceased]

Without seeing the code its purely speculation. 

LabVIEW is inherently parallel, if there is no data dependency (a wire or structure to force execution order) between your "start something" and the "is something finished" call you can create a race condition between the two. (Since the two will try to execute in parallel).

If this happens, the "start something" call could happen at the same time (or later than) the "is something finished" call.

0xDEAD

[theycallmedavid]

The "error out" wire of the Call Library Function Node of start_something() is wired to the "error in" of the other Call Library Function Node.

[deceased]

That should eliminate the first theory.

It may be that you are experiencing some magic as described in this thread: https://forums.ni.com/t5/LabVIEW/When-is-dataflow-not-data-flow-Updating-LabVIEW-Arrays-through/m-p/...

If that is the case I don't have any solution.

0xDEAD

[theycallmedavid]

Sorry for not providing a VI or picture from the start. Here is a picture: https://i.imgur.com/qumGonq.png

In the picture "1" is the wrapper VI for the Call Library Function Node of start_something(), and "2" is the wrapper VI for the Call Library Function Node of is_something_finished().

Later we tried out what happens if the read_data is just wired through (without shift register) the loop of is_something_finished(), and it worked that way too, without delay in the loop, the read_data always got updated.

Before that, when it didn't always work the read_data indicator was inside the loop.

With these experiments and your first comment in mind, I presume that when read_data indicator was inside the loop, sometimes it got updated (by the UI thread or something similar) before the VI for is_something_finished() returned (or even before it was called), and that's why it seemed like it doesn't get updated. Other times is_something_finished() returned (probably with "finished" result on the first call) and it happened that read_data indicator got updated only after this.

In the end it seems it really was about the execution order, just not that of the Call Library Function Nodes, but the updating of indicators.

[wiebe@CARYA]

If something is wrong, it will be in VI "1".

I had some problems dlls when arrays where automatically resized by the DLL configuration. So when no input array was wired to the CLFN, and then specifying another input to automatically specify the minimal length. That gave the exact problem as you're describing: sometimes new data, sometimes old data. The solution was to predefine the array (Initialize Array) with the length, and use that as input for the DLL.

[rolfk]

While you make sure that the array is kept in memory by wiring it through the shift register in the loop, this is still only working by the gratitude of LabVIEW not reallocating the array handle halfway through since that would be unneccessary performance loss. Nothing in the managed contract of LabVIEW memory handles however forbids LabVIEW to do just such a relocation and then your saved pointer in the DLL goes very bad.

You will need to create that array handle in the DLL itself instead of passing it in from LabVIEW, store it somewhere and then start filling it and once your is_something_finished() function indicates that the work is done you can call another function that retrieves this handle. You can even avoid an extra copy by something like this:

#include "extcode.h"
typedef struct
{
    UHandle handle;
    ......... 
} session_rec;

MgErr prepare_something(session_rec **session, int32 size, ......)
{
    MgErr err; 
    session_rec *ses = DSNewPClr(sizeof(session_rec));
    if (!ses)
        return mFullErr;
    err = NumericArrayResize(uB, 1, (UHandle)&(ses->handle), size); 
    if (!err)
    {
        // do whatever else is needed

    }
    if (err)
        DSDisposePtr(ses);
    else
        // return the session we created
        *session = ses;
    return err;
}

MgErr is_something_finished(session_rec *session, LVBoolean *done)
{
    MgErr err;
    // Drive the acquisition based on other information stored in the session
    return err;
}

MgErr retrieve_data(session_rec *session, UHandle *data)
{
    MgErr err;
    UHandle temp = *data;
    // Check that everything is really done

    // Exchange the two handles
    *data = session->handle;
    session->handle = temp;
    return err;
}

[PatrikKaranNI]

Hi theycallmedavid,

Do you still experiencing an issue with updating of your array? 

Rolfk's explanation and additional solution looks like something you were looking for.

Kudos to him! Mark answer as solution when it satisfies your needs.

Regards,