axcess programing

cbucha

I am tring to find the best way to program volume control buttons on an axcent 2 system, with a receiver that is rs323 controlled. As of now i am using a while loop trigered by a variable but when i release the button if takes so long for the variable to turn off that the volume continues the ramp. I added a wait before the loop and in the loop,it works but the volume ramping is to slow even with a wait of 1. I know there has to be a better way.

Darkside

Without seeing your code, its a bit hard to say, but it's likely the while loop you are triggering is stacking up a whole bunch of send_string cmds that will be executed after what appears to be when you stop pushing the button etc..

Here's a very simple way to get very 'responsive' control from your button press...(If it is a very large code, there will be a bit of a lag as mainline loops through)

push[tp,1]
{
on[vol_ramp_up]
}

release[tp,1]
{
off[vol_ramp_up]
cancel_wait 'ramp'
}

if (vol_ramp_up)
{
wait 2 'ramp' send_string dev,'vol up string'
}

The tp button PUSH switches the vol_ramp_up variable ON. As soon as the variable is ON, the if (vol_ramp_up) routine will run.

The RELEASE switches the vol_ramp_up variable OFF as fast as mainline will allow. The cancel_wait will cancel the pending string.

You can replicate this method for vol down - making it unique of course!

Check the minimum tx speed the device will respond to without coming unstuck....

cbucha

this is my code:

(*volume controls*)
PUSH[TP,24]
{
ON[VOLUP]
FN = 24
CALL 'RECEIVER FN'
}
RELEASE[TP,24]
{
OFF[VOLUP]
}
(*VOL DN*)
PUSH[TP,25]
{
ON[VOLDN]
FN = 25
CALL 'RECEIVER FN'
}
RELEASE[TP,25]
{
OFF[VOLDN]
}

WHILE ([VOLUP])
{
WAIT 1
CALL 'RECEIVER FN'
}

WHILE ([VOLDN])
{
WAIT 1
CALL 'RECEIVER FN'
}

Darkside

Without seeing the call, I can't tell if it has any error handling etc inside that may slow things down as you have described, however, if it is just a generic string handler that assembles the protocol etc, then I suggest you try the approach I posted to see if it will give you the desired effect.

If you are concerned about other routines being able to use your amplifier call while you are simply porting the string from mainline, then drag your 'lock out' variable into the PUSH/RELEASE statement I suggested.

..plenty of assumptions being made here...!

You should be aware of the way WHILEs are handled in axcess. They have a finite duration of half a second only and will then be terminated - regardless of what your code demands! It's related to how the axlink buss is handled and may well be related to your issue.

LONG_WHILE and MEDIUM_WHILE were ways around this - it enabled the processor to go off and do things yet still maintain the integrity of the 'WHILE' procedure.

I'm straining my mind here a little, but I think the LONG_WHILE enabled mainline to keep running and receiving axlink updates, and MEDIUM_WHILEs let mainline run and see axlink changes, but not update them until the MEDIUM_WHILE had exited.

To pursue your approach for now, try a LONG_WHILE as a last resort, but make very sure the loop can exit logically and is not relying on the processor to terminate it like the WHILE statement could be - otherwise the loop will run forever!

cbucha

here is a link to my code: http://www.cbt-ent.com/loft_sys.axs

DHawthorne

What I do with the Axcent3 is to set a variable with my button press to the volume up/down state, much like you have, and un-set it with the release. The difference is that I don't use a while loop, I put my operating code right in mainline, using a second flag for timing; something like this:

DEFINE_VARIABLE

VOL_FLAG
VOL_ACTIVE

DEFINE_PROGRAM

PUSH[TP, 24]
PUSH[TP, 25]
    VOL_FLAG = PUSH_CHANNEL

RELEASE[TP, 24]
RELEASE[TP, 25]
{
     VOL_FLAG = 0
     CANCEL_WAIT  'VOL DELAY'
}

IF(VOL_FLAG AND !VOL_ACTIVE)
{
     SELECT
     {
          ACTIVE (VOL_FLAG = 24) : (* code for volume up *)
          ACTIVE(VOL_FLAG = 25) : (* code for volume down *)
     }
     VOL_ACTIVE = 1

     WAIT 8 'VOL DELAY'
          VOL_ACTIVE = 0
}

You have to fiddle with the value of the WAIT depending on the device, but I have found 8 to be appropriate for most RS_232 devices. If it keeps ramping after you have released your volume button, the length of the wait needs to be longer to allow the RS-232 buffer to empty on each pass. I will generally make the WAIT length a CONSTANT so I don't have to hunt for it in the code sixth months later when the customer upgrades their receiver and I need to adjust it. The CANCEL_WAIT is there so no cycle gets cut off prematurely in the event of a pending WAIT (unlikely, I know, and you could probably do without).