Lathe turret tool changer with absolute encoder

I'm at the point in my retrofit where the last 2 big things I would like to wrap up are the spindle winding selection and the tool changer,  I'm unsure how to proceed with the tool changer.

It's a pragati 8 tool , driven by a 3 phase motor and absolute encoder with a prox switch for tool clamp verification. This turret simply runs the motor forward or backward and has a internal cam system for unlocking , no prawl , no locking pins , no lifting.

I have the 3 phase motor running off a mollom vfd and I can manually cycle the tool changer forward or reverse , the vfd supports +10v analog signal and can have a reverse input.

The output from the encoder is 3v but i forgor to grab a pic of that page.

I have the encoder and prox switch powered,  the prox switch is wired to a input on my 7i95t and is functioning.

my mesa setup is 7i95t-7i83-7i84

debian 12 , linuxcnc 2.9 gmoccapy

I guess I'm looking for advise on how to proceed , tool changer setup seems unique to every machine . And I can't find much info about absolute encoders , I would be up to ditching the encoder and going with some kind of "tool home" sensor if it's easier.



 

This looks like a simple binary position encoder and looks like a perfect fit for the "carousel" HAL component.

In fact you can probably just set up the tool-change position in the INI and in the HAL connect:
You might want to put the carousel comp in the tool-prepare loop rather than the tool-change loop, maybe experiment to see which works better.

Note that by default LinuxCNC _requires_ an M6 command and a G43, whereas most lathe controllers do not. This can be changed via a remap.

You then need to connect the carousel motor-fwd and motor-rev pins in such a way as to operate the motor, and wire the encoder outputs (including strobe and parity) to the correspoind carousel comp outputs.

linuxcnc.org/docs/2.9/html/man/man9/carousel.9.html

Thank you for the direction , I was reading about carousel  bit last night , looks like it will fit the bill.

For wiring of the encoder should the signals be connected to the i/o of the 7i95t ? I'm still confused on that part but I did find an example from bigjohnt who uses a similiar encoder and I believe that's how it was wired.

I think that you are probably wrong when you say

The output from the encoder is 3v but i forgor to grab a pic of that page

The output is shown as being PNP which means that it is effectively a switch to the positive rail that feeds the Proximity sensor. This could be anywhere between 10 and 30 V.

www.se.com/uk/en/faqs/FA142566/

When wiring his sort of thing it is helpful to think in terms of current flow, rather than voltages.

When the sensor is tripped it will allow current to flow from the proximity sensor brown wire and out of the black wire towards the blue wire.
If you take the black wire to the Mesa card then the input will be high if current flows from the black wire, into the Mesa connector Input terminal (for example INPUT0), through the LED in the optocoupler on the Mesa board, out of the INCOM0,1 terminal and back to the blue wire.
Thoigh you wouldn't typically run that last wire back to the actual sensor, but rather connect it to some point on the same signal ground net.

You are correct,  I misunderstood the data sheet.

your explanation is great and now I actually have an understanding of what is happening.

From the factory it only usues bits 1-3 and parity , i have connected all these and can see them cycing in hal show.

I'm going to try and sit down over the next few days and try to see if i can get this going , thanks for all your help so far.

 

Started working on it this evening , I have a couple questions since I can't find an example to use for reference.

What pins to I connect my encoder in bits to ? I thought it was sense-0/1/2/3 etc but i was mistaken

When I do get that setup how do I setup so it knows what encoder Input = tool 1? , I played with the emco changer comp and it referenced a truth table that you could configure.