Updated Labview 6 code to labview 2017, Config.llb errors

[JCooper509]

We have some complex ATE code written in Labview 6, and we need to compile it to run on Labview 2017.

I've loaded it up, but it didn't find config.llb, which appear to be used extensively in the code. A search of the computer it runs on (an XP machine) reveals a local copy which I transferred across to my Win7 machine, and then pointed the Labview loader at this config.llb file. It found the required vis and loaded them, however they are badly broken.

For example, Config Data Registry.vi contains the error list shown in the attached jpg. I'm not sure exactly what's going on with it, the upgrade process appears to be getting data types very wrong, but it's beyond my meagre skills to fix.

I'm hoping that this config.llb is a Labview file rather than a locally made one, and that therefore others have run into this problem before and fixed it. Any help you could give to go forward would be appreciated.

[crossrulz]

The Config File library went through some massive updates over the years including making a bunch of the files private (can only be used by VIs in the lvlib).  I would rework what you can in your code to only use the public facing VIs.

[Ben]

I agree with crossrulz posted.

Spoiler

This is the situation that soured me on any of those "hidden gems hidden in LV"! If it ain't on the palette DO NOT USE IT!

Been there, done that.

In my case, there was a VI in the llb that would let us force a write to disk without closing the config file that was used by a predecessor in some re-use code. In the re-written config VIs, that where converted from the old GOOP approach to the new LVOOP version, only the VI that were on the palette where exposed as public methods on the palette.

When the old code was opened in a new version of LV, the conversion managed to find all of the replacement VIs except the "Write" ( or was it Save?). I had to remove the offending function and replace it with a close followed by a open.

So I suggest you forget about trying to use the old llb and just let LV open the code and let it find what it can. Only when the app is opened in a broken state chase down what LV could not figure out.

Ben

[crossrulz]

---

@Ben wrote:

When the old code was opened in a new version of LV, the conversion managed to find all of the replacement VIs except the "Write" ( or was it Save?). I had to remove the offending function and replace it with a close followed by a open.

---

In this case, it looks like all of the VIs and ctls are found.  The offending files are just set to a private scope in the library.  Looking closer at the error dialog, it is the type defs that are private.  So you could potentially just replace those references with the public facing type defs.  I would need to see code to say more.

[JCooper509]

The change in type def does make some sort of sense, since it appears that a part of the problem, at least, is that the cluster definitions have changed.

The snippet attached shows one of the problems. In the central case structure, the vi is taking the boolean "dirty" and the path "path" and trying to tie them to places that don't accept those data types. In the original LV6 code, that cluster has an array of strings called "section names" and a cluster called "data" respectively. That would suggest that it's picking up the wrong typedef for the cluster.

[Ben]

Yes, that is the issue I was alluding to previously.

Do not try to fix the old stuff. Just toss all of the old config functions with the new versions.

Ben

[JCooper509]

Just to update this if anyone else finds themselves in a similar hole and finds this in a search, but we eventually fixed this when we noticed that Labview 2017 also has a config lib in its own vi.lib, and when we pointed it at that it runs absolutely fine with no adjustments. I didn't try this at first because I thought it would substitute it in itself, but for whatever reason it didn't.

[billko]

Not the most optimal solution because your code will be DEAD if you develop on a machine that doesn't have LV 2017 installed.

[JÞB]

---

@billko wrote:

Not the most optimal solution because your code will be DEAD if you develop on a machine that doesn't have LV 2017 installed.

---

Not exactly.... with a 2017 lvlibP next rtes can run it.  Hmmmm. That might be related to why the type defs were not disconnected way back when......

[billko]

---

@JÞB wrote:

---

@billko wrote:

Not the most optimal solution because your code will be DEAD if you develop on a machine that doesn't have LV 2017 installed.

---

Not exactly.... with a 2017 lvlibP next rtes can run it.  Hmmmm. That might be related to why the type defs were not disconnected way back when......

---

I took "pointing back to..." to literally mean pointing to a folder.  So it followed that I assumed if you didn't install LV 2017, the folder isn't there, so what happens then?