Message : "LabVIEW no longer supports this function..."

[MogaRaghu]

When you try to open a VI built in 7.1 using version 8. x and if it has a function like Open/Create/Replace file.vi  or Write Characters to File.vi , you get a message that says LabVIEW no longer supports that VI and instead use of another VI is recommended.

Assuming I ignore this warning ( maybe there are too many replacements to be made ) and go ahead and build the VI with LV8.0, will something unforeseen happen ? Because despite the warning of not supporting the function,  LV8.0 App. Builder still compiles and builds the EXE using those VIs. I do know that LabVIEW is quite forgiving and tolerates inefficient code but I don't want to compromise efficiency if I can avoid it..

There are many instances when you need to modify code built with previous versions and it may not be viable to spend time to replace functions just to make them compatible with the new version.

Can someone enlighten on this ?

Thanks

Raghunathan

[mikeporter]

The thing that you need to do is save those lists of warnings and go through them to see the comments matter. Some of the unsupported functions could be because the function they performed is no longer needed due to other changes in the language. For example, in V1 you had special formatting VIs to prepare data for plotting. Starting with V2 you could just wire data to the graphs and the display would morph themselves to match the datatype wired to them.

But back to you main point, it used to be that the changes that happened between one version and the next were of the sort that the conversion code could fix on the fly during the conversion process. There were things live terminals were moved around or the datatype of a function was changed. When you saved your code in the new version LV would simply reestablish the connection to the new terminals or insert a type conversion routine so the existing code would continue working. And let me be clear, LV still does that in most cases.

The problem is that NI has started making changes to the way the language works that are not possible to fix automatically. For example, the decision of whether or not to display scrollbars on a subpanel used to be a property of the subpanel - now its a property of the window being inserted into the subpanel. Now you could make the argument that logically this is the way it should have been all along (and I'd agree with you), but the fact remains that this isn't something that LV can fix on the fly because there's no way it can know at compile-time what VIs you going to be inserting into the subpanel. In the end, NI is left to make the decision whether to fix something that was implemented incorrectly the first time or leave it alone for "compatibility reasons".

Of course this opens up the question of how much input from the user community NI gets before making changes - which is clearly not enough considering all the uproar over the interface changes with V8.x. But it also gives me some hope that someday they may drop stacked sequence structures from LV - something that has been there since day 1 and has never really belonged in the language.

Mike...

[MogaRaghu]

Yes Mike I agree with all you said.

Most times when I load a 7.1 version VI in 8.0 version, the one warning that I get is the replacement of the boolean False constants to hidden controls. Apart from this there are hardly any issues. But as I said when I try to work on a "Write Character to File.vi",  the on line help warns me with dire consequences.  OK its a just a warning - but all the same I have the funny feeling that all is not well and the "incompatibilty"  might strike when least expected...

It is in cases like this that I would like to hear from the horses mouth or experts on this forum. Is it OK to use those unsupported functions (or) whatever the time penalty,  proceed to replace them with compatible functions ?

Thanks

Raghunathan

[altenbach]

---

@Raghunathan wrote:
Assuming I ignore this warning ( maybe there are too many replacements to be made ) and go ahead and build the VI with LV8.0, will something unforeseen happen ?

---

If the VI is not broken, you should be OK. Every version upgrade, some old VIs get "retired" and replaced by more functional versions. The old versions of the same VIs no longer show up in the palette, but they are still avaliable for backwards compatibility.

If you look e.g. in "labviewdir"\vi.lib\_oldvers\ you'll find some of these zombies. They are typically perfectly fine and work as before if you want to limit yourself to the old functionality.

[MogaRaghu]

---

@altenbach wrote:

---

  If you look e.g. in "labviewdir"\vi.lib\_oldvers\ you'll find some of these zombies. They are typically perfectly fine and work as before if you want to limit yourself to the old functionality.

---

 Perfect. This was the information that I was looking for.

Thanks.

Raghunathan.

[MogaRaghu]

---

...it also gives me some hope that someday they may drop stacked sequence structures from LV - something that has been there since day 1 and has never really belonged in the language.

Mike...

---

Agree and can understand your point of view. But I think the guys at  NI must have had a real reason to put in the stacked sequence as a native item on the palette. And if you see the attached VI that is pulled out of a much larger VI, you will undertand why the guys at NI did what they did.

This stack example that I have enclosed is used for checking the existence and then creating some 10 different folders as part of an intialization process. ( Just to keep it simple to post I have removed the error handling part and a few other items )  Is there any other way that this can be done ??

Raghunathan

[altenbach]

---

@Raghunathan wrote:

Is there any other way that this can be done ??

---

Ugh!!! that code is ugly. A big problem is the use of string-to-path and path-to-string functions. This immediately breaks OS independence.

Then we have 10 frames that are virtually identical except for the string constant. Here we can get away with one instance of the code in a FOR loop autindexing on an array of string constants. Right? The code will be about 10x smaller without any loss in functionality and without any need for sequence structures. And if we need to change the code, we need to change one thing, and not the same thing in 10 different places.

Why do you need to list the same folder 10x, you'll always get the same result! Way too much repetitive work.

(I don't know what your missing subVI does, so you need to adapt. Currently I am using the home path of the VI.

Message Edited by altenbach on 08-27-2007 12:59 AM

[MogaRaghu]

Hi Altenbach,

I just kept looking at your solution for a long time. Excellent ! The FOR loop - frankly it never occured to me.

I think it has got to do with the fundamental thinking of breaking down the problem and grouping common items.

I do agree that once you morph into the "data-flow" thought process, such things should become obvious.

Great job.

thanks again.

Raghunathan

[altenbach]

Of course trying to create a folder that already exists simply creates an error that we can ignore, so we don't really need to test if it exists. We don't even need to list the folders.

For a completely bulletproof program, you should still do some more error handling, for example if a file exists that has the same name as a folder you are trying to create, you would also fail.

Message Edited by altenbach on 08-27-2007 08:20 AM

[MogaRaghu]

Hi Altenbach,

Yes i did notice that you had left unhandled two points where errors are expected to happen and added them as you have just done.

But I always used to wonder if this practice of using the function "Clear Errors " is OK ? I mostly use this function to clear the error from a DAQMx Read which is meant to read Encoder pulses.( When the pulses stop, it generates an error.  ) I am not sure what happens to unhandled errors that which are not cleared like this ? Do they accumulate in the background like leaked memory or they are just ignored by the LVRT ?

Thanks

Raghunathan

PS : I am still on LV8.0 and hence could not directly use your code snippet !

Message Edited by Raghunathan on 08-28-2007 12:50 AM