How do you prefer to combine TP buttons and I/O?

travis

I'm sure there are some threads on this floating around already but I can't find them...

I have IO input channels and TP buttons that should do the exact same thing.

I'm trying to trigger the same event for either an IO trigger or a button press with the least typing (chances of mistake)

Right now I have something like

DEFINE_DEVICE
dvTP = 10001:1:0
dvREL8_12 = 12:1:0
vdvControl = 33000:1:0

DEFINE_CONSTANT
DEVCHAN dci_ShowStopSwitch1[] = { {dvIO8_23,5}, {dvTP, 235} }
DEVCHAN dci_ShowStopSwitch2[] = { {dvIO8_23,6}, {dvTP, 236} }

DEFINE_START
COMBINE_CHANNELS(vdvControl,235,dci_ShowStopSwitch1)
COMBINE_CHANNELS(vdvControl,236,dci_ShowStopSwitch2)

DEFINE_EVENT
BUTTON_EVENT[vdvControl,0]
PUSH:{...}

Which seems to fire when both when I put voltage on the input pin and when I emulate the TP button press.

I don't like the way COMBINE_CHANNELS makes me duplicate all that information.

Is there some other way to catch both BUTTON events and CHANNEL events with the same event handler? If I just use a devchan with the TP button and the IO port channel, it will only catch the the button press or the channel change, depending on what type of event it is (button or channel)

This doesn't seem to work (no push events for dvIO8_23,n)"

DEVCHAN dci_ShowModeSwitch1[] = { {vdvControl,231},{dvIO8_23,1}, {dv_TPs, 231} }
DEVCHAN dci_ShowModeSwitch2[] = { {vdvControl,232},{dvIO8_23,2}, {dv_TPs, 232} }

COMBINE_CHANNELS(dci_ShowModeSwitch1)
COMBINE_CHANNELS(dci_ShowModeSwitch2)

shr00m-dew

A couple of ways I can think of. If you set your TP button feedback to momentary, this should work:

Using a DEVCHAN all ready combines them.

DEFINE_CONSTANT
DEVCHAN dci_ShowStopSwitch1[] = { {dvIO8_23,5}, {dvTP, 235} }
DEVCHAN dci_ShowStopSwitch2[] = { {dvIO8_23,6}, {dvTP, 236} }

DEFINE_EVENT

channel_event[dci_ShowStopSwitch1]
{
	on:
	{
	     //do something
	}
}

Not sure if IO channels can have a push, but if so this should also work if you want to handle TP feedback in code.

button_event[dci_ShowStopSwitch1]
{
	push:
	{
	           //do something
	}
}

Of course without DEVCHAN's, this should work:

button_event[dvTP, 235]
{
	push:
	{
	         on[dvIO8_23,5]
	}
        release:
	{
	         off[dvIO8_23,5]
	}
}

channel_event[dvIO8_23,5]
{
	on:
	{
	       //do something
	}
}

Of course I'm sure someone that does this every day will chime in with something awesome and one line.

Kevin D.

Hedberg

I've been doing this for a while and I've never used "combine" anything other than in a training class. In Axcess programming, stuff could be combined and it was usefull, but with Netlinx programming you have arrays and you can do almost everything with arrays that you could do combining channels and devices and all that stuff. A couple years ago I attended the RMS course in Dallas and the instructor and I talked about this and he pointed out one thing you could do with combines but not with arrays, but I forget what it was.

Now that that rant is over, on to IO ports. Depending on whether you have your ports set as logic high or logic low, an IO port will trigger a button event "push" when the voltage across the port is changed to either high or low. Low (default) is 0 to 1.5 volts and high is 3-5 volts. An open circuit IO port is high because of internal voltage. So, if you are detecting a contact closure (setting the voltage to 0), and are using 'low', you detect a button push when the IO port is shorted. So, just stack the button events:

button_event[dvIO8_23,5]
button_event[dvTP, 235]
{
  push:
  {
     //do whatever
  }
}

Arrays of device channel structures also work(as noted).

In the typical case when you are using an IO port to detect a "dry" contact closure, you get a push when the contact closure is made and a release when it is broken. The feedback status of the IO port follows the button push of the IO port except if mutually exclusives may foul that up.

nicholasjames

Hedberg wrote: »

A couple years ago I attended the RMS course in Dallas and the instructor and I talked about this and he pointed out one thing you could do with combines but not with arrays, but I forget what it was.

The one thing I know DEVICE_COMBINE does that arrays do not is auto-updating the channels & levels. With an array you have to manually update the panel with the current status.

Hedberg

nicholasjames wrote: »

The one thing I know DEVICE_COMBINE does that arrays do not is auto-updating the channels & levels. With an array you have to manually update the panel with the current status.

I don't understand that. If there is an array of touch panel devices, for example, updating the status of any channel in the device array will change the status on the channel of all the device elements of the array. For example:

on[dvTouchPanelArray,123]

will turn on the feedback on button 123 on all tp devices in the array. Likewise with levels.

travis

Hedberg wrote: »

I've been doing this for a while and I've never used "combine" anything other than in a training class. In Axcess programming, stuff could be combined and it was usefull, but with Netlinx programming you have arrays and you can do almost everything with arrays that you could do combining channels and devices and all that stuff. A couple years ago I attended the RMS course in Dallas and the instructor and I talked about this and he pointed out one thing you could do with combines but not with arrays, but I forget what it was.

Now that that rant is over, on to IO ports. Depending on whether you have your ports set as logic high or logic low, an IO port will trigger a button event "push" when the voltage across the port is changed to either high or low. Low (default) is 0 to 1.5 volts and high is 3-5 volts. An open circuit IO port is high because of internal voltage. So, if you are detecting a contact closure (setting the voltage to 0), and are using 'low', you detect a button push when the IO port is shorted. So, just stack the button events:

button_event[dvIO8_23,5]
button_event[dvTP, 235]
{
  push:
  {
     //do whatever
  }
}

Arrays of device channel structures also work(as noted).

In the typical case when you are using an IO port to detect a "dry" contact closure, you get a push when the contact closure is made and a release when it is broken. The feedback status of the IO port follows the button push of the IO port except if mutually exclusives may foul that up.

Thanks for clarifying this for me. Now it seems to work even though I'm sure I tried this before.

One last problem...

DEVCHAN dci_ShowModeSwitch1[] = { {dvIO8_23,1}, {dvTP, 231} }
vs
DEVCHAN dci_ShowModeSwitch1[] = { {dvIO8_23,1}, {dv_TPs, 231} }

dv_TPs is an array of panels; dvTP is a panel.

the version with dv_TPs doesn't seem to trigger button event, while the non-array version does. The IO works with both.

BUTTON_EVENT[dci_ShowModeSwitch1]

ericmedley

travis wrote: »

Thanks for clarifying this for me. Now it seems to work even though I'm sure I tried this before.

One last problem...

DEVCHAN dci_ShowModeSwitch1[] = { {dvIO8_23,1}, {dvTP, 231} }
vs
DEVCHAN dci_ShowModeSwitch1[] = { {dvIO8_23,1}, {dv_TPs, 231} }

dv_TPs is an array of panels; dvTP is a panel.

the version with dv_TPs doesn't seem to trigger button event, while the non-array version does. The IO works with both.

BUTTON_EVENT[dci_ShowModeSwitch1]

Yeah, embedding the devchan array within another devchan array isn't going to work as you might think it should. Keep in mind the arrays have indexes and you're trying to cross reference indexes that don't line up. I'm surprised it compiled actually.

nicholasjames

Hedberg wrote: »

I don't understand that. If there is an array of touch panel devices, for example, updating the status of any channel in the device array will change the status on the channel of all the device elements of the array. For example:

on[dvTouchPanelArray,123]

will turn on the feedback on button 123 on all tp devices in the array. Likewise with levels.

Sorry, that's not what I meant.

When a touchpanel comes online, you normally want to update it's feedback to match the program. With an array, you have to ensure you do that manually:

DATA_EVENT[dvTPArray]
{
    ONLINE:
    {
        STACK_VAR INTEGER iTP;
        
        iTP = GET_LAST(dvTPArray);
        UpdateFeedback(iTP);
    }
}

With DEVICE_COMBINE, this happens automagically. So, say you've combined (vdvTP, TP1, TP2), and TP2 goes offline. While TP2 is offline you've done ON[vdvTP, 123] and SEND_LEVEL vdvTP, 124, 99. When TP2 comes back online, it will "sync" with vdvTP, and TP2's button 123 will turn on, and level 124 will go to 99. No extra ONLINE processing necessary. Well, unless you also have text to send to the buttons. That you still have to handle.

Hedberg

nicholasjames wrote: »

Sorry, that's not what I meant.

When a touchpanel comes online, you normally want to update it's feedback to match the program. With an array, you have to ensure you do that manually:

DATA_EVENT[dvTPArray]
{
    ONLINE:
    {
        STACK_VAR INTEGER iTP;
        
        iTP = GET_LAST(dvTPArray);
        UpdateFeedback(iTP);
    }
}

With DEVICE_COMBINE, this happens automagically. So, say you've combined (vdvTP, TP1, TP2), and TP2 goes offline. While TP2 is offline you've done ON[vdvTP, 123] and SEND_LEVEL vdvTP, 124, 99. When TP2 comes back online, it will "sync" with vdvTP, and TP2's button 123 will turn on, and level 124 will go to 99. No extra ONLINE processing necessary. Well, unless you also have text to send to the buttons. That you still have to handle.

Guess it depends on how you do feedback whether this is important or not.

Couple things:

With combined devices you can't, if I understand this correctly, address individual panels that have been combined. So, for example, if you want some buttons to appear on some panels but not on others, you can't if the panels are combined.

With device arrays, don't put the device array on the rhs of an expression as it may not have a unique value.

for example don't do this:

nSomeButtonStatus = [vdvTPArray,nSomeButton]

or this

[vdvTPArray,nSomeButton] = ! [vdvTPArray,nSomeButton]

added: I doubt that I made it clear about buttons appearing and not appearing. I often have occasion to have different buttons appear on different touch panels but with identical touch panel files on the various physical panels. Buttons get displayed or not displayed in code. Could do this with multiple files, of course, but because of certain condtions, this is more difficult than it might seem.