Daq factory slows then closes after 20 mins


Recommended Posts


I am setting up a scada system to log data via opc from some extrudung machines.

Daq factory gathers and displays the data ok but appears to slow down and eventually the program closes this is after 20mins running.

I have only 150 tags loading in async mode and only save data to file every minute.

OS is xp profesional PC is centrino duo with 2gB ram

there is no script in the daq program just display - program is attached

I have tried running in aquire mode and program still quits after 20 mins, this needs to be stable as it is intended to capture data on a 24 / 7 basis.

any ideas ?


Link to comment
Share on other sites

The problem is probably with the alarms. There are two things:

1) in your alarms, you do something like this:


when you should do:


without the [0] it will compare the entire history of those channels, then look at the most recent comparison. As you accumulate more data in the history, this will then take longer and longer. Its probably negligable if you only had a few alarms or a few channels, but every alarm condition is evaluated with every tag read, so the effect is multiplied many fold.

2) as I said, with every new value from any channel, every alarm is scanned. With large channel counts and large alarm counts this can get inefficient fast (especially if you forget [0], but even with it). You can control when alarms are evaluated by turning off the automatic checking, and manually checking from a sequence. You'd do something like this:

alarm.paused = 1  // stop automatic checking
while (1)

This will check the alarms once every 5 seconds. You should check the alarms at whatever the data rate is, so if your data is coming in once a second, you should change the delay(5) to delay(1).

Link to comment
Share on other sites

Ok Seems to work ok without slowing down but still quits after exactly 20 mins with no warning message. regardless to if the computer is in use or only running daqfactory. OPC server is still runnning

this happens both in runtime and in development.

question:- I am still waiting for my licence to arrive so am still running a trial version - can that be the cause?

I have modified the program to add the[0] this prevented the slow down and have set the alarm delay to 1min. the logging has been set to 5 minutes.

I have attached the revised program - any ideas?


Link to comment
Share on other sites


to change the X axis time scaling, change the Time Width parameter of the bottom axis.


you have two sequences that both autostart and both do exactly the same thing (check the alarms). I don't think they would conflict, but they would use extra processor power


Is it exactly 20 minutes? That seems odd. What OPC server are you running? What hardware? Does the hardware support Modbus? No, the trial version won't cause this problem. The only difference between trial and licensed versions is that the trial displays the opening window, won't create runtimes, and doesn't give you access to all the symbols in the symbol library.

Link to comment
Share on other sites

I didn't notice before: why are you doing async and sync? This can cause issues, but first, try changing the Timing of all your Async channels from 5 to maybe 6. Its easy to do, just double click on the top one, then type 6 then enter. You will be moved down to the next cell and so can just repeat 6, enter, 6, enter until you get through the async channels. Leave the sync ones alone. See if that changes it from exactly 20 minutes to maybe exactly 24 minutes. If not, try setting the sync ones all to Timing of 0 (essentially disabling them) just to see if its some conflict between async and sync.

Link to comment
Share on other sites

Yes i have just noticed that, this project is still in development .

I have the licence dongle now. so will be trying this program with the changes as a runtime on a remote machine.

I have a logging only program with no displays or alarms this seems to run without quitting so could this stiull be in the alarms or display area?

Link to comment
Share on other sites

OK thanks for your advice....

have set all channels to async, and have removed any unused channels etc, as a runtime it seems to be stable, working as expected.

I have another runtime looking at a plc via modbus - this does seem to work a lot better than reading async from OPC.

I tried sync for all channels but experienced problems in reliable program start up even with offsets for the channels - this may have been a network or opc issue

will let you know if I get any more problems

Link to comment
Share on other sites

  • 4 weeks later...


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