Servo as a spindle motor replacement - what to look out for?

Long story, short - I blew my spindle controller on the Sieg SX2.7 a second time (the first was under warranty and within 30 minutes of powering on my machine from delivery)... this time, the machine is most certainly not under warranty. I've tried repairing the spindle controller board but I think I've a dodgy hall position sensor and that blew the board up quite spectacularly a second time. Enough is enough, and it's cheaper to replace the motor and controller card with a Chinese servo and controller. So, that's this weeks step into the unknown. And servos are pretty much an unknown to me. So, help!

I've got a Chinese servo (this one: https://www.ebay.co.uk/itm/112227829185) that's slightly larger than the original BLDC motor. Finally managed to nibble a 10mm Ali plate to mount the motor and get it belt-coupled with the spindle. There's a knocking noise I need to bottom out but that's a different story (I think that's the spindle). I've managed to operate the spindle in a commissioning mode with the servo in speed mode and that looks to be the kind of set-up that's appropriate for a spindle. I'll have to check my pulley calls as well - looks to be somewhat faster than the old BLDC spindle though I thought I'd calculated the pulleys to get the same tool rpm. Low RPM is torquey as a very torquey thing - certainly I could hold the BLDC stalled at 40rpm, the servo is having none of that.

Tomorrow I plan to start stripping down my controller box to support the servo signalling. I've got a 400 page Chinglish manual... looks comprehensive, but it's a right bugger to read, and certainly not something you can casually browse.

I believe (99% confident) that it supports Step/Dir control and I'm using UCCNC - which also supports this. So, plan 1 is to remove the analogue drive and M3/M4 relay wires, and instead wire a couple of TTL->RS485 adapters off the back of the UC300ETH controller to generate differential step/dir signals into the servo controller. If used in step/dir mode is this a positional control mode in servo-speak?, or should the servo be configured for speed mode still? Is there a practical difference?

But, what to do with an Alarm signal from the servo? I expect that if I'm spinning this quickly that there's going to be a good rate of step pulses, and if the cutter engages with a block of steel I could expect the servo to momentarily loose speed/position (but I guess the nature of a servo is that the position will be recovered?) There's an alarm output from the controller, need this be feed back into UCCNC in someway, or into the E-stop circuit? Can I expect sporadic alarms when the spindle cutter engages the workpiece? Should I simply ignore the wiring to the Alarm output?

The servo came supplied with a 3m power and control cable. The power cable is crimped fork terminals to wire to the controller, so I'm fairly relaxed about shortening this according to the final installation on (in?) the mill. The encoder cable, however, is a multiway plug on one end and a 15-w sub-d type on the other. Is there merit in shortening this cable or is it simply not necessary (I might be able to stow this inside the column of the mill).

I guess I'm hoping that someone can spell out any gotchas before I make a pigs ear of the integration into UCCNC. Like I say, servos are a whole new game for me.

Quote:

---

Originally Posted by Doddy

I believe (99% confident) that it supports Step/Dir control and I'm using UCCNC - which also supports this. So, plan 1 is to remove the analogue drive and M3/M4 relay wires, and instead wire a couple of TTL->RS485 adapters off the back of the UC300ETH controller to generate differential step/dir signals into the servo controller. If used in step/dir mode is this a positional control mode in servo-speak?, or should the servo be configured for speed mode still? Is there a practical difference?

---

I believe you can only use Position mode with Step/Dir signals. You need Analog to use Speed or Torque Modes.

Quote:

---

Originally Posted by Doddy

But, what to do with an Alarm signal from the servo? I expect that if I'm spinning this quickly that there's going to be a good rate of step pulses, and if the cutter engages with a block of steel I could expect the servo to momentarily loose speed/position (but I guess the nature of a servo is that the position will be recovered?) There's an alarm output from the controller, need this be feed back into UCCNC in someway, or into the E-stop circuit? Can I expect sporadic alarms when the spindle cutter engages the workpiece? Should I simply ignore the wiring to the Alarm output?

---

The fact UCCNC doesn't provide a Spindle or Servo Alarm input to connect upto means your only safe option is to tap into the E-stop.
This will need to be done because when the Servo faults it doesn't just throw an alarm to say it's lost position, it cuts the outptuts and stops the Servo.
You will also need some way to Reset the Fault as well. This can be by powering down the drive or pulsing one of the inputs and configuring it to Reset the drive.

I doubt you'll have any problems because the default Peak torque is 200% and rated for 8s so you'll have 5Nm for 8's before it faults, it's also programable in the drive so you can increase to 300% and set the time current fault overload time to 80s if needed. But I can smell the smoke already if you did that...Lol

This should give you planty of torque when entering the material, there are also over options in the drive you can play with to boost torque if required. Provided you can get past the Chinglish.

Quote:

---

Originally Posted by Doddy

Is there merit in shortening this cable or is it simply not necessary (I might be able to stow this inside the column of the mill).

---

They are easy enough to shorten but I would just leave it if it's not causing you any grief.

I started writing a reply to this earlier, then got side tracked.

Dean's answered all the questions, so I'll just add a couple comments for anybody else.

Position mode officially requires a pulsed input (or some form of serial communication if the drive is fancy enough), which can usually take the form of Step/Dir, CW/CCW, or Quadrature input. Quadrature is the best option as it eliminates pulse timing issues, although as this is a spindle, that's not really an issue.

Speed/Torque are analogue modes. The key difference between speed and torque mode, is torque mode bypasses some of the internal drive filtering. It can allow better drive tuning if you're running it closed loop, but is often harder to tune as it's inherently more unstable.
If you wanted, you could just run speed mode, and interface in a similar way to old controller, it all depends on how accurately you want to control your spindle speed.


As for excess cable, if they can't be shortened simply, just cable tie them out the way somewhere.

m_c: Part of the problem with the old controller, and part of the reason for its demise was the lack of a controllable input - other than through push-button control. I intimated a 0-10/CW/CCW control, but that's a generic wiring for two mills controlled by the single controller - so I'm looking to break commonality and have different solutions for the Starmill (Ana/switched) and the Sieg (Step/Dir). Back of my mind I'm thinking that this might open up rigid tapping vs analogue control (although I think there's an encoder output on the servo controller, also. Either way, Jazz and m_c, thanks, you're giving me confidence in pursuing this (it's also an eye opener to the performance of servos vs steppers)

Quote:

---

Originally Posted by Doddy

(it's also an eye opener to the performance of servos vs steppers)

---

Servo's will always Rip a stepper to pieces in most ways except complexity, which you are just about to experience.!! This is why I always tell people who are new or don't require what servos offer to stay away.!

Wait until the encoder throws a bitch fit then you'll truly appreciate the difference between Steppers and Servo's.....:whistle:

Quote:

---

Originally Posted by JAZZCNC

Servo's will always Rip a stepper to pieces in most ways except complexity, which you are just about to experience.!! This is why I always tell people who are new or don't require what servos offer to stay away.!

Wait until the encoder throws a bitch fit then you'll truly appreciate the difference between Steppers and Servo's.....:whistle:

---

Having to bore/ream the pulley to 16mm and broach the keyway kinda painted a picture that it isn’t going to mess about. Hoping that the use as a spindle motor will be a gentle introduction to servos. Was looking at the price and you can’t escape that they are more expensive than steppers but factor in psu etc and that gap is coming down.

Okay, this is progressing slower than I'd like (having to work from home and it's planting season down the allotments with the wife), but today I managed to get the spindle under UCCNC control... of sorts.

There's a few scaling issues that I have to resolve, but that I think is pretty straight-forward (I hope). I think I need to resolve the servo drive to a normalised rpm, and use UCCNC to provide Pulley scaling to give a spindle speed. But, trying to get the servo spinning at the rated 3000rpm (spindle 2000rpm), with a 3000 line encoder (3000 ppr?) UCCNC maxes out at 1980 rpm (out of 3000), with a kernel frequency of 100kHz (default). That sort of makes sense to me - 100kHz kernel = 100,000 / 3000 * 60 (sec-to-min) = 2000 rpm @ servo.

I can increase the kernel frequency, but that feels like a sledgehammer solution (and I'm not keen on increasing the pulse frequency for all the problems that can come with that... but it is an option).

The other figure that influences the pulse rate to attain the RPM is the resolution of the servo encoder. Now, given that I'm only using this for a spindle I'm pretty sure that I don't need the resolution that this offers. Is there a feature with servos that allows the resolution to be reduced (i.e. fewer pulses to get a single revolution)??

The manual talks of "positional regulator gain", but I think that's a dabble-too-far, and there's reference to "electronic gearing" with some esoteric terms such as "pulse electron gear ratio of molecule 1", as well as a more understandable "demoninator of a pulsed electronic gear ratio".

Given that I'm using pulse/dir signalling, is this electronic gearing a route to reducing the resolution of the stepper, and allowing me to present fewer pulses per revolution, and therefore increase the achievable RPM without fiddling with UCCNC kernel frequency?

Or am I barking up the wrong tree?, is there another route here? Sorry, shed-time is limited at the moment and I'm trying not to jump into too many rabbit holes.

You've got the right tree.

There will be two main gearing ratios. One is for the input pulses, and one will be for the emulated encoder output.
You want to change the input pulses.

I've not got time to check the manual to see what they've translated the terms to, but try changing one setting at a time, reboot the servo drive, and try it.

Ok well, your problem is a little worse than you think because 100Khz won't give you 2000Rpm at the Servo. The encoder on the servo is 2500ppr x 4 (quadrature) so 10,000ppr
So 100Khz will only give 600Rpm (100,000/10,000*60).

So to get Full RPM out of the servo you need to use electronic gearing so watch this video I did because I'm not explaining it all again.!!

You could possibly use the E-gearing to give you what you want and then feed the Servo Encoder output back into UCCNC, thou I've got a feeling UCCNC will only allow a max 1000ppr Encoder to be used.?


https://www.youtube.com/watch?v=bIdzlIKDJeM&t=716s

Ah, an entertaining video (actually, I recall watching that fairly recently, maybe when you first posted, but before I got into this particular forced-upgrade cycle... and as it held no relevant context for me at the time I promptly forgot about it) - you sound as amused with the manual as I've felt frustrated - though I'm coming from a position of zero knowledge.

I'm not going to argue the numbers - but, yes, from the last couple of hours of trying to work it out by first principles I've given up, set up PN098 to 10, PN102 to 1, and "tweaked" the PPR in UCCNC until my super-calibrated rev counter (finger on spindle, so I can count RPM against a stop-watch*) and 60 rpm, I'm pretty confident I've got back to a 0-2000rpm spindle speed, now programmable by UCCNC (previously only manual panel control). And I've use the spindle to machine a slot in the belt cover to allow me to get the servo cables out without fouling the Z-column. Life is good again.


(* My real, laser-diode rev counter appears to have re-invented itself as a random number generator)
I

So you are electronic gearing at 10:1 (10,000/(10/1)=1000ppr

Yes, though within UCCNC I've settled at 1500ppr, which accounts for the 40:60 pulleys.

...which was to recover the 2000rpm spindle speed on a 3000rpm servo that replaced a 5000rpm BLDC. My head hurts.

Okay, so here's something different.

I've been driving this spindle servo using a UC300eth with step/dir signalling from UCCNC, with the two pins from the £5 Chinese BoB driving two separate TTL->RS485 adapters (£3 boards, based on MAX485 chips) - these to provide a differential drive to the PP+/PP- and PD+/PD- position inputs on the servo controller. This worked out of the box from first attempt, so many months ago. I should say there's ~10 ft of 4-core dual-twisted-pair signal cable between the control box and the servo controller.

Nothing has changed, wiring wise.

Today, no spindle. Nada.

I hate working on this machine as the controller is built into the bench as a rack-unit (I'm never doing that again). But, stripped it all down, and noticed that when scoping the step/dir signalling to the servo controller, if I (accidentally) grounded the PP- with the scope ground on the probe, that the servo kicked into life. I've checked this all the way back to the MAX485's, so it's nothing to do with the wiring or connector, but that the differential drive output from the '485 can no longer drive the Opto-inputs on the servo controller. Annecdotally, this appears to be the same on the direction input as well as the step input.

QUESTION: There's nothing other than wiring on the typical Chinese servo drivers to set Unipolar/Differential drive, is there? - pretty sure it's just a case of driving the opto-input accordingly.

So, I have a quandary.

1) Replace the 485 drivers with same (need to order some) - but I'm loathed to do that - there's no reason to doubt that the replacement will also fail at some stage.
2) Replace the 485 drivers with an open-collector transistor drive - I've plenty of trannies to hand, and that allows the unipolar drive iaw the manual. But it's a strip-down of the control box.
3) But the servo controller input is just an opto-isolator input configured for 0/5V signalling. The easiest solution is to drive the servo from the BoB output pin, and ground the PP- input at the servo controller input. This is the lazy solution.

QUESTION: What signalling method do others use for reliably driving the step/pulse input on servo controllers?

Does your controller give a rough schematic of the input circuitry? The ones that I've seen had the "differential" input simply going to the diode side of the optoisolators with an antiparallel diode and a small series resistor. If so, driving it single ended is no problem, though if it were me (and since you already have it wired up with twisted pair) I'd do the grounding of PP- back at the BOB.

I expect the "backward" drive of the opto input through the antiparallel diode reduces the recovery time of the LED, or at least overcomes its capacitance. The propagation delay of a typical opto can be around 1us or so and the input capacitance may be as much as 200pF or more.

You may have noticed that some drives show a higher PPR for differential mode than for single ended and this can only be accounted for by the LED being flipped more quickly.

Have a look at what's inside any of the controllers you have to hand. Many of them are simple, single-ended (open collector) drivers and the rest are what you used. Not much help to you, I know....

EDIT - my Yaskawa Sigma servo (4th axis) has SN75174 drivers https://www.ti.com/lit/ds/symlink/sn...oogle.com%252F

These are probably a good "golden reference".

Quote:

---

Originally Posted by Muzzer

You may have noticed that some drives show a higher PPR for differential mode than for single ended and this can only be accounted for by the LED being flipped more quickly.

---

That's a good point, so if you are going to drive them single ended you want a driver that can both sink and source current, not an open collector type.

No, generally a single ended driver just sinks current. When you turn it off, the current into the driver stops. If there is a decent capacitance in / around the opto LED, it takes a few hundred nanoseconds to actually turn off completely.

The differential line driver (RS485 etc) both sinks and sources current by swapping the polarity over using a totem pole output stage. So generally you have a choice between a sink-only single-ended driver or a full sink-source differential driver.

It's a pity the current solution already uses differential drivers. Do both sides of the driver output still work? Or is the failure due to perhaps one of the lines no longer switching? It's possible that might explain why it bursts into life when the scope grounds one side.

I scoped it last night with 2 channels in differential mode and the output from the 485 were sweet (common mode noise all gone), particularly compared against the single ended measure (full of noise). Also, last night, changed the kernel frequency of the uc300 to 50khz to increase the pulse width to 10us (at 100khz kernel the pw is a rather narrow 5us).

The thing that gets me is that this was working fine. Going single ended feels an inferior move than differential driven)... unless one of the 485 outputs is starting to fail hi-z.

Equivalent input circuit is as you describe, opto, reverse diode and series resistor -330R

Quote:

---

Originally Posted by Muzzer

No, generally a single ended driver just sinks current. When you turn it off, the current into the driver stops. If there is a decent capacitance in / around the opto LED, it takes a few hundred nanoseconds to actually turn off completely.

---

Depends whether it's a bipolar/TTL or CMOS driver. The former tend to be MUCH better at sinking than sourcing, whilst the latter are pretty symmetrical due to the complementary output stage, e.g. the datasheet for the 74HC245 which is quite popular on cheapo BOBs shows 0.18V droop when sourcing 6mA and 0.15V when sinking 6mA: 30mV difference in the ~3V across the series resistor. Differential would still be a bit better as you potentially have 2x the voltage discharging aforementioned capacitance, but it's a darn sight better tah open collector drive.

Quote:

---

Originally Posted by Doddy

I scoped it last night with 2 channels in differential mode and the output from the 485 were sweet (common mode noise all gone), particularly compared against the single ended measure (full of noise). Also, last night, changed the kernel frequency of the uc300 to 50khz to increase the pulse width to 10us (at 100khz kernel the pw is a rather narrow 5us).
The thing that gets me is that this was working fine. Going single ended feels an inferior move than differential driven)... unless one of the 485 outputs is starting to fail hi-z.

---

This was 'scoping it at the controller end or your RS485 board? What sort of signal levels were you getting?

Okay, I'm half convinced that I'd got the PP+/PP- inverted (Opto in saturation?, recent cold snap?). Ignoring that I've wired it single-ended direct from the BoB and all is good again. I would look further at this but to be honest I need the space and time to look at other projects - this can wait until I need to open the cabinet again.

Quote:

---

Originally Posted by Voicecoil

This was 'scoping it at the controller end or your RS485 board? What sort of signal levels were you getting?

---

At the '485 board, which meant resting the scope on a bin, and leaning over the horizontal band saw whilst trying to set the math function up on a scope with a crap rotary encoder for the function setting. The waveforms were pretty much 5Vpk-pk though I wasn't really paying too much attention to that. Call it 2 and a bit divisions, and cramp in my calf.

Quote:

---

Originally Posted by Doddy

Okay, I'm half convinced that I'd got the PP+/PP- inverted (Opto in saturation?, recent cold snap?). Ignoring that I've wired it single-ended direct from the BoB and all is good again. I would look further at this but to be honest I need the space and time to look at other projects - this can wait until I need to open the cabinet again.

---

Glad to hear it's working again - sometimes practical considerations are far more important than reaching ideal theoretical solutions!