09-09-2015 03:04 AM
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.
09-09-2015 07:18 PM
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.
09-09-2015 09:25 PM - edited 09-09-2015 09:25 PM
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.
09-10-2015 04:22 AM
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:
04-18-2020 07:15 AM
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.
04-18-2020 03:51 PM
@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. 🙂
04-18-2020 04:19 PM
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.
04-20-2020 09:27 AM
Try using the Labview Execution Trace toolkit, which you can find here.
It lists all open references which are not closed during runtime.