Homing on Linear Scale Index
21 Feb 2019 18:18 #126868
by dswanson
Homing on Linear Scale Index was created by dswanson
I have linear scales on the X,Y, and Z axes. There is a reference mark in the center of the scale, I want to use this mark as my home position.
I currently have homing set up with HOME_LATCH_VEL and USE_INDEX = YES. The marks are being detected properly, but there are two problems:
1. Since the mark is in the center of travel, you have to start on the correct side of the table.
2. The movement is quite slow, so if it is not positioned close, there can be quite a long wait.
What i would like to do is move to a limit switch at a reasonable speed, back off nearly half the table travel, and then go into a slow crawl as I search for the index mark.
Wondering what the best way to do this may be, or if I am overlooking a simpler method.
I currently have homing set up with HOME_LATCH_VEL and USE_INDEX = YES. The marks are being detected properly, but there are two problems:
1. Since the mark is in the center of travel, you have to start on the correct side of the table.
2. The movement is quite slow, so if it is not positioned close, there can be quite a long wait.
What i would like to do is move to a limit switch at a reasonable speed, back off nearly half the table travel, and then go into a slow crawl as I search for the index mark.
Wondering what the best way to do this may be, or if I am overlooking a simpler method.
Please Log in or Create an account to join the conversation.
22 Feb 2019 00:10 #126884
by PCW
Replied by PCW on topic Homing on Linear Scale Index
1. The search for home switch should get you there (assuming you have a home switch) you need to set the HOME_SEARCH_VELOCITY
2. Assuming you have a hardware encoder counter, You can set the index search velocity to anything you like (no danger of over running into hard stop if index is in the middle)
A faster way would be to have a flag for the home switch that was 1/2 of the travel so you have a 1 bit abs encoder so LinuxCNC always knows which way to go to get to the center
2. Assuming you have a hardware encoder counter, You can set the index search velocity to anything you like (no danger of over running into hard stop if index is in the middle)
A faster way would be to have a flag for the home switch that was 1/2 of the travel so you have a 1 bit abs encoder so LinuxCNC always knows which way to go to get to the center
The following user(s) said Thank You: dswanson
Please Log in or Create an account to join the conversation.
22 Feb 2019 08:00 #126895
by Hakan
Replied by Hakan on topic Homing on Linear Scale Index
So the precision of the home position is not dependent of the index search speed? Using 7i85+7i76e.
Please Log in or Create an account to join the conversation.
22 Feb 2019 14:06 #126910
by PCW
Replied by PCW on topic Homing on Linear Scale Index
No, if you are using "home to index", the raw scale count is latched at the physical index
in hardware (so independent of speed) and used by LinuxCNC to offset the position
in hardware (so independent of speed) and used by LinuxCNC to offset the position
Please Log in or Create an account to join the conversation.
26 Feb 2019 21:40 #127197
by andypugh
If you can arrange for a home switch sensor to be off in one half of the table and on in the other (for example a proximity sensor and a long target) then homing will either do a search and latch or go straight to latch. If those are in opposite directions than it will work on either side.
Replied by andypugh on topic Homing on Linear Scale Index
1. Since the mark is in the center of travel, you have to start on the correct side of the table..
If you can arrange for a home switch sensor to be off in one half of the table and on in the other (for example a proximity sensor and a long target) then homing will either do a search and latch or go straight to latch. If those are in opposite directions than it will work on either side.
Please Log in or Create an account to join the conversation.
26 Feb 2019 23:50 #127213
by rodw
This is absolutely the way to go. A strip of metal half the length of the table and a prox sensor might be an easy solution. The metal strip just needs to be thicker than the maximum sensing distance of the proximity sensor so it can't see any metal the strip is attached to. 5mm works on my machine...
Replied by rodw on topic Homing on Linear Scale Index
1. Since the mark is in the center of travel, you have to start on the correct side of the table..
If you can arrange for a home switch sensor to be off in one half of the table and on in the other (for example a proximity sensor and a long target) then homing will either do a search and latch or go straight to latch. If those are in opposite directions than it will work on either side.
This is absolutely the way to go. A strip of metal half the length of the table and a prox sensor might be an easy solution. The metal strip just needs to be thicker than the maximum sensing distance of the proximity sensor so it can't see any metal the strip is attached to. 5mm works on my machine...
Please Log in or Create an account to join the conversation.
- Richard J Kinch
-
- Offline
- Senior Member
-
Less
More
- Posts: 61
- Thank you received: 4
27 Feb 2019 23:38 - 28 Feb 2019 00:34 #127299
by Richard J Kinch
Replied by Richard J Kinch on topic Homing on Linear Scale Index
Please see my post
Precision automatic homing using an independent DRO scale index
.
You likely don't need any hardware as the others are suggesting, just HAL magic.
The reason for the unreasonably slow crawl working is that LinuxCNC is peculiar, not recognizing anything but a step function switch, not an impulse function with a falling edge like a scale index. By crawling at an some agonizingly slow speed, the peculiarity happens to stop before crossing the falling edge of the impulse, as if it were a step function. But given a typical 5 micron pulse width in an optical scale, "slow speed" is going to result in poor performance, or be impossible if your motor steps are more than 5 microns.
But with HAL you can turn the impulse function into a step function, and then the peculiar LinuxCNC logic works at reasonable speeds. Details are in my post referenced above. This is a workaround that works at base-thread or servo-thread rates, so it can only find and stretch in index pulse that is traversed in 2 or more {base,servo}-thread cycles per Nyquist. But that gets you higher traversing speeds, limited only by the thread rate Nyquist limit.
Software cannot solve the predicament of motor step size (servo resolution) exceeding the half the pulse width. In that case you would have to add hardware logic (D flipflop connected as a divider) between the scale index signal and the PC input. It's a case of resolution limits and detection. If your mechanism resolves D, you can reliably detect impulses only that are 2D wide or larger. If your mechanical step size is, say, 0.001in, you can't possibly detect a 5 micron (0.0002in) index reliably, or both edges at all. If you process the impulse into a step function, then you will always detect it, but at best to an accuracy of twice the mechanical step size. Step and detection rates also apply, so the speed has to also honor those limits.
I consider this peculiarity a deficiency-bug in LinuxCNC due to its non-theory of adaptive positioning, but others dispute my conclusion. The post discussion turned into my elaborate critique versus defenders of, and apologists for, the peculiarity. If you happen to have a machine with switches that's been working all along, then you might also deny the peculiarity of it, which I suppose is reasonable. I don't understand why using a linear scale index for homing provokes hostility, as if switches were ideal.
You likely don't need any hardware as the others are suggesting, just HAL magic.
The reason for the unreasonably slow crawl working is that LinuxCNC is peculiar, not recognizing anything but a step function switch, not an impulse function with a falling edge like a scale index. By crawling at an some agonizingly slow speed, the peculiarity happens to stop before crossing the falling edge of the impulse, as if it were a step function. But given a typical 5 micron pulse width in an optical scale, "slow speed" is going to result in poor performance, or be impossible if your motor steps are more than 5 microns.
But with HAL you can turn the impulse function into a step function, and then the peculiar LinuxCNC logic works at reasonable speeds. Details are in my post referenced above. This is a workaround that works at base-thread or servo-thread rates, so it can only find and stretch in index pulse that is traversed in 2 or more {base,servo}-thread cycles per Nyquist. But that gets you higher traversing speeds, limited only by the thread rate Nyquist limit.
Software cannot solve the predicament of motor step size (servo resolution) exceeding the half the pulse width. In that case you would have to add hardware logic (D flipflop connected as a divider) between the scale index signal and the PC input. It's a case of resolution limits and detection. If your mechanism resolves D, you can reliably detect impulses only that are 2D wide or larger. If your mechanical step size is, say, 0.001in, you can't possibly detect a 5 micron (0.0002in) index reliably, or both edges at all. If you process the impulse into a step function, then you will always detect it, but at best to an accuracy of twice the mechanical step size. Step and detection rates also apply, so the speed has to also honor those limits.
I consider this peculiarity a deficiency-bug in LinuxCNC due to its non-theory of adaptive positioning, but others dispute my conclusion. The post discussion turned into my elaborate critique versus defenders of, and apologists for, the peculiarity. If you happen to have a machine with switches that's been working all along, then you might also deny the peculiarity of it, which I suppose is reasonable. I don't understand why using a linear scale index for homing provokes hostility, as if switches were ideal.
Last edit: 28 Feb 2019 00:34 by Richard J Kinch.
Please Log in or Create an account to join the conversation.
28 Feb 2019 10:41 #127316
by andypugh
Using linear scale index for homing is an excellent idea. And it is well supported by LinuxCNC.
I have tried to explain how this is handled but you appear to not be willing to understand.
As you have noted, a scale index is too short to be reliably detected in the 1mS servo thread. And, also, the system is likely to move some significant distance after the index before the servo thread can act on the information.
For this reason LinuxCNC expects the index to be detected by an encoder counter (typically in the hardware of an interface card, potentially a base-thread software counter if the speed and index pulse size allow).
LinuxCNC will set (in the servo thread) the index-enable for the servo counter. The servo counter will then watch for index, zero the position at the index, reset the index-enable HAL pin and then continue counting.
At the next servo-thread interval the system notes the reset of the index-enable, captures the encoder position and uses that to calculate the exact home position relative to the current axis position.
A switch is useful to ensure that the correct index is used or to know which direction to travel to find the index. And that is what I was suggesting to the original poster in this thread.
It isn't a design choice by LinuxCNC to not be able to detect very short pulses at high speeds. You see to be keen to keep name-dropping Nyquist, perhaps you can explain how a 1mS realtime thread can be expected to detect a 1um pulse at high axis speed?
That is why LinuxCNC anticipates index detection to be handled by one of the many high-speed interface cards that are supported.
Replied by andypugh on topic Homing on Linear Scale Index
I don't understand why using a linear scale index for homing provokes hostility, as if switches were ideal.
Using linear scale index for homing is an excellent idea. And it is well supported by LinuxCNC.
I have tried to explain how this is handled but you appear to not be willing to understand.
As you have noted, a scale index is too short to be reliably detected in the 1mS servo thread. And, also, the system is likely to move some significant distance after the index before the servo thread can act on the information.
For this reason LinuxCNC expects the index to be detected by an encoder counter (typically in the hardware of an interface card, potentially a base-thread software counter if the speed and index pulse size allow).
LinuxCNC will set (in the servo thread) the index-enable for the servo counter. The servo counter will then watch for index, zero the position at the index, reset the index-enable HAL pin and then continue counting.
At the next servo-thread interval the system notes the reset of the index-enable, captures the encoder position and uses that to calculate the exact home position relative to the current axis position.
A switch is useful to ensure that the correct index is used or to know which direction to travel to find the index. And that is what I was suggesting to the original poster in this thread.
It isn't a design choice by LinuxCNC to not be able to detect very short pulses at high speeds. You see to be keen to keep name-dropping Nyquist, perhaps you can explain how a 1mS realtime thread can be expected to detect a 1um pulse at high axis speed?
That is why LinuxCNC anticipates index detection to be handled by one of the many high-speed interface cards that are supported.
The following user(s) said Thank You: tommylight, Clive S
Please Log in or Create an account to join the conversation.
28 Feb 2019 10:44 - 28 Feb 2019 10:44 #127317
by rodw
Replied by rodw on topic Homing on Linear Scale Index
I have to agree with Andy to some extent. We are not attacking you. But if you follow the
Homing configuration
docs
You can still home to an index but you don't need to crawl to find it. You can sprint or jog even.
This would work particularly well for the OP as he only has one index mark.
Please take the time to review this diagram taken from the link above
Have you actually tried this? How can this differ in finding the index mark then your method (other than being faster and not needing to "wrangle" the axis manually)?. Its the final move to the index that counts.
You can still home to an index but you don't need to crawl to find it. You can sprint or jog even.
This would work particularly well for the OP as he only has one index mark.
Please take the time to review this diagram taken from the link above
Have you actually tried this? How can this differ in finding the index mark then your method (other than being faster and not needing to "wrangle" the axis manually)?. Its the final move to the index that counts.
Attachments:
Last edit: 28 Feb 2019 10:44 by rodw.
Please Log in or Create an account to join the conversation.
28 Feb 2019 17:44 #127345
by dswanson
Replied by dswanson on topic Homing on Linear Scale Index
I did manage to get homing working by traveling to a limit switch and then proceeding to the index mark. I am using a 6i25 and 7i85s, so it is good to know that it is a hardware reset.
I did some testing to verify how good the hardware counter reset for homing works. It is quite good. I tested velocities from 1mm/s to 16.6mm/s by zeroing a length gauge at home on the Y axis, and checking the repeatability. Placed the raw data below for anyone interested. Encoder pulses occur over .0001mm, so there are 10 to 166 encoder counts per 1ms servo period. Was interesting that higher velocities homed more consistently, so I am willing to attribute the variation to dynamics of the table itself and not the homing count. (not sure why all the measurements were biased after the original setting of zero)
1 mm/s -.0026 -.0023 -.0022
3 mm/s -.0020 -.0019 -.0020
5 mm/s -.0019 -.0019 -.0020
10 mm/s -.0016 -.0017 -.0017
16.6 mm/s -.0017 -.0016 -.0016
I like the idea of a home switch that is on for half of the table travel, but won't be doing that (at least for now), since space is constrained and this works well.
Thank you all for your help.
I did some testing to verify how good the hardware counter reset for homing works. It is quite good. I tested velocities from 1mm/s to 16.6mm/s by zeroing a length gauge at home on the Y axis, and checking the repeatability. Placed the raw data below for anyone interested. Encoder pulses occur over .0001mm, so there are 10 to 166 encoder counts per 1ms servo period. Was interesting that higher velocities homed more consistently, so I am willing to attribute the variation to dynamics of the table itself and not the homing count. (not sure why all the measurements were biased after the original setting of zero)
1 mm/s -.0026 -.0023 -.0022
3 mm/s -.0020 -.0019 -.0020
5 mm/s -.0019 -.0019 -.0020
10 mm/s -.0016 -.0017 -.0017
16.6 mm/s -.0017 -.0016 -.0016
I like the idea of a home switch that is on for half of the table travel, but won't be doing that (at least for now), since space is constrained and this works well.
Thank you all for your help.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
Time to create page: 0.322 seconds