Can someone tell me why the cmd Vel produced by this program has a ripple component? I've used this structure before, without seeing such ripple, so I think its some sort of setup problem, but not sure what.
Motion Program:

05-07-2018, 08:39 AM (This post was last modified: 05-07-2018, 09:28 AM by mbalentine.)

Your intention might be that both axes move together in a continuous manner?
If so, try placing the X & Y move command together on the same line

while(1)
{
x(AMPL * sin(MyXArg))Y(AMPL * sin(MyYArg)) //in radians
...
}
It looks like the X axis is moving, stopping, moving, stopping (sort of) with the spline mode blending the moves together a bit so that you do not come to a complete stop.
There are (pi)/0.05 = ~63 ripple cycles per pi radians of the fundamental in the velocity chart, so this may agree.

It might be interesting to leave as-is but change the move mode to Linear. I would anticipate minor amplitude would go to zero (DC), but the ripple would stay at the same frequency and amplitude over the same fundamental period, giving a sine wave envelope of same freq you are now seeing.
Also just for fun: It looks like your axis has plenty of bandwidth and is executing the rather high acceleration required to produce the ripple as seen. You could try limiting the allowable accel/decel and see to what extent that will filter out the ripple (allow plenty of following error). Not that it would be a solution, just to see the masking effect of limited bandwidth.

With commands on same line, I would think you'll see a smooth sine position and velocity, at 2x frequency.(?)

Should chart at twice the frequency currently seen. This is because the axes are executing sequentially rather than simultaneously. Essentially, the individual axis are executing every 100 ms because the spline(50) statement is causing a 50ms spline for each axis sequentially. (100ms * ~63 ripple cycles =2(pi) seconds on the chart)
From the chart, you have [(pi) rad]/[2(pi)sec]/ = 0.5 rad/sec; and in software [0.050]rad/[50ms]/ =1.0 rad/sec (intended), so the software would seem to be executing axis coordinates only half as fast as intended - due to executing X&Y sequentially.

Not shown but assume axis definitions are straight forward like:
#1->(nnnnnnn)X
#2->(kkkkkkkk)Y