Yeah, the problem isn't in the sub-vi. It does call an external
DLL, but it dies just as I step into it, not when actually executing
the sub-vi. The sub-vi contains a stacked sequence structure, and
it does a few things prior to calling any external code, like calculate
a checksum and length. So there is (simple) code I should be able
to step through before the dll call is actually invoked.
From the way Labview is acting, and the exact timing of the crash, I am
fairly certain that the problem is that the sub-vi has to take an array
of unsigned 8 bit values of unknown length. In the sub-vi, the
array variable that accepts this buffer is initialized with 0 length,
or no members. In C, I could pass a pointer to the buffer.
I can create a reference to the array in the calling vi, but I don't
know what kind of "receptacle" to create in the sub-vi to accept a
pointer to the array.
I've been thinking about it, and what I'm going to try is this:
For each vi that uses the sub-vi, the variable name for the buffer will
always be "buffer". From the sub-vi, I can then refer back to the
calling vi, to a variable called "buffer". I do this in a lot of
other vis that I've written with great success. (For
example, when I want to break a complex part of a main vi out to a
sub-vi in order to simplify things, but I still want to interact in
real time with controls and indicators. The downside is that I
errors in the sub-vi don't always get detected by Labview until
runtime, and the runtime errors don't provide a lot of information -
i.e. debugging becomes more difficult.)
I'll post back on the results.
-M
