Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Velocity oscillation on PowerBrick LV with linear motors
#1
Hi all,
a customer called complaining about a X-Y cartesian plane with linear motors.
They added some mass after the initial tuning and now they hear a vibration.

So far I could only do remote tests, and while following error remains very small its plot shows a high frequency pitch.
I also took some plots showing velocity and I see the same phenomenon.

What is really strange is that the "oscillation" (o whatever it is) is exactly at a frequency that is proportional to the movement speed.

Looking better at the system specs:
20kHz Phase, 10kHz servo. Commutated motor.
XY use linear motors with 30mm magnetic pitch and sinusoidal encoder (MicroEpsilon Veratus) ,1Vpp and 20um pitch.

Doing some basic math I found that the frequency (the shape is roughly sinusoidal) is the exact ratio between the speed and the encoder pitch.

a. Vel = 4mm/sec oscillation = 200Hz
b. Vel= 6mm/sec oscillation = 300Hz
c. Vel= 8mm/sec oscillation = 400Hz

Do you have an idea on what can cause this phenomenon?


Attached Files Image(s)
   
Reply
#2
(02-26-2019, 12:05 AM)tecnico Wrote: Hi all,
a customer called complaining about a X-Y cartesian plane with linear motors.
They added some mass after the initial tuning and now they hear a vibration.

So far I could only do remote tests, and while following error remains very small its plot shows a high frequency pitch.
I also took some plots showing velocity and I see the same phenomenon.

What is really strange is that the "oscillation" (o whatever it is) is exactly at a frequency that is proportional to the movement speed.

Looking better at the system specs:
20kHz Phase, 10kHz servo. Commutated motor.
XY use linear motors with 30mm magnetic pitch and sinusoidal encoder (MicroEpsilon Veratus) ,1Vpp and 20um pitch.

Doing some basic math I found that the frequency (the shape is roughly sinusoidal) is the exact ratio between the speed and the encoder pitch.

a. Vel = 4mm/sec oscillation = 200Hz
b. Vel= 6mm/sec oscillation = 300Hz
c. Vel= 8mm/sec oscillation = 400Hz

Do you have an idea on what can cause this phenomenon?

Those frequencies correlate with the encoder pitch. I suspect you are seeing the result of offsets or distortions on the sinusoidal signals. Plot the Lissajous of the sinusoidal signals and see if you get a circle centred around zero, or a distorted/offset circle.

The distortions could be caused by misalignment of the read head. Maybe something moved when they were adding the load.
Reply
#3
(02-26-2019, 02:11 AM)Tony Wrote: Those frequencies correlate with the encoder pitch. I suspect you are seeing the result of offsets or distortions on the sinusoidal signals. Plot the Lissajous of the sinusoidal signals and see if you get a circle centred around zero, or a distorted/offset circle.

The distortions could be caused by misalignment of the read head. Maybe something moved when they were adding the load.

Attached the requested plots. I stretched the images to have the same horizontal and vertical resolution

Both seem circular but not really centered around zero.
Do you think this can cause the previous issue?

If so, how can I solve it? Maybe a ADC offset?


Attached Files Image(s)
       
Reply
#4
I had a problem once, similar to the one you are describing. It turned out to be poor performance in the current loop. Granularity/quantization was too high. I would try turning off the servo loop and execute an open-loop torque-only move somehow, and see if the signal remains.
Reply
#5
(02-28-2019, 03:31 AM)tecnico Wrote:
(02-26-2019, 02:11 AM)Tony Wrote: Those frequencies correlate with the encoder pitch. I suspect you are seeing the result of offsets or distortions on the sinusoidal signals. Plot the Lissajous of the sinusoidal signals and see if you get a circle centred around zero, or a distorted/offset circle.

The distortions could be caused by misalignment of the read head. Maybe something moved when they were adding the load.

Attached the requested plots. I stretched the images to have the same horizontal and vertical resolution

Both seem circular but not really centered around zero.
Do you think this can cause the previous issue?

If so, how can I solve it? Maybe a ADC offset?
AdcOffset[0] and[1] can be used to reduce offset errors. Problem is we can only see the raw signal, and not the net result, other than doing an FFT on the following error. External signal conditioning solutions such as Heidenhain's IBV6072 do exist and can be used to gain, offset, and phase.
Reply
#6
I think Jeff is correct here. The offsets from being zero centering in sine and cosine inputs introduce a sinusoidal position calculation error with a period of one line. This explains exactly the velocity oscillation you are seeing.

Eyeballing the charts, you should set both AdcOffset[0] and AdcOffset[1] to about -150,000,000 (32-bit units) to counteract the analog bias.
Reply
#7
Thanks for all the useful replies. The oscillating frequency - too precise not to be deterministic- was determined using a position ramp signal, so constant velocity.

In this condition FFT shows a sharp peak both for FE and velocity.

Since inserting other hardware or messing with the current loop is not an option for the moment (btw in a previous unrelated check the current loop response was looking alright) I think I will try inserting a compensating offset first.

Do you think this offset is an "electric" offset or also a mechanical misalignment could be its cause?
Reply
#8
Today I was able to implement the modification.
Curt, you were right on the mark, the values I found are very close to the ones you suggested.
One thing is still unclear: to plot a "corrected" Lissajous figure do I need to manually combine the Adc and the offset?

In the pictures the position ramp response before and after offset trimming. Maybe not perfect but much better!


Attached Files Image(s)
       
Reply
#9
Yes, that's a huge improvement! It looks like you have (virtually) eliminated the systematic errors, and the remaining jitter is likely from electrical noise.

To plot a "corrected" Lissajous, you could gather both the AdcEnc and AdcOffset registers from the ASIC and add them in the "Data Processing" step (3) of the plot utility. It's probably easier to "cheat" by simply copying the (constant) value of the AdcOffset register into the Offset term of the Data Processing step.

I suspect the cause of the bias you see is electrical -- most mechanical alignment errors reduce the magnitude of the signal pretty symmetrically. I think it's likely that the added inertia reduced a system resonant frequency [=sqrt(k/J)] so it was more excited by the oscillation introduced by the signal errors.

If you want better performance in future systems, you may want to consider our "auto-correcting" interpolator. As the name implies, it automatically detects these (and other) signal errors and corrects for them. (You will need to run the motor faster than this initially for it to detect these errors, as it identifies variations above a certain frequency as not possible physically, so must be from signal errors.) It also radically oversamples and averages to dramatically reduce the effect of electrical noise. This will require the new generation of Power Brick LV we are introducing this year.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)