HAI OmniPro II MACRO Code Problem

[SierraTech]

Greetings,

I Have PC ACCESS 3.5.0.583 and Firmware 3.2D in an OMNIPRO II Controller. The following notes apply:

Notes:

FamFirePlace = Button (Macro)
FamFire-dim = ALC Dimmer Switch
ALC 4-Button Scene Slitch (Button-3 is being used)

I am trying to use a single button on ALC 4-Button Scene Switch To increase the level of a Dimmer each time it is pressed, but the MACRO never seems to run. My first attempt is below:

73.	WHEN Fam-Scene SW3 PRESSED
			THEN RUN FamFirePlace

94.	WHEN FamFirePlace
		AND IF FamFire-dim OFF
			THEN SET LIGHTING LEVEL FamFire-dim TO 25%

95.	WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 25%
			THEN RAMP FamFire-dim TO 50% AT 2 SECONDS

96.	WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 50%
			THEN RAMP FamFire-dim TO 75% AT 2 SECONDS

97.	WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 75%
			THEN RAMP FamFire-dim TO 100% AT 2 SECONDS

98.	WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 100%
			THEN RAMP FamFire-dim TO 0% AT 2 SECONDS

I decided to try and use a flag, but the net result is the same (MACRO Never Runs). See code below:

73.	//	FamFirePlace is a Macro for Fireplace Spots

74.	WHEN Fam-Scene SW3 PRESSED
			THEN RUN FamFirePlace

95.	WHEN FamFirePlace
		AND IF FamFireCount CURRENT VALUE IS 0
			THEN SET LIGHTING LEVEL FamFire-dim TO 25%
			THEN INCREMENT FamFireCount

96.	WHEN FamFirePlace
		AND IF FamFireCount CURRENT VALUE IS 1
			THEN RAMP FamFire-dim TO 50% AT 2 SECONDS
			THEN INCREMENT FamFireCount

97.	WHEN FamFirePlace
		AND IF FamFireCount CURRENT VALUE IS 2
			THEN RAMP FamFire-dim TO 75% AT 2 SECONDS
			THEN INCREMENT FamFireCount

98.	WHEN FamFirePlace
		AND IF FamFireCount CURRENT VALUE IS 3
			THEN RAMP FamFire-dim TO 100% AT 2 SECONDS
			THEN INCREMENT FamFireCount

99.	WHEN FamFirePlace
		AND IF FamFireCount CURRENT VALUE IS 4
			THEN RAMP FamFire-dim TO 0% AT 2 SECONDS
			THEN SET FamFireCount TO 0

I had a simpler MACRO running with this switch, but I must be doing something wrong. I searched the forum and couldn't find a similar post.

Any Ideas?

 

[Desert_AIP]

Looks like your first set of code will run sequentially, all the way to 0% everytime.

Turns On
Then goes to 25%
Then goes to 50%
Then goes to 75%
Then goes to 100%
Then goes to 0%

The commands fire simultaneously each pass through the code, anything with identical trigger statements fire sequentially.

Same with the second batch of code.
You increment the flag, then check if it is the next value, since it is it runs the code under it, and so on.


Try something like this (pseudo code)

When Press SW3
Increment FamFire Flag

When FamFireFlag = 1
Fam Fire ON 25%

When FamFireFlag = 2
Fam Fire ON 50%

When FamFireFlag = 3
Fam Fire ON 75%

When FamFireFlag = 4
Fam Fire ON 100%

When FamFireFlag = 5
FamFireFlag = 0
Fam Fire OFF

 

[cornutt]

Desert-AIP hit on it; whenever a triggering event occurs, every block that has that event as a trigger will run, in the order that they appear in PC Access. When you press the button, all of blocks 94-98 run, in that order. So your code is very quickly cycling through all of the settings and back to off -- it happens too fast for the lights to actually respond to, so you don't see anything happening.

I'd do two things. First of all, if you just reverse the order of blocks 94-98, most of the problem disappears. You still need a flag to prevent the looping-around problem from 100% to off, but you can handle it more easily by taking advantage of the fact that a flag, like a lighting unit, can be turned on or off for a specific period of time:

[codebox]
WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 75%
THEN RAMP FamFire-dim TO 100% AT 2 SECONDS
THEN FamFireFlag ON FOR 3 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 50%
THEN RAMP FamFire-dim TO 75% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 25%
THEN RAMP FamFire-dim TO 50% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim OFF
THEN SET LIGHTING LEVEL FamFire-dim TO 25%

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 100%
AND IF FamFireFlag OFF
THEN RAMP FamFire-dim TO 0% AT 2 SECONDS
[/codebox]

The "FamFireFlag" prevents jumping from 50% directly to off, by preventing the first and last blocks from both running on the same button press. You may want to tweak the flag on time after you play with it for a bit..

 

[SierraTech]

Desert-AIP hit on it; whenever a triggering event occurs, every block that has that event as a trigger will run, in the order that they appear in PC Access. When you press the button, all of blocks 94-98 run, in that order. So your code is very quickly cycling through all of the settings and back to off -- it happens too fast for the lights to actually respond to, so you don't see anything happening.

I'd do two things. First of all, if you just reverse the order of blocks 94-98, most of the problem disappears. You still need a flag to prevent the looping-around problem from 100% to off, but you can handle it more easily by taking advantage of the fact that a flag, like a lighting unit, can be turned on or off for a specific period of time:

[codebox]
WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 75%
THEN RAMP FamFire-dim TO 100% AT 2 SECONDS
THEN FamFireFlag ON FOR 3 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 50%
THEN RAMP FamFire-dim TO 75% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 25%
THEN RAMP FamFire-dim TO 50% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim OFF
THEN SET LIGHTING LEVEL FamFire-dim TO 25%

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 100%
AND IF FamFireFlag OFF
THEN RAMP FamFire-dim TO 0% AT 2 SECONDS
[/codebox]

The "FamFireFlag" prevents jumping from 50% directly to off, by preventing the first and last blocks from both running on the same button press. You may want to tweak the flag on time after you play with it for a bit..

This makes sense, and thank you for the feedback. Yes, I thought about using the flag to simplify other programs turning lights off. My SW4 is a Family Room Lighting Exit program, and I already saw the simplistic approach to kill the lights no mater what level they are set at. HAI did chime in and told me to reverse the order of the programs that didn't use flags, but I was wondering how that would work because it seems the first Line testing for 100% turns it off would qualify the last program looking for 0%

I plan to try it both ways, but the Flag approach presented by Desert-AI makes perfect sense with only one line of code increments and when set to "0" by the last line so it won't loop. Thanks cornutt for confirming my wondering how just reversing would work. I will try the code (without a flag) just for my curiosity but I think it may fail since I now understand that all lines are looked at simultaneously (very important point I forgot).

I am in the process of rewriting a lot of my code with version 3 since I have many programs that perform multiple functions based on one trigger. It is easier to read multiple actions based on trigger.

I will post my results here for feedback. Thanks to you both for your help. I was looking for a FORUM like this previously but didn't find it until yesterday. Very active and great information. Thank you both!

-Bob

 

[SierraTech]

Looks like your first set of code will run sequentially, all the way to 0% everytime.

Turns On
Then goes to 25%
Then goes to 50%
Then goes to 75%
Then goes to 100%
Then goes to 0%

The commands fire simultaneously each pass through the code, anything with identical trigger statements fire sequentially.

Same with the second batch of code.
You increment the flag, then check if it is the next value, since it is it runs the code under it, and so on.


Try something like this (pseudo code)

When Press SW3
Increment FamFire Flag

When FamFireFlag = 1
Fam Fire ON 25%

When FamFireFlag = 2
Fam Fire ON 50%

When FamFireFlag = 3
Fam Fire ON 75%

When FamFireFlag = 4
Fam Fire ON 100%

When FamFireFlag = 5
FamFireFlag = 0
Fam Fire OFF

Ran into a problem (in fact I noticed this last night), You cannot Trigger on a Flag Count (can only trigger using 'ON' condition). See graphic. I will have to use cornutt's approach but still need a flag to prevent looping.

Did a later version of firmware allow Triggering from a specific count?

-Bob

 

[SierraTech]

Desert-AIP hit on it; whenever a triggering event occurs, every block that has that event as a trigger will run, in the order that they appear in PC Access. When you press the button, all of blocks 94-98 run, in that order. So your code is very quickly cycling through all of the settings and back to off -- it happens too fast for the lights to actually respond to, so you don't see anything happening.

I'd do two things. First of all, if you just reverse the order of blocks 94-98, most of the problem disappears. You still need a flag to prevent the looping-around problem from 100% to off, but you can handle it more easily by taking advantage of the fact that a flag, like a lighting unit, can be turned on or off for a specific period of time:

[codebox]
WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 75%
THEN RAMP FamFire-dim TO 100% AT 2 SECONDS
THEN FamFireFlag ON FOR 3 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 50%
THEN RAMP FamFire-dim TO 75% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 25%
THEN RAMP FamFire-dim TO 50% AT 2 SECONDS

WHEN FamFirePlace
AND IF FamFire-dim OFF
THEN SET LIGHTING LEVEL FamFire-dim TO 25%

WHEN FamFirePlace
AND IF FamFire-dim LEVEL IS 100%
AND IF FamFireFlag OFF
THEN RAMP FamFire-dim TO 0% AT 2 SECONDS
[/codebox]

The "FamFireFlag" prevents jumping from 50% directly to off, by preventing the first and last blocks from both running on the same button press. You may want to tweak the flag on time after you play with it for a bit..

Actually none of these worked (The FLAG worked once, but never again). I did resolve the issue however based on sequential programming problem. I thought I would post what does work (see below):

WHEN Fam-Scene SW3 PRESSED
			THEN RUN FamFirePlace

WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 100%
			THEN RAMP FamFire-dim TO 0% AT 2 SECONDS

WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 75%
			THEN RAMP FamFire-dim TO 100% AT 2 SECONDS

WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 50%
			THEN RAMP FamFire-dim TO 75% AT 2 SECONDS
 
WHEN FamFirePlace
		AND IF FamFire-dim LEVEL IS 25%
			THEN RAMP FamFire-dim TO 50% AT 2 SECONDS
 
WHEN FamFirePlace
		AND IF FamFire-dim OFF
			THEN SET LIGHTING LEVEL FamFire-dim TO 25%

Thanks for everyone's help! I will be adding a flag just in case the dimmer switch was used and the dimmer value does not match these numbers. That is a later step (as time permits).

-Bob

 

[Desert_AIP]

Looks like your first set of code will run sequentially, all the way to 0% everytime.

Turns On
Then goes to 25%
Then goes to 50%
Then goes to 75%
Then goes to 100%
Then goes to 0%

The commands fire simultaneously each pass through the code, anything with identical trigger statements fire sequentially.

Same with the second batch of code.
You increment the flag, then check if it is the next value, since it is it runs the code under it, and so on.


Try something like this (pseudo code)

When Press SW3
Increment FamFire Flag

When FamFireFlag = 1
Fam Fire ON 25%

When FamFireFlag = 2
Fam Fire ON 50%

When FamFireFlag = 3
Fam Fire ON 75%

When FamFireFlag = 4
Fam Fire ON 100%

When FamFireFlag = 5
FamFireFlag = 0
Fam Fire OFF

Ran into a problem (in fact I noticed this last night), You cannot Trigger on a Flag Count (can only trigger using 'ON' condition). See graphic. I will have to use cornutt's approach but still need a flag to prevent looping.

Did a later version of firmware allow Triggering from a specific count?

-Bob

Darn, yep you're right. I was going off of memory and didn;t have PCAccess available.
(I said it was "pseudo code")

Try

When Press SW3
Increment FamFire Flag

When Press SW3
& IF FamFireFlag = 1
Fam Fire ON 25%

When Press SW3
& IF FamFireFlag = 2
Fam Fire ON 50%

When Press SW3
& IF FamFireFlag = 3
Fam Fire ON 75%

When Press SW3
& IF FamFireFlag = 4
Fam Fire ON 100%

When Press SW3
& IF FamFireFlag = 5
FamFireFlag = 0
Fam Fire OFF



There's got to be a more elegant solution though.

I see you appear to have solved it.