LabVIEW 2019 SP1 Program Won't start tasks after Power off...

[Douggle07]

Hey all,

We have a machine using LabVIEW to measure and log Torque against encoder angle for various parts. This machine has been working great since late 2019. Today a new machine came in and some team members wanted to swap locations with the Torque Tester. It was powered off, unplugged and moved to another room and then reconnected. When they tried running it again the main vi gave various errors pointing to drivers being out of date and incompatible, so I updated all the drivers and firmware. Since then I can run the vi just fine and it throws no errors, BUT when I press the external start button (on a HMI), the test runs fine physically but the LabVIEW application doesn't display or log any data from the test. 

In a nutshell, we run the LabVIEW program, set up the test parameters on the HMI, press the start button. This start button sends a signal to LabVIEW to start the data acquisition from all the sensors, display them on various graphs, and log the data, very straight-forward. 

I did an electrical inspection and verified that the cDAQ-9189 chassis is receiving power and the digital input card indeed sees the start signal. Doesn't appear to be any hardware damage.

What's so interesting to me is that functionally nothing has changed in the hardware/software since late 2019, so I'm not convinced it's a problem with any vi? The project and all vi's were backed up on the network and nothing has changed in terms of file pathing. The strangest thing is that now the program throws no errors the entire test, almost as if it's receiving data from the sensors and just not displaying it or logging it?

I'm curious to know if anyone out there has had a similar issue and knows of solutions to try. I'm hoping this is something minor that I'm overlooking here since the team needs this machine to complete testing for a deadline coming up and the machine is down now.

I appreciate any help I can get, and can provide additional info upon request. For now I will just provide the main VI (Yes it's messy...) so you can take a look at how it's set up. 

Thanks in advance!

Kind Regards,

Douggle07

[billko]

I think the first mistake might have been acting on the "out of date" messages, as this introduces another unknown variable in your problem and may "hide" the fix from you.

Something doesn't add up here, though.  Just powering down, then moving and powering up shouldn't have caused these issues.  Something else happened.  e.g., maybe the shutdown was not graceful and Windows booted from a restore point?

[Douggle07]

Thanks for the quick response Bill. Indeed it is strange, the laptop does have a system restore point to yesterday morning before the machine was moved. 

I assumed updating all available drivers and firmware couldn't be a mistake, seeing as it's been a year and a half since any previous updates. 

I'm debating on trying this system restore, but still annoyed that I wouldn't really know the root cause of this issue. 

[billko]

---

@Douggle07 wrote:

Thanks for the quick response Bill. Indeed it is strange, the laptop does have a system restore point to yesterday morning before the machine was moved. 

I assumed updating all available drivers and firmware couldn't be a mistake, seeing as it's been a year and a half since any previous updates. 

I'm debating on trying this system restore, but still annoyed that I wouldn't really know the root cause of this issue. 

---

Well, it's not a mistake - unless you're trying to troubleshoot an issue, then you want to keep it as "the same" as possible because it worked that way before, that's all.  If it never worked, then updating stuff would definitely be one of the FIRST things you do.

[Douggle07]

System restored to yesterday before the machine moved.

Running the program still produces the same results, no graphs are displaying any sensor values and no data being logged. 

Anything else to try?

[billko]

Can you see the instruments in NI-MAX?

[Douggle07 · Accepted solution]

Okay, TLDR... Got it working.

More detailed explanation;

The root cause of this was a file path issue (missing a \)... can't believe it. Used highlight execution to find ERR (118) coming from the create TDMS file vi. 

This error was not being sent to the Error handler vi due to the poor architecture of my program.

If the file path is invalid, the data acquisition would not start. If the data acquisition doesn't start, any errors upstream (including file path) would not reach the final error handler at the end of the process.

Thank for your time Bill.

Doug

[billko]

No problem, Doug.  It's good that you fixed it.  (It's even better that it resulted in better error handling!)

[billko]

The strange question left unanswered: "How did it work with a malformed path to begin with?"  That might be a question worth pondering...