Retrofitting Mikron WF41C: Distance coded homing success

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

Hello Heggy,

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

Regards,

Marc

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 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 during the index-mark search and instead listening to the 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

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

mwinterm wrote: When I initiate homing the machines starts moving as supposed to. When hitting the first index mark the encoder automatically resets the

Code:

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.

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 which is set to 1 by default to be consistent with the original implementation. Further I added an output parameter I basically modified the following code in encoder.c (look for *** in the comment)
The causes the count and position not to be modfied if is 0.
The 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