Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Semi-coordinated dither motion
#1
Is there any way to add uncoordinated motion to an axis in a coordinate system?

I have several axes in a coordinate system following a pre-planned, coordinated path in pvt mode. For one of those axes, I would now like to add a back and forth dither motion on top of the existing coordinated motion. Ideally, the dither motion would be independent of the coordinated motion and continue at the same rate even if the coordinated motion slows down. However I can live with solutions that use the same time base as the coordinated motion.

The "obvious" solution is to add dither motion into the coordinated path, but that is not practical in this case since the time steps for the pvt program are not equal and are too long compared to the dither frequency.

Anyone have any thoughts? Can this be easily done?
Reply
#2
The method wherein the dither would be affected by the original coordinate system's timebase is to use kinematics. Command the path as normal in the motion program, but manipulate it slightly in inverse kinematics to add the dither. In inverse kinematics, PMAC grants you access to KinPoxAxisX, Y, etc., which you can modify as needed before manually back-calculating the motor positions in KinPosMotor1, 2, etc. If you need help writing kinematics, check out pages 410 and following of the PPMAC User Manual.

To add uncoordinated dither, compute the amount of dither you want to inject and write to Motor[x].CompPos [in motor units, e.g. counts] using a PLC program. This will proceed at the same rate regardless of the original coordinate system's timebase. I am not sure your dither criteria, whether path length or time, but if you know how to perform the calculation, it should be just a matter of writing to CompPos. If you need to write to it at a scheduled period, put this in an RtPlc; otherwise, leave it in a background PLC.
Reply
#3
(09-05-2014, 10:52 AM)CharlesP Wrote: To add uncoordinated dither, compute the amount of dither you want to inject and write to Motor[x].CompPos [in motor units, e.g. counts] using a PLC program.

Thanks. I would not have thought of using a compensation table in such a way, but it should work perfectly in this case.



(09-05-2014, 10:52 AM)CharlesP Wrote: I am not sure your dither criteria, whether path length or time ...

The compensation is in time. I will try the RtPlc approach. It is really just a sine wave, so it should be easy.
Reply
#4
I have the dither working using Motor[x].CompPos as suggested, and it works great! My problem now is how to handle the position information when the motion stops.

More specifically, there are times where the dither offset is non-zero when the coordinated motion and the dither axis complete the motion program. I would like to reset the CompPos offset to zero, but unfortunately there are some cases where allowing the necessary motion would not be safe.

So, what is the best way to do a "zero motion" move? I tried a simultaneous setting of CompPos to zero along with a jog command to the offset position. The concept is the two would cancel each other without the motor actually moving. It seems to mostly work, but it has the side effect of disabling the motor at the same time. I am guessing it is because of a fatal following error.

Do you have any suggestions?
Reply
#5
Hi,

I am not sure if I fully understand your problem, but you can issue a Dwell 0 command in your motion program. PPMAC interprets this as a "zero-distance" move.
Reply
#6
Thanks for the help, but unless I misunderstand, I do not think the dwell will do what I want. Here is a scenario:

At the end of the coordinated motion program, the dither axis has Motor[x].CompPos = 1,000,000 cts. In real world, this corresponds to an offset of let's say 30 degrees for the rotary axis being dithered. This means that the Motor[x].Pos and Motor[x].ActPos are different by 30 degrees. I would like to get these two values the same, but I am constrained to avoid physically moving the axis in the process.

In the above scenario, if I only set Motor[x].CompPos = 0 at the end of the motion program then ActPos = Pos as desired, but this will be accomplished by physically moving the motor as was done for the dithering. To avoid any actual motion, I tried to tell the axis to jog by 1,000,000 counts while at the same time changing the CompPos from 1,000,000 to zero. In essence I was trying to tell the motor to move by 1,000,000 counts while at the same time telling it that the offset was wrong by 1,000,000 counts, or in other words, I told the motor that it reached the destination immediately. This seemed to have the desired effect of avoiding any physical motion while making Motor[x].Pos = Motor[x].ActPos. Unfortunately the combination of commands also led to the axis being disabled, which I am guessing is due to a following error.

Do you know any other way I can make Motor[x].Pos = Motor[X].ActPos while avoiding any hardware motion?
Reply
#7
If you turn off the compensation, you would need a PMATCH. Also, PSET may be of use if you want to completely redefine the axis position.

As far as the comp table. I am glad that it is working for you. You may want to keep it. But traditionally, this is done by setting up a virtual motor - as a master to the real axis - which superimposes user profiles on top of the coordinated motion. I think this is more flexible for this type of applications (e.g. welding). Also, requires a PMATCH after turning following off.
Reply
#8
I think you will have more flexibility if you poke your dither value into Motor[x].MasterPos instead of Motor[x].CompPos.

(Note that because MasterPos adds into the net desired position value instead of the net actual position value as CompPos does, its direction sense is opposite.)

MasterPos should give you what you want because there are two modes of operation for it. In "offset mode" (Motor[x].MasterCtrl bit 1 [value 2] = 1), which you want to use for the actual dithering operation, the master position and trajectory position can be superimposed. In "standard mode" (Motor[x].MasterCtrl bit 1 = 0), computed trajectories would take out what the master added in.

(Another note: because you are poking directly into the MasterPos register, you want to leave the "following enable" bit -- MasterCtrl bit 0 [value 1] at 0.)

So it looks like you can get the effect you want by setting the mode bit to 1 when you are superimposing the dithering, then change it to 0 for pure trajectory moves relative to a fixed origin.

Whenever you change this mode bit, you must be sure that a "pmatch" command is issued before the next programmed axis move is commanded. A pmatch occurs automatically when you start a motion program, but if you make the change in the middle of a motion program, you must use an explicit pmatch command before the next axis move command.

You may want to look at how you set Motor[x].PosReportMode if you are querying positions in the different modes.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)