Jump to content
OMRON Forums

Resetting Motor[x].MasterPos


Recommended Posts

We are converting a custom force-mode following function from our Turbo PMAC implementation to our Power PMAC implementation. On the Turbo PMAC, we used a custom user-servo function running under an unused motor (#6). The algorithm reads a force from a designated sensor, applies PID gains to the force error, and then modifies the commanded position of a desginated motor (#1 through #5). As such, it is a fairly classic example of a cascaded loop.


On the Power PMAC, we are using a user PID task for motor #6 and are attempting to modify Motor[x].DesPos with no success. Motor[x].DesPos is apparently written by Delta Tau firmware on every servo cycle (even when no motion commands are pending). Searching for a solution, we tested Motor[x].MasterPos in normal mode. We found that Motor[x].MasterPos works quite well for us with only one problem. We are concerned about accumulated distance in the Motor[x].MasterPos register and need to reset it to zero at the start and/or end of our force mode servoing. When we attempt to do this, the motor jumps back to its original position. It is clear that we need to simultaneously change Motor[x].MasterPos and Motor[x].DesPos, but Motor[x].DesPos is written by Power PMAC firmware on every servo cycle. So, we are back to square one.


Q. What motor register can we write to in order to effect a step change in commanded position?


Q. Is there a way to zero the Motor[x].MasterPos register of an active motor without causing motion?


Please provide examples.

Link to comment
Share on other sites

  • Replies 9
  • Created
  • Last Reply

Top Posters In This Topic



I'm not 100% sure, but I think the answer for the second question, if you meant "closed loop motor" by term "active motor", is no. The reason is quoted from the following post: http://forums.deltatau.com/showthread.php?tid=390&pid=1198#pid1198


RE: How to properly zero motor position?

For all registers of this type, subtract out the value of Motor[x].HomePos, which contains the value of the motor zero position relative to the power-up/reset position. (In Power PMAC, we cannot block interrupts like we could in Turbo PMAC, so we cannot reliably reset all of these registers for a new reference position in the same servo cycle.)




By the way, what are your concerns about accumulated distance in the Motor[x].MasterPos register? Would you be able to explain?

Link to comment
Share on other sites



I wouldn't expect interrupts to be a concern since our code is running in a user_pid block. It seems to me that no other code (firmware or PLC) should have the ability to change the commanded and/or the master position of my motor during the time that the user_pid code is running.


Note that we are trying to do exactly what we did on the Turbo PMAC (which is to feed the commanded position as if we are a trajectory generator). The problem is that Motor[x].DesPos gets overwritten (possibly by the command prefiltering?) and we don't know what register feeds the command prefiltering.


To understand our application, just think about a CMM (coordinate measuring machine) which has a probe that approaches a part by riding on a motorized axis until it is deflected to some target force. Then, it continues to maintain constant force until some scanning motion (using another axis) is complete. Once complete, force-mode servoing is disabled and normal motions are used to retract the probe away from the part.


You can think of our force-mode following algorithm as a dynamically controlled trajectory generator (where the trajectory is controlled by the force error signal). The only difference is that, when the force-mode servoing is turned off, we want to revert to position control at the motor's present actual position (not the actual position when force-mode servoing was enabled). That's why the normal mode MasterPos doesn't work (unless we allow it to accumulate).


My concern about the accumulation in MasterPos is that it is not an integer register. It doesn't just roll over. It is a double precision floating point value. Consequently, resolution is ultimately traded off for range if the magnitude gets large. At some point, MasterPos could accumulate to the point where resolution is lost and the force-mode servo following stops working.


We either need a way to zero MasterPos (with no motion) while the motor position loop is closed or we need a way to feed the commanded position like we used to do on the Turbo PMAC.

Link to comment
Share on other sites

We went to the double-precision floating-point format for motor registers so you would not have to worry about these things. Yes, the range is not infinite, and in theory you could potentially get to a point where you would start losing effective resolution. However, with a 52-bit mantissa, I have not seen an application where this is a real-word worry.


In addition, in our position accumulation algorithms, we keep "residuals" such as Motor[x].ResMasterPos (also 64-bit floating-point), to ensure that in the tiny chance you start losing effective resolution of the 52-bit mantissa of the main register, the residual is there to prevent this. Effectively, here we have a 128-bit floating-point value. With this, I strongly doubt that it would be physically possible to run into the problem you are concerned about during the entire lifetime of the machine.

Link to comment
Share on other sites



Thanks for the reply and for the reassurance. I believe that you are correct (particularly if the residual argument is valid), but I think it is still worth going through the calculation.


Typical Axis Resolution: 1.2 nm/cnt

Typical Force-Mode Maximum Velocity: 100 mm/s


Assuming only a 52-bit mantissa, we will lose one bit of resolution for every 2^51 accumulated counts. Further assuming a worst-case MasterPos accumulation of:


  100 mm/s            8.33e7 cnt
---------------  =  ------------
1.2 e-6 mm/cnt              s


It will then take 2^51/8.33e7 seconds (0.85 years) of unidirectional accumulation at the maximum velocity to lose one bit of resolution. So, you are correct that we are unlikely to see a loss of resolution under these conditions. Even so, I would feel better if I could zero the MasterPos after its job is done. It should be a trivial exercise in any of the user servo functions if I only knew which register I should poke into. For example, if the register of interest was Motor[x].CmdPos, the code to clear out MasterPos in user_pid() would look like:




Of course, if I could poke into Motor[x].CmdPos (and not have my value get overwritten), then I wouldn't need to use Motor[x].MasterPos as an accumulator. Further, I would have a solution which looks mostly identical to our Turbo PMAC solution.

Link to comment
Share on other sites

The whole point of going to double-precision floating-point and keeping a residual was so that our users would never have to worry about this and play these games. Looking at your numbers, I don't think you would have any problems for the life of the universe.


If you really want to do this, it looks like Motor[x].Desired.Pos is the best register to overwrite. You would execute:





This works for me when nothing else is going on. I have not verified all aspects of this, or exactly what needs to be done (e.g. PMATCH) before subsequent motion.

Link to comment
Share on other sites



Thanks for the reply. I agree with you on the matter of resolution. Nevertheless, we will try Motor[x].Desired.Pos instead of Motor[x].DesPos in our next round of testing.


Can you offer any further explanation about the difference between Motor[x].Desired.Pos and Motor[x].DesPos?

Link to comment
Share on other sites

Motor[x].DesPos is most equivalent to the "net desired position" register in Turbo PMAC, which is the sum of trajectory, master, and compensation positions. It is automatically computed from its components each cycle, so you cannot write to it.


Motor[x].Desired.Pos holds the trajectory commanded position only. While no trajectories are being computed, you can write to it, and the new value is maintained.

Link to comment
Share on other sites

Thanks Curt. I appreciate the support.


We made the change to use Motor[x].Desired.Pos instead of Motor[x].DesPos. Motor[x].Desired.Pos works perfectly and mimics the cascaded behavior of our Turbo PMAC solution (which writes to D:$000088).


Motor[x].MasterPos is no longer needed by our Power PMAC algorithm now that we know how to set desired position. We only investigated Motor[x].MasterPos because of our failed attempts with Motor[x].DesPos.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...