Why does Labview 8.0 upgrade cause broken wires between .NET nodes ?

[Gary_H]

Hi,

I recently upgraded to Labview 8.0 on a development PC.

The current project contains VI's from a third party, which use .NET method and property nodes, developed

in Labview 7.1.

Because the upgrade created another sub-dir for Labview 8.0 in Program Files, I did an un-install, then re-installed

the 3rd party software. This was followed by a Mass Compile which did not indicate any problems.

Since the upgrade, some of the VI's have broken wires between nodes.

As an example, a broken wire now occurs between .NET Constructor node and a .NET Close Reference node.

In the past we have had similar problems with ActiveX related nodes. But these were resolved by re-establishing

the link between the third party's custom control (strict typedef) used in the broken VI's and the appropriate

ActiveX class, using the Labview .ctl editor.

Re-selecting the .NET Class for the custom control (strict typedef) used in the broken VI, did not cure this .NET problem.

It has been suggested that the problem will be resolved by deleting the related VI nodes, and then re-creating them.

This is something which I would rather avoid because it involves several VI's.

Is there a more efficient way of correcting this problem ?

Any information would be appreciated.

regards,

Gary.

[Joe_H]

Just out of curiosity did you install support for ActiveX and .net when  you installed 8.0.

Just a thought.

[Lycangeek]

I can think of a few reasons, but the one between a constructor node and a close doesn't make sense. It may be the constructor node is broken, however, if it takes any parameters.

The problem was that LabVIEW was incorrectly representing some .NET data types as input/output when they were input only, or not correctly handling .NET pass-by-reference types. Those have been fixed in 8.0 (a couple corner cases in 8.0.1, but I always recommend upgrading so I'd get 8.0.1 if you haven't already).

Unfortunately, this cause some to break. Reselecting the method or constructor variant fixes the problem (not counting fixing the wire if you wired to a now-disappeared output terminal).

The other problem I could see is if the .NET assembly you are linking to is a strongly named (digitally signed) assembly and the version has changed since you upgraded.

If you could post up an example, I could dig more into this and discover what is biting you.

[Gary_H]

Hi Brian,

I believe I've installed the ActiveX/.Net support, primarily because the Functions palette

contains both libaries, (thank you for the suggestion Joe).  

I've attached the top level VI which contains the broken wire, along with a called sub-vi.

Also included is a custom .ctl file which defines the .Net reference used in the top level VI.  

I can provide further detail if required.

With regards to your suggestion about upgrading to 8.0.1, am I taking the right path by

installing Labview 8.0, using the NI Update discs from Nov 2005 (the introduction of Labview 8.0),

then installing the next Update discs from Feb 2006 and then Aug 2006, or would you

suggest otherwise ?

(The covering letter for the Update CD's, Feb 2006, advised installing Labview 8.0 first,

i.e. Nov 2006.) 

All suggestions and advice much appreciated.

Gary.

[SachaE]

Hi,

Are they private .Net assemblies you're referencing?

  http://zone.ni.com/reference/en-XX/help/371361A-01/lvupgrade/labview_8_0_features/#Using__Net_Assemb...

In this case, you'll have to remove and replace the contructor nodes each time - sorry. - You said the suggestion of removing and replacing had been made - have you tried it yet?

Hope that helps

Thanks

Sacha Emery
National Instruments (UK)

[Lycangeek]

As far as getting 8.0.1, I don't believe you'll see that in the update disks, but I'm not certain - being a developer often means you don't know how your software is getting out to customers 🙂 It may be part of the driver update disks, or if you're part of the subscription service, you may be getting it. Either way, you should know because you'd need to run the 8.0.1 setup program.

If it isn't on those disks, you can get it here. Don't forget that you'll want to mass compile your libraries (especially vi.lib) to get the performance.

Thanks for posting the VIs. Is there any way you can post the .NET assembly as well? I'll need that to try to work out the issue.

[Gary_H]

Brian,

Please find attached the .Net Assembly file (ArendarClient.dll) as a zip file.

regards,

Gary.

[Lycangeek]

Okay, now I'm missing "Traverse Arendar ProductTestDef.vi", "Arendar - Execute and Display SQL Query.vi", "Arendar - Open Object Broker.vi", "Arendar - Close Object Broker.vi", "TYPEDEF Arendar Manager Cluster.ctl", etc.. I'm not sure what else is going to be missing. You might want to try making a copy of what you plan to send to me in a different directory (completely different drive if possible, or at least a different root folder off C:) and attempt to load it. I won't be able to address all the broken wires w/o those. However, here is what I've found...

In SN Recursive Execute.vi, I needed to fix one broken wire due to the fact that TestFolderManager.user is an input only parameter. This is one of the expected changes in upgrading, but fixing it is pretty simple. In "Traverse Arendar Folder.vi", again you have an input/output conflict in TestFolderManager.testFolder, which is input only.'

Finally, you need to help LV find your assembly. I won't go into the complexity of all the issues with .NET assembly loading, but the simple solution is to right-click on one of your .NET front panel controls, or a static invoke node, and say "select class". You'll notice that there isn't anything there at first - it's because we've lost the reference to the assembly. Simply rebrowse to your .NET assembly and pick the right class.

Once I did these three things, everything was fine except for the missing VIs and TYPEDEFs.

[Gary_H]

Brian,

Thank you for all your replies.

Following your and others suggestion,  I have corrected the broken VI's by manual repair.

To summarise the outcome:

Having installed Labview 8.2, followed by an install of software from a 3rd party, I found several broken

VI's installed to ...\vi.lib\addons.. belonging to the 3rd party.

Most of the broken VI's had an Invoke node which was reported as calling an invalid method.

By selecting another method for the Invoke node, then re-selecting the original method,

the problem would clear.

Because the VI's involved are supplied as a self installing package for a 3rd party application,

I've passed the problem back to the 3rd party who recognise that there is a problem with

their .Net components when used in Labview 8.0 - 8.2 , but is o.k. in 7.1 .

Thank you for all the help.

Gary. 

[Gary_H]

Brian,

I've seen the light........... you previously said:

The problem was that LabVIEW was incorrectly representing some .NET data types as input/output when they were input only, or not correctly handling .NET pass-by-reference types. Those have been fixed in 8.0 (a couple corner cases in 8.0.1, but I always recommend upgrading so I'd get 8.0.1 if you haven't already).

Unfortunately, this cause some to break. Reselecting the method or constructor variant fixes the problem (not counting fixing the wire if you wired to a now-disappeared output terminal).

The "Invalid methods" reported by Labview 8.0 and 8.2 did have parameters wired as both input and output.

Reselecting the methods at fault did create the parameters as input only.

This left me with some surplus Close Reference.vi 's to delete, and others to re-wire, then everything was fine.

Thank you.

Gary.