Executable using UI thread on Lab Computer

[NikolaRistovski]

Hi Everyone,

I've been experiencing an interesting bug on some of our testbenches with software which I programmed in LabView (2018).

When I compile the software and run it on my laptop (with simulated inputs/etc) it runs perfectly fine and uses approximately 10-20% CPU (HP Elitebook 840 G5, Intel Core i5-8350U)

However, when I run the software on my testing equipment it runs with similar CPU usage, however a large percentage of that runs only on the last available core. This is usually reserved for the UI thread (I've had similar issues with this before). The test benches have a PXIe8880 and are substationally better than my laptop and should (in theory) run much more smoothly. This same software is on some of our older equipment which uses the PXIe8135 and the software also runs without a problem on them. 

I've made sure that all labview runtimes are updates with all patches from 2014 up to 2020, and I've installed the latest versions of daqmx and XNET. There is a substantial increase in performance with the installation of labview runtime 2019, however the software can still lock up if I use the UI thread to much (holding down on a scrollbar will lock it up for instance).

I have made sure that as little sections of my code use property nodes or anything that will force the execution to go through the UI thread (as this was a known issue previously).

I cannot copy the code into this thread as it would be against company policy and since I don't know if its any specific section of code, I can't give any snippets either.

Any help would be appreciated as I'm running out of ideas as to what could be causing this problem.

[Bob_Schor]

The PXIe-8880 is a PXI Controller, meaning it is designed as the configurable (with LabVIEW) software "brains" of a PXI Instrument loaded with data acquisition and timing modules.  It is designed to run a Real-Time Operating System (in the case of the 8880, Pharlap) and work as the "Real-Time" partner with a PC running LabVIEW with the LabVIEW Real-Time Module installed.

Because the 8880 using an Intel Xeon processor, it is possible to install (and run) Microsoft Windows on this platform.  However, the PXI backplane is not at all the same as the PCI backplane in a PC -- it is designed for use with a Real-Time OS and gives priority to hardware devices and interrupts in ways that Windows cannot (as the OS is not designed to be deterministic).

A properly-designed Top Level VI running on a PXIe-8880 in a proper LabVIEW-RT Environment would not have the problem you are facing as the Top Level RT routine has no Front Panel.

To accomplish your goals, you will probably need to redesign your Project to fit the LabVIEW-RT Model.  You will need, at a minimum, to do several things:

• Install the LabVIEW Real-Time Module.
• Reconfigure the PXIe-8880 Controller, which will probably involve reformatting its Hard Drive (back up all your files first!) and getting MAX to install the appropriate RTOS, as well as new Device Drivers and other software.
• Redesign your Project as a LabVIEW RT Project, with routines requiring User Interaction running on the Host (PC) side, and everything involving the PXIe-8880 running on the PXI Target.  You will need to have the Target connected to the Host PC via TCP/IP.
• You will need some method to exchange data between Host and Target.  My recommendation is to use Network Streams.  A model that has worked well for me is to design both the Host and Target systems using a Message Handler design, and allow the Host to send Messages ("Do this next") to the Target and the Target to send Messages ("Do that next") to the Host.
• Since the RT Target has to do all of the delicate "Real-Time" (i.e. timing and synchronization) work, while all the PC has to do is interact with the User (both responding to commands from Controls and displaying results via Indicators, including Charts and Graphs), as quickly as the data are acquired by the Target, devote one or more Network Streams to sending them, unprocessed, to the Host, which is otherwise idle.
• An exception to the previous Bullet Point is if the Target needs to immediately respond to data it is acquiring (as in Hardware-in-the-loop).  Here you might need to do some Target processing of data, just for "feedback speed".  As I recall, LabVIEW RT allows you to dedicate processors to various tasks (but, I believe, only in the context of LabVIEW RT).  

Bob Schor

[mcduff]

---

@Bob_Schor wrote:

However, the PXI backplane is not at all the same as the PCI backplane in a PC -- it is designed for use with a Real-Time OS and gives priority to hardware devices and interrupts in ways that Windows cannot (as the OS is not designed to be deterministic).

---

PXI and PCI are basically the same thing, except, PXI has additional timing features, triggers, etc. (PXI stands for PCI eXtensions for Instrumentation (PXI)). The Wikipedia article is good place to start.

RT LabVIEW is only needed is you need the software to be deterministic. I have built multiple PXI systems with dedicated controllers that run Windows; the deterministic parts are accomplished through hardware, like triggers, sharing clocks, etc.

@OP Not sure what is causing the problem, check property nodes, references, etc that execute in the UI thread.

mcduff

[NikolaRistovski]

Hi Guys,

Thanks so much for the detailed help relating to the issue.

@Bob_Schor: Unforunately the PXI systems we bought are only licensed for Windows, to change them over to a RT engine would require us to buy the licenses and reprogram the software. The software is not timecritical so there is no point making everything realtime from my point of view and the amount of effort required to do that would be too much. However, I am setting up a meeting with a national instruments representitive to ask him about any differences in computer types between (for instance) my laptop and the PXI system to see if anything could do this.

@mcduff : I don't believe if its a problem with the UI thread, but the Root Loop. In the CPU, i can see that 90% of the time is spent in "Kernel Time". I think the software is switching through many threads and causing this slowdown. The UI is just blocked by the Root Loop and it appears that its running slow. Once again, once I speak to an NI rep I'll have more details hopefully.

Again, thank you both for great answers!

[Bob_Schor]

The last time I purchased a PXI controller, the price for Windows was higher than the price for the version without Windows.

If you have a LabVIEW License that includes the Real-Time Module, then you (forgive me for stating the obvious) "have the license that includes the Real-Time Module", which (I'm pretty sure) allows you to load the RT-OS into the Target system -- PharLap on PXI controllers, Linux-RT (or some similar name) on RIOs (including myRIO).  But I could be mistaken (it would not be the first time, not even the first time this week ...).

Bob Schor

[Bob_Schor]

Wait a minute -- I just read your last Reply more carefully (I really should do that more often ...).

Are you running your program both on a PC (I'll call this the "Host") and on your PXI-Controller-running-Windows?  I'm thinking of a system where Keyboard, Mouse, and Display are all plugged into the PC, the PC is connected to the PXI Controller via Ethernet, but otherwise has no Keyboard, Mouse, or Display attached to it. 

The alternative is that you are running only on the PXI Controller, with Keyboard, Mouse, and Display attached to the Controller, bringing up Windows and running your LabVIEW code entirely from the PXI.  That might work, though you might need some external storage for data.

Could you please clarify?  The first scenario means that the PXI is in TCP-communication with your PC, and I have no idea what that implies when running a Windows system (I do have experience with doing this with the PXI running PharLap -- dedicate a few cores to the Real-Time part of the code, and forcibly isolate the RT Threads to their own cores, works wonders).

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

..allows you to load the RT-OS into the Target system -- PharLap on PXI controllers, Linux-RT (or some similar name) on RIOs (including myRIO).

---

NI is starting to roll out RT Linux for PXIe controllers such as the PXIe-8861.  I doubt any new RT controller will be Pharlap anymore as they will all be Linux RT.

[mcduff]

This link, although a bit old, has a nice explanation of the root loop. Not sure if everything still applies to newer versions.

The other thing to check is make sure the number of threads allocated to LabVIEW did not change; look in the example finder for threads. Also sometimes hyper-threading makes things worse, you can check that.

mcduff

[NikolaRistovski]

Hi Bob,

Windows 10 is installed on the 8880, so there is no TCP connection to the chassis, it is built into the chassis. So everything is connected to the PXI Chassis, including monitor/keyboard/mouse.

Data storage (etc) is not a problem, we have a 460gb (or 480gb) harddrive installed in the 8880 plus it is connected to a server, so data is sent there once the system stops processing it. This system worked well until we upgraded to the 8880s (we previously had 8135). I have a feeling that windows 10 has something to do with it (I'm going to install windows 7 on one of the 8880 to see if the problem gets better or worse).

Cheers,

Nik

[NikolaRistovski]

Hi McDuff,

I've checked out that link already and made a few changes (which definitely helped on my laptop but still not running as well on the 8880s).

I'll have a look at the threading and hyperthreading options and get back to you.

Cheers,

Nik