Retrofitting Mikron WF41C: Distance coded homing success

The (current) homing code only sets index-enable once, and then assumes that homing is complete.

We need to look for index twice, and the _accurate_ way to do that is with the built-in encoder reset-on-index. The point here is to compensate for how far the axis moves in the up-to-1mS between the index pulse and the servo thread being serviced.

Getting the system to go straight to encoder latch is also something that needs to be figured out. I think you can do this by setp-ing the home switch in to be permanently true. Possibly with a search velocity of zero and a non-zero latch velocity. This needs experimentation on a live LinuxCNC config.
A wrinkle is that there needs to be a way to ensure that the system won't run off the end of travel looking for an index. This is probably best handled by a relatively long home switch sensor, spanning at least two indices at the end of travel.
The encoders (software and hm2) both have various types of latch available but not really documented. I think that these are intended for probing, but it isn't clear, nor is it clear to me whether they help here.

My approach for implementing distance encoded homing on a source level would be to start normal index homing which results at some point in the following state that starts the move:

From here we come into a state waiting until the index mark is found:

After that we would come to the HOME_SET_INDEX_POSITION. This is where I would potentially modify the code something along the way:

Could this make sense?

Regards,

Marc

mwinterm wrote: Could this make sense?

It certainly could be added in to the homing sequence code, but bear in mind that it does need to be handled via the index-enable mechanism as index pulses themselves are typically too brief to detect in the servo thread.

But major changes to homing code would have to go in to master for testing, and probably wouldn't be released this year.

A HAL component can be working today, and can be used to test the logic.

Whether it belongs in homing or encoder I am undecided. Homing is already complicated enough to confuse most users (and developers). It feels like a variant on an absolute encoder.

After a bit of experimentation in a sim config, I am not sure that my original idea can work.
I was thinking that it would be possible to input the absolute position to joint.N.position-fb and have that used as the position.
However, on seeing index-enable go to false, the effect is to set an internal offset such that the index position becomes HOME_OFFSET.
It would be possible to input the absolute position _after_ the index-enable has been reset, but that would cause an instant following-error.
(though on re-enabling the machine, the position would be correct)
Setting the f-error very large is no help, as the effect then would be an uncontrolled move to the HOME_OFFSET position.
So, i think that we are back to doing this in the homing code rather than in the encoder or in a HAL component.
If the system is configured with HOME_ABSOLUTE_ENCODER then the position-fb is used as actual joint position. But in that case there is no motion in search of an index.

Even doing it in the homing code has its puzzles.

The sample code earlier was using a raw_position. I think that this would actually have to be added as a HAL pin: a joint.N.raw-pos-fb which would have to be connected to a scaled-to-position version of the encoder rawcounts.

The system could attempt to just read and store position-fb at servo-thread rate. But if the axis is moving more than 0.01mm/ms (ie 10mm/s) the measured delta would be too inaccurate to trust.

Hello Andy,

I moved exactly in the direction you describe. I already added to following fields to the joint-ini-section and have them now available in the homing routines:

Further I added another input pin called to the joint. I choose 'motor' because the input could be either an absolute rotary encoder sitting on the motor or as in our case a linear glasscale. I'm not conclusive on that though. Longer term I think there should be added the concept to the joint of having motor-encoder as well as direct-encoder feedback as some more recent machines have. This allows to auto-calibrate for backlash etc and even gives the option to fall back on the servo-encoders should the direct encoders fail.
Even the Mikron at hand has rotary encoders on the servos but they are only used within the Bosch drives and not forwarded to the control.

Next step is now to add the math for distance coded homing. But after that it will probably be some time until we can test as we did not connect / test the servos controlled from LinuxCNC yet.

Best regards,

Marc

PS: @gaston48: As you already figured out the analog servo control of your Mikron would you be willing to share your PID parameters with us. This would probably help us quite a bit.