TP_ARRAY vs DEFINE_COMBINE

There is also a third way...COMBINE_DEVICES...

I use combine devices this way because you can UNCOMBINE_DEVICES anywhere in programming and then recombine it again. (Great for combinable conference rooms.) You can't do that with a DEFINE_COMBINE or an array.

With a single real device, as posted in the example, there is no reason at all to make an array or a combine. So I assume we are talking about multiple real devices, not one real with one virtual.

I almost never use combines anymore, always an array. Combining makes all of your real devices act like a single panel, so if you ever need to know exactly what panel a command came from, you are out of luck. All of your panels have to be doing exactly the same thing at any given instant. And for many modern devices, this cripples the functionality. Take any media server, from iPod to MAX - you really need for each panel to work independently, and combining them makes that impossible. And frankly, I don't see where combining gives you any advantage over an array. If you want all your panels to reflect the same thing all the time, you can just as easily send your updates to the array as to a virtual.

never ever ever use DEFINE_COMBINE twice in a system of two controllers on the same devices. we did so and both systems hung after booting. since then, we always check if we have a duplicate DEFINE_COMBINE on the systems when something is strange...

TurnipTruck wrote:

I have found that with COMBINE_DEVICES, you can get some strange feedback occurences. For example:

nBUTTON_ARRAY[]={1,2,3}

ON [dvDEVICE,nBUTTON_ARRAY] will show feedback on all three buttons.
OFF [dvDEVICE,nBUTTON_ARRAY] will NOT always stop feedback on the buttons.

I have pretty much accepted, for myself, that DEV arrays are the way to go. All of the "benefits" of combined devices can be acheived in code within a device array, with a lot more reliability.

Okay, I was going to post a thread about this, but it looks like I can continue here. TurnipTruck, you mentioned above that COMBINE_DEVICES gives you strange feedback, but your example shows an array.
My issue is when I do an array of panels, I can capture the pushes, but if I try to send feedback to the array, it doesn't work.
Example

DEFINE_DEVICE

10128:1:1 = TP_1
10132:1:1 = TP_2
10136:1:1 = TP_3

DEFINE_VARIABLE

DEV TP_ALL[]={TP_1,TP_2,TP_3}

DEFINE_EVENT

BUTTON_EVENT[TP_ALL,1]   // POWER ON
  {
   PUSH:
      {
       ON[RELAY,POWER_ON]    // JUST AN EXAMPLE  
       POWER_ON=1
      }
   }

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1    // THIS DOESN'T WORK

[TP_1,1] = POWER_ON=1        
[TP_2,1] = POWER_ON=1        // THESE WORK
[TP_3,1] = POEWR_ON=1

I've also tried it by sticking virtual devices in there, but the result is always the same. No feedback when sent to a device array.
Am I doing something wrong or is this how it works?

Thanks!

Joe

DHawthorne wrote:

With a single real device, as posted in the example, there is no reason at all to make an array or a combine.

I disagree with this. Even in systems with one panel I use a DEV array for that panel, the reason being that I can then add another control device (like a keypad or handheld) without changing too much code.

Joe wrote:

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1    // THIS DOESN'T WORK

Joe,

I do exactly this in most programs I write, and I've never had a problem with feedback to the array.

--D

Seriously, like TurnipTruck suggested:

[TP_ALL,1] = POWER_ON

There's no need to add anything else on top of that...

- Chip

Well, I not-so-subtly changed my sig recently to reflect the fact that the crown has been passed to Halo 3 from Halo 2.

But if it means anything, yes - I'm currently ranked as a Commander Grade 1 in matchmaking.

- Chip

NMarkRoberts wrote:

Chip, you've been mainlining Halo 3 for quite a while now, are you getting anywhere?

a_riot42 wrote:

What does [TP_ALL,1] = POWER_ON=1 give you that [TP_ALL,1] = POWER_ON doesn't?

There is a difference, subtle as it may be.

The line
[TP_ALL,1] = (POWER_ON=1)
will turn the feedback on if and only if POWER_ON equals 1.


The line
[TP_ALL,1] = POWER_ON
will turn the feedback on if POWER_ON equals anything other than 0 (e.g. 2).

I follow the latter style unless I explicitly need the former.

a_riot42 wrote:

I understand the difference, I guess I just wonder why you would want to break a decades old convention. To my thinking POWER_ON can only have two states, on or not on, and thus could never be equal to anything other than 0 or 1 (or some other positive integer).

I will sometimes use three states for a projector.
0=off 1=on 2=cooling/warming, this way I can change the button states and block out any pressing when in a cool/warm state.

If it is a small job with only one panel, I'll use some DEFINE_PROGRAM feedback, otherwise I always do feedback on the string return of an ONLINE device.

On a bit of a tangent for combining panels, I am just about to get into a project with a combined room. Sometimes the dividing wall is open, sometimes closed. There is a panel in each room to operate the projector, screens etc, in each room.

When the door is opened, I need to have both panels mimic each other - on a page showing the combined facilities (ie both screens, projectors, volume etc)

Woud this work...

when the rooms are separate, both panels are independant
when the rooms are open, create a page that offers all the facilities (screens, proj, volume) for both rooms and combine the panels when this page is being used.

When the rooms are separated again, uncombine them.

Thoughts?