v6.5 system going dead at end of test

The Tech is just attempting to save the results to the hard drive. The system is networked into the hospital's MUSE system, though this is at an outlying clinic. I don't believe that it is an issue with the MUSE connection; this same clinic has two of these machines and this is the only one I'm having an issue with. I installed both two years ago and both used identical settings when connecting to MUSE. That's one reason why this is perplexing, everything points to a hardware issue, but I can't understand why replacing the motherboard would cure the issue for a week only to have it come back again unless the power supply is borderline...

I'm heading down there in about 15 minutes (3-1/2 hour trip), but I'll have access to any replies or ideas you may have.

Thanks for the reply!

I ran through error logs, memory usage, hard drive space, checksums, everything I could think of while I was there yesterday. Nothing showing out of order in the system.

I did find, however, that the complete system is shutting down when the issue occurs. This is usually when the tech is adding the comments after the system is placed into recovery mode. While in this mode, the system isn't posting anything to the hard drive or to the MUSE system. Every time it has done it is when the system has been operated through three or more tests back-to-back. While looking at the power supply yesterday, I found a capacitor that is suspect (slightly raised end) so I replaced the power supply assembly. I ran the unit through several simulated tests with an ECG simulator connected and it seemed to do fine.

Time will tell. Chasing gremlins isn't so bad when the device infested with them is local, but the 7-hour round-trip makes it a PITA to deal with.

Well, it did it again, on the third patient in a row. (see a pattern?) I was also told today that it isn't shutting down, it is going through a reboot. It also isn't always in the same spot of the test either, though I had been told that it was until this came out this morning. This is starting to sound suspiciously like a software glitch... always on the third test in a row, differing places within that test, and causing a reboot.

I am planning on doing a reinstall/repair installation of the software; the hard drive passed all physical function tests that I ran it through.

Any other ideas?

Dean,

How did your reinstall/repair procedure go?

Here are a few thoughts:

Are your files being compressed? Is there a 'not enough memory' message in the error log?

It may very well be a database error. Were there any

messages in the error log after your reinstall/repair?

Is the same key being pressed each time by the user? Does it pass the mechanical keyboard test?

Your 'system reboot' might be triggering a 'power failure' error. Is there any information in the 'power up' self test?

Thanks, Mark.

I reinstalled the software Monday morning. After the install, I connected a patient simulator and started running test patients through the system. While talking to the techs, I found that they rarely have a patient go past stage three. (they only run the Bruce protocol test) I ran two test patients through to stage 4, then gave it & myself a break. I then went back and ran a test case through to stage 3, another to stage 4, then another break. I continued in this manner until I had ran seven test cases, including one through to stage 7.

During the simulated runs, I would go through and shake, wiggle, and basically abuse all of the cabling and connectors. I was also going through all of the patient entry menus and text input screens and randomly entering data from the pull-0downs and text-entry fields, both before and after the tests. I was saving locally (the default) and then posting out to Muse.

I literally did my best to simulate exactly what the techs are doing when they have a patient going through testing. I had no failures or glitches whatsoever.

Yesterday morning, I received a call from the department head, who was running a patient (the first one of the day) and the system had failed yet again. It was during the results-entry part of the test, when the system had been placed into "recovery" and she was entering the data from the test. It went through a reboot and all test data was lost.

This machine passes all keyboard tests, isn't going through data compression, shows absolutely no errors on any logs, no bad sectors on the hard drive... The hard drive is showing 25% full, so there are no buffer overload errors.

Needless to say, I am going nuts...

In a grasp at straws, I requested that the customer install UPS's on both of these machines. maybe, maybe...

Dean,

When you say the system had been "placed into recovery", are you getting a CASE BTRV error?

It is starting to sound alot like a database error.

I notice that the physical environment...the power source fluctuations...can cause such an error.

Again, No errors are showing up on any of the logs, either the system's logs or the Case software logs. We spoke to the head clinician there and she's going to have the in-house install UPS's on both of these machines and try again.

If only it would glitch every pass; then I could start replacing components & cables until it was fixed. Otherwise, if it is a hardware error and I just replace everything, I still don't know which component is faulty and would then have no faith in my parts/loaner unit.

You just gotta love chasing sporads & gremlins...

 Dean,

Well..in theory...if you end up replacing all of the hardware, software, operating system...etc....and you get a completely new system...then you can solve any problem...assuming the system was designed to work correctly, in the first place.

But....before you go that far.....let me ask you:

Have you checked to see if the Writer/Power Distribution Assembly FRU

 has the correct firmware version?

  Because...it seems  to be a power supply-related issue....or the interaction between PS and database operations........

Upgrading the firmware might be quicker than changing every subassembly......