In order to minimize parts count, cost, and complexity while maximizing flexibility, I have settled on a servo for the winder’s traverse mechanism, rather than the traditional stepper or DC motor. It will I weighed the pros and cons, and I am just not happy with stepper arrangements of either a screw+cart traverse or a belt+pulley traverse because of movement speed, belt tension and wear, thread slop and backlash on fast reversals, etc. On my last winder, I used a stepper motor with a lever arm, which was the best tradeoff I could find, but for custom patterns using quick traverse movements, the shortcomings of that arrangement became clear (I think the arrangement is workable, but I am moving on). For a simple back-and-forth traverse, a stepper or DC motor works fine as generations of pickup winders have proven, but we don’t want to be relegated to coils with side by side pattern, so we will examine what we can do.
So let’s delve into servos.
WHAT ARE OUR RPM LIMITS:
The Arduino servo control software has a command window time of 20ms/50Hz (which is a holdover from radio control), so unless we re-write the library for faster time, 20ms = 0.05 timer pulses per ms = 3000rpm for the theoretical max software speed in terms of not missing a command for every revolution. If we are not concerned with absolute precision over every turn, we can make a high-ratio traverse, measure the max traverse time across the bobbin, divide by the number of turns, and then work out the RPM we can ramp up to… which can be theoretically as high as we want, but since most folks are used to 600-1200 RPM, I think that a reasonable target range would be around that: likely centering on 1000rpm, with speed variable +/- a bit from there.
Servos have a speed rating printed on the side as ‘torque/time/to travel this angle’. A 0.17/0.15s/60 servo will take 2.5 ms to move one degree after the controller board has received the signal and processed the command. A typical servo will require a 10 microsecond (0.01ms) change to move one degree followed by a 2.5ms rotation, we have a theoretical maximum 1 degree move time of 2.6ms+’processing overhead time’(i.e. hardware response time and main loop code efficiency). Which means that if we lived in a perfect world with an instantaneous code response, could we can rotate 7.7 degrees per window, max. But we don’t have instantaneous processing, sooo… onto the computer hardware.
In reality, it means that in a window we can move 20ms/(7.7ms + ‘processing time’) degrees, and since the Arduino is only a 16MHz processor, we have to be as efficient as possible in our code… I.e. if we want to send one servo move per revolution at 3000RPM we have to have code that executes our main loop in >/= 17.4ms, and at 1000rpm we have 57.4ms, etc.
So if we have a lot of math or slow commands… we are screwed. Take this example:
int servoAngle = 0;
while(angle < 180)
Testing with this code:
unsigned int time = 0;
time = micros();
<code to test>
time = micros() – time;
The function takes >40ms to execute. And some functions are real hogs. For example, the standard hobbyist LCD screen default baud rate is 9600, which is about 1ms per character, so if we have a 16×2 LCD screen, that is 32ms right there for all characters. So to trim down that response time, we would have to add a bit of code in our setup to change the rate. If we switch to 38400, the transmit time is 4x faster (you could also switch to a parallel display, try to pseudo-multithread the code, move static characters out of the loop, etc, but that is another story). Again, we can give up control over the servo for each turn and just use a single-command with the wire diameter averaged-out, but that really defeats the purpose, and we are back to being relegated to side-by-side coils again.
The Traverse mechanism:
For a coil winder, we want our traverse to be able to move AT LEAST one wire diameter per revolution of the bobbin on the spinner if we want to be able to lay the winds a perfectly side by side — and more than that if we are doing pattern winding (like a basket weave, bank wiring, etc) or computerized ‘scatter-winding’. So even though servos are fast, if we look at a worst case scenario with a 1:1 ratio of rotation to linear movement across to the opposite side of the bobbin winding window, our move would take 450ms with a 0.15s/60 servo. Translating that to practical use, the actual time it will take a traverse mechanism will depend on it’s design.
We are turning rotational motion of the servo to relatively linear motion for the traverse, so we can adjust the length of the servo arm and/or the ratio of any linkages to produce the final ratio… i.e.: a straight linkage will depend on the length of the arm, whereas something like a Scott Russell crank-and-slider or Chebyshev linkage or Roberts Straight Line linkage will depend on various other factors.
What all that means is that as we decrease the servo movement and increase the traverse movement simultaneously, we can hop greater distances on the bobbin within our command window time BUT at the expense of resolution… i.e. if we (mechanically, via the mechanics of the traverse mechanism) map 1 degree to 1 wire diameter, with .15s/60 servo, a 1000rpm speed, and a bobbin that lays down 60 turns per layer we would not be able to make the hop across the bobbin since the time would be trying to make a 150ms move in 60ms, but a 2.5 ratio traverse would be able to make it. However, we would have to switch to a finer controller resolution than 1 degree (such as Servo.writeMicroseconds) and mathematically map out the turn-to-traverse-distance, which can be done. OR we can slow the winding down to 400rpm, but that is painfully slow.
WHAT HAVE WE LEARNED:
-Both servos and the Arduino are capable of either custom patterns or precision side-by-side winding within typical winding speeds (<3000rpm)
-We can consider our maximum THEORETICAL winding speed to be 3000rpm to have a move command available for every turn with the standard Arduino servo library, but in practice we can’t hit that because of overhead
-Because of this, we can buy ourselves more precision by using lower speeds around 1000 rpm or so
-We can however wind faster if we don’t need absolute precision OR absolute control over winding patterns
-At low-ratio traverse mechanism ratios, our limiting factor is code efficiency
-At high-ratio traverse mechanism ratios, our limiting factors are code precision and mechanical slop
-We will have to write efficient code that doesn’t block the thread if we want to maintain control… but that is for another blog
Here is the initial prototype, we’ll see how it shapes up as things go along: