Jump to content
OMRON Forums

Smooth transition from Open to Closed Loop while motor is moving: catch the egg.


meindert.norg

Recommended Posts

All, I need help implementing the following function. I called it a "catch the egg"-move. The function goes as follows: A motor with normal feedback needs to move from A to C as fast as possible. Because of varying friction between A and C, the maximal allowable velocity is determined by the highest level of friction. Let’s say that is at location B. If we’d want to go faster, we would get a servo error while passing location B. In case of the ‘catch the ball’-move, [list=1] [*]first we start a normal move ([b]action I[/b]). [*]After leaving A, and accelerating to a certain speed, the motor is placed open-loop (while maintaining the controller output at that time, let’s say 7.56 V) ([b]action II[/b]) [*] and the controller output is ramped up to the maximum value (let’s say 10 V) ([b]action III[/b]). [*]At this point the motor is moving as fast as it can, slowing down and speeding up as friction increases (location B) and decreases. When approaching C, we ramp down the controller output to (e.g.) 9 V ([b]action IV[/b]) [*] and ‘catch the motor’ by closing the servo-loop while generating a setpoint that is identical to the current position/velocity ([b]action V[/b]) as to prevent any sudden jumps in the controller output. [*]After this we decelerate to zero velocity and arrive at point B ([b]action VI[/b]). [/list] The name "catch the egg" of course comes from the movements one would make trying to catch an egg that was thrown at you: attempt to match the egg's position/velocity with your hands before grabbing it. I believe actions I-IV are doable, but for action V I ask your input. (heck, if someone wants to write the programs for all actions, go right ahead...) I'm looking forward to any input related to this problem. regards, Meindert
Link to comment
Share on other sites

  • Replies 7
  • Created
  • Last Reply

Top Posters In This Topic

If you have pure DAC output, using the DacBias term and input of location of B, one can implement what you're trying to achieve based upon the relative position of motor and B. You also should be able to achieve the same to implement the same by writing to Motor (Quadrature/torque) command bias (from TCOMP table) if you're not using the torque compensation table of course.
Link to comment
Share on other sites

Hi Sina, I'm not sure how to respond, because I'm not familiar enough yet with the compensation tables and bias that you mention. However, I understand you're still using location B for something. As I mentioned earlier, location B is unknown. I would like to see if the procedure as I described it can be implemented, (1) to get a better understanding of the possibilities of the Delta Tau architecture and (2) because I am planning to use the implementation for [b]action V [/b] of the procedure for an application of which I can-not post details in this forum. Thanks, Meindert
Link to comment
Share on other sites

  • 2 months later...
This is easily done by disabling the position loop and running in pure velocity mode. This is a very neat trick, and Turbo SRM only hints at what you need to do in the Ixx67 section. In this mode, you can slew your machine as fast as she goes for the conditions, and resume control - e.g. J/ or start a motion control program - when you reach your destination. Think -5F temperatures, grease thick as cold fudge, and big telescopes. First, however, I want to stress that you should not be running open loop: this is not a solution! Running open loop can be dangerous, and gives you no speed control. For example, open loop can spin up the motor to high speed under no load in two seconds, and quickly reach the back-EMF limit. Suddenly the motor will have no torque, and will drop back to a lower speed. Depending on the load, you can get into damaging oscillations. There are legitimate reasons for running open loop, but your application isn't one of them. On a Geobrick (Turbo PMAC2 with torque mode amplifier), do the following: 0) Set Ixx32 very carefully to produce the correct velocity. To do this experimentally under no load, do steps 1 and 2 below, and then adjust Ixx32 so that the actual velocity matches the commanded velocity. On the Geobrick you may find that Ixx32 is almost Ixx31, typically just a fraction of a percent larger. Set Ixx11, Ixx69, Ixx57, and Ixx58 for your application. You might start with Ixx69 at the maximum safe continuous current for your motor, or the maximum continuous power for your amp, whichever is lower. 1) disable the position error limit Ixx67, setting it to zero. 2) You must set the integration limit Ixx63 to zero. Otherwise you may find your motor mysteriously spinning up after a stop - not a good thing! Even if Ixx33=0, just be safe and set Ixx63 to zero. Now when you do something like J+, your motor will be running in what I call velocity/torque mode. When you hit the Ixx69 limit and your motor can't go any faster, the following error will build up and trip on Ixx11, which you can prevent by zeroing it, and use other criteria to ensure safety - you don't want your motor taking full current while stalled. Your motor will now hum along at the commanded speed or something less, depending on conditions. When you are ready to resume position mode - you might be monitoring Mxx62 for example - first do Ixx63=4194304 Ixx67=4194304 Mxx61=Mxx62 To force a smooth transition, the M variable assignment forces the commanded position to be the actual position, after which you can immediately do, for example, a J^* and land right on target. In some cases you'll need to do Mxx62=Mxx61, for example when you have backlash compensation on, and you're reversing direction. Otherwise the compensation can do strange things. Of course you could just stop under pure velocity control with a plain "J/". You'll find other times when doodling directly with Mxx61 and Mxx62 is useful. Check the manuals for the full computation of following error - it involves the position bias and a couple of other things - to tell sweet lies to the PMAC. -John Kuehne, Ph.D. McDonald Observatory, Texas
Link to comment
Share on other sites

Great! You should also look at PMATCH in Turbo SRM, which essentially does Mxx62=Mxx61, taking into account the coordinate system. I think you'll find this works, and you'll be able to take this idea and extend it to your needs. For example, you could jump into velocity mode when the following error or actual current becomes intolerable, and elide into the position loop later. -John
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...