Large Job - Tips & Pointers Please

jjames

I have a very large job (for us) coming up and I'm getting started with actually coding it (I've been working on the UI for quite some time.) Here's the break down.

8 x Masters
* 1 in the rack to control the majority of the panels, audio & video switching
* 5 auxiliary / stand alone rooms, but still need switching from master in the rack
* 1 master for lighting control, which will need to send feedback to all masters above
* 1 master for pool control (controllable from specific panels)

17 x touch panels
10 x R-4s

Short of hearing on how you would have designed it differently (we're past that part - gotta deal with what we have now), what advice would you have for the communication between the masters (use SEND_COMMAND for information, pulse channels,etc.) I think that's where I'm really stuck. I've done M2M with 2 masters, and that's about it (we almost never have the need for more than one master, let alone eight!) So M2M is a clear-as-mud concept for me. I've not had to manage the amount of data going between the masters or truly manage the feedback of connected panels (i.e. sending feedback, etc. ONLY when needed) so I'm trying to plan this out and do it right the first time - I won't have the time or opportunity to do any significant changes in the way that stuff is handled.

Also, any management ideas, dos-and-dont's (in respect to coding in general) would be great. A job this size isn't something I do all the time.

vining

jjames wrote:

I have a very large job (for us) coming up

Wow, that must be nice.

That's bigger than anything I've ever done too but don't imagine it to be functionally much different than having 2 masters. I would still run basically everything on 1 central master and leave the other masters to handle their local equipment (I assume that's why you have them). I like all the TPs & other UI's on the main system and talk to the local equipment via M2M.

ericmedley

My advice is queue everything. Don't count on raw string/command parsing/sending on the fly.

Also, create a good queue to handle all the TP feedback. The comm chatter of a system that large is silly.

Have fun! Sounds like a nice one to put a notch on your belt with.

jjames

ericmedley wrote: »

My advice is queue everything. Don't count on raw string/command parsing/sending on the fly.

Also, create a good queue to handle all the TP feedback. The comm chatter of a system that large is silly.

I am managing the feedback on a "need-to-update" basis, but am still trying to think of a way to queue the info up in a reliable manner.

What's everyone's thoughts on using virtual channels for feedback (source select, lighting, etc.) and having the panels grab the status when needed? I can see needing to queue up feedback such as text (i.e. radio stations, DSS station feedback, etc.), but again - using a virtual channel as a flag to tell when to update.

ericmedley wrote: »

Sounds like a nice one to put a notch on your belt with.

Yeah, that's what I'm afraid of.

ericmedley

jjames wrote: »

What's everyone's thoughts on using virtual channels for feedback (source select, lighting, etc.) and having the panels grab the status when needed? I can see needing to queue up feedback such as text (i.e. radio stations, DSS station feedback, etc.), but again - using a virtual channel as a flag to tell when to update.

That's actually what I do for Lutron stuff right now. I've found that our clients are all over the map with using Lutron. Some want every possible button / fader/ etc. on the panels, some want someting in between and some want only a few simple lighitng controls.

coming up with a 'modular' way to program that was driving me crazy. So, I ended up creating a virtual device and dev_chan array and structure for all possible Lutron VirtKeypads and it populates and builds itself from the data you fill in when setting it up. What the client sees on the panels is all determined from the data entered. The panel's layout is built when they access the lighting pages. Feedback for that is only active for the specific button(s) they're looking at at the moment.

At first it was a daunting task. But afterwards, it changed doing and entire house's lighitng (programming and TP design) in two days to about 1-2 hours.

So, I think it's a great idea. I'd definitely go for it.

HARMAN_icraigie

Write the code the way you would if the panel was on the same system except in the define device section its system number is something other than :0. For example if the lighting processor is on system 3 it may well be monitoring and changing the feedback for buttons on touchpanels connected to system 1 (and/or 2 and/or 4 and/or 5...).

For the really complex stuff (like using room temperature offsets developed on one system that are compared to astronomic time data from another system to control shades attached on yet another system), well you'll need your own api communicating through a virtual device for that.

vining

I like using alot of vitual levels for feedback cuz there more flexible than channels. If I have text displays that aren't dynamic and never vary from x number of phrases I'll create a multi-state bargraph and put a different phrase in each state. In code I just send levels and let the master track them and manage FB updates. Of course you still need to track these levels yourself for when a new TP comes "on page". The only draw back is making sure you set your virtual level counts and actually getting them to work.

jjames

Pardon me while I think out loud, please feel free to comment.

What I was planning on doing for the lighting would be this...

We've got the seperate master (#7) for the LiteTouch processor. I was thinking about having a single virtual device (vdvLIGHTS) on that master (35007:01:07) on all of the other masters, and update when needed (entering lighting page and when a button on the keypad changes states.) The only purpose vdvLIGHTS would serve is just an on/off status of the keypad's buttons. I would have a function or two and some variables on each of the masters that would keep track as to which keypad they're looking at.

The virtual device would break down like so: 1,107 channels (there are 123 keypads with a maximum number of 9 buttons). Parse the incoming feedback and do a little bit of math so that keypad 72, button 3 would be channel 642 on the virtual device.

For having the auxiliary masters tell the main master to switch, I was going to simply do some SEND_COMMANDS in the format of: "'a:IbOc',$0D" where a is A for audio, C for component, or V for video; b is input, c is output. I had thought about some crazy thing of having a bunch of channels that'd be designated for input, output and some that be for what needed to be switched (audio, component or video) and one last one for a "take" command - but quickly abandoned that as it'd be A WEE BIT complicated. Am I over thinking this a little?

I'm trying to have as few dependencies as possible, so each master will control their own equipment and that's it. If another master needs to control another's equipment - which the only time that'll happen is a whole house off command - functions on the respective master will be triggered by a channel. I don't want to have them all depend on one another in the case of a break down in the chain. If the lighting master goes out - they have no lighting; I don't want it to be if master #4 goes out, lighting goes out because #7 depended on #4.

Ugh - it just seems like it's so complicated - but in reality, it's not. There's just more of what I'd normally be doing to do . . .

Anyway - thoughts on my rambling would be appreciated.

HARMAN_icraigie

jjames wrote: »

Ugh - it just seems like it's so complicated

Got that right

DEFINE_DEVICE

dvTP1_THIS_MASTER        = 10001:1:0
dvTP2_OTHER_MASTER       = 10001:1:2
dvTP3_YET_ANOTHER_MASTER = 10001:1:3


DEFINE_CONSTANT

MAX_TP = 3
DEV dvTP = {dvTP1_THIS_MASTER,dvTP2_OTHER_MASTER,dvTP3_YET_ANOTHER_MASTER}
INTEGER TP_BUTTON_CHANGE_LIGHTS_ROOM[ ] = {1,2,3,4,5,6,7,8,9,10}
INTEGER TP_BUTTON_LIGHTS_KP[ ] = {101,102,103,104,105,106,107,108,109,110}
INTEGER TP_BUTTON_LIGHTS_KP_FB[ ] = {201,202,203,204,205,206,207,208,209,210}

DEFINE_VARIABLE
PERSISTENT INTEGER nLightRoom[MAX_TP]


DEFINE_EVENT

BUTTON_EVENT[dvTP,TP_BUTTON_CHANGE_LIGHTS_ROOM]
{
  PUSH:
  {
      TO[BUTTON.INPUT]
      nLightRoom[GET_LAST(dvTP)] = GET_LAST(TP_BUTTON_CHANGE_LIGHTS_ROOM)
  }
}

BUTTON_EVENT[dvTP,TP_BUTTON_LIGHTS_KP]
{
  PUSH:
  {
      TO[BUTTON.INPUT]
      LightsButtonPush(nLightRoom[GET_LAST(dvTP)] ,GET_LAST(TP_BUTTON_LIGHTS_KP))
  }
  RELEASE:
  {
      LightsButtonRelease(nLightRoom[GET_LAST(dvTP)] ,GET_LAST(TP_BUTTON_LIGHTS_KP))
  }
}

DEFINE_PROGRAM
WAIT 1
{
  LOCAL_VAR INTEGER iTp, iButton

  FOR(iTp=MAX_TP; iTp; iTp--)
  {
    IF(nLightRoom[iTp])  
    {
       FOR(iButton=LENGTH_ARRAY(TP_BUTTON_CHANGE_LIGHTS_ROOM); iButton; iButton--)
       {
         [dvTP[iTp],TP_BUTTON_CHANGE_LIGHTS_ROOM[iButton]] = (nLightRoom[iTp] = iButton)
       }             
       FOR(iButton=LENGTH_ARRAY(TP_BUTTON_LIGHTS_KP_FB); iButton; iButton--)
       {
          [dvTP,TP_BUTTON_LIGHTS_KP_FB] = (nLightsFb[nLightRoom[iTp]][iButton])
       }
    }
  }
}

PhreaK

The first thing that comes to mind would be to set up modules (duet or netlinx, whichever way you swing) on the masters for all of their locally attached devices and logically attached IP devices. Then handle all your system logic on a centralised master. If you're really paranoid have any crucial (security, lighting etc) mirrored on a another of the masters, but with a bit of logic so that it only be executed if the 'master master' is offline. Which will allow you to have an automatic fallover, assuming they are controlled via IP.

Setting it up this way should greatly reduce any unneccesary chatter from referencing raw devices using master to master. The theory behind it is that the modules can handle all of your buffering, message translation and verification, and device behaviour standardisation (ie. a projector in the home theatre will act the same as the plasma in the lounge room, no need to worry about telling one to unmute when your swich inputs and the other one does it automatically). This should distribute any processing load for this across your system. It will also mean your only having to use standardised API's for communicating with every type of device and if things are changed in the future its all done at one point in the system.

The other way you could take it is that if you are wanting to distribute the system behaviour processing you could look into rolling some SOAP libraries for passing meaningfull data between your masters.