By continuing to use this site, you agree to our use of cookies. Find out more
Forum sponsored by:
Forum sponsored by Forum House Ad Zone

Arduino Gear Hobber

All Topics | Latest Posts

Search for:  in Thread Title in  
John Haine28/07/2020 16:59:11
5563 forum posts
322 photos
Posted by Bazyle on 28/07/2020 14:26:55:

This was possible with CMOS discrete chips back in the day but they became obsolete and difficult to get which is what drove JS to find someone who could do it in software.

Nothing obsolete about CMOS discretes - TI list a full range for one.

Yes, with a PLL you need more than 1 ppr to follow the spindle speed variations. But say a 100 or 200 line encoder is a lot easier than a 4000 line one.

sam sokolik28/07/2020 17:06:18
126 forum posts
Posted by SillyOldDuffer on 28/07/2020 16:04:08:
Posted by Bazyle on 28/07/2020 14:26:55:

...

The first problem with most of the micros with a 'high level' operating system is that they don't tell you that they go off and do their own thing every few milliseconds which interupts the flow.

Coincidently I've been looking at the possibility of using a RaspberryPi 3 or 4 and Rasbian Linux as a microcontroller. Advantages: a real operating system, multi-core 64 bit CPU, built-in GPU, FPU, wifi, usb, print support etc and cheap. The CPU in a Raspberry is considerably more powerful than both Arduino and Nucluo. Disadvantages: limited number of IO pins (about 40), delicate interface electronics, no easy access to hardware interrupts, and the default Completely Fair Scheduler (CFS) that causes Bazyle's impossible to predict interruptions.

CFS is the main problem: it's designed to share multiple tasks across multiple cores such that tasks don't get stuck. Basically tasks run in a time-slice allocated by the operating system and return to the queue when time runs out or they stop for any reason such as waiting for a disc drive. Tasks are restarted by CFS in a fresh time slice when whatever it's waiting for is available, or it rises to the top of the queue again. Although there's some notion of priority, the scheduler pays lip service to it, unless it's reduced! (You can volunteer to stay at the back of the queue.) Anyway, given a queue of tasks waiting for a time slice, CFS selects the task which has least time on the system so far and everything gets a fair crack of the whip. Works very well except when a program must run to a timetable or respond immediately to events. This sort of task needs to stay at the top of the queue without being mucked about by routine business!

The ideal answer is a Real Time Operating System, and there are some for the Raspberry for those with time to investigate. Bit too specialised for me. However, newer Linux Kernels come with scheduler options that might be 'good enough' for embedded work. The Deadline Schedule gives favoured tasks the priority they need to meet a deadline, FIFO does First In First Out, and Round Robin is FIFO with time slices. All these options override CFS and allow tasks to queue jump and dominate. Unfortunately they can't take the system over completely because Linux has other essential jobs, but - on a multicore CPU - they get close to running continually, behaving rather like a fast embedded microcontroller with short glitches.

The open question is, can a linux program with 4 cores available and top scheduling priority do better than an Arduino? Worth a try I think.

Not recommending Raspberry for John's Hobber. Nucleo is a very good choice if faster than an Arduino is needed, and the programming can be very similar.

Dave

I have been playing with linuxcnc on the RPI 4. Linuxcnc requires a realtime kernel. (in this situation - rt_preempt)

The thing with linuxcnc is you get a whole bunch of realtime building blocks. Like step generators with vel and acc limits, pwm generators, logic and tons of other pre-built realtime components. (plus you can make your own)

All of these components have been tested and are done

This was done on a RPI 4 With a custom realtime component - slaving the axis to spindle rotation. (well - most all the latest videos about the green machine are done with the rpi)

Joseph Noci 128/07/2020 22:03:50
1323 forum posts
1431 photos

John Rutzen said:

You do need to sense the position on the cutter at all times and its position must be accurate, 4000 P/R is what is suggested so you need a rotary encoder geared up to provide this.

True, to a point - I made the encoder a quadrature encoder so that I can sense direction as well - not really needed. So, if a Quad. encoder then you can use a 1000PPR encoder, which will give 4000 pulses per rev. That will 'limit' you to around 10 tooth gears as a minimum.

The power needs to drive the blank will depend on the method used. If it is worm driven then the power needs must drive the blank with no missed steps. A 4 amp stepper motor will do this . it isn't having to push against the cutter, the helix angle of the cutter keeps the blank rotating.

Also true, to a point. The power needed when running is low. However, the power must be sized to cope with the stepper acceleration requirements in relation to hob RPM, hob, pitch, and how quickly the hob reaches terminal speed. The key here is to ensure the best stepper acceleration possible.

To achieve that, you should feed the stepper driver with as high a supply voltage as possible - dV/dT must be large to overcome the stepper's inductance preventing current to flow for a short while..This really means try feed the stepper driver with at least 50v, even 60 to 70v if possible. Also run microsteps - go for at least 800 steps/rev, 1600 is even better. The microsteps are not to improve positioning accuracy, or even resolution ( it does not do any of those actually..) - microsteps help get past those low-end resonances as well.

You should also reduce mechanical inertia where you cannot control it - large driven pulleys, etc. Excess friction is a no-no, but some friction can be your friend - it helps stifle stepper resonance at the low end while accelerating.

Joseph, thank you for the point about stepper motor speed . I did the calculation and the worm gear is no use. E.g. cutting 10 tooth pinion, Hob running at 300 rpm, the blank has to rotate at 30rpm, max gear ratio for 200 rpm stepper is around 6:1. So need to go toothed belt drive route.

And also true, but maybe I scared you too much with my stepper speed warning! Steppers tend to lose steps for two reasons - At the low speed end - 4/5 rpm and up, to maybe 12/15 rpm - they suffer self resonance and this is where the greatest possibility of losing steps lies. At the high speed end - 200/300 rpm and up - maybe up to 800/900 rpm, steps will be lost if the stepper torque runs low - as the stepper increases in speed, so the torque decreases and its not linear! An 8 amp NEMA-42 stepper running at 1200rpm has lost nearly 90% of its sub 10 rpm torque.

Supply voltage plays a huge role in acceleration, and in high speed torque. A stepper supplied with 40v, will probably not run much past 400rpm AT VERY LOW LOAD. At 80v supply, it will supply that same torque at maybe 900rpm.

Back to the hobber-

What do we need in terms of driven blank/stepper drive ratios, versus hob pitch, etc.

Lets assume a hob rpm of 350 for these cases.

Well, for a Mod 0.8 - 10 tooth gear ( 8mm diameter blank - more or less..), the blank rpm = 35.

For a stepper/blank drive ratio = 40:1 - stepper rpm = 1400, for a ratio of 20:1, stepper rpm = 700.

For a Mod 0.8 - 150 tooth gear ( 120mm diameter blank) - the blank rpm = 2.3

Stepper rpm = 92 @ 40:1 ratio, and obviously, 46rpm @ 20:1

So you need to find a 'sweet spot' in drive ratios.

But, there are few tricks one can play to get past the resonance problem - Use high voltage drive, fit a flywheel to the stepper drive shaft - an aluminium disc, 55mm diameter, 15/20 mm thick, for a nema-23 motor is good - add a bit of friction to the blank drive shaft - eg, a felt pad that presses up a disc ( disc brake..) fitted to the blank drive shaft..

Or, fit a rattle damper to the stepper drive shaft - that will cure almost any resonance problem! I won't go into rattle dampers here - somewhere on the forum are my lost posts on teh subject..

What did I do? - My rotary table worm drive dictated the ratio - 40:1. I used a double stack nema 23 motor. I drive the motor with 75volts. The encoder is a 1000PPR quadrature unit.

The reason for a double stack motor - a nema 34 would be good for the torque curve, but is has much worse resonance issues with acceleration, mainly due to the larger rotor diameter. The nema 23 single stack ( square motor size) has a poorer torque performance and is marginal at 400 rpm drive on my rotary table ( with rattle damper) . The double stack motor offers almost the same torque as the single stack nema 34, and works well at 800/900 rpm with the rattle damper. Acceleration is very good.

So, I would suggest, go for a 30:1 to 40:1 ratio, use a double stack nema 23 motor, at 60 to 70 volts, and fit a rattle damper. That will give you a no nonsense solution with very good performance.

Anything down from this spec will also work, if you are happy to just go a little slower, halve the hob rpm, slow down on the feed, etc, and it will work!

Joseph Noci 128/07/2020 22:32:16
1323 forum posts
1431 photos

Now, that previous post was a long one...

Hers is a follow on, a little shorter..

On the software side - I would not go the route of PLL's, etc - a little too fiddly, and rather difficult when you want to add features or functions, esp if adapting a rotary table to do hobbing - a little more software makes the table dance all sorts of jigs - angular steps size increment, turns at specific RPM's, etc, etc. For a dedicated hobber, less so, but still , in my opinion, a lot easier to get to work, and modify, and add more gear tooth options, etc..

My software is very similar in operation to the ELS system I did for my lathes -

The Encoder gives pulses that are directly related to the angular position of the hob. We need to rotate the blank periphery at a rate that matches the rotational pitch rate of the hob.

The hob encoder gives 4000 pulse per rev. Lets say we have a hob pitch, and a gear blank number of teeth setting, that, with our stepper setup, means I have to give the stepper 1000 steps pulses to advance the blank by one hob pitch.

That's easy - Since the hob gives 4000 pulse / rev, and that's one tooth pitch, and that's 1000 stepper pulses, we simply place a divider between the hob encoder and the stepper pulses - divide by 4 and everything works! However, the divisor needs to cope with a myriad of ratios, many giving divisors with a remainder...

So I use a device known a Bresenham's line draw algorithm. this is a neat bit of math that generates a pulse train that is a result of interpolation of the present hob pulse and the desired stepper pulse, in a perfectly synchronised manner. Errors do not accumulate, and are averaged out over the 4000 pulse input pulse train.

It's simple and elegant, and works!

A 16MHz Arduino might however be a little pressured to do all this at the highest rates -

For a 10 tooth gear and hob rpm = 350:

hob rpm 350 - 6 revs/s = 24Khz pulse train from encoder ( 24 KHz interrupt rate)

Stepper RPM @ 40:1 ratio = 1400 (!) = 24 rev/s

Stepper pulse train, @ 1600 steps/rev - 24 revs/s * 1600 = 37KHz.

And then the processor must still execute Bresenhams, and do whatever else you want it to - monitor pushbuttons, etc.

However, the Arduino will do just fine if you are content to go slower, feed slower, etc...

Joe

(whew..)

 

EDIT - WRT Rasp-Pi - a huge overkill and a massive complication for noobs - have to contend with an environment that is so not machinist...

           WRT an operating system ( of ANY sort) - also a total overkill for these what amount to rather simple applications. An OS NEEDS to be deterministic for these applications, and good, solid RTOS's for these small end systems are notorious in their inconsistency, both in event sequencing and timing. Fine if running a 2GHz processor - a 100 cycle latency is around 50picoseconds and is is not really going to be noticed. 20 cycles at   16MHz WILL be noticed at a 16MHz processor clock, when trying to synchronize Encoder inputs, stepper pulse outputs, and Bresenhams..There is NO reason for an OS in a single function simplistic embedded system. There is even no need for an OS in complex single function systems, but rather the need for a scheduler.  I eventually even won that argument with BAe...

Edited By Joseph Noci 1 on 28/07/2020 22:44:04

Joseph Noci 129/07/2020 07:14:32
1323 forum posts
1431 photos

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 IoM29/07/2020 07:30:54
1395 forum posts
30 photos
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 Rutzen29/07/2020 07:34:11
411 forum posts
22 photos

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.

Bazyle29/07/2020 08:53:27
avatar
6956 forum posts
229 photos

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 Gilligan29/07/2020 09:14:08
avatar
23121 forum posts
1360 photos
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.

________

mgnbuk29/07/2020 09:26:26
1394 forum posts
103 photos

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.

SillyOldDuffer29/07/2020 10:04:50
10668 forum posts
2415 photos
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 webster29/07/2020 10:25:23
5307 forum posts
83 photos

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 329/07/2020 12:10:58
109 forum posts
23 photos

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 229/07/2020 13:01:41
avatar
1891 forum posts
37 photos

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 129/07/2020 13:10:54
1323 forum posts
1431 photos

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

stepper motor.jpg

Joseph Noci 129/07/2020 13:24:24
1323 forum posts
1431 photos
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 229/07/2020 15:24:08
avatar
1891 forum posts
37 photos

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 sokolik29/07/2020 16:06:03
126 forum posts
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 Other29/07/2020 17:56:41
327 forum posts
1 photos

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 229/07/2020 18:11:05
avatar
1891 forum posts
37 photos

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.

All Topics | Latest Posts

Please login to post a reply.

Magazine Locator

Want the latest issue of Model Engineer or Model Engineers' Workshop? Use our magazine locator links to find your nearest stockist!

Find Model Engineer & Model Engineers' Workshop

Sign up to our Newsletter

Sign up to our newsletter and get a free digital issue.

You can unsubscribe at anytime. View our privacy policy at www.mortons.co.uk/privacy

Latest Forum Posts
Support Our Partners
cowells
Sarik
MERIDIENNE EXHIBITIONS LTD
Subscription Offer

Latest "For Sale" Ads
Latest "Wanted" Ads
Get In Touch!

Do you want to contact the Model Engineer and Model Engineers' Workshop team?

You can contact us by phone, mail or email about the magazines including becoming a contributor, submitting reader's letters or making queries about articles. You can also get in touch about this website, advertising or other general issues.

Click THIS LINK for full contact details.

For subscription issues please see THIS LINK.

Digital Back Issues

Social Media online

'Like' us on Facebook
Follow us on Facebook

Follow us on Twitter
 Twitter Logo

Pin us on Pinterest

 

Donate

donate