LabVIEW Executable freeze Randomly

[bshvartsman]

Hello everyone. I have an issue where my executable freezes randomly, sometimes after an hour and sometimes after five hours.

As the software is large, thats why I will describe firstly what it is doing, closely describe the error and mention what I have already tried.

The software:

The application acts as a master and communicates with Siemens PLCs via Modbus and with 4 high-voltage power devices via Ethernet.
The framework I am using is DQMH.
PLC communication is in its own DQMH module, and the high-voltage power devices are cloneable DQMH modules.
In addition to some commands for the PLC and power devices,
Each slave module has a helper loop where values are written to the indicators on the front panel of the master module using property nodes.

The issue:
After an undefined amount of time (1h, 3h or 5h), the whole .exe freezes. There is no abort button and nothing is working.

What I have tried and paid attention to:
- Memory leak.
Hence, no data is logged. I did not expect this, and while the application is running and when it is freezing, the allocated memory is low (300MB).

- Writing logs to a file
I have implemented a log buffer. I enqueue messages from EHl and MHL from each module and write them to a text file in a separate helper loop inside the main VI of the master module.
I couldn't see anything special there. At one point, there are no logs. There is also not much to log; after a successful day without crashes, log.txt is about 2 MB in size.
- Inside the event structure, I only enqueue messages to the MHL and the log buffer.no other procedure.

Have you experienced this too and/or do you have any suggestions on what I can try?

[Bob_Schor]

There is something seriously wrong (I'm guessing here) with your code (or possibly your version of LabVIEW cannot correctly execute "valid LabVIEW code").  Since you've shown us nothing about your code (except to suggest it uses the latest version of LabVIEW, which many of us have not yet installed), it is difficult to suggest how to help except to say "Find a colleague who knows LabVIEW and show her (or him) your code and ask for help".  If you are lacking such a colleague, find someone who knows any programming language and "walk them through your code", explaining what the various LabVIEW symbols mean and how Data Flow languages work (Google "Rubber Ducky Debugging").

Bob Schor

[altenbach]

---

@bshvartsman wrote:

Hello everyone. I have an issue where my executable freezes randomly, sometimes after an hour and sometimes after five hours.

---

Does that mean it never happens in the development environment, just after building an executable?

If so, you might be able to do some remote debugging.

Is this running on plain windows or an RT system?

Is the event structure(s) always "in the dataflow"?

You said you checked for memory leaks. How about other resources (e.g. constantly opening new references and never closing them)

[Kyle97330]

The 3 main things I would check for on a system that "suddenly" stops working:

1. Unhandled errors

Check to be sure that there's nowhere that an error could occur that won't result in some sort of error message or log being generated.  Remember that "automatic error handling" does NOT work in an EXE, so if there's anywhere you're depending on that in dev it won't work in an EXE.  You also need to check any loop that has its error wire on a shift register that isn't programmed to exit when it sees an error.

2. Counters reaching a limit

If you have any loops that spin super fast (over 10000 times per second) and use their "iteration" terminal for something, or anything else that increments over time (especially things that only use 16-bit counters), they could be hitting their limit and either they don't increment any more or go negative and cause a problem that way.

3. Resource limits

Altenbach already mentioned this (constantly opening new references and never closing them), but more specifically, LabVIEW can only have a little over 1 million opened references at a time (2^20th power).  So, look for anything that creates a new reference in a loop without closing it.  This can be queues, DVRs, notifiers, user events, .NET references, VI references, and many other things.  It will NOT be anything that's a GObject, so the property nodes that you mention probably won't be the problem.

[bshvartsman]

@Bob_Schor

---

Yes, I did a lot of 'rubber ducky debugging' with myself. Hence, I am the only software guy in my branch office here.

The software went live with LabVIEW 2024Q1, and I updated it in the hope that the bug would be resolved. My colleagues know how to handle the issue (kill the software with Task Manager and restart), and they are happy, but not me 😂

@altenbach

I haven't experienced it yet in the development environment. I let my colleagues work on my laptop with the development environment for a couple of hours several times, and it worked.

Hence, my colleagues know how to handle the issue (kill the software with Task Manager and restart), and it doesn't really disturb the workflow. However, I cannot let them work on my laptop all day.

Is this running on plain windows or an RT system?: 
Plain Windows

Is the event structure(s) always "in the dataflow"?:
No nested Event structures. I am using the DQMH Framework

How about other resources (e.g. constantly opening new references and never closing them)

The only references I am opening are the GObjects (controls and indicators). For PLC communication, I am using the Modbus library, and for power devices, I am using the VISA. I create a Visa session at the start of the programme and close it on exit.

@Kyle91330
Thank you for proving the points.

Unhandled errors:

I know this, which is why I am using the DQMH framework — the errors should be handled. But if that were the case, the whole front panel should not freeze?

Counters reaching a limit:

That's interesting to know for the future. However, I am not using them in this application.

Resource limits:

The only references I am opening are the GObjects (controls and indicators). For PLC communication, I am using the Modbus library, and for power devices, I am using the VISA. I create a Visa session at the start of the programme and close it on exit.

Thank you all for the quick replies.

Any more Suggestions?

[Kyle97330]

You say "There is no abort button and nothing is working".

Does the main window of your application have the LabVIEW "Abort" button (the stop sign) visible on it?  Usually it's a good idea to hide it, but if you have done so I would suggest adding it back in just for testing.  As a general rule, if you use that "Abort" button and it fails, it usually means it's either a problem with LabVIEW itself or with a 3rd-party library (DLL/ActiveX) that you're using.  If that Abort button is available and works, then it's more likely that it's a problem with LabVIEW code somewhere getting stuck.  So, by adding it in and trying it, it can possibly narrow down just how "locked up" it really is.

Also, this question and response I think needs clarification:

Is the event structure(s) always "in the dataflow"?:
No nested Event structures. I am using the DQMH Framework

I believe you are answering a different question than was asked.  Typically anything in an event structure should be something that resolves near-instantly, such as enqueueing a command to a message handler or similar, and not something that could take a lot of time to resolve.  And if you have an event structure on a VI, it should usually activate quickly and stay active until right before the VI closes (i.e., it's "in the dataflow").  If this ever isn't the case, you can get an event structure that builds up a pile of events that never resolve.  So, is there a way that could be happening?

[bshvartsman]

Hello Kyle,

Abort button fails as well.

Is the event structure(s) always "in the dataflow"?:

I only enqueue messages inside the event structure. I didn't completely understand the second part.

Do you mean that if the ELH is finished and the MHL is about to exit, but some dynamic user events are triggered, it could crash the application? If so, it would be interesting to check. In my case, however, the crash never happens during the exit procedure; it always happens while the application is running.

[Kyle97330]

With what you're describing, it sounds more like it's something in a DLL or ActiveX call that's halting, not anything related to your code. LabVIEW's abort button should be more than able to force an exit if you somehow had an event structure's loop end causing an event "pile-up".

Do you have anything that calls DLLs (.NET or otherwise) or ActiveX in your application?

If you haven't added anything like that directly, it could be something that's in a LabVIEW toolkit (for instance, the Report Generation Toolkit).  It could also be a driver problem with some of the hardware you're using.

[bshvartsman]

What i am using is:

• Visa communication over TCPIP with 4 devices
• Modbus librarary
• DQMH functions

So no .NEt or Active X.

I am also using sound output from the sound palette. Hence it is not really relevant, will deactivate it and try.

[pincpanter]

---

@bshvartsman  ha scritto:

I am also using sound output from the sound palette. Hence it is not really relevant, will deactivate it and try.

---

That may be the winning bet. One of my programs also freezed abruptly after a variable time (typically 30 min to few hours). After weeks of tests, I found that using Play Sound File in a thread other than the user interface one seemed to solve the problem. Further tests are undergoing.

If it's really this vi, I guess it's a bug. Or at least the help should warn about this issue. This problem occurs in LV2017 and LV2021. Not tested in later versions.