Increasing memory when reading values from Beckhoff PLC with .NET

[UliB]

Hello,

I have a simple LabVIEW program which gets the latest values from Beckhoff PLC using TcAds (.NET ?) and displays them.
At the start the program uses about 25 MB of RAM. In task manager I can see that the memory is slowling increasing. After running for some hours the read routine throws an error 2 'Memory full'. At this point the program uses more than 200MB of RAM. 
I quit the program and if I try to run it again I get an error message 'error 9 creating temporary LVSB resource file', so I have to restart the PC.

Could someone please have a look at my code and suggest what I should change to avoid increasing memory.

UliB

[Kyle97330 · Accepted solution]

You're disposing and closing these references with .NET nodes, but not telling LabVIEW you're done with them.  Add a Close Reference function to close it in LabVIEW in addition to .NET, and see what that does.

[UliB]

---

@Kyle97330 wrote:

You're disposing and closing these references with .NET nodes, but not telling LabVIEW you're done with them.  Add a Close Reference function to close it in LabVIEW in addition to .NET, and see what that does.

---

Thank you,

that solved the memory problem. The solution is kind of obvious, but I did not see it.

Another question:

Right now I open and close the references for every read. Is it possible to open AdsStream and/or BinaryReader only once and reuse the references?

What would the code look like?

Would it just be AdsStream.Position=0 and BinaryReader.Read in the loop and the other nodes outside the loop? Or would BinaryReader have to be recreated each time with the reference of AdsStream.Position?

UliB

[Kyle97330]

I mean... maybe?  It all depends on how the DLL you're using is set up.  I'd suggest checking the programming guide for the DLL or manual for the PLC in question.

It looks like you're getting some measurements, not sure of what, but you can probably just set it up to run on one of the measurements without recreating the reference each time, then try it over and over again while you vary whatever it is you're measuring, and check to see that the measurements you're taking are different each time and track the changes in real time (i.e. they're not buffering and lagging behind, for instance).

[UliB]

---

@Kyle97330 wrote:

I mean... maybe?  It all depends on how the DLL you're using is set up.  I'd suggest checking the programming guide for the DLL or manual for the PLC in question.

It looks like you're getting some measurements, not sure of what, but you can probably just set it up to run on one of the measurements without recreating the reference each time, then try it over and over again while you vary whatever it is you're measuring, and check to see that the measurements you're taking are different each time and track the changes in real time (i.e. they're not buffering and lagging behind, for instance).

---

Thank you very much for your suggestions.

Unfortunately I don't get the time to try it again and again and I have too little experience working with .NET elements. But opening the reference once every 250 ms works and I'm fine with it.

I was just curious and hoping someone who has experience with Beckhoff ADS would comment.

UliB

[rolfk]

I only use the Beckhoff ADS DLL (or my own TCP/IP based since that also runs on cRIOs) interface and there I don't need to open and close a port continuously. I do have some provisions in my driver that when detecting an error on any read or write method, will close the port and the next method call will detect the closed port and open it again. This is all transparently hidden away behind a class implementation, and I have a class for native TCP and DLL use.

I also have an ActiveX and .Net class implementation but never use them. The ActiveX variant suffers from a bug in the Beckhoff ActiveX type library that defines the Read method to only return one byte with each call and there is no way to convince LabVIEW to ignore this type library definition. I hacked the Beckhoff ActiveX component at some point to change the type library to define the read buffer correctly as an array of bytes rather than a pointer to a byte and that worked, but it is an unmaintainable solution.

The .Net class I never use since I like to avoid .Net whenever possible.

[UliB]

Thank you for sharing your insights.