Light Machine Corp. Benchman XTr (retrofit)
Here's my breakout from the encoders. My X cable has different colors but the signals still appear on the same ribbon cable conductors.
Encoder Output , Ribbon Cable , Ribbon Cable Conductor
VCC +5V White > Brown > 1
( VCC +5 White) > White > 2
- B channel Blue > Red > 3
+ B channel Green > White > 4
- A channel Pink > Orange > 5
+ A channel Red > White > 6
+ Z channel Yellow > Yellow > 7
0 V (grn) Black > White > 8
- Z channel Orange > Green > 9
( 0 V (grn) Black) > White > 10
as this will catch runaways much faster than you can hit Estop (Estop is of course still needed)
If the encoders are working and LinuxCNC has control of the drive enables, you will get an immediate following error
and disabled drives in the event of a runaway
- X.Y, and Z axes home and move within 0.0002"
- zbrake off when estop is out
- spindle runs at variable speed
- flood coolant
- renishaw touch probe in (need to make a bracket for the tool height setter)
- ATC: actuators, endstops, dc motor, atc encoder, spindle hall detector
- electro doorlock signals closed and locked
- light comes on
- sso & fro pots input read (resds voltage in)
- setup classic ladder for the ATC
- figure out how to use the probe interface
- set scales on sso snd fro for pot adjustments
- interface physical on/off button
- setup mpg and increment dials
- machine new atc collet holders to work with Darkon collets
- setup 4th axis
The thing that made it all start to click was rearranging a copy of the hal file into components, parameters, and signals/pins.
I used classicladder for my Hardinge CHNC turret gnipsel.com/shop/hardinge/hardinge.xhtml
I also have a turret sim gnipsel.com/files/linuxcnc/configs/cl-turret-sim.zip
and a classicladder tutorial gnipsel.com/linuxcnc/ladder/index.html
wrightsh wrote: So on my ProLight (which I think is pretty much the same machine) there's a board that takes the encoders as an input and runs through several logic chips to produce a tachometer output. At one point I tried tracing out all of these components and found datasheets for them and got a schematic but if I remember correctly I would have needed a few more supply voltages then just +5 and +24. I think each of the LED's below and to the left of this tachometer board correspond to each of these supply voltages which are fed from the box that houses the computer. I ended up just getting rid of that board and running the servos in torque mode and have been happy with it. I can look up the tuning values that I used if you want.
The encoder in the motors is a Tamagawa "Singlesyn" or "Smartsyn" resolver that can't be used without the dedicated ASIC (also made by Tamagawa). It's a funny magnetic component with an "exciter" winding (Z) and 2 outputs A & B. The ASIC drives the resolver Z winding with a high frequency waveform and also does lots of processing on the resulting output signals. Several outputs are available including the simple pulse output that is used here. For permanent magnet motors where rotor position information is critical etc, it provides a 10 / 12 bit absolute position signal and that's normally why people install them. Seems a bit of overkill just to generate a speed / direction signal but it's a very good quality solution.
Basically, if you want to use this original (absolute position) encoder you will need to retain the interface board with its ASIC (AU6802). If you want a simpler solution, you may be better off removing the encoder and associated interface board and replacing them with a much simpler and conventional (speed) encoder.
Muzzer wrote: Basically, if you want to use this original (absolute position) encoder you will need to retain the interface board with its ASIC (AU6802). If you want a simpler solution, you may be better off removing the encoder and associated interface board and replacing them with a much simpler and conventional (speed) encoder.
Mesa offer a board that works _very_ nicely with resolvers.
I like it so much that on my recent Lathe retrofit I removed an encoder and fitted a resolver
The 7i49 produces a very high quality velocity output, and it would be relatively easy to route that back to one of the analogue outputs on the board to get a velocity-proportional voltage.