Retrofitting Mikron WF41C: Distance coded homing success

More
13 Apr 2021 15:19 #205805 by gaston48
Replied by gaston48 on topic Retrofitting Mikron WF41C
Exploiting the "distance coded" would be a great challenge

the circuit is an MC 3487 to have RS422 differential outputs immunized against noise
the resolution of ic-nv is 10 X 4 = 0.5 microns.

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

More
13 Apr 2021 16:38 #205810 by mwinterm
Replied by mwinterm on topic Retrofitting Mikron WF41C
We also considered going for differential outputs but thought we should get away without it as the TTL signal lines are relatively short. But we might well add it if we do another iteration of the board.

We didn't try 10x interpolation yet. Did you do any testing if the quality of the grid on the Heidenhain scales is good enough that 10x interpolation (or even higher) can make sense?

Regards,

Marc

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

More
13 Apr 2021 18:36 #205814 by gaston48
Replied by gaston48 on topic Retrofitting Mikron WF41C
At the oscilloscope, the signal is very clean. Even if this does not correspond to real precision,
concerning the control loop, the calculation of the instantaneous speed is more fluid I think.
To avoid noise on the analog inputs, each channel is shielded in a separate box.

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

More
13 Apr 2021 22:05 #205831 by andypugh
Replied by andypugh on topic Retrofitting Mikron WF41C

So the next step now is to find out how we can home the machine using these index signals. It looks to me that the the standard homeing sequences of LinuxCNC are not suited to home glasscales like the LS403C. Any help / suggestions are greatly appreciated.


It would probably be easier to do if you were not using quadrature. (ie, if the absolute position could be sent via serial)

Are the two pulses on the same or different channels?

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

More
14 Apr 2021 07:27 #205856 by gaston48
Attachments:
The following user(s) said Thank You: J Green

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

More
14 Apr 2021 07:47 #205858 by andypugh
Replied by andypugh on topic Retrofitting Mikron WF41C
I think that this can be done with a HAL component, if home-to-index is enabled.

The HAL component would sit between the hm2_ninn.0.encoder-position pin and the joint.N.position-fb pin.
It would take index-enable as an input and output a modified index-enable to the counter.

index-enable -> true, the component sets index-enable on the counter. The counter is zeroed and the component stores the (rawcounts - counts), waits for index-enable from the counter to go false and sets it true again. When that signal is set to false again by the counter the component once more calculates (rawcounts - counts) to calculate the absolute position (10.02, 20, 30.04, 40, 50.06...), and adds that value to the position fed back to the system whilst setting its own index-enable input pin to zero to indicate to the system that homing can complete.
This putative HAL component should run first after hm2_minn.0.read.

I will try to knock something together this lunchtime.
The following user(s) said Thank You: J Green

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

More
14 Apr 2021 08:07 #205861 by andypugh
Replied by andypugh on topic Retrofitting Mikron WF41C

I think that this can be done with a HAL component, if home-to-index is enabled


Or, even better, it could be built-in to the hm2 and software encoder drivers.

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

More
14 Apr 2021 11:50 #205880 by mwinterm
Replied by mwinterm on topic Retrofitting Mikron WF41C
@gaston48: Thank you very much for sharing the Heidenhain document with the formula. Would have saved me from figuring it out
myself but nice to see that my calculation was correct :-)

@andypugh: What you are proposing is the very same I also had in mind (see my old post here: forum.linuxcnc.org/27-driver-boards/4060...rial?start=10#203443). I also already tested it with a little hacked together Python hal-component (I know not really real-time suited, but good enough for what I wanted to try out). I could easily implement this as well in a C++ hal-component. The only thing I'm unclear about is how to do as you stated

and adds that value to the position fed back to the system


I also looked a little more into the LinuxCNC homing source code and it does not look so complicated anymore as I thought initially. So adding there something like a distance-encoded-index option could to my understanding also be feasible.

@andypugh: I'm not sure if I understand your last post correctly:

Or, even better, it could be built-in to the hm2 and software encoder drivers.

Is this because the reset once the index is hit is executed by the hm2 driver? Where would you calculate the position and take the parameters specific to the individual galsscale from? Sorry, I'm not yet very familiar with the whole architecture...

Best regards,

Marc

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

More
14 Apr 2021 12:20 #205883 by andypugh
Replied by andypugh on topic Retrofitting Mikron WF41C
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.

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

More
14 Apr 2021 14:22 #205897 by mwinterm
Replied by mwinterm on topic Retrofitting Mikron WF41C
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:
case HOME_INDEX_SEARCH_START:
		/* This state is called after the machine has made a low
		   speed pass to determine the limit switch location. It
		   sets index-enable, which tells the encoder driver to
		   reset its counter to zero and clear the enable when the
		   next index pulse arrives. */
		/* set the index enable */
		H[joint_num].index_enable = 1;
		/* and move right into the waiting state */
		H[joint_num].home_state = HOME_INDEX_SEARCH_WAIT;
		immediate_state = 1;
		home_do_moving_checks(joint,joint_num);
		break;

From here we come into a state waiting until the index mark is found:
case HOME_INDEX_SEARCH_WAIT:
		/* This state is called after the machine has found the
		   home switch and "armed" the encoder counter to reset on
		   the next index pulse. It continues at low speed until
		   an index pulse is detected, at which point it sets the
		   final home position.  If the move ends or hits a limit
		   before an index pulse occurs, the home is aborted. */
		/* has an index pulse arrived yet? encoder driver clears
		   enable when it does */
		if ( H[joint_num].index_enable == 0 ) {
		    /* yes, stop motion */
		    joint->free_tp.enable = 0;
		    /* go to next step */
		    H[joint_num].home_state = HOME_SET_INDEX_POSITION;
		    immediate_state = 1;
		    break;
		}
		home_do_moving_checks(joint,joint_num);
		break;

After that we would come to the HOME_SET_INDEX_POSITION. This is where I would potentially modify the code something along the way:
case HOME_SET_INDEX_POSITION:
    // nr_ref_marks is 0 at the beginning of the homing sequence
    // distance_coded is a flag indicating that we have distance coded glasscales at hand

    /* 
    - When the first index mark is found homing goes into the if() statement and 
    from there back to search for another index mark. 
    - When the second index mark is found homing goes into the else if() statement 
    and calculates the correct 'home_offset'
    - As state was not changed in the else if() statement homing goes one more time
    into HOME_SET_INDEX_POSITION but this time in to the else section doing the regular
    offset setting
    */

    if(distance_coded && nr_ref_marks < 1) {

        raw_trigger_pos_1 = current_raw_pos - current_pos;
        ++nr_ref_marks;
        H[joint_num].home_state = HOME_INDEX_SEARCH_START; //sent it back to index mark search

    }else if(distance_coded && nr_ref_marks < 2){

        raw_trigger_pos_2 = current_raw_pos - current_pos;
        ++nr_ref_marks;

        // calculate and set the 'home_offset' based on raw_trigger_pos_1, raw_trigger_pos_2 and current_pos

    }else{
        //normal HOME_SET_INDEX_POSITION
    }

Could this make sense?

Regards,

Marc

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

Moderators: piasdom
Time to create page: 0.134 seconds
Powered by Kunena Forum