12-15-2021 09:13 AM
Hello,
I am experiencing an odd issue with a LabVIEW2019 executable application that has been occurring the past two weeks. The application has been built for over a year with no software changes and the issue was not present until now.
In the test, if a number of operating parameters are not met within a defined timeframe a dialog box (built on prompt user for input express VI) is supposed to appear and give the user the option to abort the test or "continue" which resets the timeframe and continues to wait until the parameters (RH% and temperature inside a humidity chamber) reach their setpoint. This loop worked fine until now. Currently when it reaches the timeout it will open and then immediately close the subvi and then go to the next case in the case structure without user input.
Troubleshooting steps:
The application is built on a windows 7 PC and I have transferred it to my windows 10 laptop and the issue persists.
I have tried to rebuild the executable from the source code but it will not build due to some Modbus master library error (this code was written an engineer who no longer works for us, I tried transferring all his LabVIEW files to my PC but might not have it all)
unplugging any peripherals like mouse and keyboard during execution yet the issue persists.
If anyone has ideas or needs additional information please let me know thank you.
Solved! Go to Solution.
12-15-2021 09:41 AM - edited 12-15-2021 09:44 AM
@mulcahla wrote:
Currently when it reaches the timeout it will open and then immediately close the subvi and then go to the next case in the case structure without user input.
The 'Choice (SubVi).vi' will close after 1 loop iteration if there is an incoming error. Maybe another SubVI before 'Choise (SubVi).vi' is generating an error? Maybe Email SubVi?
You should probe/monitor the error wire.
12-15-2021 09:49 AM
I can't open your VI, but from the picture I can tell there is no error handling, and some of the error wires originate from default values, so the error won't even propagate from there. Automatic error handling is disabled by default in an executable, so you won't get those pop-ups that you get when running source code.
Time to add some error handling. With proper error handling, you probably would've spotted the issue. (I am in full agreement with UliB that some error occurred that was swallowed so you have no idea it occurred in the first place.)
12-15-2021 09:56 AM
There are 6 inputs that will stop your pop up vi. How many have you checked?
My guess also is the error chain has an error.
12-15-2021 10:08 AM
I had suspected this issue was related to the email subVI as well, it is supposed to email the programmer that something is wrong and his email was recently removed from our server which is in check with the timeframe this issue started occurring. I have fixed the compiling issue so I will recompile the code without that block and see if this fixes my issue, TYVM!
12-15-2021 12:10 PM - edited 12-15-2021 12:16 PM
And, that's the problem with hardcoding variables. Create an ini file with a notification email address and do something to throw or, at least log, a real error whenever the email server takes a maintenance break. You are too dependant on IT staff task loading.
On the plus side, the engineer that authored that "code maintainence headache-in-waiting" no longer works there. 😉
12-16-2021 10:49 AM
@UliB wrote:
@mulcahla wrote:
Currently when it reaches the timeout it will open and then immediately close the subvi and then go to the next case in the case structure without user input.
The 'Choice (SubVi).vi' will close after 1 loop iteration if there is an incoming error. Maybe another SubVI before 'Choise (SubVi).vi' is generating an error? Maybe Email SubVi?
You should probe/monitor the error wire.
Email was the issue. In the SubVI the SMTP server was trying to use a port that had been recently closed. Thankfully I was able find the older source files and set the port to 25 (standard, but unsecure SMTP) to make sure this was the problem which is was. We found what port the built version was using and re-opened it while also locking down any unsecured ports such as 25.
A huge thanks to you! 😁
12-16-2021 10:54 AM
Just make sure you add error handling to this application. You probably wouldn't have had to come to the forum and save a couple of days of troubleshooting if you did. 🙂