1 Topic by cwa

  • cwa
  • cwa
  • Peavey Technical Director
  • Offline
  • From: Boulder, Colorado USA
  • Registered: 2007-08-13
  • Posts: 193

Topic: Change in fault relay/light behavior.

I would like to propose a new behaviour for the fault light (and relay).

Currently, the light is on whenever the unit is not passing audio.  The reason it works the way it does now is that there was a belief that the fault relay should always reflect whether the unit is passing audio or not.  Thus, it turns on even if the unit is fine, but just not running a project.

The logic, while perhaps sound, is confusing. 

I propose we change it to work as follows:

1. On power up, the fault light either stays off or flashes briefly.

2. If the power on self test detects a problem, the fault light turns on.

3. Once a project is running, any hardware or software fault will turn the light on.

One thing I'm not sure about is whether a mute caused by the fault policy should turn the light on or not.  For example, if the fault policy requires that the unit mute if any NION in the project fails, should the fault light on all the muted (but not really failed) units light?

2 Reply by Noiseguru

  • Noiseguru
  • Noiseguru
  • Member
  • Offline
  • From: UK
  • Registered: 2007-09-07
  • Posts: 6

Re: Change in fault relay/light behavior.

The fault light should come on if the project is set to mute on fault and stay on but it would be useful if the unit that caused the project to halt flashed its fault light to aid troubleshooting.

Noiseguru's Website

3 Reply by cwa

  • cwa
  • cwa
  • Peavey Technical Director
  • Offline
  • From: Boulder, Colorado USA
  • Registered: 2007-08-13
  • Posts: 193

Re: Change in fault relay/light behavior.

The only problem with this is that the fault relay is connected by hardware to this light.  This would cause the relay to click on and off.  This may confuse the downstream fault monitoring system, if there is one, connected to the relay.

Perhaps instead we can display a message on the LCD detailing the reason the fault light is on.

4 Reply by phils

  • phils
  • Member
  • Offline
  • From: Sydney, Australia
  • Registered: 2007-08-15
  • Posts: 322

Re: Change in fault relay/light behavior.

I must confess that when I deployed my very first project, I thought I'd broken it.
However, I guess the real question is "What market is the Fault reporting meant to capture?"
It would be good to ensure that the relay behaviour meets the requirements of the standard 60849 for a "conforming system". [I'm away from the office, so forgive me if those details aren't quite right]

That said, I also think the fault indication should follow the fault policy of the project, and that status screens should show "system stopped: fault on NioNode3", or similar.

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

5 Reply by Fergy

  • Fergy
  • MM Tech Support
  • Offline
  • From: The Home Office--Meridian
  • Registered: 2007-08-15
  • Posts: 334

Re: Change in fault relay/light behavior.

This is perhaps a moot point on the Fault LED.  The type that is next to this LED has been changed, and now says Mute/Fault.  This change better reflects what this LED actually indicates, which has helped to limit the confusion.

That said, CWA suggestion is already the case.  If the Project is in Mute/Fault, the status page on the LCD screen will normally indicate the problem, including showing which Nion has caused the fault.  The exception to this is if the problem is a hardware error.  However, a hardware error will light up the button labeled "Attn", which when pressed, will cause the LCD screen will change to the status page that shows the hardware problem.

If the Fault Dependency has been changed to something other than the factory default, and only the Nion with a problem has muted, then only that Nion’s LED should be on.  The others will continue to pass audio, and the LED should not be on.

So what we need is for users to let us know when this is not the case, with enough info so the software and/or hardware can be corrected.

Make it intuitive, never leave them guessing.