BBC Micro:bit versus Arduino and its use for a Rotary Table Indexer

[GreensandsParticipant @greensands]

I have recently been reading around the topic of the BBC micro:bit micro-controller and how it compares with the more widely based Arduino system. Having built and used the Arduino based rotary table Step- Indexer as described by Gary Liming I am wondering if anyone has designed and made an equivalent circuit based on the micro:bit controller. Should make an interesting comparison with the simplified approach to programming adopted by the BBC/Microsoft

[Dave SParticipant @daves59043]

Should be fairly straightforward, assuming you want full or half  stepping.

this https://kitronik.co.uk/collections/accessories-for-the-bbc-micro-bit/products/5698-compact-motor-driver-board-for-the-bbc-micro-bit will drive a small stepper.

Dave

[BazyleParticipant @bazyle]

Other stepper drivers might be better as many offer microstepping selected on board, say 16x so giving more resolution. Then just use step and direction lines.

It is interesting that this is raised wrt a development system designed for children / teenagers. 30 years ago the OPs request would have been right up the street of lots of the teenagers doing hands on real workshop activities who would actually know what a dividing head was. Now probably none understand the question.

Unfortunately the child aspect means lots of its I/O capability is directed at pretty LED displays on board.

Note the Microbit is not the same as the Micromite which is a smaller microcontroller using BBC Basic.

https://geoffg.net/micromite.html

https://microbit.org/

[SillyOldDufferModerator @sillyoldduffer]

By coincidence I’ve been looking at using a Raspberry Pico for this.   Both the pico and Micro:bit are based on ARM M0 Cortex, except the pico has two and they’re both at least as twice as fast as the micro:bit.   Might matter because MicroPython (which both platforms run) is rather slow, and Python might struggle to produce pulses fast enough to get decent RPM out of a rotary table.

Prodded by the late John Stevenson, who hated nested menus, I wrote an alternative to Gary Liming’s Arduino effort:  Gary used a combined 5 button/LCD  IO module, whereas I use a 4×4 keypad, and separate LCD display.  My version also has some extra features like backlash correction, undo/rewind, and remote control.   Performance is similar.  Intended to be an MEW article, but I thought World of Ward and Gary got there first.

The keypad eliminates nested menus by allowing numbers to be typed in directly, and simply by having more buttons.  I decoded my keypad thus, using A for Angle, B for Bump, ie ‘Jog’, C for continuous, and D for division steps.

 

 

 

I think 4 or 5 have been built, most recently by Peter Cook of this parish, who spotted a couple of bugs and suggested an improvement.   Looking at the code to confirm Peter was right, he was, reminded me I’d intended to revisit the code with a view to driving the table faster.  At the moment the Arduino drives a 90:1 HV6 reasonably, but I’d like it to be faster.

Motor speed is limited by how fast the microcontroller can send pulses to the controller, and is throttled in my implementation by how long it takes a 16MHz Arduino to loop through the control logic.    Written in C so adequately performant,  but my design does motor control by “bit banging” in software, which is slow.   I hoped to use one of the Arduino’s built-in hardware counter/timers to send a stream of ‘n’ steps on demand, which would be much faster but turns out the Arduino family doesn’t support that.

Same problem with the Micro:bit.    Python will make it easy to implement the control logic, but Python may not be fast enough on a 64MHz M0 to bit bang a stepper motor as quickly as needed.

The reason I’m looking at the pico is because it includes a Programmable Input Output peripheral/  The PIO contains 8 individual state machines each specialising in high-speed IO, making it very easy to send ‘n’ pluses.   Freed of responsibility for pulsing. MicroPython on a pico should be plenty fast enough for everything else.

I’m not sure about the Micro:bit.  As far as I can tell from the datasheet pulses would have to be “bit banged” by the software just as I’ve done on an Arduino, making the table’s RPM uncomfortably slow.  Confident it will work, but not that a microbit will be adequately fleet of foot.   Will a high-level, semi-compiled, user-friendly, garbage collecting Python program on a 64Mhz processor keep up with a fast. efficient compiled C program on a 16Mhz processor?    I suspect it won’t, because Python trades performance for fast development, whereas C delivers fast efficient executables that take much longer to write.

Adequate performance is relative though – even a downright sluggish electronic rotary table should outperform a human twirling a handle carefully, and the computer won’t lose concentration and make silly mistakes.   Indexing non-trivial angles with a rotary table manually is hard work, whereas a computer is a doddle.

For what it’s worth as an overview, the micro:bit targets learners, not a bad thing but the board comes stacked with goodies not needed for a rotary table.  Arduino is aimed at makers and the boards are robust rather than powerful, so not ideal either!  Arduino users are required to learn C/C++, albeit in user-friendly form, which some find too steep.   The pico is aimed at power-makers, either writing code in no-holds-barred C, or friendly but chug-along MicroPython.  Although the pico has a friendly aspect, it’s not as cuddly as a micro:bit.  On the other hand, the pico runs rings round the micro:bit if brute performance is needed, but it’s a shade harder to learn, much more so if C is used.   They can all drive a rotary table, but in theory I think the Micro:bit will turn it slowly. perhaps too slowly, unless recoded in C, much harder than Python or Scratch.

The way to find out is to prototype the software and measure how fast a Micropython microcontroller outputs pulses.  If a micro:bit gets anywhere near the speed of an Arduino, I’d say that was ‘close enough’.

Dave

 

 

[Robert Atkinson 2Participant @robertatkinson2]

The lack of a decent user interface probably limits the microbit.  Personally I’d just use a PIC microcontroller e.g 16F886 and PicBasicPro 3. All you need to drive a unipolar stepper from a PIC with 4 times microstepping is 4 transistors, resistors and diodes.
For personal use there is a free “student” version of PBP3 and it works with the 16F886
https://pbp3.com/
The other bits ou need (2 or 4 line LCD, input switches etc) are the same whatever processor you use.

Microstepping more tha 4 times is not very good for precision angle setting as the shaft angle attained depends a lot on the load.

Robert.

[Robert Atkinson 2Participant @robertatkinson2]

Post crossed with Dave’s.

I’m not an ardunio user but a bit surprised that it can’t send pulses to a stepper driver fast enough. A simple 8 bit PIC running at 16MHz programmed in PBP3 (a compiled basic) can esilly drive a stepper faster than the stepper can step. That holds true for the PIC generting a 4x microstep sequence to drive 4 transistor or direction and step pulses to an external driver module.

Robert.

[Robert Atkinson 2]

On Robert Atkinson 2 Said:

Post crossed with Dave’s.

I’m not an ardunio user but a bit surprised that it can’t send pulses to a stepper driver fast enough. …

My fault Robert, I didn’t explain the issue at all well!

If an Arduino, or PIC, does nothing other than toggle a pin, it easily outruns a motor-controller.  The issue is that a rotary table program has a great deal of other work to do.   A control loop monitors the keypad, parses commands, and drives a slow-mo LCD display.  Commands can be entered whilst the motor is running.

The requirement is to issue ‘n’ pulses that will operate a stepper motor controller at an acceptable rate, ideally user set.  Brownie points for altering the pulse width and rate to accelerate and de-accelerate the motor during start/stop.  (I haven’t attempted that!)

My ‘bit banging’ solution.  At the end of each control cycle, taking a few milliseconds, the program pulses the motor-controller, counting down the number of steps needed to fulfil the last command one at a time.   As the motor is slow, the program can’t simply send a stream of pulses at top GPIO speed, rather it emits one pulse only, repeats the control loop giving the motor enough time to move, and counts down until all the steps are sent.   Thus the pulse rate is limited by how long all the other processing in the control loop takes, which is much more time consuming than the couple of lines that start and stop an individual pulse.

A messy solution because pulse timing depends on balancing how much work the program does as a whole, how long each function takes, what the motor-controller can take, and how fast the motor moves.   Nothing in the code is allowed to block the control loop, and all the functions are engineered to do their stuff quickly.

I’m looking to off-load pulse management to the pico’s PIO peripheral, so that the speed of the control loop doesn’t affect pulse width or pulse rate.  Not quite as simple as letting the PIO run independently because the user must be able to pause and restart the motor – the PIO must be interruptible.

Another way of doing it would be to time slice the Arduino with a hardware timer, and run the whole thing off software interrupts.   Feels like overkill though, and I hate work!

Dave

 

 

 

 

[Robert Atkinson 2Participant @robertatkinson2]

Ahh,
OK that makes sense. I didn’t realise you were allowing data entry during moves other than stopping.  Interrupts would be the normal way of doing that but it can be a lot of work.
I can’t talk, you are the one who has done it.
Both a a rotary table drive and ELS are on my to do list but (unusually) I’m doing similar work in the day job so don’t feel doing it after work.

Robert.

[John HaineParticipant @johnhaine32865]

I don’t know why people don’t just use GRBL to generate the pulses, sending it appropriate g-code commands.  Takes care of all the high speed pulse stuff, acceleration etc, runs on an Arduino Nano.  Then use another Nano, or a Pico or whatever for a UI.  Since GRBL can run 3 axes, you could use another one for the table feed for each cut.

[BazyleParticipant @bazyle]

The GBRL suggestion makes sense. We didn’t find a quick answer to the OP’s question but maybe there is existing code for GBRL associated with 4th axis for a CNC engraver.

[Robert Atkinson 2Participant @robertatkinson2]

GRBL seem like overkill for a single axis. The basic commands don’t even support direct angular positioning as it is designed for interpolation on an X-Y system.

The idea of using two processors, one for tha stepper driving and another for the machine interface is valid. Particuarly given the low cost of processors. I have used this approach even on professional products where the number of products produced is low, and development times short. In these cases the cost of programming time, particuarly if you have to validate your code, is higher than multiple processors costing a pound or two. It can also simplify the software making valibation easier. An example wasa ventillator prototype. This used a total of four processors one for interface, one for control and two identical PID valve drivers. This allowed it to be accepted as “simple” code without an RTOS or even interrupts. Thus the level of validation required for this truly “safety of life” system was minimal.

Robert.

[Bazyle]

On Bazyle Said:

The GBRL suggestion makes sense. We didn’t find a quick answer to the OP’s question but maybe there is existing code for GBRL associated with 4th axis for a CNC engraver.

Both grblHAL and FluidNC support 4 axes (up to 6, I think) and are backward compatible with the original GRBL.

 

FluidNC

grblHAL

 

 

[Robert Atkinson 2]

On Robert Atkinson 2 Said:

GRBL seem like overkill for a single axis. The basic commands don’t even support direct angular positioning as it is designed for interpolation on an X-Y system.

 

So what? Compared with having a Nano plus custom software why does it matter?  And though it’s “designed” for linear positioning  it’s only a matter of setting the “steps per” for a degree rather than a mm.  Plus it gives you the option of driving other axes for free.

[IanTParticipant @iant]

“The reason I’m looking at the pico is because it includes a Programmable Input Output peripheral/  The PIO contains 8 individual state machines each specialising in high-speed IO, making it very easy to send ‘n’ pluses.   Freed of responsibility for pulsing. MicroPython on a pico should be plenty fast enough for everything else.” (DoS)

 

I saw the Micro.bit article and thought it was very interesting but (as I’m sure you will recall) I converted to MicroMites (PIC32s) many years ago and these days use PicoMites in my projects. I thought it worth mentioning that PicoMites can run their PIOs at very high speeds using a PIO ‘Assembler’ – I’ll paste the introduction to this from the PicoMite manual below. One user has built 6-channel a logic analyser that can run at 40Mhz per channel using a PicoMite – so speed really isn’t a problem if you use this feature, quite apart that most PicoMites can be clocked at over 300Mhz

However, I think it would be simpler to use a commercial stepper motor controller rather than bit-bang the motor. These days I also use my (Android) phone to connect to my Mites using WiFi (PicoW based ‘WebMite’) or Bluetooth and a simple HC-06 set-up, Just serial connecitons but they work very well.

 

Regards,

 

IanT

 

Introduction to the PIO
The RP2040 has many built in peripherals like PWM, UART, ADC, SPI. In addition the RP2040 chip contains
two PIO blocks, rather like cut-down, highly specialised CPU cores. MMBasic refers to them as PIO0 and
PIO1 in line with the Raspberry Pi documentation. They are capable of running completely independently of
the main system and of each other. They can be used to create such things as very high accuracy serial data
interfaces and bit streams, although they are by no means restricted to this sort of thing. They can be made to
run extremely fast, with a throughput of up to 32 bits during every clock cycle.
Before a state machine can execute it’s program, the program needs to be written to PIO memory, and the state
machine needs to be configured.
This appendix describes the support MMBasic can give in using PIO. It does not contain an explanation how to
write PIO state machine programs. For better understanding how the PIO state machines work look at
following thread “PIO explained PICOMITE” on the thebackshed.com forum:
https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=15385

[John Haine]

On John Haine Said:

I don’t know why people don’t just use GRBL to generate the pulses, sending it appropriate g-code commands.  Takes care of all the high speed pulse stuff, acceleration etc, runs on an Arduino Nano.  Then use another Nano, or a Pico or whatever for a UI.  Since GRBL can run 3 axes, you could use another one for the table feed for each cut.

Could do, but then you need another program to generate the G-Code, and have to learn to operate it!

A rotary table fitted with index plates needs no software at all, but the operator has to fit the indexer, look up the setting in the the manual, and then manually turn the handle ‘n’ rotations plus ‘p’ index notches, and repeat.  I find it all too easy to lose count, and just for laughs the HV6 index setting table has a few errors!   Manual indexing is quite hard work and error prone.

 

A dedicated rotary table like World of Ward, or Limings, or mine,  basically replaces the mechanical indexer system with a microcontroller, input system, display, and stepper motor.   Thereafter, all the counting and maths is done by a program.  All the operator has to do is tell the microcontroller what angle is needed, and press ‘go’.    They’re easy to use, the chief objection to Gary Liming’s version being that his use of a delightfully cheap and widely available keyshield module makes a nested menu necessary, because the keyshield only has 5 usable buttons.

 

Normally, rotary table drivers are just a black box, plugged into the mains, and connected to a stepper motor replacing the rotary table’s crank handle.  Meant to be easy to use rather than feature packed as full CNC has to be.   The operator plonks the black box down anywhere handy, types in what he wants the table to do, usually just turn an angle, and then hits the go button.  Mine is mostly used for cutting gears: all it does is turn the blank one tooth space at a time, and then stops whilst the tooth is milled, before I tell the balck box to turn the blank again.  No need to worry about the complexities of grbl or how to generate g-code for straightforward indexed table turning, for which a simple push-button interface is ideal.

My code allows the black box to be commanded remotely by a USB connected PC as well as obeying the keypad, providing a sort of junior CNC capability, but I’ve never used it in anger, and now think the remote feature is an unnecessary complication.

Dave

[IanTParticipant @iant]

I use this Kitronics motor controller to remote control dual DC motors (with a PicoMite mounted on it) in my model G3 (battery electric) locomotives. It can also be used to run a stepper motor too, although I’ve not done so yet. It’s a very tidy solution and quite affordable (about £9-10 pounds from Farnell or Pi Hut)

I do have a mechanical application in mind that will involve controlled ‘steps’ and I will use a Kitronics Controller + a PicoW (WebMite) connected to my phone – via our home router. A serial WiFi app on the phone has ‘macros’ set-up that will both step and change settings. Frankly, I never imagined I had the neccessary ‘skills’ to do something like this but a very interesting YouTube by ‘0033mer’ got me ‘up and running’ so to speak – https://www.youtube.com/watch?v=SoIjVfdcqLs

When I started using MicroMites (PIC32 based) the o/p devices were plumbed in using veroboard set-ups and a good degree of wiring/soldering etc. Using a ‘standard’ device like the Pico does make life a lot easier with so many useful plug-in accessories available for them (it’s very much on par with the Arduino now). Any PicoMite can use these Pico accessories, so this makes them very easy to use and affordable.

However, I think I may have ‘missed’ your rotary table work Dave – do you have a link to more details please?

Regards,

IanT

[Robert Atkinson 2Participant @robertatkinson2]

SOD basically answered for me, thanks Dave.
Im no G-code expert but it also seems to me that you wouldneed a second CPU and custom code to generate G-code commands for manual operation of the table.

Not everyone uses CAD. Indeed not using CAD or using CNC is a very good reason for wanting a motorised rotary table….

Robert.

[Peter Cook 6Participant @petercook6]

To add some numbers to the discussion. As Dave mentioned above , I have used his code to drive my little no-name 4″ table. The motor driver is set up to for 8 micro steps or 1600 steps per rev, and the table worm is 72:1.

Dave implements bit banging with a 500us delay to control pulse width and then does speed control by inserting a further delay into the main loop. After making some minor changes to the code to alter the delay times, my little table produces these figures. The first column is the rotation speed – measured by timing 90 degrees of rotation using the angle function. The third column is the delay included in the main loop, so the top row is full speed.

deg/sec pulses/sec delay ms
4.3         1376        0
3.2         1024        0.25
2.5           815        0.5
1.6           506        1.25
1.0           310        2.5

4.3 degrees/second is about as fast as I could comfortably whirl the handle, and works fine for small (25-30mm) radius cuts in aluminium. My little (SX1LP) mill struggles to do the same cuts in steel so I use 2.5deg/sec.

One jog step is about 11seconds of arc – which is more than enough precision!

I suspect I could speed things up somewhat by reducing the number of micro steps to 4  and also by reducing the 500us pulse width, but so far the unit has done everything I need.

Thanks Dave!

 

[Robert Atkinson 2]

On Robert Atkinson 2 Said:

Im no G-code expert but it also seems to me that you wouldneed a second CPU and custom code to generate G-code commands for manual operation of the table.

 

I use GRBL to drive the X axis power feed on my mill.  I drive GRBL from a free utility called Grbl Controller (GC) on my phone, which talks to the Arduino through Bluetooth.  GRBL is configured through a simple script which you compose on the phone once and it remembers it.  You would configure say the Y axis for 320 steps/unit – nothing in GRBL says it has to work in degrees. GC supports jogging, if you set the step size to “1” and tell it to jog the axis would rotate 1 degree at a speed you can set also from the GC jog screen.  The X axis can be used to move the table to for example apply the cut.  In this configuration with 2 axes driven by GRBL you get X axis power feed and a rotary axis.  User doesn’t have to touch g-code.

You could of course have a second Arduino, or any other small processor, set up to handle the UI with the type of screen and keypad Dave shows.  In fact you could probably use the same UI software, strip out the pulse generation, and insert some simple code to generate g-code commands.  For a move like the one above rotating at 4*/sec = 240*/min it needs to output:

G1 Y1 F240

Complicated isn’t it?

Actually I haven’t yet driven the rotary axis on my mill with the “2 axis CNC controller” box I built as previously I made a Ward controller.  I do however use it to drive the rotary axis and feed axis on a simple coil winder I made.  Again I use GC to send a simple g-code program which itself is generated by another bit of open source software.

[duncan webster 1Participant @duncanwebster1]

I have an early version of the SOD code, but I modified it to have ramps and increased the top speed. It works, but I haven’t had the need to use my dividing head since. Still it was an interesting project

[NealebParticipant @nealeb]

I have a project in mind at the moment which involves real-time control of both some electronics and a stepper motor, such that feedback from the electronics will determine what to do with the stepper motor. I also want a user interface, with things like pulse frequency and duty cycle control, machine start/stop/home type of functions, some of which need variation in real time while the machine is running. My interest in the current thread is to do with the overall architecture of the system. So, I need to monitor a keypad of some kind, plus drive a simple display (4×20 – something like that) showing system parameters and state, again in real time.

I read suggestions here that splitting the functions between a couple of processors, each dedicated to certain tasks, might be a good way to go. I lean towards Arduino simply because I have used them before (including use with GRBL) although I know quite a few people who would automatically go PIC – although I see some tempting alternatives mentioned in this thread!

My “architectural” question, though, is, if you are using something like Arduino or, I guess, PIC, how you get them to talk to each other. Never had to do this! The UI processor needs to update parameters used by the electronics driver processor – but how? Maybe the PicoMite is the answer, where there is a co-processor or two that could handle pulse generation, etc (and maybe pick up feedback voltages from the electronics?) and presumably communicates with the main processor via shared memory.

Unfortunately, this is the kind of question where n responders will come up with n+1 opinions, all of which would work!

[IanTParticipant @iant]

I have an unused UNO laying around that would run GRBL for my particular application John. It’s not speed sensitive in the same sense as a CNC axis is.

I assume that you are simply sending G-Code (text) messages to the GRBL controller but there must also be some sort of handshake with the ‘sender’ ?  Presumably the Android app manages this process? I’ve not looked at this in detail as both my GRBL controllers came built in (e.g. 3D Printer & CNC router)

I’ll guess that GRBL (on the UNO) either sets a pin high (or low) or sends some form of ‘ACK’ etc – to indicate it’s OK to transmit and maybe there is some form of internal buffer. This is probably well documented somewhere but I’ve not had the need to know before…  🙂

 

Regards,

 

IanT

[IanT]

On IanT Said:

…
However, I think I may have ‘missed’ your rotary table work Dave – do you have a link to more details please?

Regards,

IanT

 

Hi Ian, this Dropbox link should take you to a folder containing the necessary files:

1. rotarytable.pdf is a draft MEW article describing the project and build.
2. the folder keytab_ic2 contains 3 versions of the arduino sketch program.   keypad_i2c_v1a.ino is the latest with Peter Cook’s improvements.

Dave

[IanTParticipant @iant]

Excellent, thank you Dave!  🙂

Nealeb: “My “architectural” question, though, is, if you are using something like Arduino or, I guess, PIC, how you get them to talk to each other. Never had to do this! “

Talking as a complete amateur, in my experience old fashioned serial connections have a lot going for them – in what I think of as being simple “Command & Status” applications. These can be both ‘keyboard’ (manual) and 2nd CPU (automated) connections. These are generally one-to-one, duplex serial connections, requiring just crossed TX/RX connections and at their most simple, just two physcial wires.

In practice you can use all sorts of ‘actual’ connections, such as ‘serial’ over WiFi & Bluetooth or longer range radio (LORA etc). Some systems come with these abilities already embedded (PicoW, ESP32, Rpi etc) but it is usually simple to add them using external devices such as the HC-05/6 or HC-12.  If a wired connection is preferred but distance is an issue then RS232 (up to 50ft) or RS485 (up to 4000ft) adaptors can be used. The point is that a serial connection can be made over a number of different connection types but they all look (to the software used) like just a couple of wires. Of course, some devices need configuring and some applications may need some form of handshake and/or error checking.

There is another approach used that involves an I2C connection between two (or more) devices and this has been used to set-up master-slave devices that (for example) increase the number of available I/O ports or to off-load tasks to a secondary processor. I2C Master/Slave commands are fully supported within MM Basic and there is an example of two Picomites communicating using I2C (including the code) given in the PicoMite manual. I’m sure you could implement this with two Arduinos.

In summary, for many jobs a serial connection is quite good enough and is usually easy to set-up. For more complex needs/connections there are other solutions available (such as I2C or the PIO ‘state’ machines) but they will also be more complex to programme.

If you can do what you want (need) within a single ‘system’ then that’s generally going to be preferable/easier I think.

Hope this helps.

Regards,

 

IanT

[IanT]

On IanT Said:

….

I assume that you are simply sending G-Code (text) messages to the GRBL controller but there must also be some sort of handshake with the ‘sender’ ?  Presumably the Android app manages this process?

….

Yes, the handshake is managed solely on the bi-directional serial link.  The sender can send a string of commands, I think each one gets a character back to ack, and there’s a buffer in GRBL which queues them for execution.  When the buffer is full it sends a different character to stop sending.  A command that changes config is prefaced with a $ symbol IIRC.  The interface is described here:

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands

IIRC if you connect to an Arduino running GRBL over the serial monitor at 115200 baud you can send commands and see the responses and so get an idea of what’s happening.  You can even control the machine that way though it would be too clunky for a real application.  I have an HC06 Bluetooth module connected to the Arduino which my phone connects to.  From memory, configuring the HC06 was slightly tricky until I found an easy guide, but since then I have had no problems with it, it “just works”.  On the phone the GC app can be set to show you what’s happening on the serial link in all its gory detail, but that’s not needed for normal use.

[Author]

Posts