- Hardware & Machines
- CNC Machines
- Milling Machines
- Retrofitting Mikron WF41C: Distance coded homing success
Retrofitting Mikron WF41C: Distance coded homing success
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.
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.
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.
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.
Attachments:
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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.
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:
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...Or, even better, it could be built-in to the hm2 and software encoder drivers.
Best regards,
Marc
Please Log in or Create an account to join the conversation.
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.
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.
- Hardware & Machines
- CNC Machines
- Milling Machines
- Retrofitting Mikron WF41C: Distance coded homing success