07-25-2008 02:53 PM - last edited on 08-01-2008 04:31 PM by Support
08-20-2008 09:31 AM - edited 08-20-2008 09:31 AM
I would like to use VI Analyzer to help me upgrade from LabVIEW 7.0 to 8.6. I've downloaded and run the upgrade tests on my User.lib folder and identified some property nodes that have changed (deprecated) ; this tool is great!
I've also been reading the Upgrade Notes and have found that there are some VIs that have been replaced with native LV functions that are listed as not supported and should be replaced; specifically Open/Create/Replace File.VI should be replaced.
A test for VIs that are obsolete or should be replaced per the LabVIEW Help or Upgrade notes would be useful.
From Page 25 of LV 8.6 Upgrade Notes:
In LabVIEW 8.x, the Open/Create/Replace File VI is not on the Functions palette. Use the Open/Create/Replace File function instead.
LabVIEW 8.6 Context Help:
08-20-2008 11:07 AM
I've just finished analyzing my Instr.lib files and have another instance of VI files that are deprecated or changed. The VIs were found by looking for General->VI Properties-> Broken VIs. I needed to drill down and find the problem, which turns out to be that these were removed from the distribution LabVIEW 8.5.
Again, this is known and documented in the Upgrade Notes, and a specific test would help me to more effeciently determine the scope of my upgrade efforts.
08-20-2008 11:18 AM
Thanks for the feedback Phillip. Tests for deprecated VIs along with the properties and methods are defiantly things that we want to include. Each release we attempt to document the VIs that were deprecated (in the Upgrade Notes as you indicated). We included Analyzer tests for VIs that were newly deprecated in 8.6 (for example, see the Deprecated Nonlinear System VIs test). As we move forward, we'll continue to include Upgrade Analyzer tests to look for newly deprecated VIs. We lucked out a bit as it just so happened that the technology we use to detect deprecated properties/methods made it possible for us to test for any deprecated property/method as opposed to just the newly deprected ones.
Hope that clears things up -- thanks again for the feedback, and glad the tests have helped you out!
11-06-2008 07:59 AM - edited 11-06-2008 08:00 AM
If you upgrade a 7.0 VI containing a Read File function that uses a certain combination of inputs, LabVIEW 8.6 replaces this with TWO elements, a Set File Position function and a call to "compatReadText.vi". This is not a problem per se, BUT the compatReadText.VI icon almost completely covers the Set File position function (2 pixel offset).
Its almost as if this was done on purpose to make the code appear the same as it did in 7.0. I can understand why this might have been done, but it doesn't seem to pass good VI coding practice and to me represents a 'code smell'.
I only found this because I am carefully scrutinizing hidden wires and making use of the 'Find VI Calls' VI Analyzer Test (that Darren provided here) set to look for files named 'compat'. I don't know if a new test for this represents an Upgrade Test or a good General Purpose test.
See images below:
11-10-2008 04:40 PM
Thanks for reporting this to us! I actually regard this behavior as a bug, and I filed a bug report (ID132760) to have that changed so that it doesn't do that anymore. Hopefully that gets fixed so that people upgrading won't actually experience this anymore. It is also good to note that this doesn't actually change the run-time behavior of the VI, so your code should continue to function as normal after upgrading.
11-12-2008 09:03 AM
Thanks for taking the time to look at this. As I said, it works but just doesn't pass the 'smell' test.
It does point out the problem of functions covering up other functions. I originally thought this might be an upgrade analyzer test based on my example above, but I think I would put this in in the same category as controls or functions inside a structure but outside the visible bounds.
It is quite easy to place sub-vis directly on top of another by using the align objects functions in the wrong way. The wiring will remain and the code will work, but the code is certainly not readable. You can find these overlapping VIs using the existing capabilities of VI Analyzer by scrutinizing the hidden and overlapping wires, but they are the result of a higher level problem. I would suggest that a VI Analyzer test for overlapping sub-vis and functions be added...