homing & encoders

More
30 May 2009 13:18 #370 by gtom
Replied by gtom on topic Re:homing & encoders
But the index goes low and there is a small "offset" until this is handled by servo-thread, how does emc notice this? i mean if the index is tripped and emc set the cmd-pos to 0.00 is this done inside the servo thread also??? If yes there will be no way to use the index properly.... !?

Please Log in or Create an account to join the conversation.

More
30 May 2009 19:21 - 31 May 2009 22:33 #372 by gtom
Replied by gtom on topic Re:homing & encoders
hi Alex, Thank you for your help, now the reset works as desired:

void hm2_stepgen_prepare_tram_write(hostmot2_t *hm2, long l_period_ns) {
int i;
for (i = 0; i < hm2->stepgen.num_instances; i ++) {
if (*(hm2->stepgen.instance.hal.pin.reset) == 1) {
if (hm2->stepgen.instance.index_search == 0) {
hm2->stepgen.instance.index_search = 1;
}
} else {
if (hm2->stepgen.instance.index_search == 1) {
*(hm2->stepgen.instance.hal.pin.reset) = 0;
hm2->stepgen.instance.subcounts = 0;
hm2->stepgen.instance.index_search = 0;
}
}
if (*(hm2->stepgen.instance.hal.pin.enable) == 0) {
hm2->stepgen.step_rate_reg = 0;
hm2->stepgen.instance.subcounts = *(hm2->stepgen.instance.hal.pin.position_cmd) * (hm2->stepgen.instance.hal.param.position_scale * 65536.0);
} else {
hm2_stepgen_instance_prepare_tram_write(hm2, l_period_ns, i);
}
}
}

This is the hal:

## connect encoder index-enables for homing on index
net xindex-enable hm2_5i20.0.encoder.00.index-enable <=> axis.0.index-enable
net xindex-enable => hm2_5i20.0.stepgen.00.reset

this is the ini-part:

## Homing mit Index
HOME_OFFSET = 180
HOME_SEARCH_VEL = 4
HOME_LATCH_VEL = -0.5
HOME_FINAL_VEL = 4
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = YES

Thank you!
Last edit: 31 May 2009 22:33 by gtom.

Please Log in or Create an account to join the conversation.

More
30 May 2009 21:49 #373 by alex_joni
Replied by alex_joni on topic Re:homing & encoders
gtom wrote:

*(hm2->stepgen.instance.hal.pin.reset) = 0;


I am a bit worried about that.. that might cause index-enable to be 0 before the encoder index is 0.
I'd rather wait only for reset to go 0 (while index-search is 1), and if it is 0 set subcounts to 0 and index-search to 0.

Regards,
Alex

Please Log in or Create an account to join the conversation.

More
31 May 2009 05:33 - 31 May 2009 05:34 #374 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
gtom wrote:

i looked thru the code of stepgen today, what do you think about setting the stepgens position_fb to the same value as the position_cmd when the enable-signal changes to false ???

I looked at the software stepgen (as per our conversation on irc around 22:39). It does not copy .position-cmd to .position-fb when .enable is low. Here are a pair of halscope traces showing this: enabled , disabled .

I'm not opposed to considering this change in behavior, but i want to discuss it with someone who understands the reason for the current (software stepgen) behavior first.
Attachments:
Last edit: 31 May 2009 05:34 by seb_kuzminsky.

Please Log in or Create an account to join the conversation.

More
31 May 2009 13:30 #377 by gtom
Replied by gtom on topic Re:homing & encoders
Hi seb, heres the hal-scope with the modified stepgen

Attachments:

Please Log in or Create an account to join the conversation.

More
31 May 2009 15:08 #378 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
The encoder notices the index pulse in the FPGA, it checks at something like 50 MHz.

The stepgen notices the index pulse in emc2, it checks at something like 1 KHz.

After the encoder notices the index, but before stepgen-in-emc2 notices the index, the stepper is still moving, and the encoder is moving from it's new zero. When the stepgen finally notices and sets its position to zero, the encoder is potentially not at zero any more. How do you deal with that? Do you do the "index search" stage of homing at <1 encoder edge per servo loop?

Please Log in or Create an account to join the conversation.

More
31 May 2009 15:21 #379 by gtom
Replied by gtom on topic Re:homing & encoders
Well, homing on index is a problem of EMC at all, as alex mentioned above the reset is done in the servo-thread. Even with Software-Stepgen or with a servo system there will always be an offset.

the question is: How far ist that offset away from 0.00??? As you can setup the velocity of the home procedure you can control this offset more or less.
Until a Homing- Speed of 10mm/Sec its within a tolerance 0.01mm thats enough for my application.

Anyway: As i know the encoder-position and the position where the reset happended i can also (if needed) move the axis back that amount and reset both (enoder & stepgen) to 0. That will be the absolute 0.00 Position on that machine.

Please Log in or Create an account to join the conversation.

More
31 May 2009 15:32 #380 by PCW
Replied by PCW on topic Re:homing & encoders
Actually homing on index is not a problem with servo systems and can be done at any speed to 1 count resolution
(its designed that way) This is because the index event is captured by hardware, the servo period does not affect this
accuracy of index detection at all.

The problems come in when you combine a step motor with the index logic thats designed for servo systems

BTW if you make changes to clear the stepgen fb, make sure you do this by capturing an offset, not clearing the hardware register.
clearing the hardware register when in motion has several nasty side effects...

Please Log in or Create an account to join the conversation.

More
31 May 2009 18:15 #382 by gtom
Replied by gtom on topic Re:homing & encoders
Yes, i understand that the encoders are reset within the MesaUnit, but please tell me: What is EMC doing on this Reset???
I think that EMC sets the cmd-position to HOME_OFFSET, isnt it??
Does EMC take care of the moving axis? If not, there will be an offset between Encoder 0.00 and EMCs - 0.00 Position.

If you have a axis moving lets say 10000mm /Sec, Servo-Thread is 1msec, Mesa-Freq is say 10000Hz
in this case:

The Mesa Index (worst case) will be 0.00 when the axis is 1mm from the "real" index away.
EMC will reset the Index (worst case) 10mm after the index-event occured.

Just to explain what i mean...

All this is a Problem of thread-timing & Velocity

As we can control both (within limits) we can also control the amount of offset.
There will never be a machine that has the index EXACTLY on 0.000000000

Also: The FASTEST Thread is the internal Mesa-Thread, so this Position is very near to the real 0.00 Position.
We can calculate the offset that occured and move the axis back to Encoder-Position.

Please Log in or Create an account to join the conversation.

More
31 May 2009 19:56 #383 by seb_kuzminsky
Replied by seb_kuzminsky on topic Re:homing & encoders
gtom wrote:

Yes, i understand that the encoders are reset within the MesaUnit, but please tell me: What is EMC doing on this Reset???
I think that EMC sets the cmd-position to HOME_OFFSET, isnt it??
Does EMC take care of the moving axis? If not, there will be an offset between Encoder 0.00 and EMCs - 0.00 Position.

The true picture is more complicated than what you describe above.

Maybe one source of confusion is that emc2 maintains separate positions of joints and axes, and that while the servo joint position is reset to zero at the index pulse, the corresponding axis position is reset to HOME_OFFSET. The joint controller maintains this offset. There's a pretty clear diagram of the joint controller in the code Code Notes document.

You might also want to read the Homing Configuration document if you haven't already.

gtom wrote:

If you have a axis moving lets say 10000mm /Sec, Servo-Thread is 1msec, Mesa-Freq is say 10000Hz
in this case:

The Mesa Index (worst case) will be 0.00 when the axis is 1mm from the "real" index away.
EMC will reset the Index (worst case) 10mm after the index-event occured.

No, this is wrong, as PCW explained.

The Hostmot2 encoder counter runs at 33 MHz or 50 MHz depending on the board. The filtering is configurable to either 3 clocks or 15 clocks, so even at the slowest setting, the slowest board accepts a 2 MHz signal on the encoder lines. If the rotary encoder has 4096 lines (16K edges/revolution), then the motor shaft would have to be turning at 125 revolutions per second, or over 7K rpm, to max out the hm2 encoder counter. Not a typical homing velocity. ;-) Even at that ridiculous speed, the encoder counter would latch the count within 500 nanoseconds of the index pulse. On a 5mm pitch lead screw at 7K rpm, 500 ns is about 0.0003 mm, an acceptable positional uncertainty at speed.

Ok, so that's what happens inside the FPGA. Whenever emc2 comes around to read it later (in the 1 KHz servo loop) it would have an incredibly accurate idea of the joint's true indexed home. By the time emc2 reads the latched encoder count, the joint would have moved past the latched, indexed home. The hostmot2 driver would report to emc2 the encoder's position as this small amount past the home location, and it would report that the index event had occured. The homing logic would start to decelerate the joint, overshooting somewhat, as shown in the Homing Configuration document linked above.

This all works great with single-feedback servo systems. And it would work great on your machine if you used the stepper in velocity mode, and used your encoder as the sole source of position feedback.

Please Log in or Create an account to join the conversation.

Time to create page: 0.154 seconds
Powered by Kunena Forum