HAAS VF1 retrofit

A n encoder on the spindle motor will do you no good for an orient as your spindle has a belt drive and the belts will never be in the same place, and you will never find orient with a 2 speed gearbox . The encoder will allow you to rigid tap though. To use an encoder for orient it should be driven 1:1 off the actual spindle.

programming the tool in/out button is easy, that you can do on hal.

im pretty sure a prox sensor counts each tooth of a geneva cam incrementally on the carousel.you add or subtract present tool position to next tool position.It would not have a prox switch for each pocket. You could try mounting an encoder on the shaft that turns the carousel. A 20 pos bcd one would be ideal.

homing the carousel to tool1 prox switch will require looking for it in a loop till it see's the prox switch and killing the motor,

you now also have hi-low gear to contend with. my guess is you can jog the spindle motor at about 5 rpm while activating the solenoids that shift the gears. this is how matsuura does it, unless the gears only line up in 4 spots(like the B&S) then the spindle will have to be oriented....

subroutines are not exactly safe for this type of thing, you could very easily tear the tool changer off!!! You could use subroutines with macro variables tied to hal signals, but you are right back to writing logic again, twice removed!!

The spindle encoder is on the same shaft as the orient ring, and output pulley to the spindle, this is after the gearbox,
the out put pulley and the spindle pulley are 1:1 and have timing marks to keep everything oriented.
spindle encoder is 1:1 ratio also. Machines with no gearbox ran off the motor itself.

There are only two prox switches on the carousel, , and a in prox and out prox on the shuttle

I have been all over this thing now, read factory maintenance manuals etc... probably could be a pretty good HAAS tech


With all the code on here i could probably snip and paste and get something going but i have no idea how to
code in C , i read it and kind of makes sense but i dont think i could do it from scratch.

JR1050 wrote: Im not sure you can run the tool carousel as an axis, I have not worked on a Haas, but I suspect it is run by a plain motor and uses a geneva cam like a Fadal.Even if it is run by a servo and has an encoder, you will have to write a function to count angular degrees to get to you intended tool

My suggestion of configuring the carousel as an "axis" is just a way to get the required carousel position out to HAL as a target, and at the same time have it feature in the homing sequence.

The control/feedback would be fwd / rev relays and using the tool sensors as a low-count encoder. This ought to work, in the HAL layer it is all just numbers, if you can get the right outputs from the right inputs it doesn't matter what you call things.

One complication I have glossed over while I think about it is how to persuade the single-channel encoder counter to count up or down depending on which way the motor is running. I think that cunning use of LUT5 can be used to create a synthetic B-phase for the software encoder component.

Whether the carousel is configured as an axis or not is not such a big change. If it is an axis then the command to move it is G0 B[ #<tool> * 360 / 11] and if it isn't then it is M68 E0 Q[ #<tool> * 360 / 11] (or similar).

As a non-axis homing would have to be handled separately, but that isn't too hard, you could just set it moving and do a G-code wait-on-input on the index sensor then zero the encoder.

JR1050 wrote: subroutines are not exactly safe for this type of thing, you could very easily tear the tool changer off!!! You could use subroutines with macro variables tied to hal signals, but you are right back to writing logic again, twice removed!!

As this tool-changer requires Z-axis movements I think that G-code subroutines are the way to go.
They will need to be written carefully, with time-outs and abort mechanisms.

In the final configuration the G-code subs would be built into a remapped M6 code. Remapping supports tool-change abort methods.

There is a lot to read here, but it's a very useful new feature in 2.6:
www.linuxcnc.org/docs/html/remap/structure.html

Note especially: www.linuxcnc.org/docs/html/remap/structu...g_dealing_with_abort

This says that the "M2" codes in my sample G-code routine are a very bad idea. Luckily the remapping feature has added a new G-code comment style

(abort, abort message)

sspeed33317 wrote: The spindle encoder is on the same shaft as the orient ring, and output pulley to the spindle, this is after the gearbox,
the out put pulley and the spindle pulley are 1:1 and have timing marks to keep everything oriented.
spindle encoder is 1:1 ratio also. Machines with no gearbox ran off the motor itself.

There are only two prox switches on the carousel, , and a in prox and out prox on the shuttle

This is all very familiar. What year is this thing???? I just replaced the tool position switches 6 months ago, but unfortunately was not paying much attention to the motor at the time.

Is this a horizontal or side mounted changer? Oh, wait... never mind, you pointed out your shuttle... horizontal... okay, no delay needed for the tool pocket to flip down...