lathe spindle encoder

[russell gower]

Hi,

  I'm trying to use a BBB to drive a small lathe, Based on initial testing I don't think I'm going to have any problems driving the steppers (using Gecko drivers) but does anyone have any examples of interfacing a quadrant encoder with index?

Regards

  Russell

[Charles Steinkuehler]

There is currently (minimal) support for encoders in the PRU code, it
should work mostly like the hm2 encoders (that's the intent, anyway),
but the PRU task period will currently limit the maximum pulse rate that
can be tracked. I've tested basic counting, but I don't have any
encoders with index support, so that might have some problems. If you
start playing with this, report back, and I can try to fix the problems
that will likely come up with using the index mode.

The BBB also has three hardware encoder inputs, one of which can be used
w/o messing up most of the other critical pins (eMMC and HDMI), but
AFAIK no one has yet written a HAL driver.

--
Charles Steinkuehler
cha...@steinkuehler.net

[russell gower]

Hi Charles,

  I'm struggling to work out which pins to specify in the hal file to configure the pru encoder, I have my spindle encoder connected to a BrBoPR board as follows

  J9 Encoder Z, J10 Encoder A, J11 Encoder B.

Do you have an example hal file I could look at?

Regards

  Russell 

[russell gower]

Hi,

  I've been struggling with this for a few hours now and am getting no where, I just can't figure out how to enable the pru encoder component, if i add num_encoders=1 to the ini file then /var/log/debug "reports num_encoders: 1" but it crashes shortly afterwards, these are the last few entries in that log

Nov 23 14:58:19 lathe msgd:0: hal_lib:7383:rt Init encoder

Nov 23 14:58:19 lathe msgd:0: hal_lib:7383:rt hpg_encoder_init

Nov 23 14:58:19 lathe msgd:0: hal_lib:7383:rt malloc: hpg_encoder_instance_t = 0xb6766320

Nov 23 14:58:19 lathe msgd:0: hal_lib:7383:rt malloc: hpg_encoder_channel_instance_t = 0xb6766348

Nov 23 14:58:25 lathe msgd:0: normal shutdown - global segment detached

 
this learning curve is really step for me, I'm probably missing something obvious but I really appreciate any help I can get right now :-)

Regards

  Russell

[Charles Steinkuehler]

On 11/23/2014 9:10 AM, russell gower wrote:
> Hi,

> I've been struggling with this for a few hours now and am getting no
> where, I just can't figure out how to enable the pru encoder component, if
> i add num_encoders=1 to the ini file then /var/log/debug "reports
> num_encoders: 1" but it crashes shortly afterwards, these are the last few
> entries in that log

Unless you built from source and modified the names of the encoder HAL
pins, the PRU encoder won't work. The hal_pru_generic prefix makes the
resulting HAL names long enough that when truncated to the maximum HAL
name length several pin names collide, HAL doesn't properly load, and
everything comes crashing down.

If you're up to building from source, there's details on the required
changes in the list archives.

--
Charles Steinkuehler
cha...@steinkuehler.net

[russell gower]

Thanks, I've found the archive post so that side of it should be straight forward for me, I'm not new to building from source i fact I do it all the time, i've just never done it on a BBB before, whats the best way to attack it - cross compile or native? 

Thanks

  Russell

[Charles Steinkuehler]

On 11/23/2014 9:50 AM, russell gower wrote:
> Thanks, I've found the archive post so that side of it should be straight
> forward for me, I'm not new to building from source i fact I do it all the
> time, i've just never done it on a BBB before, whats the best way to attack
> it - cross compile or native?

Best way?

Commit a pull-request and let the build-bot take care of it! :)

You can't truly cross-compile the code at the moment, so building on an
x86 machine means running under QEMU, which is about a wash vs. building
on the BeagleBone. If you've got a powerful ARM board (CuBox,
WandBoard, etc), you can natively compile on that, otherwise just build
it native on the 'bone.

...or if you'd like, I encourage you to send a PR. I planned on adding
a local variable to use for the prefix replacing all the
hpg->config.name entries in the encoder file:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/encoder.c#L233

So something like:

char prefix[];

// Default prefix is too long
// prefix = hpg->config.name;
prefix = "hpg";

WARNING:
Above is untested and my C coding skills are rusty (especially string
and pointer manipulations), so adjust as required. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[andy pugh]

On 23 November 2014 at 16:00, Charles Steinkuehler

<cha...@steinkuehler.net> wrote:
> If you've got a powerful ARM board (CuBox,
> WandBoard, etc), you can natively compile on that, otherwise just build
> it native on the 'bone.

As a reference point the quad-core Udoo can compile the Xemomai kernel
in about 20 minutes.
I don't know if that is sow or fast.


--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Charles Steinkuehler]

On 11/23/2014 10:32 AM, andy pugh wrote:
> On 23 November 2014 at 16:00, Charles Steinkuehler
> <cha...@steinkuehler.net> wrote:
>> If you've got a powerful ARM board (CuBox,
>> WandBoard, etc), you can natively compile on that, otherwise just build
>> it native on the 'bone.
>
> As a reference point the quad-core Udoo can compile the Xemomai kernel
> in about 20 minutes.
> I don't know if that is sow or fast.

It's significantly faster than the 'Bone, anyway. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[russell gower]

Hi Charles,

  I've managed to make some progress in as much as I can now enable the encoder (once I've got it all working I'll raise a pull request).

I'm now struggling with the physical hook up, would you mind sharing the steps to recreate your youtube encoder demonstration?

Regards

  Russell

[Charles Steinkuehler]

On 11/24/2014 2:43 PM, russell gower wrote:
> Hi Charles,
> I've managed to make some progress in as much as I can now enable the
> encoder (once I've got it all working I'll raise a pull request).
>
> I'm now struggling with the physical hook up, would you mind sharing the
> steps to recreate your youtube encoder demonstration?

I just wired the encoder directly to the BBB pins. I was lucky the
encoder I used would run off 3.3V, so I didn't need level translators or
anything.

You *DO* have to setup the pins as direct PRU inputs, however. I did
this by loading the universal cape overlay and using the config-pin
utility to put the pins I was using into direct PRU input mode. Make
sure the pins and the PRU core you use both match (there are two sets of
PRU direct I/O pins, you need to enable the pins for the PRU core you're
using to run the code).

--
Charles Steinkuehler
cha...@steinkuehler.net

[karl....@gmx.de]

Hi Russell,
I installed the latest machinekit package with your support for the eQEP encoders. I am not terribly knowledgeable about the device tree system, so my question is if I can connect the encoder signals (3.3V) directly to P9-41 (index eQEP0), P9-25 (strobe) P9-42 (Phase A) P9-27 (Phase B) or do I have to make changes to the setup.sh script or anything else (I am using a Xylotex DB26 cape using the Xylotex config files, modified for my small lathe).
Thanks,
Karl

[Charles Steinkuehler]

On 12/14/2014 11:28 AM, karl....@gmx.de wrote:
> Hi Russell,
> I installed the latest machinekit package with your support for the eQEP
> encoders. I am not terribly knowledgeable about the device tree system, so
> my question is if I can connect the encoder signals (3.3V) directly to
> P9-41 (index eQEP0), P9-25 (strobe) P9-42 (Phase A) P9-27 (Phase B) or do I
> have to make changes to the setup.sh script or anything else (I am using a
> Xylotex DB26 cape using the Xylotex config files, modified for my small
> lathe).

If you're using my universal overlay, you don't have to mess with any
device tree files. You should be able to simply use the config-pin
utility to set the pin mux values, probably in setup.sh. You'd want
something like:

config-pin -f - << EOF
P9.25 qep
P9.27 qep
P9.41 in
P9.91 qep # Pin 41.1
P9.42 in
P9.92 qep # Pin 42.1
EOF

You'll also need to enable the encoder hardware, which the universal
overlay isn't doing yet (the eQEP drivers weren't in the kernel when I
wrote the overlay...I'll need to add support for them). For now, just
use the bone_eqep0 overlay as usual (echo to the slots file).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Karl Jacobs]

Am 14.12.2014 um 18:38 schrieb Charles Steinkuehler:
>
> If you're using my universal overlay, you don't have to mess with any
> device tree files. You should be able to simply use the config-pin
> utility to set the pin mux values, probably in setup.sh. You'd want
> something like:
>
> config-pin -f - << EOF
> P9.25 qep
> P9.27 qep
> P9.41 in
> P9.91 qep # Pin 41.1
> P9.42 in
> P9.92 qep # Pin 42.1
> EOF
>
> You'll also need to enable the encoder hardware, which the universal
> overlay isn't doing yet (the eQEP drivers weren't in the kernel when I
> wrote the overlay...I'll need to add support for them). For now, just
> use the bone_eqep0 overlay as usual (echo to the slots file).
>

Just to see if I (newbie) got the hang of it: for QEP1 the config-pin
would be

config-pin -f - << EOF
P8.31 qep
P8.32 qep
P8.33 qep
P8.35 qep
EOF
Simpler because there is no "double" pin 41 involved, but may conflict
with hdmi. P9.41 is used as "Home A"-axis input on the Xylotex DB26
cape, so I guess I could use that input (which I don't need) to feed the
index pulse to eQEP0. I still have to climb the learning curve.
Karl

[Karl Jacobs]

Am 14.12.2014 um 18:38 schrieb Charles Steinkuehler:

> On 12/14/2014 11:28 AM, karl....@gmx.de wrote:
>> Hi Russell,
>> I installed the latest machinekit package with your support for the eQEP
>> encoders. I am not terribly knowledgeable about the device tree system, so
>> my question is if I can connect the encoder signals (3.3V) directly to
>> P9-41 (index eQEP0), P9-25 (strobe) P9-42 (Phase A) P9-27 (Phase B) or do I
>> have to make changes to the setup.sh script or anything else (I am using a
>> Xylotex DB26 cape using the Xylotex config files, modified for my small
>> lathe).
>

I would like to be able to operate the eQEP in counter mode (Phase A =
clock, Phase B = direction). As far as I understand the code, this would
mean to change line 333 of hal_arm335xQEP.c to: eqep->eqep_reg->QDECCTL
= QAP | QBP | QIP | QSRC0
Can you confirm that?
If that is true, there could be an additional hal pin similar to the
linuxcnc encoder hal-pin "encoder.N.counter-mode bit rw".
Karl

[Russell Gower]

Hi,
Yes i believe that is the case, I didn’t implement this originally because I didn’t have that sort of encoder to test with, but thinking about it I could have just used two push buttons, also the 3 polarity bits should also be added as hal pins.

I’m currently in the process of building my control enclosure, so it will be a few days before I can fire up the BBB again to look at this.

Regards
Russell

[Karl Jacobs]

Am 15.12.2014 um 17:36 schrieb Russell Gower:
>> I would like to be able to operate the eQEP in counter mode (Phase
>> A = clock, Phase B = direction). As far as I understand the code,
>> this would mean to change line 333 of hal_arm335xQEP.c to:
>> eqep->eqep_reg->QDECCTL = QAP | QBP | QIP | QSRC0
>>> Can you confirm that? If that is true, there could be an
>>> additional hal pin similar to the linuxcnc encoder hal-pin
>>> "encoder.N.counter-mode bit rw". Karl
>>>
> Hi, Yes i believe that is the case, I didn’t implement this
> originally because I didn’t have that sort of encoder to test with,
> but thinking about it I could have just used two push buttons, also
> the 3 polarity bits should also be added as hal pins.
>
> I’m currently in the process of building my control enclosure, so it
> will be a few days before I can fire up the BBB again to look at
> this.
>
> Regards Russell

Hi Russel,
studying your code I stumbled over the code for the index event:
/* check if an index event has occured */
if( *(eqep->index_ena) && (iflg & IEL)) {
eqep->index_count = eqep->eqep_reg->QPOSILAT;
}
in which you do not set index_ena to zero (this is connected to the HAL
pin index-enable). The code in teh software encoder in
hal/components/encoder.c does that:
/* handle index */
if ( buf->index_detected ) {
buf->index_detected = 0;
cntr->index_count = buf->index_count;
*(cntr->index_ena) = 0;
}

and I imagined it had to be reset because of what linuxcnc motion needs:
"motion.spindle-index-enable I/O BIT
For correct operation of spindle synchronized moves, this signal must be
hooked to the index-enable pin of the spindle encoder"
and linuxcnc encoder says: "encoder.N.index-enable bit i/o
When true, counts and position are reset to zero on the next rising edge
of Phase-Z. At the same time, index-enable is reset to zero to indicate
that the rising edge has occurred". I am guessing that motion sets it
back to 1 to catch the next index? Or does motion set it to 0 as well?
Then *(cntr->index_ena) = 0; would be superfluous of course, but then I
wonder why index-enable is a hal io and not just input.
Sorry if I am showing total ingorance here, but I did hook up the
standard linuxcnc software encoder that way and it works with correct
indexing (and it does not work without that net connection). I have not
yet tested your code yet, I have to admit.
Cheers,
Karl

[Russell Gower]

Hi Karl,
No your right, I seam to have missed place that bit of code when I refactored the code from the individual capture and update functions I initially wrote.

I’ve finished mounting the steppers and encoder on my lathe but I still need to finish the control box, I cut out and folded the panels last night, next job is to mount the Gecko drivers on the heat sink and then wire it all up, I hope to be in a position to test thread cutting on Sunday, I’ll wait until after that until I submit another pull request so I can be relatively confident it’s all working correctly.

Regards
Russell

[Karl Jacobs]

Hi Russel,
I got the eQEP working in counter mode by adding a hal pin
"counter-mode" hooked to a new variable eqep->counter_mode and adding
if(*(eqep->counter_mode)) {
eqep->eqep_reg->QDECCTL |= QSRC0; /*set to counter mode if hal
pin set*/
}
to the update function loop. In the init-code I set the XCR bit in
QDECCTL, otherwise the counter will count both signal edges. For people
working with position-scale = 1.0 (as I do with one pulse per rev), you
should add eqep->scale = 1.0; in the init function, otherwise the
variable will stay at zero if you never change the position-scale from 1.0.
Contrary to what Charles suggested,I did not load the bone_eqep0 overlay
but just set the qep pins with config-pin like he said. If I load the
bone_eqep0 overlay, the system crashes.
One more thing I had to do on my Xylotex BBB_DB25 board is to remove the
large capacitance at the LVC541 buffer input that I used to drive the
eQEP-clock input with. Otherwise it stops counting at higher rev's
because the pulses get smeared out.
On second thought, due the slow 1ms servo-thread triggering the update
function, the hardware QEP does not give you an advantage over the
software encoder in terms of index position accuracy, which is important
for e.g. threading. You might be missing the index pulse by 1ms max.
which means a 6 degree rotation angle at 1000 rev/min (60msec per rev, 1
ms corresponding to 1/60 of a full rotation = 6 degrees). Do you agree?
Thanks for your great code!
Cheers,
Karl

[Charles Steinkuehler]

On 12/30/2014 12:04 PM, Karl Jacobs wrote:
>
> Hi Russel,
> I got the eQEP working in counter mode by adding a hal pin
> "counter-mode" hooked to a new variable eqep->counter_mode and adding
> if(*(eqep->counter_mode)) {
> eqep->eqep_reg->QDECCTL |= QSRC0; /*set to counter mode if hal
> pin set*/
> }
> to the update function loop. In the init-code I set the XCR bit in
> QDECCTL, otherwise the counter will count both signal edges. For people
> working with position-scale = 1.0 (as I do with one pulse per rev), you
> should add eqep->scale = 1.0; in the init function, otherwise the
> variable will stay at zero if you never change the position-scale from 1.0.
> Contrary to what Charles suggested,I did not load the bone_eqep0 overlay
> but just set the qep pins with config-pin like he said. If I load the
> bone_eqep0 overlay, the system crashes.

Probably because I've enabled the encoders in the latest version of the
universal cape:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L1731-L1784

> One more thing I had to do on my Xylotex BBB_DB25 board is to remove the
> large capacitance at the LVC541 buffer input that I used to drive the
> eQEP-clock input with. Otherwise it stops counting at higher rev's
> because the pulses get smeared out.
> On second thought, due the slow 1ms servo-thread triggering the update
> function, the hardware QEP does not give you an advantage over the
> software encoder in terms of index position accuracy, which is important
> for e.g. threading. You might be missing the index pulse by 1ms max.
> which means a 6 degree rotation angle at 1000 rev/min (60msec per rev, 1
> ms corresponding to 1/60 of a full rotation = 6 degrees). Do you agree?
> Thanks for your great code!

The hardware is supposed to capture the position at the time of the
index pulse, so when the HAL code runs it should be able to read both
the position when the index pulse occurred and the current position
(which might be up to 1 mS removed in time from when the index occurred).

I'm glad to see people starting to use the hardware encoders, keep us
updated on the progress!

--
Charles Steinkuehler
cha...@steinkuehler.net

[Russell Gower]

>>
> Hi Russel,
> I got the eQEP working in counter mode by adding a hal pin "counter-mode" hooked to a new variable eqep->counter_mode and adding
> if(*(eqep->counter_mode)) {
> eqep->eqep_reg->QDECCTL |= QSRC0; /*set to counter mode if hal pin set*/
> }
> to the update function loop. In the init-code I set the XCR bit in QDECCTL, otherwise the counter will count both signal edges. For people working with position-scale = 1.0 (as I do with one pulse per rev), you should add eqep->scale = 1.0; in the init function, otherwise the variable will stay at zero if you never change the position-scale from 1.0.
> Contrary to what Charles suggested,I did not load the bone_eqep0 overlay but just set the qep pins with config-pin like he said. If I load the bone_eqep0 overlay, the system crashes.
> One more thing I had to do on my Xylotex BBB_DB25 board is to remove the large capacitance at the LVC541 buffer input that I used to drive the eQEP-clock input with. Otherwise it stops counting at higher rev's because the pulses get smeared out.
> On second thought, due the slow 1ms servo-thread triggering the update function, the hardware QEP does not give you an advantage over the software encoder in terms of index position accuracy, which is important for e.g. threading. You might be missing the index pulse by 1ms max. which means a 6 degree rotation angle at 1000 rev/min (60msec per rev, 1 ms corresponding to 1/60 of a full rotation = 6 degrees). Do you agree?
> Thanks for your great code!
> Cheers,
> Karl

Hi Karl,
As per Charles is email, the hardware latches the current position into QPOSILAT when the event occurs, then the update function uses that to update index_count so that the HAL sees how far the position has changed since the event, but I don’t think thats going to help you if you’ve only got one pulse per revolution, I’ve added a slotted disk with 90 slots (one of which is longer than the others) and 3 optical slot sensors to the spindle on my lathe so I have 360 pulses per revolution.

I’ve added counter_mode, but i’ve done it like this

/* has counter_mode been changed? */
if ( *(eqep->counter_mode) != eqep->old_counter_mode ) {
eqep->eqep_reg->QDECCTL ^= QSRC0;
eqep->old_counter_mode = *(eqep->counter_mode);
}

as i don’t like the idea of updating the hardware every 1ms.

It’s too late to go out into the cold workshop to test it at the moment, but I’ll be finishing work early tomorrow so should be able to grab a couple of hours then.

I didn’t have to do anything with the overlay either, I thought that was due to the kernel eQEP driver.

Regards
Russell

[karl....@gmx.de]

Am Dienstag, 30. Dezember 2014 19:30:20 UTC+1 schrieb Charles Steinkuehler:

The hardware is supposed to capture the position at the time of the
index pulse, so when the HAL code runs it should be able to read both
the position when the index pulse occurred and the current position
(which might be up to 1 mS removed in time from when the index occurred).

I'm glad to see people starting to use the hardware encoders, keep us
updated on the progress!

--
Charles Steinkuehler
cha...@steinkuehler.net

Do I get it right that HAL knows that because the position signal is derived from raw_counts - index_counts? Otherwise I cannot see how HAL could know about the index count latched in QPOSILAT. As Russell pointed out, that mechanism does not help for a single pulse per rev anyway.
Karl

[Karl Jacobs]

Am 30.12.2014 um 22:03 schrieb Russell Gower:
> Hi Karl, As per Charles is email, the hardware latches the current
> position into QPOSILAT when the event occurs, then the update
> function uses that to update index_count so that the HAL sees how far
> the position has changed since the event, but I don’t think thats
> going to help you if you’ve only got one pulse per revolution, I’ve
> added a slotted disk with 90 slots (one of which is longer than the
> others) and 3 optical slot sensors to the spindle on my lathe so I
> have 360 pulses per revolution.

Hi Russell,
(sorry for keeping to omit that second "l" in Russell)....
As I am forced to use the position-interpolated signal for threading,
hal cannot correct for the index jitter, as you said. I could imagine
that one could code something like an "interpolated index" signal, but
now that I have the hardware QEP, I guess I will rather switch to a
slotted disk as well.
Karl

[Russell Gower]

>
> Hi Russell,
> (sorry for keeping to omit that second "l" in Russell)....
> As I am forced to use the position-interpolated signal for threading, hal cannot correct for the index jitter, as you said. I could imagine that one could code something like an "interpolated index" signal, but now that I have the hardware QEP, I guess I will rather switch to a slotted disk as well.
> Karl

Hi Karl,
Don’t worry about that as long as you’ve got the first 4 letters your all right.

I’ve just spent a couple of hours in the workshop, successfully turned down a bit of 303 stainless steel to 12mm and then cut an M12 thread in it, so all looks good with the quadrature mode, would you be able to test the counter mode before I submit a pull request?

The changes are in the bbb_eqep branch on my github repository https://github.com/russellgower/machinekit/tree/bbb_eqep/src/hal/drivers

This is the documentation for the new pins


* '(bit) <name>.counter_mode' - When true QEPA input will provide the clock
for the position counter and the QEPB input will have the direction
information, defaults to false (quadrature count mode).
* '(bit) <name>.x2_mode' - When true count rising and falling edges in
counter mode, defaults to false;
* '(bit) <name>.invert_A' - invert polarity of QEPA input.
* '(bit) <name>.invert_B' - invert polarity of QEPB input.
* '(bit) <name>.invert_Z' - invert polarity of QEPI input.

Happy new year
Russell

[Karl Jacobs]

Hi Russell,
Happy new year!
I tested your new code in counter mode and it works perfectly nice. I
had to setp eQEP0.invert-B 1 to count forward (my B input, which is the
count direction, is presently floating, I'll change that). Threading
motion is fine.
My only suggestion to the code is to name the new hal pins according to
the software encoder pins of linuxcnc, so not "counter_mode", but
"counter-mode". People would not have to modify their hal files then.
LCNC does not have the the invert-pins, but you might do the same there.

By the way, it should be easy for you to test the counter mode by yourself:
1) disconnect the A and B inputs from your encoder
2) connect the Z (index) input also to the A input (I did that on my
DB25 cape by soldering a small wire across the neighbouring pins P9.42
and P9.41)
3) in your hal file:
setp eQEP0.counter-mode 1
#assuming that you renamed the pin as suggested
setp eQEP0.position-scale 1.0
net spindle-pos eQEP0.position-interpolated => motion.spindle-revs
#need to use position-interpolated for 1 pulse/rev instead of eQEP0.position
net spindle-index-enable motion.spindle-index-enable <=> eQEP0.index-enable
#index signal same as with quadrature index

and you should be done. Actually, I would be very much interested if you
see a difference in thread quality compared to the slotted-disk
quadrature version. My guess would be you don't.

(OT: I use the ShuttleXpress jogging wheel which I find nice, worked
with machinekit right out of the box. I changed the axis selectors to
exclusive toggle action, though, didn't like the push-button action).
Karl

[Russell Gower]

>>
> Hi Russell,
> Happy new year!
> I tested your new code in counter mode and it works perfectly nice. I had to setp eQEP0.invert-B 1 to count forward (my B input, which is the count direction, is presently floating, I'll change that). Threading motion is fine.
> My only suggestion to the code is to name the new hal pins according to the software encoder pins of linuxcnc, so not "counter_mode", but "counter-mode". People would not have to modify their hal files then. LCNC does not have the the invert-pins, but you might do the same there.
>
> By the way, it should be easy for you to test the counter mode by yourself:
> 1) disconnect the A and B inputs from your encoder
> 2) connect the Z (index) input also to the A input (I did that on my DB25 cape by soldering a small wire across the neighbouring pins P9.42 and P9.41)
> 3) in your hal file:
> setp eQEP0.counter-mode 1
> #assuming that you renamed the pin as suggested
> setp eQEP0.position-scale 1.0
> net spindle-pos eQEP0.position-interpolated => motion.spindle-revs
> #need to use position-interpolated for 1 pulse/rev instead of eQEP0.position
> net spindle-index-enable motion.spindle-index-enable <=> eQEP0.index-enable
> #index signal same as with quadrature index
>
> and you should be done. Actually, I would be very much interested if you see a difference in thread quality compared to the slotted-disk quadrature version. My guess would be you don't.
>
> (OT: I use the ShuttleXpress jogging wheel which I find nice, worked with machinekit right out of the box. I changed the axis selectors to exclusive toggle action, though, didn't like the push-button action).
> Karl
>

Hi Karl,
Thanks for testing - I did think about testing myself, but the BBB is in an enclosure mounted to the back of the Lathe and it would have meant dragging the lathe out again.

I’ve changed the _’s into -’s and have raised a pull request, so hopefully it will be merged soon.

Also thanks for the jogging wheel recommendation, I’m already finding the keyboard to be quite un suitable, I was going to knock something up myself connected to one of the other eqep modules but I think i’ll save myself some effort and buy a ready made one. Strangely the cheapest place I’ve been able to find one is Apple, just hope it isn’t a special Mac only version http://store.apple.com/uk/product/TX055VC/A/contour-shuttlexpress

Regards
Russell