I want to make a sine trajectory and keep the resultant velocity rate constant.

I know there are different ways to make a sine trajectory, such as a while loop in motion prog, kinematic subroutine, projection of an circle interpolation and simulink. But I found it difficult to keep the resultant velocity rate constant.

I want to make a sine trajectory and keep the resultant velocity rate constant.

I know there are different ways to make a sine trajectory, such as a while loop in motion prog, kinematic subroutine, projection of an circle interpolation and simulink. But I found it difficult to keep the resultant velocity rate constant.

(02-23-2018, 03:31 PM)steve.milici Wrote: Yes – use the federate command with motion program code like this:
P1=1
P2=0
P3=0
P4=1
While (P2<360)
X(P3+P1*Cos(P2))
P2=P2+P4
EndWhile

Hi Steve,

1. I tried to make a sine trajectory move like y=a*sin(w*x+b), not just one motor move;

2. I tried to cut the wave into approximate equal length segment and get the points, then throw them into a linear loop move, in feedrate mode. But however big F is given, speed crashes occured at peak and trough of the wave.

3. What's more, speed should be limited deeply by length of segments and servo motor performance.

How is CNC keep the speed of head when machining irregular curve?

02-26-2018, 01:24 PM (This post was last modified: 02-26-2018, 02:44 PM by mbalentine.)

(02-23-2018, 06:58 PM)lovu Wrote:

(02-23-2018, 03:31 PM)steve.milici Wrote: Yes – use the federate command with motion program code like this:
P1=1
P2=0
P3=0
P4=1
While (P2<360)
X(P3+P1*Cos(P2))
P2=P2+P4
EndWhile

Hi Steve,

1. I tried to make a sine trajectory move like y=a*sin(w*x+b), not just one motor move;

2. I tried to cut the wave into approximate equal length segment and get the points, then throw them into a linear loop move, in feedrate mode. But however big F is given, speed crashes occured at peak and trough of the wave.

3. What's more, speed should be limited deeply by length of segments and servo motor performance.

How is CNC keep the speed of head when machining irregular curve?

1) You'll need to have a separate relationship for X & Y
X(P22) Y(P188) ;P22 & P188 are dummy variables

2) Your system must be physically capable of following the frequency and amplitude of the programmed move.
- Torque
- Inertia
- accel & vel limits
- Physical range of motion
- Properly tuned

3) Allow PPMAC trajectory generator to check and provide system limits in real time. Basic approach is to use FRAX and F commands. If the system cannot follow the prescribed velocity of the F command, then PPMAC can slow both axis so path is preserved.

Expanding on Steves code example:

P1=1
P2=0
P3=0
P4=1
P5=32.6 ;any number for desired feedrate

LINEAR ABS FRAX(X,Y)
While (P2<360)
X(P3+P1*Cos(P2)) Y(P2) F(P5)
P2=P2+P4
EndWhile

Don't use this code as-is, it only illustrates the concept. For instance, the Y axis will move 360 linear units. First move will be to X(P3+P1) Y0 from wherever you start.
You should see the velocity along the sine-wave maintain at constant 32.6 units/sec while the X&Y axis coordinate to exactly follow a sin path.
Probably good advice to make P4 smaller so the path is calculated more frequently.
Note also that Cutter Radius Comp (when used) will maintain the constant velocity F at the cutting edge, not the spindle center.
Sounds like you're doing a CNC type application - you'll find PPMAC has a very capable set of internal routines to make your life easier. These capabilities have been very well thought out over 20+ years.

For irregular curves the same thing will happen. PPMAC will coordinate axis so that path is followed at the F velocity (actually the path at the tangent edge of the cutting tool). A problem can occur when going around a small radius in the path with Cutter Radius Compensation turned on. This can cause the spindle center to require very high accelerations and/or velocity that may exceed machine capability. If this happens, PPMAC may not be able to stay on path. This is what 'Look Ahead' is for - PPMAC will identify this situation before it gets to that part of the path and slow down enough so that path fidelity can be maintained.

Another way to do this:
In the above example PPMAC is really making straight lime moves between 'way points' on an imaginary sin (cos) path. By making P4 small, this can for all intents and purposes be a true sine or cosine.
But there is another method to use PPMAC for this. If you define a third axis (D) as a dummy (no electronics or motor), you can use CIRCLE mode to scribe a circle using the X and D axis while commanding the Y axis similar to the example above. The X axis will move in a Sine while the dummy D axis moves in a Cosine.
Still use FRAX(X,Y) and F(). Do not include D in the FRAX statement.

linear
abs
ts (test(98))
ta (test(97))
F (test(99))
intt++
while(Px(intt)>0 && intt<=3999)
{
x(Px(intt)) y(Py(intt))
intt++=
}
dwell 0
intt=0

close

However big dpxt, ds and F are, speed crashes occured at peak and trough of the wave, every time!

Can interpolating speed of sine wave stays constant when using circular interpolation?

Constant speed is the keypoint!

Quick review of your code raises some questions:
1) Why are you using PLC 0 to pre-process the data?
2) The code as written fails the comparison test on the first pass and exits PLC 0 immediately
dt=sqrt(pow(pxt-Px(intt),2)+pow(pyt-Py(intt),2)) = 17x10^-6

if((dt-ds)>0 && (dt_last-ds)<=0) //ds=0.05
(dt-ds) = -0.049983 ;fail comparison on first pass
No data is loaded into the arrays. These lines of code never execute.
Px(intt)=pxt;
Py(intt)=pyt;
Apparently there is junk data in the memory, which you then try to use as an X Y data path for motion in prog 7

Unfortunately, the code is not fulfilling your intentions.

It is possible for your strategy to work, but you will need to refine your code a bit.

I would say that this is not really the best way to use PPMAC, but I do not know your objectives.

My advice:
1) try the code outline shown in previous comments. This would be fully executed in a motion prog with no PLC processing required.
Drawback is that it executes in Linear mode so there will be some granularity to it that reduces as you make the increments smaller. It is essentially the same strategy you show in your code, but simpler. Each X Y point is calculated as needed instead of filling arrays ahead of time.
2) Use Circle mode to generate a true sin function (PPMAC interpolates a table for trig functions) by setting up a phantom or dummy axis. Again, simpler and the data points are calculated as needed instead of pre-processed.
3) Use a cam table to drive the Y axis from the X axis. The table will use 3rd order spline calculations between points, so you should get very good results with as few as maybe 21 points - easy to add more if you find fidelity is not sufficient. After thinking about it, this might be the easiest and best solution. You can fill in the cam table either manually or by calculation. You only need to fill data for one cycle as the table will wrap onto itself. (This is not typically what PLC0 should be used for, use a non-synchronous PLC for this and test or set a flag to know it is complete if necessary)
4) PPMAC either goes 'point to point' in which case you have to calculate each point including desired velocity & acceleration (why??, usually for external CAM program interface), or you generate 'Way Points' in a program and allow PPMAC to use its internal algorithms to interpolate points for each servo interrupt. This is where PPMAC's power resides. It has one of, if not the, best trajectory generator anywhere. Take the time to understand how to use its' capabilities and it will do virtually anything you can imagine.
5) Note that both 2) & 3) are interpolating a sin table. PPMAC uses a 2048 entry table and interpolates using 3rd order spline for all trig functions. Using the cam approach of #3, you are essentially interpolating a smaller table, so accuracy will vary.

If you want cosine in degrees on power pmac, then use the function cosd().

I believe I saw a picture on here with a velocity graph that is horizontal line, that takes a slightly smaller value when position is at a min/max. Now it says the attachment has been removed. I was assuming the issue was special lookahead or PMAC otherwise limiting your speed/position.

Are you currently using special look ahead or software limits? Could you re-upload the plot and specify what a "good" plot would look like?

(02-27-2018, 03:35 PM)mbalentine Wrote: [quote='lovu' pid='10962' dateline='1519693135']
Hi mbalentine,

Quick review of your code raises some questions:
1) Why are you using PLC 0 to pre-process the data?
2) The code as written fails the comparison test on the first pass and exits PLC 0 immediately

...

hi mbalentine,

1) Just because plc0 runs faster than background plcs or cplcs.
2) I just want to show the outline or the method of my test, not the whole project. I have run it successfully.
3) I'm sorry but I think you may have misunderstood my needs. I know there are many methods to get such sine trajectory, but what more important is to keep resultant velocity rate constant, which means, stays the same along the path.

(02-27-2018, 04:30 PM)Eric Hotchkiss Wrote: If you want cosine in degrees on power pmac, then use the function cosd().

I believe I saw a picture on here with a velocity graph that is horizontal line, that takes a slightly smaller value when position is at a min/max. Now it says the attachment has been removed. I was assuming the issue was special lookahead or PMAC otherwise limiting your speed/position.

Are you currently using special look ahead or software limits? Could you re-upload the plot and specify what a "good" plot would look like?

I'm wondering too why the attachment disappeared!
No special lookahead or software limit is used.
See attachment below:

02-28-2018, 07:54 AM (This post was last modified: 02-28-2018, 08:24 AM by mbalentine.)

(02-27-2018, 07:56 PM)lovu Wrote:

(02-27-2018, 03:35 PM)mbalentine Wrote: [quote='lovu' pid='10962' dateline='1519693135']
Hi mbalentine,

Quick review of your code raises some questions:
1) Why are you using PLC 0 to pre-process the data?
2) The code as written fails the comparison test on the first pass and exits PLC 0 immediately

...

hi mbalentine,

1) Just because plc0 runs faster than background plcs or cplcs.
2) I just want to show the outline or the method of my test, not the whole project. I have run it successfully.
3) I'm sorry but I think you may have misunderstood my needs. I know there are many methods to get such sine trajectory, but what more important is to keep resultant velocity rate constant, which means, stays the same along the path.

Have you ever do applications like this?

Yes, I have.
Based on the graphs you posted, look for a possible speed limitation on the X axis. It appears you are following your desired path with constant velocity except where Vx is near maximum.
In other words, can Vx >= F ?

Also, is your data density so high that point to point increment per servo interrupt in this region will not allow F to be achieved? (not sure how PPMAC would respond to this conflict, but I think it would give priority to the path, thus slowing down)
In your PLC0 software the 'dt' calculated value is minimum in the area of issue so the question is whether (dt/servo)<F ? (where your use of 'dt' = distance traveled)
Does the total error get smaller if F is reduced?
Is the error affected by values in TA or TS?

Just for fun, in western calculus notation dt is commonly used for delta time or the time derivative. The name 'Delta Tau' is derived from this as tau (greek) is commonly used for a repeated time increment as in a servo interrupt.

I am also assuming your velocity is being limited. There is a small chance it can be a position that is limited since I am not sure what variables are plotted. Lets try lowering the feedrate to try to get below any velocity limits and if that doesn't work multiply the amplitude of your cosine by 1/2 to get away from position limits.

I am not sure of the configuration of your two axes. I think one motor is slaved off another. If that's the case it could be a limit on either motor.

The F (vector feedrate) specification for moves is useful for moving in a 2D or 3D Cartesian system (spatially perpendicular axes) so the tool is moving in the plane or space at the same speed regardless of direction.

When this specification is used, PMAC automatically calculates the time for a move as (VectorDistance/VectorFeedrate), with VectorDistance computed as sqrt(Dx^2 + Dy^2 + Dz^2) for a 3-axis system.

I think this is fundamentally the wrong mode for you to be using here, as you do not seem to be using your X and Y axes as spatially perpendicular axes, wanting a constant vector speed over this 2D plane.

Most people who want to create a custom profile as you are doing from a series of small moves with many intermediate points on the move use the TM (move time) specification, typically with a constant TM, TA=TM, and TS=0 to produce a quadratic B-spline fit of their desired profile. I think this will create the profile you desire.