piervali Posted August 21, 2014 Posted August 21, 2014 Hi to all from Paul Scherrer Intitute, I did today some tests with the "Brakes control" function. We have some applications where brakes are used to keep firmly axis in position while removing motor current for cooling purposes in typical scientific applications. We already used this break control with other motion controllers brands. I believed that I could do the same with Delta Tau PPMAC, but I just noticed a strange misbahaviour. Here down I write more details. The questions will be: a) did I setup correctly the brake control ? b) if yes, if there a workaround to the problem ? c) if not, I will not use the brake function and write a specific buffered program instead... :-( Problem description: Note: for my test I did not use real brakes installed on motor shaft. The latter is free to rotate and I monitor the digital output separately. I did use the PowerPMAC IDE and wrote commands in terminal window: motor[1].pBrakeOut=PowerBrick[0].GpioData[0].a // set brake pointer to GPIO register motor[1].BrakeOutBit=17 // set bit 17 as GPIO output pin coonected to my brakes system motor[1].BrakeOffDelay=1000 // set delay to 1000 ms for brakes release delay after "j/" command (long enough for my tests purpose) motor[1].BrakeOnDelay=1000 // set delay to 1000 ms for brakes on after "dkill" command (long enough for my tests purpose) #1j/ // closing the servo-loop. What I observe: Current set immadiately in motor. after 1000, ms GPIO dig output 17 set to "1" and brakes released. dkill // delayed kill. GPIO dig output 17 set to 0 instantly (brakes on). After 1000 ms servo-loop and motor current removed. So far my tests where satisfacctory ... but the following test behaves not like I would expect to: Instead of just closing the servo-loop with "#1j/" command, I want to directly order a motion with "#1j^10000" command. Here the result: #1j^10000 // What I observe: current set and immediate motion start !!... After 1000 ms, GPIO dig output 17 set to "1" and brakes released. Of course I do not want motion controller tries to move the motor while brakes are still ON !! So I think there is a little misconception problem in this brakes control function (or a firmware bug or whatever...). I believe the right behaviour should be:[/font] #1j^10000 // motion order... immediately, should servo-loop be closed... but WITHOUT motion !!also immediately, should digital output 17 go to 1 to release brakesafter the "BrakesOffDelay" time, the desired motion could start In this case "BrakesOffDelay" is more related to the minimum time brakes really need to be completely released after digital output if set to 1 (may depends on a list of processing delays... one among them: removing current in a coil if not instantaneous !!). In software reference, is described as the time needed to close the loop before brakes release. This has also sense, but the main point of my post: the necessary time for brakes to fully release since the digital output set is not taken in acount ! (or I did miss something... sorry). I stop here my post and hope to get some feedback... thanks Best regards PV
curtwilson Posted August 21, 2014 Posted August 21, 2014 The brake control algorithms were not intended to support real move commands - delayed or not - given while the brakes are still engaged. We consider a move command in this state to be erroneous - not valid in the context of the state machine for the system. We do not presently provide explicit protection against this in the Power PMAC, as our users typically include this as part of their own application-specific state machine logic. You misunderstand the purpose of our "BrakeOffDelay" time parameter. The delay is to provide time for the servo (especially the power stage) to engage fully before starting the release of the brake. If the brake release starts too early on an axis with a net load such as gravity, you can get uncontrolled motion before full control is established. It is not intended to provide a precise delay from enabling the amplifier until a move can be started. We are now evaluating the addition of logic to reject a move command that is given with the brake still engaged. If the process of disengaging the brake has not started, it would start the process. (In other words, it would treat your j^10000 command as a j/ command.) But we do not believe that providing the functionality to start the motion after two delays (the BrakeOffDelay we provide and the additional delay you point out would be necessary) would fit into our safety logic well.
piervali Posted August 22, 2014 Author Posted August 22, 2014 Curt, thanks for quick reply. So I guess my wished sequence of actions should be implemented in a buffered program. An upper programming layer of us ( "EPICS" ) sends "online" command to the PowerPMAC by SSH. I tried this online command: cpx jog/1 PowerBrick[0].GpioData[0].17.1=1 dwell2000 jog1^10000 ... but it does not work as "jog1^10000" starts imediately and does not wait for the "dwell2000" 2 seconds delay to finish. I have two practical quetions now: how can I program a delay in a buffered program ? (delay and dwell commands did not work for me)in case I use the "BrakesOffDelay" with a "j/" command, how can I automatically trigger the following "j^10000" command after Brakes have been released ? Some practical example would be welcome. Thanks to all. PV
Omron Forums Support Posted August 22, 2014 Posted August 22, 2014 Curt, thanks for quick reply. So I guess my wished sequence of actions should be implemented in a buffered program. An upper programming layer of us ( "EPICS" ) sends "online" command to the PowerPMAC by SSH. I tried this online command: cpx jog/1 PowerBrick[0].GpioData[0].17.1=1 dwell2000 jog1^10000 ... but it does not work as "jog1^10000" starts imediately and does not wait for the "dwell2000" 2 seconds delay to finish. I have two practical quetions now: how can I program a delay in a buffered program ? (delay and dwell commands did not work for me)in case I use the "BrakesOffDelay" with a "j/" command, how can I automatically trigger the following "j^10000" command after Brakes have been released ? Some practical example would be welcome. Thanks to all. Pierfranco Hi, Dwell and Delay both definitely work. The reason your commanded cpx program is not working is because of the following invalid command: PowerBrick[0].GpioData[0].17.1=1 You first must assign a ptr variable to PowerBrick[0].GpioData[0].17.1 and use that ptr variable instead; for example: ptr IOPTR->PowerBrick[0].GpioData[0].17.1 cpx jog/1 IOPTR=1 dwell2000 jog1^10000 In order to use BrakeOffDelay, you have to first specify a nonzero Motor[x].pBrakeOut. Then, you have to enable the motor with a jog/ first before jogging it anywhere. Also, generally speaking, PLCs are better for jogging than motion programs. Motion programs are intended for synchronized motion of multiple axes, not asynchronous jogging. In this case, you would need to use a call to a timer subprogram rather than using Dwell.
curtwilson Posted August 22, 2014 Posted August 22, 2014 For what you want to do, I think you will want to keep the motor technically enabled and closed-loop when the brake is on, but effectively disable it. If it is a servo motor, you could set Motor[x].Servo.Kp to 0 (and probably Ki also). If you are doing direct microstepping, you would want to set Motor[x].IdCmd to 0. This would mean that there would be no current in the motor. Next, you would want to assign the motor to an axis in a coordinate system, so it can execute as part of the sequence in a motion program. &1 #1->X assigns Motor 1 to the X axis in C.S. 1 Now when you want to re-establish electronic control of the motor, release the brake, wait for the brake to disengage, and move the motor, you can issue a command like: &1 cpx Motor[x].Servo.Kp=100 PowerBrick[0].GpioData[0].17.1=1 dwell 2000 x10000 I would probably embed all of the commands to re-establish control into a subroutine so the command could look like &1 cpx call EngageControl(1) x10000 with the subroutine looking something like: open subprog EngageControl(MotorNum) Motor[MotorNum].Servo.Kp = 100; Motor[MotorNum].Servo.Ki = 0.0001; PowerBrick[0].GpioData[0].17.1 = 1; dwell 2000; return
Recommended Posts