Jump to content

Labview Ghosts


Dachenday

Recommended Posts

By ghosts I don't mean anything supernatural, but rather a certain phenomena I have witnessed various times in labview.

One of my previous programs had a strange issue when every now and then it simply wouldn't work. It would compile just fine ( the run arrow wasn't broken) but it wouldn't work. I discovered that if I go into the block diagram, and delete any wire, it didn't matter which one, and redraw it exactly like it was before, then my program worked just fine. From this I made 3 hypothesis:

1- my code was compiling, but just barely. That there is something going on inside of labview that runs on a "lower" level than the block diagram.

2-That I had programed my code so badly that my program was sitting on a "knife edge" and that sometimes this lower level compiling worked fine and sometimes it didn't.

3-That by deleting and recreating any part of the block diagram I was forcing this lower level code to recompile and end up or the right side of the "knife edge"

I guessed that there were some elements of this lower level program that changed with each compile, and I termed these things ghosts, because whatever they are (if they even exist) they are not visible on the block diagram.

Eventually these ghosts went away, and I figured that meant that I had changed the block diagram enough to step away from the knife edge, but now I'm not so sure.

My current program, which was built on the previously mentioned program, used to cause labview to shut down as soon as the run button was pushed. I went into the block diagram and started removing things, hoping that eventually I could get labview to not commit seppuku every time I tried to run the program. I removed several sections of "vestigial" code (my term for pieces of code that don't do anything anymore, and that are simply left over from previous versions). I had left these sections in because as I said, they didn't do anything, so there was no reason to remove them yet. (I would have removed them when the program was finished, simply to clean up the block diagram) After I had removed the vestigial sections the program still wouldn't work, so I started removing important stuff. Eventually it ran, so I put the important stuff back, and strangely enough, it still worked.

Now every time I run my program it goes really slowly. As before I started removing things until it worked, and eventually got something working (by that point I had removed lots of vital stuff, so leaving it in that state wasn't an option). However I though that I had figured out which part of my code was causing the problem, it was a build array vi that combined 32 1dimensional arrays into a 2 dimensional array. I wasn't sure how that could be causing a problem, but I figured I'd just find another way to combine the arrays. The really strange thing is that now my program won't run even without the build array vi. It's like the opposite of the deleting and recreating the wire I mentioned previously, i that any save that I doesn't have the build array vi works fine, but any save that I add the build array vi into won't work, even if I remove the build array vi.

My question is : am I right about these "ghosts" and if I am how do I solve problems that aren't on the block diagram?

I'm sorry that I can't post my code ( that's why I made such a long post describing my problems, but I realize code would have been better) I also understand if nobody can help me without my code, but I figured that it couldn't hurt to ask.

Link to comment

The best way I can suggest is to contact NI tech support and arrange for us to look at your code under secure conditions (possibly even rising to the level of signing an NDA).

The sorts of problems you're describing are the deepest dread of compiler writers -- they might be user error, they might be our fault, neither you nor we can tell at the moment, and the longer it goes on, the more it will undercut your confidence in our language. That's bad for both of us -- you eventually will rewrite using some other tool and we lose a customer. Please take the effort to contact NI (though this being Labor Day Weekend, I'm honestly not sure what our staffing is like at the moment).

If you're using Source Code Control, commit your changes regularly so we can see the different evolutions of the code. If you're not using SCC, zip your VIs up regularly and name the files with timestamps.

Link to comment

Subtle race conditions can be affected by recompiles. So, sometimes it works (and works every time) and then after a recompile, the code is executed in a different order (like if you edited the block diagram and caused the compiler to rethink the compile order). Suddenly, the code does not work because the intended flow 'loses the race'.

That is the joy of LabVIEW, There is no such thing as a syntax error but there are plenty of opportunities for race conditions to bite you in the behind.

(BTW: that is why in my opinion EEs make better LabVIEW programmers than CS majors. We just naturally think in terms of races and not syntax.)

Link to comment

Thank you for the responses!

I think I have gotten it working by just deleting sections and rewiring them in a different way. This time I had to redo a section of code that allows the user to choose the name of the save file he's later going to create. It took me so long to find it because that section of code was inside step 10 of a sequence structure, and the program would stop running in step 14.

"The sorts of problems you're describing are the deepest dread of compiler writers -- they might be user error, they might be our fault, neither you nor we can tell at the moment, and the longer it goes on, the more it will undercut your confidence in our language"

I've only been programming in labview for a few months, and NI has been around for considerably longer ,so I'm pretty sure that I just did something wrong. I realize that it's possible that I found some glitch, but I'm not arrogant enough to think that that's likely.

"(BTW: that is why in my opinion EEs make better LabVIEW programmers than CS majors. We just naturally think in terms of races and not syntax.) "

Actually, I'm a BME, not a EE. Hey.... maybe that's my problem!

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.