FBL2360 Zero-Angle Reference Search

I am using a FBL2360 (firmware v1.8) to control a two axis stabilized gimbal. I have it configured for sinusoidal mode with hall and encoder feedback. On startup the system performs a homing sequence in closed loop speed position mode. The homing sequence is a simple 5 deg/sec search in azimuth and elevation to find the limit switches (about 250/100 degrees respectively). While slewing to find the switches I notice this stutter movement (in the direction of the moving axis) much like that of the bind sequence (!BND) command. Eventually the stuttering stops and I never see it again in rest of the operation of the gimbal. I was not expecting this as per the documentation on pg 100 of users manual, it says the reference angle search is not needed when using hall and encoder sensors for sinusoidal feedback. To test my theory that this was the bind process, I increased the the reference seek power value to a point where I knew it would make the gimbal unstable and watched that happen during the first stutter motion. Is this behavior expected? I was trying to eliminate the bind sequence as the gimbal is on a moving platform and I cannot guarantee I have the correct reference seek power value in which the bind sequence will always pass.

Kevin

Hi Blake

I have attached two files - config.txt and startup.txt. I run config.txt once to setup the configuration for the motors and save it to eeprom. This contains all of the static parameter changes from the shipped baseline configuration of the FBL2360. startup.txt is the operational script. The homing sequence is performed when the controller detects motor power. Labels HS_FSM_INIT and HS_FSM_EXEC are executed twice for each stage (azimuth and elevation). The state machine in HS_FSM_EXEC is fairly straightforward. I move in the negative direction first for about 10 degrees (in case I'm between the limit switch and the hard stop) and then start moving forward until I detect the limit switch. Once I find the limit for elevation stage, I execute the same process for the azimuth stage. I don't issue any !BND commands. They are referenced in the file but are commented out (I iniitally tried some stuff without hall sensor input). The behavior I am seeing seems to be coming from the firmware of the motor controller as I am moving in the positive direction towards the limit switch, both stages.

Kevin