Arduino Gear Hobber

[Joseph Noci 1Participant @josephnoci1]

Seems when I post, everyone heads for the hills….Did not mean to chase you all away! There are many ways of achieving the topics dictate – maybe telling the way I did it will help others not make my mistakes..

Joe

[Frances IoMParticipant @francesiom58905]

Joe – your posts + those from other Transmarines (a quaint term found in Manx deeds as ‘beyond the seas’) would be the ones I would really miss if they stopped.

[John RutzenParticipant @johnrutzen76569]

I appreciate what you have to say Joseph. It sounds like a lot of sense to me. No one wants to spend years and a lot of money only to get it not to work. I think it would be good if we could get this problem sorted out properly and the code published. The advantage of doing this on the forum is that others do criticise it.

[BazyleParticipant @bazyle]

I wonder what you think of this. If you are say cutting a 37 tooth gear you have to do a calculation every encoder pulse and decide what rate to pruduce the stepper pulses, and another and another etc. If you do a second 37 tooth gear you do it all again exactly the same, So why not do all the calculations in a desktop computer and download them into a big chunk of memory and have a very simple thing, maybe not even a microprocessor, that just keeps updating the pulse generator.

[Michael GilliganParticipant @michaelgilligan61133]

Posted by Joseph Noci 1 on 29/07/2020 07:14:32:

Seems when I post, everyone heads for the hills….Did not mean to chase you all away! There are many ways of achieving the topics dictate – maybe telling the way I did it will help others not make my mistakes..

Joe

.

Joe,

It’s time for my public confession …. which I hope will benefit the general discussion.

MichaelG.

________

A couple of years ago, I planned to build a gear-hobber of my own mechanical design
Joe stepped forward to offer software to drive it. … This was enormously generous and helpful.

Unfortunately, Joe’s brilliant concept for the tightly controlled drive, meant that the machine would become much larger than I could accommodate. … it turned-out that a NEMA 34 motor was needed, to provide ‘agility’ in a machine intended specifically for making small 32DP [Mod 0.8] gears.

I abandoned the project

The ‘lesson learned’ is [I think] that we need to fully appreciate the dynamics of what we want to do, before committing to the mechanics or the electronic control scheme. My choice of hardware simply didn’t match well with Joe’s beautiful concept, and the result would have been a monster.

________

[Ex contributorParticipant @mgnbuk]

I used a double stack nema 23 motor.

What stall torque rating was that please, Joe ?

"Nema 23" & "double stack" just give the physical dimensions of the motor & rated current is no indication of the motor performance either – I have Nema 23 motors rated at 2.2Nm stall that are longer & take more current than anothers rated at 3Nm. I have seen yet others rated 4Nm with the same physical dimensions as the 3Nm motor & with the same current rating. I would be interested to know the stall torque rating of the motor you used.

Servo motors are usually specified by their torque rating, yet this rarely seems to be mentioned in relation to stepper motors, where only the frame size gets mentioned despite there being options for a range of torque outputs within the frame size ?

Nigel B.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Joseph Noci 1 on 29/07/2020 07:14:32:

Seems when I post, everyone heads for the hills….Did not mean to chase you all away! There are many ways of achieving the topics dictate – maybe telling the way I did it will help others not make my mistakes..

Joe

Not at all Joe, I read all the posts with considerable interest, and they answer several questions I haven't asked yet. If I have a go at coding a Hobber your information would save me a lot of R&D time, maybe even avoiding a pitfall or three I might have got stuck in! All valuable info thanks.

Moving on, I see PIC, Arduino vs Nucleo vs Raspberry in terms of opportunity rather than competitors.

My background & experience happen to lead me to reject PIC instantly, but versions running BASIC would appeal to chaps who already know BASIC. (The other good reasons for choosing PIC don't tick my boxes.)

Arduino scores high on my list because it manages to be friendly despite being a C/C++ platform. Although thin on high-end tools like debuggers it's been made relatively easy to use. Well supported by the community and electronics trade. Although slow and short of memory Arduino's are robust and well suited to clumsy home electronics. Also, if needed, an expert programmer can penetrate the user-friendly shell and go deep into the works.

I also like Nucleo very much. They can be programmed using the Arduino IDE, or from the Web, or in grown-up mode. Much faster, more memory, and more hardware features than the Arduino family. Tasty! But there are disadvantages for hobby use – the I/O pins are more delicate and provide less current than an Arduino. And because they are so fast long leads dangling over a dining table prototype cause trouble. Being less well supported is a beginner disadvantage.

RaspberryPi 4 has all the advantages and disadvantages of a full-blown multi-user/multi-tasking operating system. Like Nucleo, Raspberry uses an ARM processor, but it's got 4 64 bit cores, each of which is about 5x faster than a Nucleo. It's ability to do do HDMI, USB, Gigabit Etherenet, Wifi are all attractive. Less usefully, it guzzles power, only exposes 40 I/O pins and those pins have limited functionality. No ADC or DAC, and maybe half a dozen I2C/Serial/SPI interfaces in total compared with 17 on a STM32F429. Many handy microcontroller functions like interrupts and multiple timers are missing or inaccessable. Even so, Raspberry has possibilities as an embedded platform. I'm not recommending it as a general alternative to Arduino, PIC or Nucleo, only suggesting it's a popular platform that might be useful for some embedded jobs.

Dave

[duncan webster 1Participant @duncanwebster1]

I've made an ELS to Joe's design and can confirm it is a wondrous beast! However could someone clarify a couple of points on which I'm confused

Joe tells us that a double stack Nema 23 is better than a Nema 34 because it has lower inertia, but also says fitting a flywheel helps.

With an ELS the stepper has to accelerate very quickly, but with a hobber can't it take longer to get itself in synch? Having to wait say 5 seconds after setting the spindle and rotary device going would not be onerous and would allow say 8 spindle revs. The controller could have an 'in synch' led.

[Paul White 3Participant @paulwhite3]

I too built Joe's ELS and must agree it is a wonderous beast.

I have also built the, Hobber / divider, to Joe's design, however the problems of accelerating the stepper to sync. with the cutter arbor would only arise if the machining was stopped mid pass, this is an operational technique situation, best avoided.

The matter of, stepper size required, has been stated as relevant to cutter rotational rate, cut back the rpm of the cutter and the stepper size required goes down. When using the ELS I always select a start point ,in the setting procedure, that is pre the actual cutting start , this allows any time needed for speeding up and backlash.

Just my thoughts on the matter.

Paul.

[Robert Atkinson 2Participant @robertatkinson2]

One way to improve performance of these systems is to combine hardware and software. Use hardware ro keep track of the encoder(s) and software to do the clever bits. When doing this sort of things for the day job we used HP/Avago/Broadcom encoder interfaces like thw HCTL-1100 and HCTL-2020. Now for critical counting applications I use Microchip PICs with built-in hardware counters and dividers. They also do versions with encoder interfaces built in. See http://ww1.microchip.com/downloads/en/DeviceDoc/70208A.pdf

Sone of the Atmel (now Microchip) chip range used in Arduinos have hardware encoder interfaces but I'm not an Arduino user so don't know if the specific chips are used or supported by the development environment.

Robert G8RPI.

[Joseph Noci 1Participant @josephnoci1]

Nigel, brief datasheet of the stepper I used ( and use on a few other machines a well) is posted below. It works well, where a similar Nm NEMA34 did badly.

I think Paul sums it up – go slow and gentle, gear it low, and even a NEMA 17 will do!

Duncan WRT the '5 sec wait' –

What Paul says is key – all this only matters if you wish to start and stop the job in process, with cutter engaged or ensconced with the teeth in the 'blank'. If you are ok with first retracting the cutter completely and start again with it retracted, wait a few seconds for everything to catch up, and then put on feed again, then you can get a way with good gearing and smaller stepper motors.

Stopping the job with the cutter still ensconced is fine – the stepper will decelerate at the same rate as the hob drive and motor decelerate – as there is more rotating mass there, as higher speed, that lot will take a few seconds to halt, and so the stepper is very happy. Its the start that is the issue, and only so if you wish to stop in situ to have a gander at the teeth appearing, and then restart from there.

This situation is present in the lathe ELS setup at as well. It is in fact worse, because the stepper has to accelerate the whole apron's weight, and fight the main slide friction. Since it is impossible to accelerate from zero to full in an instant, we start the thread with the cutter say 2 or 3 threads away from the workpiece. This give the stepper 2 or 3 spindle rotations time to catch up – the start of the thread , and of stepper movement, is sunced to the spindle index pulse. At that point the software counts how many spindle encoder pulses ( @ 1000PPR) are coming, and so know how far behind the stepper is lagging. The stepper pulses are then accelerated, so much so to go past the constant feed rate, so that the apron is in fact fed at a speed greater than the thread pitch being cut. At a point the stepper pulse count exceeds the required rate and the stepper starts decelerating, until the pulse rate is correct for the pitch speed of the thread being cut. THAT point must co-inside with the thread start point on the work piece…An so it all comes together.

The exact same principle is followed on the hobber ( mine and Paul's) . The faster the stepper can accelerate, the smaller the number of pulses the stepper is lagging behind the encoder, and the closer it all is to engagment.

If the stepper on the lathe ELS were undersized, ( not too under that it cannot drive the apron properly!) you could still do the job – simply start 4 or 5 or 10…threads away from the workpiece thread start point.

Duncan, the flywheel thingy….This is an area where it helps if you are direct cousin to Gandalf…there are scientific ways of working out what size flywheel will help, but the data set needed is impossible to accumulate in our environment! Friction coeff's, inertial masses, etc….So you have to suck your thumb a little and apply some basic first principles. Since the stepper 'steps', ie, it sort of stops at each indent, it behaves like a spring. If you attach a weight to a spring, you change its resonant frequency – so thats all you are trying to do. Fit a flywheel and see what happens. If the loss of steps are at the upper end of low rpm ( 10 to 20rpm maybe) increase the flywheel diameter, etc. The rattle damper through some magic ( !) dampens more than just a narrow frequency range, so is more effective.

Joe

[Joseph Noci 1Participant @josephnoci1]

Posted by Robert Atkinson 2 on 29/07/2020 13:01:41:

One way to improve performance of these systems is to combine hardware and software. Use hardware ro keep track of the encoder(s) and software to do the clever bits. When doing this sort of things for the day job we used HP/Avago/Broadcom encoder interfaces like thw HCTL-1100 and HCTL-2020. Now for critical counting applications I use Microchip PICs with built-in hardware counters and dividers. They also do versions with encoder interfaces built in. See http://ww1.microchip.com/downloads/en/DeviceDoc/70208A.pdf

Sone of the Atmel (now Microchip) chip range used in Arduinos have hardware encoder interfaces but I'm not an Arduino user so don't know if the specific chips are used or supported by the development environment.

Robert G8RPI.

That is true to some extent Robert. It depends on what the 'divisor' method is that you wish to implement.

Since the objective here is to keep the stepper pulse rate AND TIMING synchronized to some relationship to the incoming encoder pulses, you cannot just let the hardware counter accumulate the encoder pulses and then get to them 'later' – in the meantime you were supposed to generate stepper pulse so you lost the plot…

Synchronized operations like this require real-time software response – and the definition of real time is any time as long at the software keeps up with the execution rate required.

Joe

[Robert Atkinson 2Participant @robertatkinson2]

Agreed, you can't just let pulses accumulate, but if you know you need n encoder pulses per stepper output pulse you just preset the hardware to max count -n (or n and count down) and on overflow (or zero) generate a interrupt or even better, some chips will generate a hardware pulse on overflow. As you imply there is no such thing as realtime software, just fast enough to create the illusion. Using controllers with hardware intended for this type of application allows the embedded hardware do the time crtical work while the software does the user interface and calculate things like the encoder/step ratio. There are lots of ways to this and everyone will have a preferred method. A lot of th work I've done before had a lot of variability (some actually truely random) in timing so more susceptable to missing pulses. If everthing is on a regular timescale it's a lot easer to acheive accuracy.

Robert G8RPI.

[sam sokolikParticipant @samsokolik60334]

Posted by Joseph Noci 1 on 29/07/2020 13:24:24:

Posted by Robert Atkinson 2 on 29/07/2020 13:01:41:

One way to improve performance of these systems is to combine hardware and software. Use hardware ro keep track of the encoder(s) and software to do the clever bits. When doing this sort of things for the day job we used HP/Avago/Broadcom encoder interfaces like thw HCTL-1100 and HCTL-2020. Now for critical counting applications I use Microchip PICs with built-in hardware counters and dividers. They also do versions with encoder interfaces built in. See http://ww1.microchip.com/downloads/en/DeviceDoc/70208A.pdf

Sone of the Atmel (now Microchip) chip range used in Arduinos have hardware encoder interfaces but I'm not an Arduino user so don't know if the specific chips are used or supported by the development environment.

Robert G8RPI.

That is true to some extent Robert. It depends on what the 'divisor' method is that you wish to implement.

Since the objective here is to keep the stepper pulse rate AND TIMING synchronized to some relationship to the incoming encoder pulses, you cannot just let the hardware counter accumulate the encoder pulses and then get to them 'later' – in the meantime you were supposed to generate stepper pulse so you lost the plot…

Synchronized operations like this require real-time software response – and the definition of real time is any time as long at the software keeps up with the execution rate required.

Joe

This is actually how linuxcnc works with external interface hardware. (not a motion controller as the motion controller is in software – linuxcnc) The external hardware just does the stuff computers don't do well (fast encoder counting, High speed step generation, Pwm generation and such) Linuxcnc is running a realtime thread that polls the external hardware every 1ms (or 500us or whatever the system can handle) It gets the encoder counts, sets pwm levels, sets step rate and so on. This works very well. (as a cnc controller and hobber as others have shown)

The other thing you get with with a computer running linuxcnc – floating point calculations. (this is the stuff the computer does well)

sam

[An OtherParticipant @another21905]

Very interesting thread – since Arduino is 'open-source', many companies market copies and developments. One such is Redboard (US I think), and they market an Arduino UNO compatible board which runs at 48 MHz (3X faster clock than the standard 16MHz UNO) – it can be programmed using the familiar Arduino IDE.

Redboard stuff seems to be marketed fairly widely. I haven't done the calculations, but this may be useful to those familiar with Arduinos, and get round the speed problems. (no connection with Arduino or Redboard).

[Robert Atkinson 2Participant @robertatkinson2]

It should be noted that a stepper driven CNC X/Y/(Z) system where you are controlling all axis is a lot easier than a gear hobber or Electronic Lead Screw where you have to syncronise with a spindle that you have no control over.

Robert G8RPI.

[ToolParticipant @tool]

There is a board that I use called a Teensy 4.1, it is programmed using the Arduino Ide. It is very easy to use and operates at 600MHz. I think it was less than £30. It has encoder inputs. Might be a contender?

[SillyOldDufferModerator @sillyoldduffer]

For lovers of speed trials, I compared how fast Arduino, Nucleo and Raspberry can flip an output pin:

Arduino Uno using digitalWrite() – 3.30uS pulse width (approx 150kHz)
Arduino's DigitalIO library – 0.94uS (approx 0.5 MHz)
Arduino direct IO register bit toggling – 0.31uS (approx 1.1MHz)

Nucleo F446RE and mbed DigitalOut with out = !out; – 0.15uS (approx 3.4MHz)

RaspberryPi3B (Completely Fair Scheduler) – 0.042uS (approx 11.6MHz), with occasional jitter.
RaspberryPi3B (FIFO Real Time) – 0.042uS with no obvious jitter.

Ought to explain Arduino's digitalWrite() is slow compared with absolute top speed because the function stops the programmer from making silly mistakes. Bit twiddling IO may be fast but it's hard to understand and easy to get horribly wrong. The DigitalIO library is a good compromise and similar to mbed's approach to IO.

Anyway, without resorting to bit twiddling, a Nucleo can pulse 3 times faster than an Arduino, or 22 times faster if the Arduino programmer sticks to digitalRead() and digitalWrite(). This is a good thing!

However, the RaspberryPi3B wins this simple contest – it's 3.6 times faster than a F446RE, and 83 times faster than Arduino's digitalWrite().

Speed writing isn't exactly a fair test of computers. Comparing power consumption, I'm sure the Nucleo would be clear winner. And I think a Raspberry would come off worse running a benchmark testing inputs on several pins. I've no idea how quickly Linux can react to a pin change – as there are no microcontroller-style interrupts, processes have to rely on signals from the operating system, which are probably slow, or polling, which is wasteful.

I also need to investigate the results further. With an ordinary oscilloscope it's hard to catch rare gaps in a pulse stream, so my report may be optimistic. Meanwhile I put absence of obvious jitter down to the scheduler having access to 4 cores. While my test program ran with top priority on one core, the other 3 were easily able to handle the other 132 dozy tasks on the system.

Dave

[SillyOldDufferModerator @sillyoldduffer]

Posted by Tool on 29/07/2020 18:27:16:

There is a board that I use called a Teensy 4.1, it is programmed using the Arduino Ide. It is very easy to use and operates at 600MHz. I think it was less than £30. It has encoder inputs. Might be a contender?

Sure is! Spoilt for choice…

[Joseph Noci 1Participant @josephnoci1]

Posted by Robert Atkinson 2 on 29/07/2020 15:24:08:

Agreed, you can't just let pulses accumulate, but if you know you need n encoder pulses per stepper output pulse you just preset the hardware to max count -n (or n and count down) and on overflow (or zero) generate a interrupt or even better, some chips will generate a hardware pulse on overflow.

As you imply there is no such thing as realtime software, just fast enough to create the illusion. Using controllers with hardware intended for this type of application allows the embedded hardware do the time crtical work while the software does the user interface and calculate things like the encoder/step ratio. There are lots of ways to this and everyone will have a preferred method. A lot of th work I've done before had a lot of variability (some actually truely random) in timing so more susceptable to missing pulses. If everthing is on a regular timescale it's a lot easer to acheive accuracy.

Robert G8RPI.

Bear in mind that my implementation ( and almost ALL ELS type systems out there) uses Bresenham's. Hardware counters simply don't work with this because you would have to read the counter every single encoder pulse anyway to know when to change the hardware counter divisor ratio. – There cannot be a 'constant' ratio between encoder pulses and stepper pulses that you can simply load into a counter –

An ELS example, let the leadscrew pitch be 5mm and we want to cut a 1.5mm pitch thread. Lets say the stepper to leadscrew drive ratio is such that the stepper must turn 0.3 turns for every spindle turn. Lets also assume the stepper is set to 1600 pulse/rev. Thats 0.3*1600 = 480 steps , ie, 480 step pulse for every 4000 spindle pulses. Thats 1 stepper pulse for every 8.3333333333333333333333333 encoder pulses…….

Now the remaining 0.333333333333333333 pulse has to be evenly distributed over stepper pulses to minimize the resultant pitch error. You cannot load a counter with 8.3333, and even if you use a pulse-swallowing counter ( like the good old odd/even prescalers..) you have to switch it at a rate that evens out the 8.3333 by setting it to divide by 8, then by 9 at some point , for a little while, then by 8 again for a little while, etc..and to know when to do that, you need to know where you are in the sequence of groups of 8 and 9 pulses…

That's why Bresenham took us out of our misery.

And from Sam:

Pwm generation and such) Linuxcnc is running a realtime thread that polls the external hardware every 1ms (or 500us or whatever the system can handle)

I did try LinuxCNC out, but did not enjoy the experience – it was long ago, it was not called LinuxCNC then – can't remember the name as it was then…

But, I would hope that the core heart rate is a lot better than 1ms or 500us, or even 100us? Since in Bresenhams you HAVE feed the algorithm at the encoder rate, and with a spindle speed of say 400 rpm, a 1000ppr encoder will out pulses at 27KHz or 37us tween pulses. Since counters cannot implement Bresenhams, the software has to keep up. Nyquist says youd need to do 15us for that, under a heavy operating system, etc – For sure LinuxCNC doesnt do Bresenhams!

There are other ways – I think Dave ( SOD) did some study on alternatives?

[Neil WyattModerator @neilwyatt]

I used a hard coded Bressenham for my equatorial platform (on a Uno).

With a pulse rate of a few 2Hz there weren't any heavy demands on the processor…

Neil

[Joseph Noci 1Participant @josephnoci1]

Posted by Neil Wyatt on 29/07/2020 19:46:02:

I used a hard coded Bressenham for my equatorial platform (on a Uno).

With a pulse rate of a few 2Hz there weren't any heavy demands on the processor…

Neil

That's neat Neil! I'd be interested in your description how the setup functions – what are the inputs and outputs to/from Bresenhams doing? Maybe I shouldn't hog this thread any more though…!

Joe

[Andy PughParticipant @andypugh44463]

For this sort of thing I would[1] look at using a Feather from Adafruit, a lot more capable than an Arduino with floating point and orders of magnitude more memory, but programmable with the Arduino tools and IDE.

I think that you can setup a hardware interrupt on the spindle encoder pulses. Then in the ISR decide whether the workpiece motor needs a pulse or not. I am imagining here that the encoder resolution is high enough that there are more encoder counts per spindle rev than stepper pulses in the work spindle, but a factor of a few.

If that condition is not true then it is harder.

single-start hob, 12 tooth gear, 1024 PPR spindle = 12,000 ISR calls per gear blank revolution.

200 step motor, 4 x microstepping = 800 pulses per rev, so that is fine, one step every 13 encoder edges. It gets better for higher tooth counts.

Basically, in the ISR the code looks at encoder pulses counted so far, compares to step pulses sent so far, and if the ratio is more than the tooth count requested then it toggles the state of the step pulse output. This should be about as low-overhead as it gets.

Other approaches need to set up constant rate step-generators.

[1] Well, I wouldn't. I would (and do) use LinuxCNC for gear hobbing.

[Robert Atkinson 2Participant @robertatkinson2]

Hi Joe,

I'm not disagreeing with you and their are "many ways to skin a cat", but given your example the software can preset the counter with 8 for a couple of cycles, then 9, and back to 8. The software has to keep track of were you are but not actually count pulses. I'm a bit biased becuse one of our applictions was reading a 1 micron encoder on a bi-directional linear axis at a peak speed of 3m/s. This ran for several days with a cumulative error limit of 20 microns, A ruined run had a cost in 5 or 6 figures. We were compensating for thermal expansion etc. You only had to lose a few counts to lose a run. That did of course run on custom hardware implemented in FPGAs. No I didn't design the hardware or write the code. I did use a Rennishaw laser interferometer to verify the accuracy.

You have written great code and it works, I'm just suggesting some options for those having a go.
I am going to put ELS on my ML2(eventually, after I actually get it running) but am going to "cheat" and use an expensive Rockwell Automation servodrive and brushless DC servo motor that has built in electronic gearing to an external encoder. I'm only using that because I have it, it cost me nothing, I used the drive model for work in the past and still have the essential configuration software. It would be cheaper to buy a small CNC than put that package together with new parts, never mind sorting out the configuration.

Robert G8RPI

[Gerrit VisserParticipant @gerritvisser32558]

The clearest example I have seen of Arduino and gear hobbing is in this series of videos by F. Cleff. Unfortunately he lost his source code,and has not posted anything in quite a while. He had planned on serialing it for articles.

In episode VIII you can see how simple the code is, much of the added complexitiy is the user interface,

https://www.youtube.com/channel/UCF91fwCPdAZfGbnRfu8_dXg/videos

Gerrit, who is about to renew his MEW subscription to get the new series

[Author]

Posts