Horrible LabVIEW code

[Neil Pate]

So, this is the code provided by an instrument vendor for interfacing with a bit of measuring hardware.

 

Even though the input array should not change according to LabVIEW's dataflow rules as it should be a "constant" after it enters the While Loop, the data in the Channel A indicator actually gets updated!

 

Horrible...

[hooovahh]

Yeah lets see, there also wires going backwards, and error terminals being in a nonstandard location on the connector pane.  there's also unnecessary wire bends but whatever.  To be honest I've seen much worst vendor drivers.

[Neil Pate]

error terminals being in a nonstandard location on the connector pane.

 

I had not even spotted that one! At least they have kept the error wire straight 

[ShaunR]

Yeah lets see, there also wires going backwards, and error terminals being in a nonstandard location on the connector pane.  there's also unnecessary wire bends but whatever.  To be honest I've seen much worst vendor drivers.

 

I don't know what you are talking about 

 

[SDietrich]

We all focus on the horrible image we see when looking at this piece of code. But the actual horror lies underneath it. As Neil said in his original post:

The indicator gets updated but according to LabView semantics it should not!

 

How does this happen?

 

I can only imagine the VIs outside the loop internally save a pointer to the array and the VI inside the loop writes the new data to this memory location and returns the number of bytes it has written. This is the actual horror, because this only works as long as the LabView-Memory-Manager keeps the array in its original spot. If for some reason it decides to move this memory, unexpected results will happen. If you're lucky the application crashes. If you are unlucky you read out wrong data and keep working with it.

 

So it holds true again: If the code looks ugly, it probably is ugly.

 

By the way, the solution would be so simple: Just pass the array to the VI inside the loop and have it write its new data to that memory location. The memory-manager does not shift memory around while in a call-library-node.

[Neil Pate]

I can only imagine the VIs outside the loop internally save a pointer to the array and the VI inside the loop writes the new data to this memory location and returns the number of bytes it has written.

Yes, in the 4th VI an array is allocated (in LabVIEW memory space) and passed to a DLL, and passed out of the VI (that then goes via the tunnel into the While Loop). The DLL must then internally update the array via the pointer.

[ned]

One right way to do this is to allocate a pointer to a memory block (using DSNewPtr), pass that to the DLL, and then inside the loop call MoveBlock to copy the current data to a wire. That way no changes to the DLL are necessary, unlike SDietrich's suggestion.

[Neil Pate]

Thankfully the vendor does also provide a more "usual" method of getting the data via a Read_Data function in the DLL. I just don't know why the LabVIEW example (which doesn't always work anyway) does not use it!