Retrofitting Mikron WF41C: Distance coded homing success

mwinterm wrote: When an index is found the encoder would still reset while the machine being in motion. Unless I would within the HAL-component try to capture the event of the reset instantaneously and artificially generate a 'fake' position signal consistent with the one before the reset

That is exactly what I am proposing for the first index.

(something I would not consider to be very elegant)

It's all just numbers to the computer. The system gets a position update from the Mesa driver once every 1ms, if the HAL component is inserted in the call-list between hm2_xxxx.read and motion-command-handler then the timing is guaranteed and the motion controller will always see the modified result.

The HAL component is going to have to modify the input position to convert it to an absolute position anyway.

The LinuxCNC system already has a way to avoid an f-error when the index reset happens on homing, which saves some trouble.

Imagine the HAL component has two index-enable ports, one connected to motion and the other to the encoder counter. Additionally it an encoder-position-out pin for use by motion and is connected to the encoder counter .counts and .rawcounts pins.

At startup the component feeds back encoder.rawcounts * encoder.scale on its position-out pin.

When, during the homing process, motion sets the joint.N.index-enable the component will set the encoder-index-enable.

It then waits until it sees the encoder-index-enable go false, indicating the first index has been seen.
The component, at this point, continues to output rawcounts * scale, so there is no position glitch.
It stores (rawcounts - counts) internally, as the exact point at which the index ocurred. It will set the encoder-index-enable true again, to search for the second index.

Then, when the encoder-index-enable resets for the second time, the component calculates the absolute position that the reset happened at (rawcounts - counts - index1.rawcounts). It resets joint.N.index-enable to signal to the system that an index has been seen and starts to output an internally-calculated absolute position based on the calculated index position and the encoder counts.

This is the point where I am not sure if changes are needed to the base LinuxCNC code.

The system should be configured for HOME_INDEX_ONLY_START which is set if the latch velocity is non-zero and HOME_INDEX_ENABLE is true. That is probably the appropriate configuration in this case.

Looking at:
github.com/LinuxCNC/linuxcnc/blob/master...otion/homing.c#L1092

I think that no changes are needed to the base code. If the INI HOME_OFFSET = 0 then when the index-enable goes false
joint->motor_offset = 0
joint->pos_fb = joint->motor_pos_fb
joint->pos_cmd = joint->pos_fb
joint->free_tp.curr_pos = joint->pos_fb

Which all sounds right. (the assumption that position resets to zero on index works in our favour here)

What isn't ideal is that there seems to be no way to skip the HOME_FINAL_MOVE_START so whilst the home search will be a short move, the system will still move the HOME_POSITION afterwards.

mwinterm wrote: When an index is found the encoder would still reset while the machine being in motion. Unless I would within the HAL-component try to capture the event of the reset instantaneously and artificially generate a 'fake' position signal consistent with the one before the reset


That is exactly what I am proposing for the first index.

(something I would not consider to be very elegant)


It's all just numbers to the computer. The system gets a position update from the Mesa driver once every 1ms, if the HAL component is inserted in the call-list between hm2_xxxx.read and motion-command-handler then the timing is guaranteed and the motion controller will always see the modified result.

The HAL component is going to have to modify the input position to convert it to an absolute position anyway.

I agree that this is feasible...

The LinuxCNC system already has a way to avoid an f-error when the index reset happens on homing, which saves some trouble.

I have seen that there are some measures in place (didn't study them thoroughly though). But I tried using an unmodified LinuxcCNC to just home to the next index found (no distance-coded homing) and the jerky move at the end of the homing happened non-the-less (not necessarily an f-error; f-error seemed only to occur on top when homing with faster speeds). I have the impression that the means in place to avoid the f-error work probably fine for step/dir controlled systems but not so well for velocity controlled systems with direct position measuring like the Mikron. I experimented a bit with it and the only way to reset the offsets without some jerky moves I found so far are when first making sure that the system is not moving before resetting.

The system should be configured for HOME_INDEX_ONLY_START which is set if the latch velocity is non-zero and HOME_INDEX_ENABLE is true. That is probably the appropriate configuration in this case.

That is exactly the configuration I used for the experiment with a single index-pulse described above as well as with the modified homing I used for distance-encoded homing.

What isn't ideal is that there seems to be no way to skip the HOME_FINAL_MOVE_START so whilst the home search will be a short move, the system will still move the HOME_POSITION afterwards.

That is also what I found. However according to the docu linuxcnc.org/docs/html/config/ini-homing...ome_absolute_encoder should cause no final move in my understanding. But this was not the case. Therefore I also modified the homing to skip the final move and adhere to the docu. I considered this to be a bug...

I'm pretty indifferent regarding the distance-coded homing within the LinuxCNC homing routine or within a separate HAL-component. But modifying the Hostmot2 to allow for an index-signal trigger without resetting is basically three lines of code and in my mind simpler than doing the additional fake position math in the HAL-component. However at the moment it is also the only thing that works for me without a jerky move at the end.

Regards,

Marc

PS: ...the only way I could find so far to have an encoder reset during a move without the jerky stuff was by driving the servo directly with a constant voltage during homing. But I doubt that this is the way to go....

mwinterm wrote: I'm pretty indifferent regarding the distance-coded homing within the LinuxCNC homing routine or within a separate HAL-component. But modifying the Hostmot2 to allow for an index-signal trigger without resetting is basically three lines of code and in my mind simpler than doing the additional fake position math in the HAL-component.

Something, somewhere, has to calculate an absolute position from the index spacing. Putting that in the homing code will work fine, but limits the system to one specific version of scale encoding.
Doing it as a HAL component is more modular and flexible, I think. But that is only any good if it works.


HOME_ABSOLUTE_ENCODER can't be used here (with the existing code) as it prevents any axis motion, so no indexes will be found.

PS: ...the only way I could find so far to have an encoder reset during a move without the jerky stuff was by driving the servo directly with a constant voltage during homing. But I doubt that this is the way to go....

If the index-enable signal is fed to the homing code _and_ to the PID component then the system should basically ignore feedback for a thread cycle. This is specifically so that it does not respond to the step change in feedback.

PS: ...the only way I could find so far to have an encoder reset during a move without the jerky stuff was by driving the servo directly with a constant voltage during homing. But I doubt that this is the way to go....

This suggest that the index_enable falling edge -->PID suspend FF1 calculation scheme is not working for some
reason. This normally works fine for velocity mode servos so your disable reset on index workaround is not required.
I have heard of this symptom occasionally but have not determined the exact cause.

That said, I think a better overall index system is to always latch the position on index and have LinuxCNC
use the latched position for its internal offsets and avoid steps in the joint position. This also has the advantage
of being able to use index for a position sanity check. The disadvantage of this method of index handling is
that some encoder counter hardware may only have the option to clear the count on index.

Hi Marc,
Please inform me about the servo motor , encoder , and drives part or model numbers and its specifications if possible.
Best regards,
Heggy

Hello,

another update from our retrofit project...

Y-axis ballscrew issue: I happened to find on ebay the exact ballscrew assembly for my machine in good condition at a price slightly below what I would have paid for the axial bearings only. So we bought that assembly and now have the machine back together.

Distance coded homing: After having the machine back operational we could continue to test distance coded homing and we know can reliably home the machine on all 3 axis! Basically it is just working now without any fuss at all
Currently the modifications I have done to the linuxcnc code are in the hm2 (extended to detect the index-position without resetting) and in the homing procedure itself where an option for distance coded homing was added. Besides a little bug we had to fix the code corresponds to what I posted in 209052 . The exact code can be found in my branch on GitHUB .
It actually took as a while to get it running on the Y-axis which proofed to be unrelated to the code. The problem simply was a cheap d-sub 9 female connector which sometimes didn't transmit the glasscale signal reliably.
Lesson learned: the glasscale signals are definitively delicate and all the shielding an high-quality connectors that come with the Heidenhain originals are there for a reason...
But in the process of debugging this issue the modification to hm2 became very handy as we could use it to check consistency and found that counts were lost sometimes between index-marks. So along the line what @PCW wrote in an earlier post I will keep the modification in the hm2 and implement an additional component for sanity check of the encoder signal.

PID tuning: After the initial quick success we had with the PID tuning process we realized that we are not done yet. While we really could bring the f-error down below 0.002mm with just tuning P, FF1 and FF2 as well as the current offset we found now that just adding some weight in the form of e.g. a vise is affecting our setup significantly. So some more work on PID tuning is need to give that machine a good performance over a wider operating envelop (actually I think the machine is specified for table loads up to 400kg).
I'm currently thinking about writing an optimization procedure in an external python script that would execute the same G-code reference program over and over again, accumulating the integral of the f-error as well as the max and then use some probably gradient based optimization algorithms from scipy to optimize the setup. Could this make sense? Did already someone do something like this?

Best regards,

Marc