missing second button event

Rich Abel

In a Netlinx system controlling Radia lighting, momentary contact switches are used to generate contact closures. Switch operating logic is: turn light on or off upon release. Ramp light up or down if held.

When a user pushes adjacent light switches on simultaneously, the system only sees one button event.

BUTTON_EVENT[dvLSW_ON]
{
	PUSH:  // NOT DOING ANYTHING ON PUSH, SHOULD DELETE THIS...
	{
		STACK_VAR INTEGER nSW_INDX
		
		nSW_INDX	=	GET_LAST(dvLSW_ON)
	}
	
	HOLD[nHOLDTIME]:
	{
		STACK_VAR	INTEGER	nSW_INDX

		nSW_INDX	=	GET_LAST(dvLSW_ON)		
		SEND_STRING dvDEBUG, "'dvLSW_ON HOLD BUTTON_EVENT, nSW_INDX=',ITOA(nSW_INDX),$0D"
		bRAMP[nSW_INDX]	=	1	// SET RAMP FLAG
		ON[dvLTS[nSW_INDX].DEVICE,(dvLTS[nSW_INDX].CHANNEL + 128)]	// START RAMPING UP
		// RAMP UP CHANNEL IS OFFSET BY +128
	}
	
	RELEASE:
	{
		STACK_VAR	INTEGER	nSW_INDX
		
		nSW_INDX	=	GET_LAST(dvLSW_ON)
		
		SEND_STRING dvDEBUG, "'dvLSW_ON RELEASE BUTTON_EVENT, nSW_INDX=',ITOA(nSW_INDX),$0D"
		IF(bRAMP[nSW_INDX])
		{
			bRAMP[nSW_INDX]	=	0		// CLEAR FLAG
			OFF[dvLTS[nSW_INDX].DEVICE,(dvLTS[nSW_INDX].CHANNEL + 128)]	// STOP RAMPING UP
		}
		
		ELSE
		{
			SEND_COMMAND dvLTS[nSW_INDX].DEVICE,"ITOA(dvLTS[nSW_INDX].CHANNEL),'L',cON_PERCENT,'T2',$0D"
		//		DEVCHAN ARRAY DEVICE,"'DEVCHAN ARRAY CHANNEL','L', ON PERCENTAGE,$0D"
		}	// END ELSE
	}	// END RELEASE
}	// END BUTTON_EVENT[dvLSW_ON]

Device-channel arrays are used for the on and off switches, and the radia module, channel for the loads. The devchan arrays are arranged to share a common index. An integer array is used for the hold state flag for each switch.

The issue isn't electrical, I see the both I/O leds illuminate in testing, yet only one release event registers and only one light is effected. I don't know this for sure, but it seems that one release needs to happen before the second hold or release can commence.

I'm stumped....Anyone have any ideas for me?

Thanks,
Rich Abel

Rich Abel

missing second button event

I found this under "Event Handlers" in Netlinx Studio help:

Note: The processing of an event associated with a given member of a device, channel, device-channel, level or device-array must be completed before processing can begin on another event associated with the same array.

I guess I'm breaking that rule in this case since the first button event is still in process when the second button event occurs.

Any suggestions on valid alternate coding approaches to achieve the same functionality accepted....

Rich

GregG

Netlinx will queue events that come in at the same time and process both of them in order, waiting for your code for the first one to finish before throwing the second one to your code. So there may be something else going on here.

One thing that could be going on, if the devchan array has the same exact button device and channel in two places, it will get squirrely because the get_last can only return one value for the array position.

Related to this, if you put a 0 into a devchan array for one of the buttons (thinking it's like a placeholder), the 0 will actually match every possible button. So any function that is a zero will happen all the time no matter what is pressed.

vining

GregG wrote: »

One thing that could be going on, if the devchan array has the same exact button device and channel in two places, it will get squirrely because the get_last can only return one value for the array position.
.

I would think that's one value per event table that is built which includes the event triggering UI / channel. Then get_last function will return the array position used in any given event table if one was actually used. If an array wasn't used then you need to use B.I.C. You should be able to have multiple button events using arrays which may include duplicate DevChan combo's and all should fire and get_last should return the appropriate array index for each since the "last" channel doesn't change until the next event is triggered or queued event is processed.

Rich Abel

missing second button event

GregG wrote: »

One thing that could be going on, if the devchan array has the same exact button device and channel in two places, it will get squirrely because the get_last can only return one value for the array position.

That's a possibility I'll check out.

At my office I setup a master with some switches and have been testing the button event code. Naturally, I can't get it to fail here. However I don't have all of the real devices to run my test with.

Thanks for the suggestion Greg. I'll check that out.

Rich

GregG

vining wrote: »

I would think that's one value per event table that is built which includes the event triggering UI / channel. Then get_last function will return the array position used in any given event table if one was actually used. If an array wasn't used then you need to use B.I.C. You should be able to have multiple button events using arrays which may include duplicate DevChan combo's and all should fire and get_last should return the appropriate array index for each since the "last" channel doesn't change until the next event is triggered or queued event is processed.

Yes, i was talking about duplicating the same devchan value in the single array he's diagnosing. Having the same devchan combination used singly in different arrays will not confuse get_last because you can only be looking for the get_last of the array that triggers your current event anyway. Using get_last on an an array that is outside of your current event is also a fun error of another type - it's one of my most common copy/paste errors.

vining

GregG wrote: »

Yes, i was talking about duplicating the same devchan value in the single array he's diagnosing. Having the same devchan combination used singly in different arrays will not confuse get_last because you can only be looking for the get_last of the array that triggers your current event anyway. Using get_last on an an array that is outside of your current event is also a fun error of another type - it's one of my most common copy/paste errors.

Ok, then get_last will return the first instance of the devchan combo it comes across and never the duplicates that are in the same array, either the first or the last depending on the direction get_last searches through the arrays, ascending or descending. I wouldn't exactly call that a squirlly behavior but what should be expected.

ericmedley

vining wrote: »

Ok, then get_last will return the first instance of the devchan combo it comes across and never the duplicates that are in the same array, either the first or the last depending on the direction get_last searches through the arrays, ascending or descending. I wouldn't exactly call that a squirlly behavior but what should be expected.

While I agree 100% with Vining in this case I can say that I have found cases where get_last did produce some very squirrelly results or no result at all. I know many of you are super sleuths at this and cannot leave a mystery unsolved and therefore go on fascinating trips to figure it out. I am not always this way myself. If something truly seems to be rattling under the hood, I tend to abandon it pretty quickly. I have my own get_last function called MyGet_last that I grab when I run into issues.

In most cases it something I did to cause it but there are a few where I'm more than certain it's just a ghost in the machine. For the record get_last has served remarkably well.

GregG

I'm not saying this get_last behavior is _unexpected_, just undocumented.

the8thst

You are using the IO ports to initiate the event, so you can easily check the status of the IO ports directly instead of multiple events running at the same time.

It could be as simple as a for_loop to check each IO port in question and toggle the corresponding lighting load if that channel is high.

vining

ericmedley wrote: »

While I agree 100% with Vining in this case I can say that I have found cases where get_last did produce some very squirrelly results or no result at all. I know many of you are super sleuths at this and cannot leave a mystery unsolved and therefore go on fascinating trips to figure it out. I am not always this way myself. If something truly seems to be rattling under the hood, I tend to abandon it pretty quickly. I have my own get_last function called MyGet_last that I grab when I run into issues.

In most cases it something I did to cause it but there are a few where I'm more than certain it's just a ghost in the machine. For the record get_last has served remarkably well.

I can't say I've ever had odd get_last behavior post the fix for "hold" handlers as long as it was used in an event handler and on an array used create that particular event table. Could be I've just been missing it. Just like usng button., data., channel. outside of an event handler you may not get what you were expecting but inside the handler it just works from my experience.