Previously operational systems are now hanging the PC

[el-d]

Vi's and hardware which have successfully tested thousands of UUT are now hanging up. This happens across the board now for all models,each having a seperate application. I have removed all but the basics in hardware (c:drive, a:drive, keyboard/mouse/monitor I/O) from the chassis including all of the test equipment, DAQs, Relay Cards, GPIB and multiplexers and still see the problem, which is apparent as soon as the application is opened. The software is password protected and nothing has been altered by those who know the password-the only thing which prompted this problem was an untrained operator pressing buttons maybe! What could be causing this?

[Ray.R]

Was something changed in the test setup? Anything at all?

If not... what OS are you using. If MS-Win, then... simply try to re-install or "repair" the installation of the OS.

Curious.. How long has this test automation been running? Not the number of units tested, but rather how many days was it running okay? Keep track of this in case there is a pattern emerging.

-JLV-

[el-d]

Nope nothings changed - it was running yesterday until an inexperienced operator was put on it and now its hanging/looping without anything hanging off the software at all. The system uses Win2000. Curious is the politer words for what I thought! I have repair records going back on this system to 2002 which I inherited in the last 6months, obviously with upgrades and rev changes made to software in use but even the old stuff hangs in the same way as soon as its loaded. There have also been testhead changes but all alterations have been running without incidance for the last month or so - until this! I didn't think it worth re-loading the individual applications (since its an across the board occurance) but I did think removing and re-installing labview altoget
her to be a drastic step (though I'm rapidly heading towards it!) All I do know is that the operator tried to run the wrong application for the UUT but there are failsafes and fuses which protect the hardware at least and all fuses/ circuit breakers are intact- besides I removed all but the basics and the fault is still displayed on all Labview applications. I'm not quite sure how this could've affected/corrupted the software. Any ideas? Or am I reduced to reformatting LV?

[Al_S]

What is "hanging up"? Windows or just the test application? Do other Windows apps still run?
Are you running compiled code or in the LabView environment?
What debugging have you done in LabView (e.g. Highlight Execution, breakpoints, etc.)? Have you determined what the test app is trying to do when it hangs up?
How can your test application run without the test equipment? If your program goes through an initialization step where it talks to all instruments, does it wait forever if an instrument doesn't respond or does it timeout with an error message?
Does your program use registry entries or INI files (or something similar) to pass info from one session to the next? If so, will the app go to a default if you delete or rename the keys or files?
How did the oper
ator abort the test after selecting the UUT? Was it a graceful abort under program control or was it "Hit the Emergency Switch!"?

[el-d]

Woh! Loads of Q's! I'll try my best but I'm very much a beginner inheriting code which has so far run according to plan- here goes. The initial test screen calls for a serial number and user ID and has several 'Pass/Fail' stages which must be green before the test completes. Currently, 'hanging up' is not letting the operator input anything while the stages are flickering between red/green constantly. This hangs up the entire PC and the only way to escape is to switch off the PC without a shutdown cycle. Without running Labview applications, the rest of the PC capabilities are fine. The PC is not the developer suite (for which we only have one licence and several different test solutions which use it) but runtime only which makes debugging difficult as it must
be done remote from the test(especially since I'm a total beginner and not sure how to go about it!) The applications hang up immediately the screen is displayed so no error messages are displayed although the program should timeout to an error message. No idea if the program uses registry entries or INI files but, as I read it, the programs have an error code for non matching files which should timeout in the same way as hardware errors(?). Most definitely a 'maintenance reset' since thats the only way to escape the condition!

Phew! Sorry, perhaps the answers are less knowledgable than would be helpful but I'm definitely paddling in the deep end here.

[Al_S]

Can the operator enter the serial number and user ID, or is it hung up before it even gets there?
How the is user entry loop controlled?
What happens in the program before the user entry loop starts? You may be hanging up trying to talk to a dead instrument. What kind of error trapping does the program do (e.g. chain Error In/Error Out, call General Error Handler.vi, etc)?
Can you run the program on the development PC and get to the user entry screen?
What do the different applications have in common? Just the test hardware and the LabView Runtime module or do they share data/INI files, etc?
You could try uninstalling/reinstalling the LabView Runtime module on the test system. That should just take several minutes and won't ask you any trick q
uestions.
Debugging without LabView on the test station will involve a lot a trial and error. You may need to temporarily uninstall LabView from your development PC and install it on the test station. Then you can do simple things like run with Execution Highlight or pause the program or set breakpoints and single step it.

[LesHammer]

Is there anything in the code that remembers what it has been doing? Registry writes, creating directories or files?

What I'm getting at is that the operator started using the wrong program. It set up the expectation for a different unit. It did not complete. It may be waiting for that other program to find that other unit. (My code would never do that, but we haven't seen the code you are using. 🙂 Look in the code for file/directory/registry create/write - or reads. When you find how the code is recording "progress", go to that directory/registry and try to correct it.

Les Hammer

[el-d]

It has hung up before it even gets there!! Unfortunately I cannot uninstall/ install Labview development anywhere since (as daft as it sounds) I don't have administrator privileges on the test systems and IT won't get round to anything in a hurry...beaurocracy!!! but I will check the points you've mentioned and try your suggestions. Thanks for all your help and tips- you've given me plenty of ideas. Watch this space....I'm sure I'll still need advice once I check out your points!

[Al_S]

Start by finding the user entry loop in the diagram for the main VI. There's probably an OK button on the front panel. Right-click on OK and select Find Terminal. Look at the loop you end up in and determine what happens in the loop or before the loop that could be hangin up.
Post some code or some pictures of it to get more help.

[Ben]

1) With all the "extra" hardware removed, make sure the machine does not have any trouble with non-LV applications.

2) Look for the creation and modification dates of files used by the app.

3) Do you have a good image you can restore?

Ben