Calling DB Tools Open Connection VI Slows down the application execution when DB is offline

[Adarsh]

Hi,

In my application I'm logging data samples to a Database (DB is SQL server, Inserting a set of data for every one sec). If database connection lost I retry to reconnect every 1 min until I succeed. My application is pretty large does data acquisition, process and display all have been implemented in different independent loops.

When DB connection is lost, a separate loop will be enabled to try connecting DB, loop iteration is ~1min. The issue I'm facing is when I call "DB Tools Open Connection VI" with connection time out 5 sec, the entire application execution slows down(all the independent loops) for 5 sec. An interesting fact is the processor utilization goes down in the 5 sec time.

Processor utilization in normal execution time is ~45%.

Can any one experienced similar issue or any thoughts on this?

Thank you

Adarsh

Development environment: LabVIEW 2016 32bit on a Windows7 64bit i5 processor with 8GB RAM

[rolfk]

Well the database toolkit uses ADO to realize the database connection. ADO is an Active X technology that typically will require apartment threading. This means that an application needs to call any method on an object always from the same thread. The only thread where LabVIEW can guarantee that is the UI thread. This thread also is responsible to do user interface updates (not generally a problem as the UI simply freezes during that time) but also functions like the Open VI Reference and all Frontpanel object property nodes will require a switch to the UI thread. So if your loops contain property nodes to change attributes (or God beware values of frontpanel controls) they need to wait (and therefore block the according loop) until your DB Connect returns control.

One more very good reason to NOT use the Value property to update the front panel!

[Adarsh]

Understood the cause, How do we resolve this? We can't avoid FP object property nodes as we do a lot with that(Change background color etc).

Thank you

Adarsh

[Blokk]

---

@Adarsh wrote:

Understood the cause, How do we resolve this? We can't avoid FP object property nodes as we do a lot with that(Change background color etc).

Thank you

Adarsh

---

Changing background colour is not something what you do iteratively in a loop. For the rest is the common LV rule applies: change controls by local variables, change indicators by wires...

[Adarsh]

As per my application requirement, I have to change the background color and other indicator properties iteratively in a loop based on alarms and warnings. so I can't avoid it.

I still surprised LabVIEW is getting freezed in all the FP updating functions inside the loops(Though loops are running independent) if we use ActiveX call in one place. That too until the activeX call returns its control!!

Is there any there any alternate solution?

Thank you

Adarsh

[Blokk]

Regarding to (overusage of) property nodes, you cannot really do anything. They are slow, that is why using them (even reading property!) iteratively, will slow your app down. When you use property nodes, the code swaps to the UI thread, and it takes time. Property nodes are 1-2 order of magnitude slower than local variables or "by wire" operations.

As per my application requirement, I have to change the background color and other indicator properties iteratively in a loop based on alarms and warnings. so I can't avoid it.

You did not mention, but how fast do you iterate through these properties? What is the iteration time? I imagine, you could improve this part of your code. First of all, you should not use property nodes for reading out control/indicator properties (BG colour, etc), instead store these info in a shift register (in a cluster, array of clusters, etc). Second, you should only call a write property node (changing BG colour, etc) when a certain status changes, so use a Case structure+FOR loop combo with an array of references for your indicators/controls. Maybe you already do this, but if not, this should limit the number of property node calls per iteration.

Another thing you can try, when you need to go through a bigger number of references (so when you need to change a lot of properties by property node writes), you call the Defer Panel Update node and set it true before you start to set the lots of properties, and when you finished it, you turn it back. This might help.

But the real solution would be just not use control/indicator properties for GUI enhancement, specially not in a iterating loop! There are other ways to create such GUI elements, like creating special clusters for your indicators/controls including 2D picture controls, etc. With such design, you do not need to rely on the slow property nodes, you set 2D picture indicators by wire!