Program freezing

[kknight95]

Hi,

I am very new to LabVIEW, this is actually my first program that I have written. I want this program to read the temperature from a thermocouple (NI USB-TC01). I want to be able to set the temperature and then a power supple (bkprecision 1900b) responds and ramps the temperature to a certain rate. I am using the same computer that the program was written on. This is with LabVIEW 2025. 

My program was working great for the first few days, but now, anytime I try to use it, it freezes. It use to only freeze every hour or so, but now it can only go a few minutes before freezing. When it freezes, I hit the stop button, but a box pops up that says resetting. I have to use task manager to close the program or it will never close. I have checked the power management for each device and unchecked "Allow this computer to turn off to save power."

[RTSLVU]

1. We can't troubleshoot pictures, please upload your code
2. I see you are using "bytes at port", watch this video VIWeek 2020/Proper way to communicate over serial

[Kyle97330]

In addition to the "Allow this computer to turn off to save power" option, also check the "USB selective suspend option".  If you're using Windows 11 it may be hidden and you have to use a registry key to enable it:

https://www.tenforums.com/tutorials/100643-remove-usb-selective-suspend-setting-power-options-window...

Besides trying that, the general behavior you describe is something I've only seen when hardware misbehaves so badly that it's not returning control of a thread to LabVIEW, ever (instead of just timing out after a few seconds).

I would first narrow it down to which device it is.  I would recommend making a program that runs just one device, sending identical instructions as your current program, then letting it run for a few hours.  If it doesn't freeze in the same way, try again with the other device.

Once you know which one it is, see if you can update its drivers, the drivers of whatever it's connected to (motherboard chipset drivers for USB, probably).  If it's a USB to serial adapter that's misbehaving, try a different brand, especially if the one you are using is a Prolific chip (switch to FTDI, probably).

[rolfk]

The only functions I can see that could reliably cause this phenomena would be the DAQmx nodes with their internal Call Library Nodes. If it would be a third party DLL, I would declare this the culprit for 99.9% probability. DAQmx is however written in a way that this can almost not happen unless the driver installation itself got somehow corrupted seriously.

Possibly reason might be use of a very modern computer in combination with recent Windows updates that enabled chipset PCI features that the NI driver stack can't handle. I would try as a first remedy to install the latest version of the DAQmx driver. That might solve it.

The Bytes at Serial Port is definitely going to bite you sooner or later. This is NOT how serial communication should be implemented and the presentation mentioned by RTSLVU is a very good resource to watch in its entirety from begin to end to learn to do instrument communication properly.

And yes, debugging pictures is extremely limited. There could be a hidden VI somewhere that does all the nastiness and is not visible on a picture. Causing us to run in circles to find the problem, which is impossible to find in a picture.