BUTTON_EVENTS & CHANNEL_EVENTS

hodeyp

I'm using rs232 to control my AV processor. Currently my code is set to switch a channel on/off from a button event e.g...

BUTTON_EVENT[TP1,VOLUP]
{
PUSH:{PULSE[dvAV,VOLUP]}
HOLD[3,REPEAT]:{PULSE[dvAV,VOLUP]}
}

CHANNEL_EVENT[dvAV,VOLUP]
{
ON:{SEND_STRING dvAV,"'VOLUME+',13"}
}

Question is, if I do not care what the status of the channel is (all buttons are set as momentary on the tp) is this efficient? It seems to make more sense just to put the SEND_STRING directly into the BUTTON_EVENT.

If this is the case, what are the channel events useful for? Even if you wanted to record the state, surely you could just do this with variables?

What am I missing here?

DHawthorne

A BUTTON_EVENT is generated by an input action, and a CHANNEL_EVENT by an output. I've never run across a situation where I felt something would work better in a CHANNEL_EVENT, since we these controllers are mainly input driven. I'm sure there is some use for it, but in your example, I see no reason not to put it on the PUSH handler of the BUTTON_EVENT, or perhaps the RELEASE.

hodeyp

Thanks, i've witten my code so that anything i need to track status of is written in a channel but all else is in a BUTTON_EVENT. Sounds as if this is ok...

Chip Moody

hodeyp wrote:

If this is the case, what are the channel events useful for?

I guess the answer to that is whatever you find them to be useful for. (If you don't overcome your fears, your fears will overcome you - yada, yada, yada)

I've taken recently* to tracking device status using channels on that device's port, like having a channel set if a VTC unit is in a call, has the mic muted, or the power states (on, off, warming, cooling) of a projector. This usually happens in the DATA_EVENT/STRING: code that parses feedback from the device.

If I determine at some point that I want some action to happen with regard to a channel's state, instead of splicing code in with the parsing block, I'll add a CHANNEL_EVENT. So, if I want to make sure a projector has the correct input selected after it warms up, I'll do something like:

CHANNEL_EVENT [Proj,WarmUp]
{
  OFF:  // the channel goes off when the projector is done warming up
  {
    IF ([Proj,VideoIn]) {ProjCmd (SelectVideoIn)}
    ELSE IF [Proj,RGBIn] {ProjCmd (SelectRGBIn)}
  }
}

Also - there was a time when you would have to do this in mainline:

[Relay,1] = [VTC,MicMute]

I now prefer to do this:

CHANNEL_EVENT [VTC,MicMute]
{
  ON: {ON [Relay,1]}
  OFF: {OFF [Relay,1]}
}

Both of these examples probably have more to do with how my brain works than anything else. The separation of logic between a section of code that ONLY parses data and sets flags and a completely different section of code that detects changes in flags and acts accordingly just seems (IMHO) to have a better structure. Not to mention that if I have to swap a device, or copy some code into a new program that uses a different projector/VTC than the last project, I just have to make sure that the parsing code sets the flags right. I know at that point that the code that reacts to those flags already works, and doesn't give a damn that the strings from the Mitsu projector I'm using on this project need to be parsed in a different way than the ones on the NEC I used on the last job. I don't have to worry about the code that responds to a device's state being intermixed with the parsing code, y'know?

And if anyone remembers stuff like this:

X = A AND B AND C
IF (OldX <> X)
{
  IF (X) 
  {
    (* Three conditions were just met - do something *)
  }
  ELSE
  {
    (* One of the three conditions isn't true anymore - do something else *)
  }
  OldX = X
}

I find it reads - and 'feels' - better like this:

// This is in feedback handling loop
[SomeDev,1] = A AND B AND C

//  Then elsewhere:
CHANNEL_EVENT [SomeDev,1]
{
  ON: {}  // Three conditions have been met - do something
  OFF: {}  // One of the three conditions isn't true anymore - do something else
}

Just my 2 cents, for what they're worth.

- Chip



* - My NetLinx certifications on the wall are all dated 2000/2001 - that still seems "recent" to me, too.

Irvine_Kyle

Inter Module COMMS

I use CHANNEL_EVENT to trigger things in main source code from a module sometimes. For example say you want a very specific action to occur when a door opens. I can monitor the door opening in the security system module but rather than change the module I just pulse a channel through the virtual device.

This generates a CHANNEL_EVENT which in essence traps the input change; the door opening; then I can send commands to touchpanels, pulse relays, run turn on sequences etc, all from within the main code without the need to muck about too much with the module.

frthomas

Some comments:

(a) I find all of the latching stuff pretty useless in Netlinx. In particular, I could not make them work on virtual device channels. I can't comment on their usefulness in Axcess, but I would not bother with Netlinx.

(b) The difference between channel and button is that the former is all about the STATE and the latter about the state CHANGES. In practice as your example demonstrate, you can pretty much mix and match. If you were to replace the CHANNEL_EVENT in your code with a BUTTON_EVENT, it would still work (because PULSING a channel results in it becoming ON for a while then OFF). Essentially this is DHawthorne point. BUTTON_EVENT are more "natural" for inputs, and CHANNEL_EVENT for outputs or internal stuff.

(c) The value of the indirection you're doing is that the device specific code that handles increasing the volume is distinct from the panel specific code that handles the "VOL+" button. If you had another TP that could increase volume on this particular device, and if it happened to be a different model (so that combining was not a viable option), then both buttons could call the same device specific code (instead of having it duplicated).
Essentially, you're doing a "virtual" module: the CHANNEL_EVENT would be the module code and the BUTTON_EVENT the mainline code.
It would work if you were to put the SEND_STRING directly in the BUTTON_EVENT but would be less flexible.

(d) For the particular application (VOL+), I would not use a CHANNEL_EVENT since it is a temporary action by nature, not a state thing. I feel BUTTON_EVENT convey this meaning better.
But say you needed some code that would bring the volume back to some THX calibrated level, then a CHANNEL would be adequate (and volume change commands would have no effect while the "CALIBRATED VOLUME" channel was on, for example).

HTH

Fred