[n1tr0]

I haven't had any luck with rigid tapping on my mill yet, but it's one of the driving factors along with lathe thread cutting that I'm going to try switching over to UCCNC. My current VFD doesn't have the option of adding a braking resistor so I'm looking at some different options. I'm wondering if anyone has some suggestions on key features to make sure are included? Is there a preferred way to control/monitor speed? Right now I'm controlling speed by sending the pwm signal to the gecko g540 which then converts that into a 0-10V analog input for the VFD. I wouldn't mind bypassing the gecko and going digital, but I'm not sure what the best route is there? Also with my lathe and mill spindles, I have a single index (1ppr) output and I'm wondering if that's good enough, or if there's a required or preferred spindle encoder method/hardware?
Thanks

[derek]

I have 2 machines with encoder tapping. One has a braking resistor and the other doesn't. The one with I just run it as it is and it works fine. It as a bit of over shoot but not bad. Half a turn or so The one without is another story. It has a lot of overshoot but it's consistent. So if I'm tapping a hole that is to a closed bottom I'll run it cutting air first and watch the Z axis DRO to get the over travel. I then deduct it from the thread depth in the code. It works surprisingly well. Life pro tip: Use your camera phone in slow motion video to record the DRO. Makes things easier

[vmax549]

ANY kind of a decent VFD that has a breaking resistor will work ok. BUT you must have an encoder with index for the spindle as that is what drives teh function.

(;-) TP

[n1tr0]

Thanks for the feedback on the braking resistor. Any input on digital controls? Most of the VFD options seem to come from China with minimal documentation. They have all the keywords like modbus support, but not a lot on what that means. Specs indicate 0.1% speed error with analog input and 0.01% with digital input which makes it sound like going directly from the UC400 to the spindles digital inputs is the best way to go, but I haven't found any documentation on how that's best accomplished.
Thanks
Attachment 331372

[ger21]

There are probably a lot more VFD's that are not chinese, then chinese ones. Sounds like you're looking in the wrong place.

[stampsm]

The option I am looking at for rigid tapping and spindle speed control is using a servo motor instead of a VFD. You are not looking for speed control as much as you are looking for spindle location. You will need an encoder on the spindle to tell where the head is located exactly. 1 PPR is not adequate and far from it. Imagine being 180 degrees off as that is the max error with a 1 index location encoder. You will also ideally need a motor with low rotational inertia so when the power is removed it stops quicker. A VFD does not seem the best bet for this. I was looking at using one of these possibly. DG4S-08020 DC servo drive - CNCdrive - webshop with a cnc servo and a encoder, probably 400 counts per rotation or up to maybe 1k encoder counts per rotation.

[OlfCNC]

The UCCNC can cut thread with an uncontrolled spindle which means you can have a 3phase motor running off the mains or VFD and the only thing you need under software control is direction change which can be achived with a direction input to the VFD or with a relay changing mains phases to the motor.
No need for servo motor, just for an encoder on the spindle which you feedback to the UC.
This is cool, because a servo system can be very expensive compared to a standard 3phase motor and a VFD especially in the high power ranges.
And rigid tapping might require a high power motor when using a high dia. tool.

Ofcourse rigid tapping with servo is also possible, but it is a more expensive solution in most cases.

[vmax549]

VFD are just fine I routinely stop teh spindle within +/- 1 thread with a VFD and Braking resistor and add a touch of DC braking. Servos are FINE if you can afford them A 3kw AC servo with a good drive is not cheap. But then neither is a GOOD VFD and a GOOD inverter rated high torque 3 ph motor that can spin 6000 RPM.

With encoder following an exact stop is raely needed except with some blind shallow holes. But then +/- 1 thread has never been a problem either (;-)

(;-) TP

[A_Camera]

Is there a preferred way to control/monitor speed? Right now I'm controlling speed by sending the pwm signal to the gecko g540 which then converts that into a 0-10V analog input for the VFD. I wouldn't mind bypassing the gecko and going digital, but I'm not sure what the best route is there?

Use Modbus. Much better than 0-10V and is more accurate and stable since you are not dependent on the 0-10V linearity and accuracy. You can also read back the actual spindle speed (at least as far as the VFD is concerned) and control CW, CCW and OFF the spindle. You can do much more also, but that's just the basics. All you need is a cheap USB - RS485 converter.

[vmax549]

Modbus does not just have to be RS485 it could be rs232 or ethernet as well. Also analog is a more direct approach. Modbus may involve a slight delay.


(;-) TP

[A_Camera]

Modbus does not just have to be RS485 it could be rs232 or ethernet as well.

Definitely. Just that RS485 is the simplest and very reliable and cheap solution. I dislike RS232 and Ethernet is a bit of an overkill for hobby use, mainly because it demands a more expensive interface to the VFD. My VFD has only an RS485, so the most straight forward interface is a tiny cheap dongle in the PC USB port to convert it to RS485 and then two thin wires to the VFD.

Also analog is a more direct approach. Modbus may involve a slight delay.

Yes, but the greatest delay is in the VFD and the acceleration/deceleration time, so the . Also remember that the 0-10V is pretty inaccurate and non-linear, at least in the budget version of DA converters, so in the end, I still think Modbus is better. Besides, if the delay is a problem than Ethernet Modbus should be the solution, with that the delay should be negligible. But...

Even with ordinary RS485 or RS232 you can ignore the Modbus delay, at least according to my calculation.
You only need to send 11 bytes to control speed/on/off/CW/CCW commands. 11 bytes = 88 bits + 33 bits for start and stop bits between each bytes, total 121 bits per message. At a rate of 38400bps you will be able to send 317 messages every second, which is 3.15ms per message. Using low speed serial connection (not every VFD can handle 38400bps), say at a more common 9600bps, that message rate is 1/4th, so the message time is 4 x 3.15 = 12.6ms. So, in theory the worst case delay is 12.6ms caused by the serial transfer of command. I don't think that this is going to cause any problems since the accelerating/decelerating changing direction takes a lot more, even with braking resistor.

[samco]

Here is the deal though... On most systems the motion controller is doing the pwm to create the analog voltage. This is probably realtime. Running serial though the computer outside of the motion controller adds a significant delay to it. When you want the spindle to change direction as fast as it can - analog / dedicated i/o is still the best.

Another example would be simple orienting with the vfd. People have done it using VFD and analog input (running through a pid) - not possible with serial. (unless the vfd has a orient function of course)

sam

Definitely. Just that RS485 is the simplest and very reliable and cheap solution. I dislike RS232 and Ethernet is a bit of an overkill for hobby use, mainly because it demands a more expensive interface to the VFD. My VFD has only an RS485, so the most straight forward interface is a tiny cheap dongle in the PC USB port to convert it to RS485 and then two thin wires to the VFD.



Yes, but the greatest delay is in the VFD and the acceleration/deceleration time, so the . Also remember that the 0-10V is pretty inaccurate and non-linear, at least in the budget version of DA converters, so in the end, I still think Modbus is better. Besides, if the delay is a problem than Ethernet Modbus should be the solution, with that the delay should be negligible. But...

Even with ordinary RS485 or RS232 you can ignore the Modbus delay, at least according to my calculation.
You only need to send 11 bytes to control speed/on/off/CW/CCW commands. 11 bytes = 88 bits + 33 bits for start and stop bits between each bytes, total 121 bits per message. At a rate of 38400bps you will be able to send 317 messages every second, which is 3.15ms per message. Using low speed serial connection (not every VFD can handle 38400bps), say at a more common 9600bps, that message rate is 1/4th, so the message time is 4 x 3.15 = 12.6ms. So, in theory the worst case delay is 12.6ms caused by the serial transfer of command. I don't think that this is going to cause any problems since the accelerating/decelerating changing direction takes a lot more, even with braking resistor.

[A_Camera]

Here is the deal though... On most systems the motion controller is doing the pwm to create the analog voltage. This is probably realtime. Running serial though the computer outside of the motion controller adds a significant delay to it. When you want the spindle to change direction as fast as it can - analog / dedicated i/o is still the best.

I can be wrong, but like I said, changing direction, regardless how fast you do it and if you use a brake resistor or not, takes a VERY long time, compared to the 3.15ms it takes to transfer the message, it is an eternity. What is the fastest brake and reverse speed a spindle can make at 3000rpm? Perhaps 1 second for braking to zero and 1.5-2 seconds for accelerating up? Can it go faster? Perhaps, but I am pretty sure it takes at least 2 seconds, and in that case the 3.15ms is totally ignore able. But sure, I have zero experience in tapping with VFD, so I can be wrong, but if the Modbus can not be used it is not because of the delay in communication, but something else, like low priority task or something similar.

Another example would be simple orienting with the vfd. People have done it using VFD and analog input (running through a pid) - not possible with serial. (unless the vfd has a orient function of course)

sam

You mean positioning the spindle? How on earth would that be possible?

[samco]

I can be wrong, but like I said, changing direction, regardless how fast you do it and if you use a brake resistor or not, takes a VERY long time, compared to the 3.15ms it takes to transfer the message, it is an eternity. What is the fastest brake and reverse speed a spindle can make at 3000rpm? Perhaps 1 second for braking to zero and 1.5-2 seconds for accelerating up? Can it go faster? Perhaps, but I am pretty sure it takes at least 2 seconds, and in that case the 3.15ms is totally ignore able. But sure, I have zero experience in tapping with VFD, so I can be wrong, but if the Modbus can not be used it is not because of the delay in communication, but something else, like low priority task or something similar.



You mean positioning the spindle? How on earth would that be possible?

This is using a vfd

https://www.youtube.com/watch?v=D6dGYsXAPIU

sam

[A_Camera]

This is using a vfd

https://www.youtube.com/watch?v=D6dGYsXAPIU

sam

Yes, but I don't think you can position the VFD with PID. You need a position sensor, not PID.

[samco]

Yes - this has an encoder on the spindle. Using that and a pid loop for position.

sam

[A_Camera]

Yes - this has an encoder on the spindle. Using that and a pid loop for position.

sam

Sure, but the actual positioning is done with the help of the encoder. You can do that without PID as well.

But we are far too off topic now...