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

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.

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?

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.