Is Labview 2009 Supposed to be backwards Compatible?

[Peñata]

Hi QlarityEng,

There shouldn't be any issues with LabVIEW 2009 and backwards compatibility as far as OPENING the VIs is concerned, especially if your customer was already using your VIs in LabVIEW 8.6. However, this backwards compatibility does not always apply if the actual functionality of any of the VIs you are using has been modified. If this is the case, then you will need to go into your code to where the inconsistency is occurring and update your code accordingly. I understand that this can be an inconvenience, but sometimes functionality modification is necessary between versions to fix bugs or improve performance.

Thank you for choosing National Instruments.

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support

[QlarityEng]

It will open in Labview 2009, it  does not function the same.

[Angela M · Accepted solution]

I am sorry for the delay in this post, but for posterity sake, I want to provide some more information.  There are a few unique things about the Functional-DataToBeSent.vi that make this issue interesting.  First, the VI is set to subroutine priority, which is a very special execution priority.   See the subroutine priority level section of the Prioritizing Parallel Tasks help topic for details about what this does.  Next, the terminal in question is inside of a case structure, which complicates how the value of this terminal is handled if those cases do not execute.

First, the simple fix, I find that if I set the Functional-DataToBeSent to a priority other than subroutine, I believe the code executes as you expect it to execute.  If this code does not actually require the subroutine priority, then this could be easily changed.

The more complex (but I believe better) solution would be to modify the code to be more explicit.  I would recommend moving the Output Buffer Full terminal outside of all structures so it is on the top level of its diagram.  Then wire the appropriate data through the tunnels to the terminal.  In this case, I presume that in all other combinations of True/False for the case structures, you want this terminal to have a value of False, correct?  In this way there is no confusion about what the value of the terminal will be, since you have defined the values.  I believe this is related to a specific update regarding when the terminal is written to (which is different from using a local variable) when the UI thread is not used.  The code change I am recommending would not have any confusion about the value that the terminal should have.

One other thing to note, there is an input terminal wired to a local variable, then that wire is wired to the while loop, but never used.  For all priority levels other than subroutine, the writing of the value to the local variable will actually happen in parallel with the code inside the while loop, but I'm sure this was intended by the way it was written to happen before, in which case a sequence structure would be needed.  If you follow the directions in the paragraph above, the local variable is not needed anyway.  

I do hope this helps.

Regards,

Angela M

Product Support Engineer