LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET losing referene

Hello,

 

I am currently facing a very strange problem when using the LabVIEW .NET functionality.

 

I am using an external Library from BECKHOFF to interface with their TwinCAT software via ADS (a special protocol). They give out the .dll file for the .NET protocol and I used it in various solutions including MATLAB and VB and it worked seamlessly.

However as soon as I tested the same library with LabVIEW I get connection issues.

 

My first problem was a hidden timeout, which made my reference unusable after 5000 seconds. I "solved" that problem by reconnecting every 20 Minutes. But now a new problem turned up: I don't get any answer from the TwinCAT software after 8-9 hours.

I have to clarify, that I run the same functions from the library in a VB program and LabVIEW to test for a possible solution. However only LabVIEW loses the connection after some time.

ADS Connect.JPG

ADS Read Variable.JPG

 

You can see in the picture above, that the communication inherits a lot of functions from the basic stream class.

 

I don't know if this is a general issue with LabVIEW or if I am missing something in my code.

0 Kudos
Message 1 of 8
(3,852 Views)

To be honest what you have posted isn't very helpful in solving the issue. I have applications with .NET assemblies galore running for months straight with no issues. Perhaps you could post your code or an complete example that demonstrates the issue.

 

0 Kudos
Message 2 of 8
(3,815 Views)

Hello Engmar,

 

It's very possible that LabVIEW is trying to use a different .NET framework version than you expect. Try to investigate the .NET assembly a little more to see which framework it was targeted for and this should give us some more clues. 

 

If the .NET assembly was targeted for a specific framework, you can use a KnowledgeBase article like this one to make sure LabVIEW is using the right one to load the .NET assembly:

 

http://digital.ni.com/public.nsf/allkb/32B0BA28A72AA87D8625782600737DE9

 

Also, you should be able to use NI I/O trace to see what calls those methods are actually making. If they match exactly the calls you're making in VB, then it's probably a bitness or framework issue, if not, it's probably an issue with how LabVIEW is reading the assembly. I assume the former.

 

Collin D.
Software Product Manager
0 Kudos
Message 3 of 8
(3,803 Views)

Sorry,

 

You'll find a code example in the end. I just copied the relevant code from a rather big project. In order to run the code the TwinCAT Software from Beckhoff is needed.


@tyk007 wrote:

To be honest what you have posted isn't very helpful in solving the issue. I have applications with .NET assemblies galore running for months straight with no issues. Perhaps you could post your code or an complete example that demonstrates the issue.

 


 

I tried to create a config file and am currently testing if it works. It will take several hours for the error to occur anyway, so I'll just have to wait


@TheNIDragon wrote:

If the .NET assembly was targeted for a specific framework, you can use a KnowledgeBase article like this one to make sure LabVIEW is using the right one to load the .NET assembly:

 


 

0 Kudos
Message 4 of 8
(3,784 Views)

Did you find the solution? I have the same problem, after some hours, error appears. I think that is a closing references problem. At first, i didnt close the Adsstream and binary reader references and the problem appears after 20 minutes.. not at 5 or 6 hours. I am iterating at 16 ms.

0 Kudos
Message 5 of 8
(2,703 Views)

@Juan_Carlos1983 wrote:

Did you find the solution? I have the same problem, after some hours, error appears. I think that is a closing references problem. At first, i didnt close the Adsstream and binary reader references and the problem appears after 20 minutes.. not at 5 or 6 hours. I am iterating at 16 ms.


.NET can only keep 1 million refs open, so if you don't close them when they're not needed that can happen quickly. A quick calculation shows that if you're iterating at 16ms and opens 13 refs that doesn't close you're at 1000000 after 20 mins. 🙂

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 8
(2,691 Views)

Yes, I know IT, but i have the same vi showed in a picture before in which i close the reference for the adsstream and for the binary reader and i dont know if i have to close more than this references each time i make a read, because in the examples of beckhoff official site, the references are not closed never. 

0 Kudos
Message 7 of 8
(2,689 Views)

Try using the Labview Execution Trace toolkit, which you can find here. 

It lists all open references which are not closed during runtime. 

0 Kudos
Message 8 of 8
(2,657 Views)