Spindle at speed using CSS and G33 (Spindle controlled with VFD)

We have an Emco lathe with a Automation Direct GS2 VFD driving the motor. We have an encoder on the spindle. The machine is running Linuxcnc 2.7.11.

We have CSS on and are threading with a G33 on our Emco lathe and we are seeing the spindle decelerating during the cut. Seems like the spindle speed should be fairly steady at a given X location during a G33. What I think is happening is that the spindle is still decelerating to speed while it’s in the cut rather than before entering the cut.

We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0) and so CSS spins the spindle up to full speed as I’d expect but it appears that our spindle is still decelerating to speed as the next threading pass is happening. We read that G33 will wait for spindle-at-speed before looking for the index pulse. But our spindle-at-speed signal seems to be high during the full cycle once the spindle speeds up the first time. It seems like spindle-at-speed should go low after rapiding out of the part as it moves to it’s next X location and decelerates to it’s next speed at the cutting diameter. Or are we misunderstanding spindle-at-speed when CSS is in effect?

In our configuration the hal pin motion.spindle-at-speed is set by the VFD (according to the examples for using the GS2 VFD):


The only other spindle related config in my .hal file is:

But sections 6.1 and 6.2 of this manual: linuxcnc.org/docs/html/examples/spindle.html
Show the spindle velocity (as determined by the encoder) and the commanded velocity compared though a "near" component to determine the state of motion.spindle-at-speed.

What is the right way, when using the VFD to still ensure that the spindle is really at speed before cutting?

Thanks,
-Tom

If you are using the VFD's spindle-at-speed then you must adjust the VFD it's self to adjust the behavior.
I am not sure the options available on your VFD.

You can use linuxcnc to calculate spindle-at-speed using encoder feedback (if available) and the near component.

In linuxcnc's motion controller case it doesn't care how it's done - if spindle-at-speed is false at the beginning of a feed move if will wait.


On a side note looks like you used PNCconf for your initial configuration - how well did that work for the VFD ?
It's an option that I can't test well as I don't have that VFD.

Thanks
Chris M
Chris M

cmorley wrote:

On a side note looks like you used PNCconf for your initial configuration - how well did that work for the VFD ?
It's an option that I can't test well as I don't have that VFD.

Thanks for the reply Chris. It has been a couple years now since I made the config for the lathe. I can't recall if PNCconf did the right thing with the VFD. I want to say I found the configuration for that separately on the Linuxcnc wiki but I could be mistaken.

-Tom

BigJohnT wrote:

I have a GS2 on my BP with encoder feedback on the spindle.

This is my HAL for the spindle:

# Spindle Drive
loadusr -Wn spindle-vfd gs2_vfd -s 2 -p none -A 0.5 -D 0.5 -R -n spindle-vfd -v
# connect the spindle direction pin to the GS2
net gs2-fwd spindle-vfd.spindle-fwd <= motion.spindle-forward
# connect the spindle on pin to the GS2
net gs2-run spindle-vfd.spindle-on <= motion.spindle-on
# connect the GS2 at speed to the motion at speed
net gs2-at-speed motion.spindle-at-speed <= spindle-vfd.at-speed
# connect the spindle RPM to the GS2
net gs2-RPM spindle-vfd.speed-command <= motion.spindle-speed-out
#vfd panel fan
net gs2-run => hm2_5i25.0.7i77.0.0.output-03

# Spindle Encoder
setp hm2_5i25.0.encoder.03.scale 10000
net spindle-position hm2_5i25.0.encoder.03.position => motion.spindle-revs
net spindle-velocity hm2_5i25.0.encoder.03.velocity => motion.spindle-speed-in
net spindle-index-enable hm2_5i25.0.encoder.03.index-enable <=> motion.spindle-index-enable

JT

JT,
Thanks for the reply. So, our two configs are essentially identical as far as I can see. Do you do threading, tapping, or other synchronized motion on your machine and if so, does it work reliably for you?

I do wonder if using the spindle encoder is a better method of tracking spindle-at-speed rather than relying on the VFD to say it is at commanded speed? There are pulleys and a belt that connect the motor to the spindle on my lathe whereas the encoder is directly connected to the spindle...

BigJohnT

I just added a quadrature 720 encoder with index to my BP mill. Assuming you have BP knee mill, not to hijack this thread but was hoping to get your gear ratio for the backgears? I failed to count them when the head was apart!
Also, I don't have a vfd hooked up yet (will be a future upgrade) I'm reading in the spindle rpm to the axis gui via pyvcp and have a spindle speed indicator and at speed led. I'd like to add a second speed indicator that shows the scaled rpm when in backgear. Would you have an example of how to display the correct rpm in backgear?

Thanks!

Thanks Andy, yes we have now fixed the rpm rather than use css. I also re-wired Hal so that spindle at speed is set by the encoder rather than the VFD, that also made CSS much better, but fixed rpm is better still.

The reason for the G33 is that G76 doesn’t fix the retract path, it varies with each successive cut. This caused the tool to bang into the back of the workpiece and break (annoying for a $100 tool!). We have very tight quarters on the internal acme thread we are cutting (about .010”). We wrote our own threading routine which keeps the retraction path constant, right down the center, so we can control tool position inside the hole. G76 seems to be broken to me since it keeps moving further away from the thread tops with each pass. It is fine for external threads, or internal with a big-ass hole and a small-ass tool but not so good for acme or tight quarters...

-Tom