Re : application freezes during user inactivity

[DKoehl]

Hi.

That's my first post, since usually I find all the answers I need in the already existing posts. But on this specific issue I haven't found anything. So, here it is:

I am experiencing a rather strange behaviour of my LabView application (built executable) lately. The whole application totally freezes after some random time (typically a few minutes) of user inactivity. It should be noted that "user inactivity" doesn't mean that I'm not working with the PC, but that I'm just not working with the running LabView application. When the application is frozen, it does not perform any task, i.e. none of the various instrument I/O, data logging or process controller routines is running anymore. However, as soon as I perform a simple mouse click onto the panel it immediately resumes work just as if nothing had happened. There is no error message or anything. Only from the data log (and unfortunately also from the behaviour of the machine I'm operating...) it is evident that ALL routines were frozen instead of the frontpanel only.

I was not yet able to identify any possible reason for this behaviour. As I mentioned, it also happens while I'm working with the PC, having the application running in the background. So it's very likely not related to any general power save modes or the screensaver (especially since they're disabled anyway). It also doesn't seem to be related to whether the application is the active foreground window or not. It freezes in both cases. Although I'm not sure about this, the problem seems to occur more likely in cases where some sub-VIs are running in a fast mode (like when I activate a fast process controller). However, CPU usage is still far away from critical even in such a case. So I don't think it's a simple performance issue either.

To me it appears as if either the LabView application or the operating system (Win7 enterprise, 32 Bit) decides to freeze the application due to user inactivity. Although our system administrator doesn't think it's a Win7 issue. But who knows...

I'm communicating with up to 5 remote SPS clients (Beckhoff TwinCAT) via the ADS dll through an Ethernet and Ethercat connection. Data from these clients is read at fast pace when the process controller is active, which is when the application most likely freezes. Could it be a problem with the network probably?

I'm using the LV 2011 professional development version with the latest service pack installed.

Unfortunately it is not possible to post any code, since the application is just far too large.

I have already tried to change the priority of the application in the task manager by changing the priority of the process to "high" instead of normal. However, this hasn't changed a thing...

I hope I've posted enough information about my issue. If not, please let me know if you need any additional info.

I would be very grateful for ANY hints that would help me fixing that annoying issue.

Thanks.

[DKoehl]

Here's some additional info about my specific problem:

I have now also experienced the application freeze when I ran the code in the development environment. Hence it is not restricted to the built executable.

Furthermore, I had experienced these freezes a couple of weeks ago, which was when I implemented the sub-VIs that communicate with the SPS clients via a shared dll. As I mentioned, there are 5 clients that I'm communicating with. For 4 of 5 clients, the sub-VI is identical, which is why I run that as a reentrant VI. The remaining client is dealt with by a different sub-VI, so I had left this at the standard setting (non-reentrant). When the application freezes first occured, I had changed the thread setting in the respective dll calls from "run in UI thread" to "run in any thread" (in both, the reentrant and the non-reentrant sub-VIs). At that time, this seemed to have fixed the issue and freezes did no longer occur. The (possible) reason why these freezes are occuring again now is because for the process controller I'm now running that remaining non-reentrant VI at a fast pace.

So, now I have checked the LabView help file for dll calling conventions. Regarding the thread selection it says the following line (amongst other hints of course):

Before you configure a Call Library Function Node to run in any thread, make sure that multiple threads can call the function simultaneously. In a shared library, code can be considered thread-safe when:

• It is called by only one non-reentrant VI.

If I interpret this correctly, my code should be safe because so far the dll was called by four reentrant and one non-reentrant sub-VI. Or am I doing a mistake? However, I have now changed also the VI for the single client to execute reentrant. I don't know whether this will have any effect but I'll just see whether this makes any difference now.

I know that my issue is rather specific and it might be difficult to give any advice without a code that I could post. But I hope that anyone at least has any idea about what might be wrong with my application.

Thanks in advance for any advice.

[Aurelie]

Hi,

what you describe is no standard LabVIEW error. To be quite honest, it does look more like a programming error/unexpected effect... Could it be that you in a subVI have an event waiting for a click or waiting for the application being given the main focus ?

Could you maybe try to get the "essence" of your VI and post it/a screenshot of it ?

--

Aurelie

Application Engineer

National Instruments

[MaxCrunch]

---

@DKoehl wrote:

Regarding the thread selection it says the following line (amongst other hints of course):

Before you configure a Call Library Function Node to run in any thread, make sure that multiple threads can call the function simultaneously. In a shared library, code can be considered thread-safe when:

• It is called by only one non-reentrant VI.

If I interpret this correctly, my code should be safe because so far the dll was called by four reentrant and one non-reentrant sub-VI. Or am I doing a mistake? However, I have now changed also the VI for the single client to execute reentrant. I don't know whether this will have any effect but I'll just see whether this makes any difference now.

---

I believe your interpretation of this is not correct. The statement you quoted would be better expressed as " It is called by only one non-reentrant VI and is not called by any reentrant VIs".

Calling a dll from 4 reentrant VIs means that it is executing in 4 separate threads, which may well cause problems if the dll itself is not thread safe.

Good luck!

[Ezraal]

I actually have the same problem and I am using Twincat IO.

I actually work on this problem and it seems that the problem occurs when i install the antivirus.

Can you tell me the name of your antivirus?

[GillesB]

Hello Erzaal

I am currently very much affected by the same problem.

My application freezes at any point of execution.
I also use TwinCAT I / O. It seems that the problem only happens in Windows 7.

I developped a big application (7 axis, vision, DB) and the problem only happens in some clients.

Have you found a solution to this serious problem?

With best regards

Gilles

[mikeporter]

Please note that this is a very old thread with multiple reply posts. You will be lucky if the people who can answer you question see it. My recommendation is to repost it as a new question with a complete description of your problem.

Mike...

[Ezraal]

I also have seen this problem on XP.

Just after the IT manager installed the protection of the computer (antivirus, firewall)