nware v1.4 and CAB4n's dropping offline

Check the device placement of those cab's, it maybe that they are all being controlled by 1 nionode.
If this is the case distribute the Cab's over the 4 nodes to share the workload.

It's not so much how the audio is being routed/distributed between nodes in the system but more relative to the control data being sent to the cab's i.e. Polling from the nion's.
If you do a right click on those cab device blocks and go to "device placement" this will tell you which nionode in the system is responsible for that device.
At the compile stage by default all cab's will be placed under nionode#1, so unless you have gone in manually and changed this i suspect this will be the case in your file.

I have seen issues in the field on a couple of occassions(in 1.2.6 or earlier) where 7-12 cab's being controlled by one nionode resulted in Cab's randomly disconnecting due to "missed polls".

So i would try and place some of those cab's under different nionodes in the system if it is the case that nionode#1 or whatever it maybe called is serving all 8.

Are you seeing the same rate of disconnects in 1.4.1 as you where in 1.2.6?

Let me re-ask James important question, because we in tech support are all anxious to know;

Which version of software are you using?

Two items that this thread brings up;
1).  Should (or can) the compiler be made "smart" enough to automatically allocate control of CABs across more than one CM-1 (NioNode).

2).  The “why" , and the “how to stop"  the dropping off of CABs needs to documented for the help files.

Moatsy may have also answered Phils' question of "Does the improved CAB polling of V1.4.x reduce CAB drop-off".  Phil, still have your customers go ahead check for improvement with their systems.

Phil, you know, I'm sitting here thinking that maybe we in Meridian have assumed that one of the other of us has already suggested to you James' solution...And you know what assume stands for.

If you have had this problem, and James solution worked for you, please respond with how many and type of CABs and how many NioNodes are in your Project (this will help us with the documentation process).

Also, check (if you can) if you have control of the analog inputs or outputs.  If you have control, this means that this is a polling "time-out" problem, as opposed to a control bridging problem.

Thanks

Wigl:

If you go to advanced Cobranet assignment, you can improve the efficiency of the Cobranet traffic to and from your CABs. This of course requires you to have similar advanced subchannel mapping capabilities in your CABs. Basically you can pack more channels into a bundle, which can mean a significant reduction in frames/sec and a rather small reduction in bytes/sec that must be handled by the Cobranet interfaces. It will make no difference in the DSP usage.

If by 'Control frame' you mean either the conductor or the CAB control polling, the conductor frame size will change slightly if you reduce the number of bundles, but the rate at which both it and the CAB polling messages are transmitted is not affected by settings in the advanced Cobranet dialog(AFAIK).

The amount of efficiency you can gain is of course dependent on the exact Cobranet configuration you currently have, as you obviously don't want to change the audio channels' source and destination, but rather how they are packaged.