.NET losing referene

[Engmar]

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.

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.

[tyk007]

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.

[TheNIDragon]

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:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LDcSAM&l=en-US

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.

[Engmar]

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:

---

[Juan_Carlos1983]

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.

[Yamaeda]

---

@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. 🙂

[Juan_Carlos1983]

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. 

[aptivo]

Try using the Labview Execution Trace toolkit

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