Many new features were added to the Accelera motion controller product line that were not available in prior generation Galil motion controllers. One of these more overlooked features is the fact that some Automatic subroutines no longer require thread 0 to be running on the controller for the routine to run. This is extremely useful as a safety feature for the #AMPERR, #LIMSWI and #POSERR routines, a helpful diagnostic tool for #TCPERR, and it gives the programmer much more flexibility when using the #ININT routine.

Because prior generation motion controllers required thread 0 to be running in order for those routines to execute, the routines could be easily written using arrays, variables or other settings that could be initialized in something like a #AUTO program, or a the beginning of a program that is executed from a host. With Accelera controllers, the programmer can no longer rely on the program running on the controller to initialize variables or settings, because the automatic routine has the ability to run before that program is even executed.

When programming Automatic subroutines on Accelera motion controllers, the programmer should not depend on variables or settings that are either not defaults on the motion controller, or are not burned into non-volatile flash. The automatic routines should also remain in the routine until the error or reason for the routine execution is cleared.

Here is an example of a #AMPERR routine that will cause problems, and another that should run without problems


REM Incorrect #AMPERR routine
#AMPERR
IF initvar=1
MG"Run Init Routine"
ELSE
ENDIF
RE


If an Amplifier Error occurs while there is no program running on the motion controller and the above code is in program memory, there are potentially 2 issues that could arise with the above code. If the variable "initvar" is not defined in controller memory, an error will occur and the routine will end. If there is no #CMDERR routine in program memory, #AMPERR will then automatically start again because there is still an amplifier error. This is essentially an infinite loop. If "initvar" is defined, the #AMPERR routine is a very short routine that does not address that actual amplifier error before it exits the routine. Once the routine ends, #AMPERR will start right back up - another infinite loop.

Here is a #AMPERR routine that will allow the motion controller to deal with the amplifier error, or at least properly notify the user/host of the state of an amplifier error. (This code is written for a DMC-40x0 controller) The routine uses no variables that are not defined in the actual #AMPERR routine, and it also checks to see if the amplifier error has cleared and only exits the routine under a cleared condition.

#AMPERR
REM mask out axes that are in brushed mode for _TA1
mask=(_BRH*128)+(_BRG*64)+(_BRF*32)+(_BRE*16)+(_BRD*8)+(_BRC*4)+(_BRB*2)+_BRA
mask=@COM[mask]
mask=((_TA1&mask)&$0000FFFF)
LU0;'turn off auto update of LCD
REM amplifier error status on LCD
MG"A-ER TA0"{L1},_TA0{L2};WT2000
MG"A-ER TA1"{L1},mask{L2};WT2000
MG"A-ER TA2"{L1},_TA2{L2};WT2000
MG"A-ER TA3"{L1},_TA3{L2};WT2000
LU1;'turn on Automatic Axis Update of LCD
WT5000
REM the sum of the amperr bits should be 0 with no amplifier error
er=_TA0+mask+_TA2+_TA3
JP#AMPERR,er0
REM Notify user amperr has cleared
LU0
MG"AMPERR"{L1},"RESOLVED"{L2}
WT3000
LU1
RE