Retrofitting Mikron WF41C: Distance coded homing success

J Green
Offline
Elite Member

06 May 2021 15:00 #208127 by J Green

Replied by J Green on topic Retrofitting Mikron WF41C

Marc
A very BIG THANK YOU for detailing that event ! It will be of much use for those doing future conversions to read an consider .
If it was me -- I would wonder if the axis limit override manual switch circuit was causing the problem , say a mis-wiring .

You questioned the large difference of P.I.D. values from Gaston48 vers your Mikron WF41C machine . I wonder if there is a big difference in " *.ini files (like max speed, acceleration etc) " ?
Would be quite useful if Gaston48 could share his Ini. & Hal. files . More of a let's improve a Wheel instead of the constant invent the Wheel .
The magical almost interconnect cable --- I sadly share that pain .
Best regards
Bob

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

mwinterm
Offline
Senior Member

07 May 2021 07:26 #208183 by mwinterm

Replied by mwinterm on topic Retrofitting Mikron WF41C

Damage update

We checked the ball screw by fixing a 0.001mm dial indicator to the ball screw nut and having it touching on the ball screw thread. Then we turned the ball-screw forth and back and like that we would see any play between ball screw and ball screw nut. The result was mind blowing to me. There was not only zero play, the surface quality of the ball screw is so perfect that the 0.001mm indicator didn't move at all. I hade to touch it several times to make sure that it was actually working. This is really a testimonial about the quality of these machines and also underlines why it is worth to still invest in them with a new control.

Then we removed the whole ball screw assembly from the machine.

Now we could very clearly feel that the bearings in the fixed block were damaged. They made a clear grinding noise when turning the ball screw by hand while as expected after the measurement the ball screw nut was moving smooth like butter.
Sow we further disabled and removed the fixed block. Here the nut that fixed the ball screw to the fixed block (notice the little brass inserts that are worked into the nut and that lock the nut onto the thread when tightening the three set-screws).

And here finally the fixed block with 4 axial trust bearings.

So after the initially excitement that ball-screw and nut were still perfect we got a little surprised when we realized that the 4 axial bearings (being as well super high quality standard) are 200 Euro each. Nevertheless still much cheaper than dealing with a broken ball screw.
Next we have now to make a little custom tool with 4 pins to remove the cap from the fixed block (see first picture) and order the bearings.

Best regards,

Marc

The following user(s) said Thank You: cscegypt

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

cscegypt
Offline
New Member

12 May 2021 07:48 - 15 May 2021 08:09 #208612 by cscegypt

Replied by cscegypt on topic Retrofitting Mikron WF41C

Hi Mark,
Many thanks for your efforts and valuable information. I enjoyed while reading your research and eager to know the results.
You can download the service manual for the TNC 355 via this link , maybe it can help :

www.yumpu.com/en/document/view/18882606/...issioning-heidenhain
Also there are other links for schematics of TNC 355 and also operator manual for mechanical part of the Mikron WF 41 CH
you can retrieve and download it in this website :
www.practicalmachinist.com/vb/deckel-mah...-wf41-c-mill-332906/
here is also the link for electro document of WF41to be downloaded.
drive.google.com/file/d/163tkgEy81i2cP-Rte4XLYW-Tc6Ng5uFe/view
also the schematics of 355 input board:
drive.google.com/file/d/1yUM2iP0Qc3McEn9BFEfq-942jTDPIbTB/view
I hope that you can repair the machine sooner .
Big thank you .
Heggy

Last edit: 15 May 2021 08:09 by cscegypt.

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

mwinterm
Offline
Senior Member

15 May 2021 14:36 #208916 by mwinterm

Replied by mwinterm on topic Retrofitting Mikron WF41C

Hello Heggy,

thank you very much. I already had all the documents in paper form but not electronically. This is very handy!

Regards,

Marc

The following user(s) said Thank You: cscegypt

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

mwinterm
Offline
Senior Member

15 May 2021 15:09 #208918 by mwinterm

Replied by mwinterm on topic Retrofitting Mikron WF41C: Distance Coded Homing

Hello,

We finally started the next step of our retrofit journey which is implementing distance coded homing. I already outlined in earlier posts how I modified the code of LinuxCNC to support it but didn't try it out until very recently.
When trying it out I encountered the following problem:
When I initiate homing the machines starts moving as supposed to. When hitting the first index mark the encoder automatically resets the

hm2_7i92.0.encoder.01.position

This leads to a miss-match between the commanded position and the actual position and results in a jerky move to actually re-establish a match between the two and eventually in a following error.

Not sure how to really solve this problem. I have two approaches in mind:
1. Not setting

hm2_7i92.0.encoder.01.index-enable True

during the index-mark search and instead listening to the

hm2_7i92.0.encoder.01.input-index

pin and try to capture the corresponding encoder raw-position. But if I do my math right I would have to move very slowley (<1mm/sec) to reliably grab the index position.
2. Extending Hostmot2 by a mode that would not reset the encoder when an index-mark is hit but rather write the corresponding position to an output pin.

Any help or suggestions greatly appreciated...

Best regards,

Marc

The following user(s) said Thank You: cscegypt

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

cscegypt
Offline
New Member

15 May 2021 16:08 - 15 May 2021 18:13 #208925 by cscegypt

Replied by cscegypt on topic Retrofitting Mikron WF41C: Distance Coded Homing

Hi Marc,

I just read this paragraph in page 47 of the following link which is belong to Rockwell automation
literature.rockwellautomation.com/idc/gr...tion-rm003_-en-p.pdf
(Since the homing procedure usually requires the machine to be taken
offline and placed in a manual operating mode, for example, not making
product, anything that would require you to rehome one or more axes
on the machine is undesirable. This is downtime and costs money. The
APR feature maintains the machine reference or absolute position
through power cycles, program downloads, and even firmware updates)
Also , I searched Bosch website and found that link:
dc-us.resource.bosch.com/media/us/produc.../USL00010_2015-1.pdf

I wish that will introduce help.
Good luck.
Heggy

Last edit: 15 May 2021 18:13 by cscegypt.

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

andypugh
Offline
Moderator

15 May 2021 23:30 #209006 by andypugh

Replied by andypugh on topic Retrofitting Mikron WF41C: Distance Coded Homing

mwinterm wrote:
When I initiate homing the machines starts moving as supposed to. When hitting the first index mark the encoder automatically resets the
hm2_7i92.0.encoder.01.position
This leads to a miss-match between the commanded position and the actual position and results in a jerky move to actually re-establish a match between the two and eventually in a following error.

This was why I was suggesting an intermediate HAL component that would pass through a modified version of the encoder position.

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

mwinterm
Offline
Senior Member

16 May 2021 08:24 #209052 by mwinterm

Replied by mwinterm on topic Retrofitting Mikron WF41C: Distance Coded Homing

Hello Andy,

while I don't dismiss a separate HAL-component (I just tested the modified home procedure first as I already implemented it) I don't understand how it would help with my current problem. 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 (something I would not consider to be very elegant) I still would experience the same behavior. Maybe I'm missing something here....

However in the meantime I have modified the Hostmot2. I added a flag

hm2_7i92.0.encoder.01.reset-on-index

which is set to 1 by default to be consistent with the original implementation. Further I added an output parameter

hm2_7i92.0.encoder.01.index-rawcounts

I basically modified the following code in encoder.c (look for *** in the comment)

if (0 == (latch_ctrl & HM2_ENCODER_LATCH_ON_INDEX)) {
            // hm2 reports index event occurred

            rtapi_u16 latched_count;

            latched_count = (latch_ctrl >> 16) & 0xffff;

            reg_count_diff = (rtapi_s32)latched_count - (rtapi_s32)e->prev_reg_count;
            if (reg_count_diff > 32768) reg_count_diff -= 65536;
            if (reg_count_diff < -32768) reg_count_diff += 65536;

            //***Added if-statement to reset the offset only when hal.pin.reset_on_index is true (default)
            if(*e->hal.pin.reset_on_index){
                e->zero_offset = prev_rawcounts + reg_count_diff;
            }
           //***Additionally always setting the rawcounts of the last index-position to pin.index_rawcounts
            *e->hal.pin.index_rawcounts = prev_rawcounts; 
            *e->hal.pin.index_enable = 0;
        }

The

if(*e->hal.pin.reset_on_index){ ... }

causes the count and position not to be modfied if

hm2_7i92.0.encoder.01.reset-on-index

is 0.
The

*e->hal.pin.index_rawcounts = prev_rawcounts;

is always set to rawcounts value corresponding to the last index signal encountered.
Like that I was able to have the first successful distance-coded homing routines executed which delivered what seemed to be reasonable results

However some more testing and detailed verifying is still needed.

Best regards,

Marc

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

andypugh
Offline
Moderator

16 May 2021 10:26 #209061 by andypugh

Replied by andypugh on topic Retrofitting Mikron WF41C: Distance Coded Homing

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.

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

mwinterm
Offline
Senior Member

16 May 2021 12:23 #209085 by mwinterm

Replied by mwinterm on topic Retrofitting Mikron WF41C: Distance Coded Homing

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

HOME_ABSOLUTE_ENCODER = 2

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....

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

Moderators: piasdom

Time to create page: 0.163 seconds

Retrofitting Mikron WF41C: Distance coded homing success

Attachments: