Jump to content

Horrible LabVIEW code


Recommended Posts

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...

post-7375-0-20948000-1424451678_thumb.pn

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.