I have been experiencing some severe popping when deploying a new project to a running system.  I have not experienced this in the past, but we have damaged HF drivers from the experience.  Any knowledge of a way to resolve this aside from shutting all of the amps off before deploying each time?

Are you using Cobranet and or XDAB?
I have only heard reports of Pops and Gunshots occasionally when there is XDAB Cluster(s) being used. If the Audio Clock has not been set correctly between nodes in a system using XDAB when Re-Deploying you can experience many XDAB Reconfigurations as a Master/Leader Node within the Cluster(s) is being arbitrarily selected which can result in Digital Pops. This may happen if all the nodes have the same XDAB Clock priority values.
Take a look at the Nion Log(s) and see if there are any PIOND/XDAB Errors being flagged at the time of deploy.
If the Timing in the system has been set up correctly and you are still experiencing Popping it may be down to Hardware,Cat6e XDAB Cable or XDAB Hardware Issue within a Nion.
What version of Nware is being used to Deploy the new Project? and what Firmware is in the running Node(s) ?
I have never known a Non-XDAB Nion system experiencing Popping, if this is the case then should contact MM Tech Support in Meridian.

XDAB and cobranet are both being used.  1.4.4 is the version being deployed.
Next time I am at the job site I will see what I can find on the log.  I don't remember needing to set clock priorities from the class.  What is the process on this.

To follow up on this issue, I was on site and did deploy a new version of my project.  I took a look at the log and did not see any PINOD / XDAB errors at time of deployment.  It is still a mystery, and everyone at the site is quite nervous about the problem occurring in the future.  We are shutting all amps in the facility off each time we deploy to avoid any further damage.  This does not seem to be a good normal practice.  When I was at class in Meridian, we deployed live numerous times and did not experience any sounds through the system.

There is a possible other issue, check to see how your Fault Policy is set.  File/Project Properties, and look at the bottom of the box.  If this is set to any other setting other than "Mute all on any node or XDAB failure", then pops and clicks would be expected on a project that has XDAB.  We have been asked why there are other selections, if they can cause problems?  Because with some projects that don't have an XDAB, the project may be better served with a more relaxed policy.
For example, lets say that there are four single NioNodes in four amp rooms throughout a theme park.  Background music is transported via CobraNet from a single source NioNode in the main Control Room, as well as normal control of the system.  They want to control the entire system using a single project (a Kiosk Mode page), but one of the problems that they have from time to time is the fiber for the network that goes out to the park will get cut.  One to 2 NioNodes will now be isolated from the main project, both for control and CobraNet.  So by setting the Fault Policy to "Mute only XDAB nodes on XDAB failure", the Nions will continue to run.  A short, simple selection of background music is stored as WAVs in the NioNodes, with the play and stop button triggered by the CobraNet link LED.  I understand that they will upgrade their Compact Flash from the 256 megs to the new 2 gig Flash sometime this next year, which will enable a larger WAV for BGM.
If this is not the problem, and you continue to have problems, get in contact with us, and we will take a look at your project.

I have seen this too, in a system I worked on last year. I made it stop by muting all my outputs when I uploaded. I think that James' clock theory is probably worth a look though. We reprioritized the NIONs as a part of a cobranet fix. I never put it together before but the system quit doing the POP on upload before we left.

We've experienced Pops and Clicks too as part of projects that have the clock priorities set correctly.  In our case, the priorities don't matter because each role takes a different amount of time to start.  For example, in a 5 NION 'cluster', if N#1 has the highest priority, but N#3 starts it's role first then when N#1 finally starts it's role, there will be clicks/pops.
As a separate note, We have also seen (heard) clicks/pops that have been recorded in the log as IN our OUT XDAB errors...  maybe I'm missing something, but if the NION recognizes that those packets are errors, shouldn't it be able to counteract them - not just log them?   It seems the muting may not be fast enough (even if the fault policy is set to mute) in this case.

I'd agree that this issue of speaker safety (or at least comfort for any unfortunates in the building) during deploys does still need some work.
The NIONs take long enough to start anyway, that a few more seconds to come up fully muted until all units agree that they are happy wouldn't be much of a loss. Perhaps the Fault Policy mechanism could differentiate between a unit that is "starting role" after a deploy from something like a network break(?).

I have been able to reproduce the big bang in my office rig. I alerted engineering and they're working on it. I am positive the issue will be resolved soon. I hate to say it but turning off the amplifiers before deployment is the safest way to go for right now.

While we're bugging engineering, I guess a related issue is the noise when the NION is powered down (either deliberately or otherwise).

phils wrote:
While we're bugging engineering, I guess a related issue is the noise when the NION is powered down (either deliberately or otherwise).
Phil-
Yes, that is included. The scope of their work on this topic includes all of this.

Along the same lines, on a couple of projects recently we had multiple Xdab clusters linked via Cobranet, the Main Theatre was always the Conductor as this was the most important and high profile venue. Whenever the Main Theatre goes off line due to a deploy or some other reason the next Xdab cluster with the highest conductor priority takes over as the Conductor. Now the problem, when an Xdab clusters re-clock there is a very loud noise, this noise is as the Nion unmutes, its as if the Mute relays open before the Xdab has re clocked, the Fault tolerance is set to "Mute all on any node or Xdab Failure". Experimenting with different priorities and fault tolerance has not given a solution.
In theory when the project is up and running this will never happen but it has, the noise was so loud in one venue some of the cast ended up in the medical center.