Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Asynchronous following error
#1
Hello,
I just did a measurment that I don't understand.
I have a set of 2 signals one is a 1KHz pulse signal , the other one is a 256KHz quadrature signal perfectly synchronized with the 1KHz

I plugged the 256K signal on a motor A B channel and the 1K on the C channel

Then I setup the trigger for this motor to react on a up level of the C channel, I then built a plc to read and rearm automatically the trigger and give me the difference in position between 2 triggers.
I get a perfect 256 all the time. so the triggering plc seems OK

I now plug the 1K signal to the C channel of an other motor, a real motor.
and I did the exact same.
I jog my axis at 5um/ms and I read the difference of position between 2 triggers..

what I obtain is a really noisy signal centered on 5um but with a big jitter (+ or - 2 um) so I get distances between 2 pulses varying from 3 to 7 um

what bothers me is that it does not relate to my following error, indeed, when I plot the following error at the same time, it only varies of + or - 300 nm .
so my expectation was that I could have a maximum of twice the following error in my difference , so never more than 600 nm...

The only explanation I can come up with is that pmac the following error showed by PMAC is good because it is sampled at the same rate as the reaction time of the servo loop. but what happens between 2 servo cycles can be much more dramatic than the following error !

but this is scary, could it mean that every time I manage to regulate a motor down to 200 nm of following error, I can actually have 2 um without knowing it ?

I am doing this because I am studying a setup to use an external clock (so fundamentally asynchronous) to command a position on a motor. (the motor has to be at a designated position at every tic of the clock without making stops (as if the move was linear))
Reply
#2
What type of PMAC, amplifier and motor do you have? What type of encoder and resolution?

Can you post your PLC please. Don't forget that the normal uncompiled PLCs only start every millisecond so would not reliably re-arm the position capture for a 1KHz trigger.
Reply
#3
With the phase clock virtually always running at a higher frequency than the servo clock (default by 4x), you can use the phase gathering feature to log the IC channel's PhaseCapt register at this higher frequency to check for how it changes at shorter intervals than the servo update.

I'm very confident that your mechanical system does not have the physical bandwidth to behave in the manner you are concerned about.
Reply
#4
(12-05-2018, 03:51 AM)Tony Wrote: What type of PMAC, amplifier and motor do you have? What type of encoder and resolution?

Can you post your PLC please. Don't forget that the normal uncompiled PLCs only start every millisecond so would not reliably re-arm the position capture for a 1KHz trigger.

I use a Power PMAC CPU in CPCI format with ACC24C2A 4 axis cards, it talks to an external driver in +-10V which drives a linear motor (brushless) from faulhaber
my encoder is a mercury II encoder, optical encoder with 5 nm resolution

my code is described in the plc0. because I thought that it was really running at rti frequency (as a compiled rticplc) is that wrong ?
in my setup I have set the phase clock at around 144 kHz, servoclock at about 9Khz (110us) and rti same as servo

here is the plc 0

open plc 0

p2017 = Gate1[14].Chan[3].PosCapt;

if ( Gate1[14].Chan[3].ABC <4 )
{
if (p2017 ==2 && p2019==1)
{
p2019 = 0;
p2010 = Gate1[14].Chan[3].HomeCapt;

difference_to_previous = p2010 - p2011
p2011 = p2010
}
} else
{
p2019 = 1;
}


close
Reply
#5
(12-05-2018, 11:39 AM)curtwilson Wrote: With the phase clock virtually always running at a higher frequency than the servo clock (default by 4x), you can use the phase gathering feature to log the IC channel's PhaseCapt register at this higher frequency to check for how it changes at shorter intervals than the servo update.

I'm very confident that your mechanical system does not have the physical bandwidth to behave in the manner you are concerned about.

I used to do that, that is why my phase clock runs at 144 KHz (there used to be a phase algorithm) but as it was causing me a lot of confusion about what was updated and what was only depending on the last servo cycle, I stopped bothering to use that , and went back to the plc0 (thinking it was fine as 9KHz gives me 9 cycles to do the reading , (4 if you consider that I only allow mysel to rearm during a low-state of the C channel))
Reply
#6
One thing to be aware of is that the trigger capture is level triggered in the Gate1 IC. Reading the HomeCapt register automatically re-arms the triggering circuit, and if the trigger input is still at the specified state, it will immediately latch the present position again into the HomeCapt register, and a subsequent read of HomeCapt can report a different position that what was captured at the front edge of the trigger.

I'm not sure if your logic protects you against this. Remember that another task, such as the IDE watch window monitoring the value of HomeCapt, can re-arm the trigger before your code reads HomeCapt.

Another possible issue is how the encoder generates its signal. Encoders like this typically synthesize a high frequency digital quadrature signal from a lower frequency analog sinusoidal signal through an internal tracking feedback loop. In some encoders, this loop produces excellent (stable, accurate) results, but in others, undesirable non-physical effects come into the signal.
Reply
#7
(12-06-2018, 11:52 AM)curtwilson Wrote: One thing to be aware of is that the trigger capture is level triggered in the Gate1 IC. Reading the HomeCapt register automatically re-arms the triggering circuit, and if the trigger input is still at the specified state, it will immediately latch the present position again into the HomeCapt register, and a subsequent read of HomeCapt can report a different position that what was captured at the front edge of the trigger.

I'm not sure if your logic protects you against this. Remember that another task, such as the IDE watch window monitoring the value of HomeCapt, can re-arm the trigger before your code reads HomeCapt.

Another possible issue is how the encoder generates its signal. Encoders like this typically synthesize a high frequency digital quadrature signal from a lower frequency analog sinusoidal signal through an internal tracking feedback loop. In some encoders, this loop produces excellent (stable, accurate) results, but in others, undesirable non-physical effects come into the signal.

Hello, Curt, thank you for helping me once again,
I read about the level triggering in the doc, that is why in my PLC I protect the call to HomeCapt with a check :
if ( Gate1[14].Chan[3].ABC <4 )

that is to ensure the C channel of the coder is down while I read the flag (it triggers on index C high)
I also was carefull about the watches windows.

But yesterday evening I found my problem. indeed I plotted the state of the arming flag (posCapt) and the C channel at the same time, and although my C channel was perfectly good , the arming signal was erratic. More interesting, the capture signal stopped to be erratic when I cut the power of the main motor. My biggest mistake was to only rely on the PMAC scope to look at the C channel which was always looking super good despite that the real signal was less clean and messy just enough to mess up with the capture but not the content of the Gate1[14].Chan[3].ABC signal !

It was causing all my problems, also the ones I had with the trigerred time base system.
now this fix has removed what we called the "jitter" which is now almost equal to the following error, and what we called the "offsets" has been fixed by using the calibration movement (1 triggered move that I do just to measure the offset ) and then I apply this offset to the following moves of the program (the time base is re-frozen briefly)
This now looks super good.
Thank you very very much for your help.
have a good day.
Cheers,
Jeremy
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)