channels eating RAM memory --> TERRIBLE!!!


Recommended Posts

Hello DAQFactory crew and users,

I have a very serious problem :rolleyes: . My runtime eats memory at my computer and this results finally in a system crash! How can i ever deliver runtimes to my customers with this kind of problem? They can't even work any longer than 1 week without restarting the computer! DAQFactory please help me because this situation needs to be solved as soon as possible. Are there more customers with memory problems??

How do I know it's caused by the channels?

I've deleted all pages, all sequenes, all:

  • logging sets
  • export sets
  • V-channels
  • Alarms
  • PID sets
  • Conversions

And the problem still remains....

I'm using OPC communication to Eurotherm OPC server with the following functions:

  • analog out
  • asynchronous read (without persist (pts) but with history (10pts) )
  • asynchronous read (with persist (2678400pts) and history (3600pts) )

I've checked everything with the help topics but the number of points are far away from the critical area.

Also tried to split up the problem into the different types of "I/O type" but i could only exclude the "Analog out" type. It seems to be that it doesn't matter if I i'm using persist or not.

The runtime is attached

Please help,

Bart van Diepen, Pro Control B.V.

run1_v2_1_testChannels_all.ctl

Link to comment
Share on other sites

The problem is that you have two sets of two async channels with different channel names referring to the same OPC tag. This is causing the async requests to get reentered every other second into the tag database which is causing the database to grow over time. Simply remove the duplicates and the problem will go away.

Link to comment
Share on other sites

Hello DAQFactory,

Thanks a lot for this reply! This seems to be the solution for the problem! I really appreciate the fast response. I couldn't find out where the problem was coming from because i made at 2 places this failure.

I see also a disadvantage for the future, because before i ship a runtime to a customer i should check manually if i've duplicated OPC items. Maybe a check or warning coming from DAQ would be nice.

kind regards,

Bart van Diepen

Link to comment
Share on other sites

Hello Daqfactory,

It seems that the duplicate channel address is not the issue. We corrected the tags, and the memory usage still increases. The next test that we did was a single screen with one sync OPC tag. After a day we notice that the memory usage is still rising. We did this test on a number of machines, and get the same result everywhere.

When we repeat the test using modbus communications, we see that there is no more memory leaking. So i guess that the problem is somewhere in the OPC layer of daqfactory(we did the opc test with different clients).

How can we isolate the problem even further??. We feel that we are really close to a solution.

Bart van Diepen,

Pro Control B.V.

Link to comment
Share on other sites

Hello,

The memory increase with appproximitely 5-10mb in one day. The runtime was set up completely new with one channel created. We thought maybe it's caused by the OPC server (Eurotherm) and yesterday we run a test with another OPC server (Matrikon), but unfortunetely the same results.

This is really nasty bug and i'm suprised that there are no other customers complaining about this...

Is there a solution?

Bart van Diepen

Pro Control B.V.

Link to comment
Share on other sites

I am surprised too. I believe the bug is somewhat new, though I am unsure what is causing it as this code has not changed in many years and never had this problem before. I can only presume that there has been some change in the OPC dlls. Perhaps you can try it with the OPC servers from Software Toolbox (www.softwaretoolbox.com). In the mean time we will be looking into it intently.

I presume this is with sync tags only?

Link to comment
Share on other sites

  • 2 weeks later...

Hello DAQ developers and users,

With the new release 5.78 two memory bugs are fixed:

- OPC memory problem

- change frequently forecolors of text elements

I've tested this now for 2 days and now the memory usage is stabile :blink: .

Great job DAQFactory!

Thanks a lot,

Bart van Diepen

Pro Control B.V.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.