Obsession Questions

Will, the short answer is that the Software Watchdog was added to 2.4.3 for purposes like reducing the chance of the A board crashing when the B board gets into trouble but doesn't cease indicating that it is present. It would be useful to know if this is a new problem, or if the two boards have never worked that well together. In general, 2.4.3 is much more robust in networking than any other version 2 software, so I would not go back to older system software.

You didn't say whether you have done a 7-8-9 deep-clear (NOT just with the Clear menu option) on both boards. This then requires re-entering several Setup options, but it MUST be done.

I don't know of a key to the Message Log messages, but I always found that they were, in a crude way, clear enough. For example, a "Face Panel Error", if you're lucky, might suggest that a ribbon cable connector on the face panel might be loose. To pick a common problem I had, if your RFU cable is too long, there may not be enough voltage at the RFU and it will reboot repeatedly. I thought this might have caused some crashes for me. But you can see the messages indicating that's what happened in the log, without understanding the specific details of the message. Hope that helps.

Normal 0 false false false MicrosoftInternetExplorer4

Tim,

Thanks so much for your response.  The question on the software watchdog was more of a general question about this as I see it often in the ‘Messages’ box of the Diagnostic Monitors, i.e. “Software watchdog set to 10 sec.”  If I see this message, does that mean something is going wrong or is this normal operation?

In response to your question about our crashes, our two Processor Units had been working together for a while, then started to crash with increasing frequency and with varying symptoms.  For example, sometimes the system would automatically switch to the backup, sometimes I would have to switch to the backup manually, and sometimes I would have to perform a hard reset to get the system responsive again.  It wasn’t until we experienced our last crash that I hooked up the Diagnostics and we now have a new “A” Processor, so I’m not sure what the Messages might have been.

What I’m seeing now even with our new Processor is a “Facepanel sync problem at 0:c0:16:5d:8:0” which is our Playback Console.  In my previous post I mentioned that we were seeing the same error message referencing the Submaster Console, but as the addresses are similar, it is possible that the previous error referenced the Playback Console as well.  This has not as yet manifested itself in a crash, but I’d still like to know what’s happening and maybe some troubleshooting ideas.

Also, we have a Remote Video Interface onstage that we run an RFU out of that has been rebooting repeatedly.  Could this be a similar problem to the one you described involving the RFU?

Thanks!

Will King, Asst. Electrician, Phantom of the Opera, Music Box Company

“Software watchdog set to 10 sec.”  If I see this message, does that mean something is going wrong or is this normal operation?
This is part of the normal bootup or processing, depending on where you saw it. It's not an indication of a problem.

For example, sometimes the system would automatically switch to the backup, sometimes I would have to switch to the backup manually, and sometimes I would have to perform a hard reset to get the system responsive again.  It wasn’t until we experienced our last crash that I hooked up the Diagnostics and we now have a new “A” Processor, so I’m not sure what the Messages might have been.
It's a personal opinon, but I think that perusing the Message log is more productive than trying to follow scrolling displays on the Diagnostic monitor. It's hard sometimes to remember to Enable Message Logging every time you do a hard reset, but it's important. If you know how to exit to DOS and copy the MESSAGE.LOG file to a floppy on each machine, then you can feel free to Clear the Message Log files (on both processors.) Then they're not so long to look at with the Obsession running. You could also email the file to your contacts at ETC.

Since they're not making Obsessions anymore, where did you get the old-new processor? You don't have to answer that question, I'm just asking whether you are confident that it was working well in its previous home. The specific suggestion you might consider is switching the less reliable machine to be the B processor. That's not a real "solution" though.

I would just note that I used to have one of two processors that displayed similar symptoms, despite considerable attention from ETC. It was moved to the B processor position so that if it got caught in a facepanel problem, the show would continue normally on the A processor. When I looked at the B Message Log, it was all the same facepanel problem, about twice a second. This would happen one or two times a year, with 275 days a year of use. I have to admit that the guy who replaced me has not complained about this. But I think he now runs software 3.1.2 all the time, whereas I changed between your version (2.4.3) and 3.1.2 depending on whether I was running moving lights. I always felt that 2.4.3 was "safer" in this situation.

For your benefit, I should note that this problem was confined to one processor, and "moved" with the processor when it was made the "B" unit. Your report is a little puzzling since the delivery of a new processor did not change the location of the problem. Are you quite certain about the hardware address of the A unit, and which processor you were looking at the messages for? (This question is in case you also looked at the Message Log screen, which would show the log file only for the processor on which you were reading it. Your posts suggest that you weren't looking at these logs, however.) It sounds like you have already learned that the best way to learn the processor addresses is either in the boot-log messages, or in the Setup-2-2 screen (IIRC) which shows all connected equipment.

If you are not on the road, I would have ETC look at your RVU onstage. If you can't get professional help, then I'll suggest that you open the RVU and carefully lift the locking tab to unmate and remate (once) the power supply connections to the main board. (I forget, this might be a double-ended harness with two connectors you could re-mate, once at each end.) On our designer's RVU, light corrosion ocasionally reduced the voltage to marginal level. (You didn't say how long the RFU cable is, or clearly whether it is the RVU or the RFU that's rebooting.) No, we were not a damp-location operation, and I was disappointed that expensive anti-corrosion sprays had no effect on this problem.

I should note that I've never used a separate submaster console. Both my processors had a full set of submasters. I wonder if a submaster console has a facepanel processor?

“Software watchdog set to 10 sec.”  If I see this message, does that mean something is going wrong or is this normal operation?
This is part of the normal bootup or processing, depending on where you saw it. It's not an indication of a problem.

For example, sometimes the system would automatically switch to the backup, sometimes I would have to switch to the backup manually, and sometimes I would have to perform a hard reset to get the system responsive again.  It wasn’t until we experienced our last crash that I hooked up the Diagnostics and we now have a new “A” Processor, so I’m not sure what the Messages might have been.
It's a personal opinon, but I think that perusing the Message log is more productive than trying to follow scrolling displays on the Diagnostic monitor. It's hard sometimes to remember to Enable Message Logging every time you do a hard reset, but it's important. If you know how to exit to DOS and copy the MESSAGE.LOG file to a floppy on each machine, then you can feel free to Clear the Message Log files (on both processors.) Then they're not so long to look at with the Obsession running. You could also email the file to your contacts at ETC.

Since they're not making Obsessions anymore, where did you get the old-new processor? You don't have to answer that question, I'm just asking whether you are confident that it was working well in its previous home. The specific suggestion you might consider is switching the less reliable machine to be the B processor. That's not a real "solution" though.

I would just note that I used to have one of two processors that displayed similar symptoms, despite considerable attention from ETC. It was moved to the B processor position so that if it got caught in a facepanel problem, the show would continue normally on the A processor. When I looked at the B Message Log, it was all the same facepanel problem, about twice a second. This would happen one or two times a year, with 275 days a year of use. I have to admit that the guy who replaced me has not complained about this. But I think he now runs software 3.1.2 all the time, whereas I changed between your version (2.4.3) and 3.1.2 depending on whether I was running moving lights. I always felt that 2.4.3 was "safer" in this situation.

For your benefit, I should note that this problem was confined to one processor, and "moved" with the processor when it was made the "B" unit. Your report is a little puzzling since the delivery of a new processor did not change the location of the problem. Are you quite certain about the hardware address of the A unit, and which processor you were looking at the messages for? (This question is in case you also looked at the Message Log screen, which would show the log file only for the processor on which you were reading it. Your posts suggest that you weren't looking at these logs, however.) It sounds like you have already learned that the best way to learn the processor addresses is either in the boot-log messages, or in the Setup-2-2 screen (IIRC) which shows all connected equipment.

If you are not on the road, I would have ETC look at your RVU onstage. If you can't get professional help, then I'll suggest that you open the RVU and carefully lift the locking tab to unmate and remate (once) the power supply connections to the main board. (I forget, this might be a double-ended harness with two connectors you could re-mate, once at each end.) On our designer's RVU, light corrosion ocasionally reduced the voltage to marginal level. (You didn't say how long the RFU cable is, or clearly whether it is the RVU or the RFU that's rebooting.) No, we were not a damp-location operation, and I was disappointed that expensive anti-corrosion sprays had no effect on this problem.

I should note that I've never used a separate submaster console. Both my processors had a full set of submasters. I wonder if a submaster console has a facepanel processor?