- Posts: 112
- Thank you received: 0
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 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 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 to join the conversation.
mwinterm wrote: 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 to join the conversation.
on the same
forum.linuxcnc.org/12-milling/28039-dist...-glasscales-possible
Attachment not found
Please Log in 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 to join the conversation.
andypugh wrote: 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 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 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 to join the conversation.
From here we come into a state waiting until the index mark is found:
After that we would come to the HOME_SET_INDEX_POSITION. This is where I would potentially modify the code something along the way:
Could this make sense?
Regards,
Marc
Please Log in to join the conversation.
