Advanced mill spindle orient setup with retrofit VFD

Targeting all you guys that setup VFDs everyday. I am swapping an older machine from a V/hz drive to a vector system. The VFD should run flawlessly for milling but some concerns are present regarding spindle orient and rigid tapping.

Spindle orient - Right now at tool change the machine is designed to slow the spindle to a very low speed, then command a very slow rpm and a shot pin is fired via air solenoid. When the shot pin falls in, a switch is tripped and the VFD is commanded to stop through the CNC control board. One concern is with the new vector system, there might be sufficient torque still at low speed that if the switch is not fast enough, it could push through the pin stop and damage it before the VFD is given the command to stop. Probably no way to tell until tried.

Obviously the shot pin arrangement is NOT ideal in any case. This VFD is equipped with the encoder feedback card as well so orient via encoder positioning is an option. The later machines do this but the encoder position is parameter set in the control. With this machine software not able to do that, I would just have to rig something to fire or close that home switch when the position is found by the VFD itself BUT the control would respond with a VFD stop command that would probably terminate the orient hold. I would also have to find a way to send a voltage signal to the VFD to command orientation.

There is likely not an easy way to add an encoder as of now because the motor snout is direct mounted in a transmission so getting 1:1 speed to the encoder might be a challenge. Also because of the retrofit, I would like to see if things work as designed before going through the trouble and would run in sensorless mode.

I am curious if the shot pin system sounds like a BIG issue or something I can work around with parameter settings?

Rigid tapping - The way this machine taps is it uses an encoder feedback from the spindle to the control board. The control board commands a speed to the VFD but ultimately just watches the spindle speed and adds Z axis feed to match it according to programming. I am just wondering if there is anything thing I need to worry about here? Specifically decelerations and stops? I can only assume that the control can react with lightening speed to spindle speed changes to make this pretty seamless but I am little worried that the tighter speed control might make the deceleration faster and something that the control is not used to accounting for.

Was this confusing to most people? I figured I might get a little input on this.

Way too many variables here - what kind of drive, what kind of controller, what is the ratio between encoder and motor . . . blah blah blah . . .

I have done this on a lot of different machines in a lot of different ways and I would just be guessing to put together any kind of answer without a lot more accurate information.

Control - Haas
drive - mits FR-A520
Encoder - not purchased yet and was under the impression that drives usually do not have a parameter to operate on a rev ratio relative to the motor other than 1:1

I think I would first like to ask about ehe sensorless orient first which would simply command a slow speed until a lock ring gets a shot pin hung in it. I am sure you have seen the design.

Control works on 0-10 relative speed voltage input to drive. Not sure yet which switching is used for stop with braking.

Encoder issue - Don't know anything about the Mits drives - The CT drives I have used in this application don't care what the encoder resolution is and this can be changed on the fly - as such, if using a transmission - I have a digital input that goes to the drive to toggle the value of encoder counts seen by the drive per revolution of the motor - this allows high quality closed loop vector control. A limit switch on the transmission shifter is all that is needed to tell the drive which encoder count to use. Drive must be disabled when shift occurs.

As for spindle orient - sounds like you are using an OPEN LOOP system - i.e. - just run the drive slow until the pin locks it's position. This will require reduced current limit features on the drive - again, a digital input should be used to tell the drive to use a lower current limit . . . easy to do with a CT drive / don't know about the Mitsubishi Drive. Perhaps take the digital signal that fires the pin and echo it to the drive.

If you are going to run sensorless - then focus on the ability to trigger a low current limit on the drive with a digital input and tie this to the Home pin firing circuit (I don't know how you would do this with a Haas control - fairly easy to do with Siemens / Fanuc / Delta Tau controllers)

can the reduced current limit only be applied digitally? You are right at the drive operates in open loop so it is commanded simply to spin at a slow speed to enage the home pin. I am not sure I can get any sort of digital signal to the drive during this sequence. I will further test but it seems that the drive just gets a very low speed command and due to the very low torque at the slow speed, the spindle will not overcome the shot pin or damage it before the drive is commanded to stop.

All in all, we are talking about a time delay probably around 50ms but I am sure that is long enough to cause problems or eventually damage the pin if the drive applies excessive torque while the pin is locked.

Again - I don't know the capability of the Mits drive - I often use a comparator to change parameters in a drive. Lets say you set the drive speed reference to 2.5Hz for orient function - you could set up a comparator that says anytime the reference frequency is below 3Hz - limit current to 30% or some such thing.

One of my engineers here worked for Mitsubishi as a sales engineer for 10 years - I'd ask him, but I would have to charge you for the answer . . .

But wouldn't limiting the current below a certain speed cause a decrease in acceleration? Possibly to small to worry about for machine spindle? I do have a programming manual and certainly do not need led by the hand, just trying to get a feel for how one might go about the event. It does seem that just a current limit set at the orient speed should protect from the issue and maybe a stall buffer to eliminate any stall alarm.