Jump to content
Neil Pate

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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  :thumbup1:

Share this post


Link to post
Share on other sites

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  :)

 

post-15232-0-38427300-1424472870.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.