Why Index and Phase for lathe threading?

it always helps too post the exact error message.

in this case I can guess the problem.

Linuxcnc doesn't allow adding an output pin to two signals.

it does allow one signal to connect to multiple input pins.


net spindle-phase-a <= parport.0.pin-15-in
net spindle-phase-a => encoder.N.phase-Z

Note the N in the encoder change to the proper number for the spindle.
You will also have to delete any other reference that connects to encoder.N.phase-Z

That should give you the idea - Hope that helps you figure it out.

Chris M

Thanks that seemed to get my GladeVCP meter picking up the signal.

The weird thing now is the meter RPM values are long decimals between 0 and 1 (and appear to be random):

net spindle-velocity gladevcp.hal_meter1

did you adjust the scale of the encoder?

Chris M

Yes I'm using a 16 slot encoder and have:
setp encoder.0.position-scale 16

I've also tried values like 16000000 and .00016 but it makes no difference. Still returns random long decimal numbers between 0 and 1.

EDIT: Attached my files, for everyone's viewing pleasure.

at this point I can only suggest that you use halmeter and or halscope on the parport pin 15 and
the encoder component while turning the spindle by hand to see that it is counting properly.

Chris M

K thanks. I appreciate your help.
I haven't played with Hal Meter but I'll start in on it tomorrow.

Trying to read this thread to see if you have ever said what you actually have, hardware wise.

I can only guess that all you have is an index pulse, that seems to be the inference.

You can feed phase-Z and phase-A from the index pulse.
It will work, just about and will produce very bad threads.

Just like Mach does, which is why I stopped using it many years ago.
When Art launched a huge long thread (no pun intended) about how it was possible to thread on a lathe with a single pulse, I just knew he was protesting too much.

The 120 to 240 impulse phase-A encoder I mentioned in a previous post, is a practical limitation which comes from using the software encoder component
Much higher than that and the thing goes haywire above a certain speed, just cannot keep up
120 produces good threads, I tried a proper 300ppr encoder on a software encoder component and it went apeshit above 500 rpm.

All you need to tie Z and A is

net encoder-output parport.0.pin-NN => encoder.0.phase-Z encoder.0.phase-A
setp encoder.0.counter-mode 1
setp encoder.0.position-scale 1

It will work, but completely unsatisfactorily

regards

ArcEye wrote:

Trying to read this thread to see if you have ever said what you actually have, hardware wise.

I can only guess that all you have is an index pulse, that seems to be the inference.

You can feed phase-Z and phase-A from the index pulse.
It will work, just about and will produce very bad threads.

Just like Mach does, which is why I stopped using it many years ago.
When Art launched a huge long thread (no pun intended) about how it was possible to thread on a lathe with a single pulse, I just knew he was protesting too much.

The 120 to 240 impulse phase-A encoder I mentioned in a previous post, is a practical limitation which comes from using the software encoder component
Much higher than that and the thing goes haywire above a certain speed, just cannot keep up
120 produces good threads, I tried a proper 300ppr encoder on a software encoder component and it went apeshit above 500 rpm.

All you need to tie Z and A is

net encoder-output parport.0.pin-NN => encoder.0.phase-Z encoder.0.phase-A
setp encoder.0.counter-mode 1
setp encoder.0.position-scale 1

It will work, but completely unsatisfactorily

regards

Thanks, I'll go try this right now and report back.
I only stated it once and not near the top of the thread, but I have 16 pulses on my encoder. I can make another to go as high as needed, however.

EDIT:

Well, this is dumb.
I created a whole new config using the stepconfig wizard and I just set it up with pyvcp and decided not to go with GladeVCP to eliminate Glade being the problem and test against pyvcp.
IT WAS THE PROBLEM!!!
Without adding any extra code or hal connections at all (like tying index to phase a), and only using the phase A for my pulse signal I am getting exactly what I expect to get.
Somehow Glade is reporting these weird long decimal numbers between 0 and 1, but pyvcp just gives me actual RPM. This is so weird.
At this point I'm just going to drop trying to use Glade and move on with my life.

Thank you everyone who have tried to help with this issue.