Dll data update

[seb]

hi,
my problem is the following:

1. With a function1, I give to a Dll a pointer to an allocated LabVIEW
array.
2. with a function2 I send a "grab" command and the dll fill the
memory pointed by function1

then I try to (re)display the array in labVIEW (which must be changed
by the dll) but the array has still his initial value....

How can I force LabVIEW to reload the value of the array from memory?

thanks in advance !

Seb

[rolfk]

seb wrote:

> hi,
> my problem is the following:
>
> 1. With a function1, I give to a Dll a pointer to an allocated LabVIEW
> array.
> 2. with a function2 I send a "grab" command and the dll fill the
> memory pointed by function1

You can't do that. LabVIEW data is highly dynamical and can be
reallocated any time it wishes. LabVIEW only guarantees that a function
pointer is valid while the you are in your Call Library Node. After that
this pointer is in most cases invalid or at least can get invalid at any
time.

> then I try to (re)display the array in labVIEW (which must be changed
> by the dll) but the array has still his initial value....

You could have gotten a crash at the point where you call the Grab function.

> How can I force LabVIEW to reload the v
alue of the array from memory?

What function do you use to display the data? Probably an IMAQ Window or
a picture control. LabVIEW is about data flow. You can not tell a
control to reread some data pointer as a control does simply not
maintain a pointer to the original data at all. Once you pass the array
to the control it takes whatever data it needs and displays it and
forgets about that pointer.

You will explicitedly have to execute code where you wire the array or
whatever again to the control to be displayed eventhough you believe it
is the same memory and all, LabVIEW works mainly with dataflow and there
usually has to flow some data on the diagram to cause LabVIEW to do
something.

Rolf Kalbermatter

[Greg_McKaskle2]

> 1. With a function1, I give to a Dll a pointer to an allocated LabVIEW
> array.
> 2. with a function2 I send a "grab" command and the dll fill the
> memory pointed by function1
>
> then I try to (re)display the array in labVIEW (which must be changed
> by the dll) but the array has still his initial value....
>
> How can I force LabVIEW to reload the value of the array from memory?

As Rolf pointed out, you are asking for LV to work in a way that makes
dataflow difficult or impossible. You have a couple choices. You can
either allocate your own buffer using malloc or new, give it to function
1, then in function two, copy the contents from your buffer to a LV
array, then wire the array into a draw command, picture control,
intensity graph, etc.

Knowing how LV currently does its memory allocations, it is also
possible to pass a presized LV array into the first function and back
out, having the DLL remember the pointer into the array. If you don't
provoke LV to do anything to the array, your pointer will remain valid.
You will also want to pass the array into and out of the second
function, and you really don't have to do much except check the status
of the call. The data will be written into the array buffer by the DLL.
The second function will be there to ensure that it is complete, grab
its timestamp, or whatever else it does. After the second function
call, you can send the array downstream to the display object, and the
first function should be called again to give it a different buffer,
otherwise, you will get nasty side effects where the displays may not
finish with the data before the DLL changes it again.

Anyway, this isn't guaranteed to work in future releases, and there are
diagram things you can do, like splitting the array or resizing the
array that will make it stop working, but it is possible to write it
this way, and it will likely work for a long time, it just isn't
guaranteed to work forever.

If you have more questions, be sure to provide more info on what the
functions do.

Also, you shouldn't be too afraid of the memory copy to the array, the
first solution. In today's computers this is actually a very fast
operation. It is nice to limit the copies, but you don't have to
eliminate all of them, and in fact in a multithreaded environment, it is
difficult to do so without lots of locks and waiting threads.

Greg McKaskle