PDA

View Full Version : Raspberry Pi



irving2008
08-07-2012, 01:40 AM
Anyone else bought one?

Got mine up and running on Debian Wheezy.... now just thinking about a project for it... stand-alone g-code interpreter and drive controller to replace PC running MACH3. Using Python as the programming language since its built in and doesn't need to be compiled with a seperate build machine. And since Python is interpreted it is easy to experiment with. Also Python has very good set/array/list manipulation which should make it easier to write the code.

Already got it set up so I can view/control/program it remotely from both my Asus tablet and my PC over the network.

Jonathan
08-07-2012, 01:45 AM
I've just got one too, so naturally I'm thinking if it's possible to do the same project with it.

The simplest way would be to get LinuxCNC to run on it, but that's not likely. This thread discusses various issues:

http://www.cnczone.com/forums/linuxcnc_formerly_emc2/141327-nerds_only_raspberry_pi_emc2.html

bobc
08-07-2012, 02:11 AM
I work on firmware for stepper drivers, for 3D printers. The RepRap 3d printers usually use some form of Arduino to receive GCode and drive the steppers.

Raspberry Pi is a great little bit of hardware for the price, and naturally people want to use it as a PC replacement in all sorts of projects. Unfortunately, the Pi falls between two stools. It is quite underpowered compared to desktop PC, but if running Linux has too much baggage for a real-time controller. So I think it would be a struggle to get LinuxCNC running nicely on it, though I am sure someone will try ;)

If you don't run Linux, then you lose all the goodies that Linux provides, and also access to graphics acceleration via the GPU. The GPU is effectively closed as Broadcom only give specs under NDA to volume customers. However, several people are looking to port non-Linux realtime OS to the Pi.

The I/O on the Pi is quite limited too, without extra hardware. It is not possible to buy the Broadcom chip and spin your hardware either.

I am pretty sure someone will turn it into a stepper driver, the MIPS/$ for the stock Pi is unbeatable. In our printer project we are looking to see how we can use the Pi. Either as a host interface or as stepper controller.

I am still waiting for one to be delivered!

Robin Hewitt
08-07-2012, 11:40 AM
I think you might do better with one of the ARM development boards.

I got one for my plasma cutter. It has a little touch screen, USB, serial, memory card socket to plug in GigaBytes of extra memory , buttons, LED's and a squeaker all powered off the USB cable.

TI even have a stepper driver dev board with all the bells and whistles plus sample code. List is 80 but someone will sell them cheap eventually.

The GNU compiler is free, gives unfettered access and runs under Windows.

Swarfing
08-07-2012, 11:46 AM
I've had mine for a while now and looked into this and the problems i have seen so far is limited number of I/O pins (10), The need to build a new kernal to support the Arm processor for realtime use. I am still sure though somebody clever will iron these out at some point to have a basic controller of sorts?

bobc
08-07-2012, 12:37 PM
I think you might do better with one of the ARM development boards.

I got one for my plasma cutter. It has a little touch screen, USB, serial, memory card socket to plug in GigaBytes of extra memory , buttons, LED's and a squeaker all powered off the USB cable.

TI even have a stepper driver dev board with all the bells and whistles plus sample code. List is 80 but someone will sell them cheap eventually.

The GNU compiler is free, gives unfettered access and runs under Windows.

Do you have a link to those products? I got a STM32 board with touch screen off ebay for about 40, I haven't got round to using it yet.

I am using the R2C2 controller board designed for 3D printers, it has 100 MHz ARM plus 4 axis stepper drivers using A2988 chips. I did a video here http://www.youtube.com/watch?v=HAKubJFlKuE&feature=plcp

Lee Roberts
08-07-2012, 12:38 PM
Interestingly enough Mike Cook (http://www.thebox.myzen.co.uk) has recently done a little BOB for the raspberry pi (http://www.thebox.myzen.co.uk/Raspberry/Breakout.html):

6284

He hasn’t had his long, however looking at his “portfolio” he has also done a CNC Conversion (http://www.thebox.myzen.co.uk/Hardware/CNC_Conversion.html) converting a Proxxon MF70 machine to cnc and then building his own version of the RepRap controller, a unit also based on the Arduino:

6286

6285

.Me

Robin Hewitt
08-07-2012, 01:00 PM
Do you have a link to those products? I got a STM32 board with touch screen off ebay for about 40, I haven't got round to using it yet.

Link to the TI motor drive dev boards?

http://www.ti.com/ww/en/motor_drive_and_control_solutions/motor_control_tools_software.htm

irving2008
08-07-2012, 11:20 PM
well i've read just about everything I can find on LinuxCNC et al ports to the Pi. Seems its possible but some way away. Sadly my knowledge of Linux is insufficient to do such a port myself. I was thinking more of a stand-alone solution along the lines of FASM or DEX-OS...

Robin Hewitt
09-07-2012, 10:11 PM
Sadly my knowledge of Linux is insufficient to do such a port myself. I was thinking more of a stand-alone solution along the lines of FASM or DEX-OS...

Hi Irving

And very nice to have you back, Sir. I think the Raspberry could be a bit of a red herring, I think you really need an ARM processor on a board with a crystal, USB socket, IO pins and the six pin header that puts in the USB loader so you can program it live.

The problem is getting started, but once past the "Hello World" stage you should be on a roll. The processors start at a couple of quid, if you stay below 60MHz they are dirt cheap. If you fancy a collaboration I am your man.

Robin

Jonathan
09-07-2012, 10:24 PM
If you fancy a collaboration I am your man.

Me too. If there's one that's available in a sensible package, i.e. not much smaller pin spacing than SOIC then I'm up for making us some 'development boards' as you suggest. Unless of course there's something cheap and suitable already available.

bobc
09-07-2012, 11:02 PM
There are many cheap ARM eval boards around, I set a goal to find the cheapest! The cheapest so far I have found is the STM32 discovery http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/7458434/ for 10. No wait, here is a cheaper one! http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/7587554/

I've got one of the former, haven't done anything with it yet. Instead I build one of the LPC1343 boards you can here http://code.google.com/p/micropendousx/wiki/Older_Designs. The nice thing about the LPC chips is they come with a USB bootloader built in, it loads likes a USB flash drive. You just need the GNU compiler and you can start using it.

I have been using it to make a Control Panel for a 3d printer, you can just make out the board here http://www.flickr.com/photos/48299294@N03/7346378716/in/photostream

There are some many options now, we are spoilt for choice. The only thing is if you are into DIY hardware, there are virtually no ARM chips in a DIP package, all LQFP or smaller. The '1343 board above is not too hard to build, I used the two soldering iron technique, a magnifier, and patience ;)

I have some spare blank PCB's if anyone wants one, most of the parts are available via RS or Farnell.

ETA; design files and sample firmware for my project is at https://github.com/bobc/bobc_hardware

Robin Hewitt
10-07-2012, 12:23 AM
I have been using it to make a Control Panel for a 3d printer,

Blimey! I thought all the "interesting" people on the planet lived miles away from me, but here you are just up the road :surprise:

bobc
10-07-2012, 01:02 AM
Blimey! I thought all the "interesting" people on the planet lived miles away from me, but here you are just up the road :surprise:

Heh, I didn't expect to find a "high-tech" client in Eastbourne, for some reason they have a factory and design centre here. Normally I am found cruising up and down M25/M4. It's a gentler pace of life down here, shall we say ;)

irving2008
10-07-2012, 01:35 AM
Maybe the Pi isn't the way to go, but my thought process was to create a g-code interpreter to drive the stepper drivers etc. and provide a real-time display of the process. Sort of MACH3 in a matchbox... (or should that be EMC2 in a matchbox)... anyway, a cut down version. No frills, no bells n whistles, just motion control and some graphics. I don't think the other boards suggested can do this (well of course with a multitude of added perpherals maybe). Big ask? maybe.

I/O isnt an issue, already sketched some ideas for a 16 port TTL compatible I/O module that uses a minimal # of GPIO and will be fast enough for this purpose (a few uS switching time and some bit-banging software) with an RTC as well. Also looking at using the I2C interface for the same, albeit slower...

So far just knocked up a simple I/O connector to get to the breadboard easily.

bobc
10-07-2012, 02:36 AM
Maybe the Pi isn't the way to go, but my thought process was to create a g-code interpreter to drive the stepper drivers etc. and provide a real-time display of the process. Sort of MACH3 in a matchbox... (or should that be EMC2 in a matchbox)... anyway, a cut down version. No frills, no bells n whistles, just motion control and some graphics. I don't think the other boards suggested can do this (well of course with a multitude of added perpherals maybe). Big ask? maybe.

It is entirely possible, it is what all the Reprap printer controllers do, they take GCode sent from a PC over RS232, plan the motion and control the steppers, and on the 8 bit Arduino platform. There is also software for CNC, have a look for GRBL.

It is the sort of project you can do from scratch, you may not achieve reliable motion control on the first go, but steppers are quite easy to work with. If you have got a Pi, you may as well use it. The nice thing about the Pi is you can use a nice sized display with it.

My Pi should arrive any day now!

irving2008
10-07-2012, 07:56 AM
It is entirely possible, it is what all the Reprap printer controllers do, they take GCode sent from a PC over RS232, plan the motion and control the steppers, and on the 8 bit Arduino platform. There is also software for CNC, have a look for GRBL.

It is the sort of project you can do from scratch, you may not achieve reliable motion control on the first go, but steppers are quite easy to work with. If you have got a Pi, you may as well use it. The nice thing about the Pi is you can use a nice sized display with it.

My Pi should arrive any day now!I'll have a look...

The nice thing about the Pi is the fact that, while you could plug a display in, if you were to use Linux you could equally remotely view/control it with VNC. I want to add this to a new PCB mill I am planning that can sit inside a sound-proof box on the next bench but I can watch it on the main PC... without tying up the main PC and without taking up the space of another PC...

For what I have in mind, I think it could be done without a real-time kernel with a 'device driver' hooked into a higher priority interrupt and a shared memory queue of simple motion commands. Sort of like a smoothstepper in software... I did something like this more than a few years back in Windows 95 for a real-time data transponder so I know the concept works, but I need to learn more about the Linux low level stuff.... and thats proving hard to find an easy way in...

bobc
10-07-2012, 11:53 AM
I'll have a look...

The nice thing about the Pi is the fact that, while you could plug a display in, if you were to use Linux you could equally remotely view/control it with VNC. I want to add this to a new PCB mill I am planning that can sit inside a sound-proof box on the next bench but I can watch it on the main PC... without tying up the main PC and without taking up the space of another PC...

That sounds like a good job for a Pi...


For what I have in mind, I think it could be done without a real-time kernel with a 'device driver' hooked into a higher priority interrupt and a shared memory queue of simple motion commands. Sort of like a smoothstepper in software... I did something like this more than a few years back in Windows 95 for a real-time data transponder so I know the concept works, but I need to learn more about the Linux low level stuff.... and thats proving hard to find an easy way in...

Some years ago I worked on Unix device drivers so I know the basics, I have been mostly working on RTOS or bare-metal systems. I am currently reading http://shop.oreilly.com/product/9780596005900.do to get up to date with latest way of doing things on Linux, it seems like a fair introduction but is not comprehensive - that would take multiple volumes I think. There are also online sources of info of course.

If you don't mind that the device driver is specific to the R.Pi, that should work. For stepper control, it basically needs a high-res timer and access to GPIO pins. The latter is straightforward. By high-res I mean < 10ms ;) I think there is a spare hardware timer on the Pi that a driver could hook into. The user-space app could parse the GCode, and sends "blocks" of motion commands (move N steps on X, M on Y etc) to the device driver with write() (to keep it simple). The driver just needs to generate a stream of step pulses with the required timing.

irving2008
17-07-2012, 12:16 AM
So, I got a breakout module (a Cobbler (http://www.phenoptix.com/index.php/front-page-products/adafruit-pi-cobbler-breakout-kit-for-raspberry-pi-for-easy-breadboarding.html), it was quicker/cheaper than putting my own together). I've been teaching myself Linux Kernel and module programming and playing with an GPIO library WiringPi (https://projects.drogon.net/raspberry-pi/wiringpi/) . A quick bit of bit bashing and inspection with the scope has proven, as I suspected, the need for an external interrupt. The Pi can generate 100nS pulses (from C) but the jitter is horrible. I'm currently writing a module that'll take an interrupt from the GPIO and toggle a GPIO line every 'n' pulses, where 'n' is a value in user space. That'll allow me to see what the latency and jitter is from an interrupt.

Robin Hewitt
17-07-2012, 12:58 AM
Jitter is the problem with running an operating system which happily delays your interrupt service.

The ARM micro's come with numerous timer channels and you can prioritise the interrupts. However I like to use a single timer for stepping because it makes it darned easy to keep the accelerations/decellerations in synch. I buffer incoming data from the host PDQ then handle it in background so it doesn't interfere with the stepping.

Two timer interrupts per step, one to set the STEP lines for any steps required, one to step everyone who is primed to go. Makes for nice square pulses and good settle time on the direction lines.

I like to smash my arcs in to individual straight lines in a buffer to keep the timer interrupt fast and simple. The timer interrupt fetches the next when it exhausts the one it is doing.

A line has 3 seperate components, acceleration steps, constant speed steps and decelleration steps.

Lines also have 3 slope values, one for each axis. Basically a number which you add in to a tally and if the tally carries that axis steps.

If the PAUSE button is pressed things get a bit hairy, every step becomes a decelleration step. It tallies decellerations so it can update the buffer to get back up to speed if it gets unPAUSEd.

If you smash the arc into enough segments you keep within 1 step resolution. I check the angle at which individual lines intersect and use a table to guess-timate how fast it is safe to take the corner. My PC does the arc to line/speed conversion with no appreciable delay and I am sure the ARM is up for it.

My mill runs it very smoothly with an 8MHz, 8 bit micro crunching 24 bit numbers. With 32 bit registers it should be a doddle, I could do the whole interrupt in ARM assembler nil problemo.

irving2008
17-07-2012, 11:24 AM
Thanks for those thoughts Robin, pretty much mirrors what I had in mind. Have got an example interrupt procedure for the ARM/Pi so will have a go at rewriting/compiling/installing that tonight and driving it from the pulse generator output of the scope.

Working on ideas for two parallel solutions, one that does it all in software and one that uses a low cost external 'intelligent buffer' (a PIC Micro and not much else... ). I hope that the final solution can work transparently with either, the hardware solution handling higher step rates (>15000 steps/sec would be the likely x-over target) for a relatively low cost plug-in board.

Robin Hewitt
17-07-2012, 12:36 PM
Before we descend in to the nitty gritty I think we need the big picture.

If the Raspberry video is interrupt unfriendly, how do we get a screen display?

I use a Win7 laptop and wrote software to drive my mills through a USB, but that requires Visual Studio and makes the cheap solution expensive.

If we add a Linux PC to get the free compiler and upload the Gcode, it has a display and the Raspberry display would seem irrelevant.

irving2008
17-07-2012, 04:26 PM
As far as I can make out the video isn't interrupt unfriendly (at least I haven't determined that yet, but reading other's work suggests its ok in this respect) as its got a separate GPU acting on the frame buffer independent of the main CPU. But thats my next goal - to see the effect of throwing a few thousand interrupts at it... I'm sure others have done this already and moved onto the cleverer stuff but I think starting at the bottom and working up is a good way to learn... and if it doesnt work, then plan B or whatever...

My goal is to have something I can send a g-code file to over the network, remotely viewed via VNC, and set running... I dont plan to use the RPi for design or CADCAM etc... just a g-code interpreter, putting motion data into a buffer and playing out the buffer in 'real-time' to the hardware while providing some level of visualisation of the cutter location on the screen...

Jonathan
19-07-2012, 07:29 PM
I think one of these would be better for development?

http://www.ebay.co.uk/itm/Brand-New-STM32F103VET6-ARM-Cortex-M3-Development-Board-2-4-Touch-TFT-LCD-7v-/380422826555?pt=FR_YO_MaisonJardin_Bricolage_Elect roniqueComposants&hash=item5892f7aa3b#ht_6416wt_1037

Then get a cheaper board without the LCD etc for the actual controller, or perhaps stick with the LCD as there's enough space there to display the important information.

Robin Hewitt
19-07-2012, 09:40 PM
I think one of these would be better for development?

That's the one I bought. Well I actually bought 2 so my brother got one which is always a good move. The preloaded program source did not compile but he did the spade work and sent me back a bare bones program to do the screen and touch panel all set up and ready to run with the "Eclipse" C compiler. I unzipped it, compiled it, uploaded it and it was fine and dandy.

I know this is cheating, but hey!

irving2008
20-07-2012, 02:43 AM
Nice n cheap and I might yet get one to play with but it doesn't have what i want on board, like the Ethernet...

Give me a few days and I should have something sort of working... just getting my head round this linux stuff...

Jonathan
20-07-2012, 05:52 PM
Nice n cheap and I might yet get one to play with but it doesn't have what i want on board, like the Ethernet...


Here's one that does:


http://www.ebay.co.uk/itm/NXP-LPC1768-Mini-DK-Development-Board-2-8-SPI-Interface-TFT-LCD-/271016835321?pt=LH_DefaultDomain_0&hash=item3f19dcb8f9


Or:


http://www.ebay.co.uk/itm/Development-Board-for-NXP-LPC1768-3-2-TFT-LCD-Module-Z-/150507082135?pt=LH_DefaultDomain_0&hash=item230aebd197#ht_5481wt_1139


I reckon I'll get one of those, not sure which...

irving2008
20-07-2012, 08:18 PM
Here's one that does:


http://www.ebay.co.uk/itm/NXP-LPC1768-Mini-DK-Development-Board-2-8-SPI-Interface-TFT-LCD-/271016835321?pt=LH_DefaultDomain_0&hash=item3f19dcb8f9


Or:


http://www.ebay.co.uk/itm/Development-Board-for-NXP-LPC1768-3-2-TFT-LCD-Module-Z-/150507082135?pt=LH_DefaultDomain_0&hash=item230aebd197#ht_5481wt_1139



I reckon I'll get one of those, not sure which...

Both nice boards tho without the touch screen of the original one you listed, but amazing pricing...

But with only 512k rom/64k RAM you're going to have to do primarily bare-metal programming which is fine for a bit of bit-bashing, but (and I admit I've not done much research yet) I'd not want to write my own Ethernet software, web server, etc., etc. I guess there are examples of these around, but I want to focus on the CNC stuff not getting the basic platform up and running... a little googling suggests that there is limited info about this (compared to the Linux world) and a shed load of work even to do basic stuff like turn an LED on and off from a web page...

But don't let me stop you....

irving2008
31-07-2012, 02:12 PM
Update:

Have the bare bones of a program now that takes a buffer of step requests (# of steps, step rate, direction) in 4 dimensions X/Y/Z/A and outputs these under interrupt driven timing to the GPIO outputs. Without having to resort to a kernel level interrupt handler (which I will do when I've worked out how to get the Linux cross compiler to work) and using an out of the box user-space handler I am able to get 5,000 steps/sec on each axis with <10uS delta between channels (10kHz interrupt). That uses around 50% CPU on an unclocked Pi.

Next is to get a basic G-code interpreter running and do the vector maths to handle acceleration/deceleration.

Robin Hewitt
31-07-2012, 05:52 PM
I have a working G code reader written in C# for Microsoft Visual Studio if that would help?

It's only really interested on G0-3 and tool changes but could be expanded.

irving2008
31-07-2012, 06:14 PM
I have a working G code reader written in C# for Microsoft Visual Studio if that would help?

It's only really interested on G0-3 and tool changes but could be expanded.Thanks Robin, I'm sure it'll save me some effort... I'll PM you my email in case you've lost it :)

Robin Hewitt
31-07-2012, 10:16 PM
Oops, forgot the cutarc() subroutine

Let me know what else I forgot

Robin

irving2008
01-08-2012, 12:48 AM
Oops, forgot the cutarc() subroutine

Let me know what else I forgot

Robin
Thanks.

Been playing around with interpolation routines but run into a snag... so need to go back and rethink the code I've written. Issue is this... in 2D to make it easy... want to move from 0,0 to 1000,1300 say (steps, not mm). Lets assume that the feed rate requires this to take 1 second... then the x rate is 1000steps/sec and the y rate is 1300 steps/sec. But I have a base rate of 5000 steps sec (10khz interrupt/2). so X is every 5th interrupt and y is every 3.85 interrupts.. but you cant do 3.85.. so i need a much higher interrupt rate and some interpolation... in this case 50000 and divisors of 38,38,39,38,38,39,38,38,38,39 per 5000 gives 1301 with a max error of 2 steps... So i need to get that kernel level interrupt working... in the meantime, i'll have to run it all at 1/10 speed :(

bobc
01-08-2012, 02:15 AM
Thanks.

Been playing around with interpolation routines but run into a snag... so need to go back and rethink the code I've written. Issue is this... in 2D to make it easy... want to move from 0,0 to 1000,1300 say (steps, not mm). Lets assume that the feed rate requires this to take 1 second... then the x rate is 1000steps/sec and the y rate is 1300 steps/sec. But I have a base rate of 5000 steps sec (10khz interrupt/2). so X is every 5th interrupt and y is every 3.85 interrupts.. but you cant do 3.85.. so i need a much higher interrupt rate and some interpolation... in this case 50000 and divisors of 38,38,39,38,38,39,38,38,38,39 per 5000 gives 1301 with a max error of 2 steps... So i need to get that kernel level interrupt working... in the meantime, i'll have to run it all at 1/10 speed :(

You could try the Bresenham line algorithm, it extends to n dimensions.

irving2008
01-08-2012, 07:25 AM
You could try the Bresenham line algorithm, it extends to n dimensions.I'm already using a modified form of that. The issue isn't one however of where the line goes, but how fast it goes in each axis. If the pulse rate is derived from a fixed clock, then the granularity of the pulse rate is limited.

bobc
01-08-2012, 09:29 AM
I'm already using a modified form of that. The issue isn't one however of where the line goes, but how fast it goes in each axis. If the pulse rate is derived from a fixed clock, then the granularity of the pulse rate is limited.

Well sure. It's a question of what level of accuracy you are aiming for, sub-atomic ? :)

Apparently on the Pi there is a USB interrupt at 8Khz which takes around 20% of the CPU, so getting a 50kHz interrupt might be a challenge.

Robin Hewitt
01-08-2012, 09:57 AM
It is fun isn't it, the hours I spent making it work. Everytime I thought I had it figured I found the next little snag :beer:

I find the major axis which steps on every interrupt, and slave everything else to that. I reload the timer after every step from the acceleration table, stretching the delay by 1.5 (approx root 2) if both X and Y go together.

I can give you the working code that drives my mills but it may not help being written in Z80 assembler. It runs from a pre-digested buffer of straight lines without any multiplies or divides. On a slow CPU, 8MHz, the interrupt steps anyone set to step on entry then reconfigures the step and direction lines at exit.

I'm a bit of a dinosaur.

irving2008
01-08-2012, 12:25 PM
Well sure. It's a question of what level of accuracy you are aiming for, sub-atomic ? :)

Apparently on the Pi there is a USB interrupt at 8Khz which takes around 20% of the CPU, so getting a 50kHz interrupt might be a challenge.No, but with 1 step = 0.05mm, a few steps out is problematic. I'm running at 10KHz interrupts now but there are reports of others handling 100KHz interrupts, using the PRE_EMPT flags in the kernel compile (another reason to re-compile). The only speed limit I have right now is the fact that the interrupt handler runs in user space so context switching is a significant part of the interrupt latency (about 50uS measured).


It is fun isn't it, the hours I spent making it work. Everytime I thought I had it figured I found the next little snag :beer:

I find the major axis which steps on every interrupt, and slave everything else to that. I reload the timer after every step from the acceleration table, stretching the delay by 1.5 (approx root 2) if both X and Y go together.

I can give you the working code that drives my mills but it may not help being written in Z80 assembler. It runs from a pre-digested buffer of straight lines without any multiplies or divides. On a slow CPU, 8MHz, the interrupt steps anyone set to step on entry then reconfigures the step and direction lines at exit.

I'm a bit of a dinosaur.
Thats essentially the way I am doing it. I have a buffer of 1024 'moves' but if I have to fill it with 1 step moves its going to need to be much bigger or the steppers are going to run out of work to do... Or did you convert the whole of the G-code into steps before putting it in the buffer? How big is your buffer?

How fast is your interrupt and do you change the rate? It occured to me that one way to control feed rate would be to have a programmable interrupt timer using the Pi's PWM generator - but that wastes a GPIO output pin as I don't think you can programme it to interrupt if its not allocated to an output pin (and possibly needs to be fed back to an input).

Robin Hewitt
01-08-2012, 01:03 PM
I have a buffer of straight lines. Lines currently are 24 bits long max. With the acceleration/deceleration/directions included I can define a straight line, XYZ, in 12 bytes.

I pinched the idea, I won't say where from. It also makes jogging easy but the buffer needs canny attention after you hit pause because unexpected braking has to become unexpected acceleration when you unpause.

I put a tidemark at 800 lines, if the buffer drops below that it gets another 10 lines. Drip feeding from the host may not be the way you want to go.

I use 2 interrupts, one for the stepping, one for the comms.

I have one bug at the mo', if the host misses a byte from the status report it waits forever for it to arrive. I need to add a timeout/retry. I haven't lost any data going the other way, yet, touch wood.

Edit: You step at .05mm? Is that a typo? I step at .005mm.

irving2008
02-08-2012, 05:42 PM
yes it was a typo...

I now have a working 3D modified/optimised Bresenham run-length algorithm. I interpret the G-Code file (or will do soon) and write the run length data to a file. When you press 'go' it just reads the file and fills the buffer, then keeps it topped up. With over 3Gb of storage available on the SD card I dont need to worry about running out of memory! I added a second 'playback' buffer so once the interrupt handler outputs the steps to the stepper it puts what it just did in the playback buffer. This is then used by the visualisation routines which run at a low priority...

Still got to work on acceleration and deceleration approaches...

Fivetide
06-09-2012, 12:36 AM
This is awesome; sorry I started the other thread I have 2 RPI’s I want to make an integrated O2 headphone amp and personal music player for my brothers 50th birthday with one. Was hoping to make a nice milled alloy or brass case for it.

Robin Hewitt
20-09-2012, 04:10 PM
Still got to work on acceleration and deceleration approaches...

I've been up to my ears in the ARM Coretex Tech Ref manual for the last few days and I think I have the hang...

The snag with accel decel is terminal velocity on a movement which very much depends on it's intersection angle with the next movement.

You don't want to be forever slowing to zero.

You don't want to work that sucker out inside the interrupt.

You have to be able to brake and recover when you hit the PAUSE button.

Looking at it I have a notion that I save the movements with a target max velocity and a desired terminal velocity, I can figure out accelerations and decelerations starting from current speed on the fly using a look-up table. If I bung in a Gig or two of Micro SD card memory I should be able to store the entire cut and simply exchange status data with the host computer while cutting. I think the USB connection becomes a weak link when the motors start turning. Also it would be nice simply to unplug the lap top and take it with me if I wanted to cut "lights out".

I am starting with TIM2 set as a down counter with interrupt on update and a big fat delay in the reload register. That way I can figure out what the delay should be, see how far the timer has got and write the counter register directly with what remains.

The interrupt looks at a status byte and decides what to do. That way my base program can simply tinker with the status byte and everything happens automatically.

Two interrupts per step, one of variable length to control the speed, one of set length, just enough to trigger the step after the DIR and STEP lines have had a chance to settle.

TrickyCNC
20-09-2012, 08:10 PM
I've been thinking of getting me a slice of Pi .... I need to have a better read through this thread though, as it seems other options were suggested ?Anyone going ahead with the Pi or did you decide on arm ?

Robin Hewitt
20-09-2012, 08:32 PM
I think Pi is ARM based. Haven't got one myself, I'm using the STM32F103V development board because it's cheap and comes with a dinky full colour touch screen I want to play with.

I'm wondering if ST is a new funky name for what was Signetics Thompson? Perhaps I've been around too long :very_drunk:

TrickyCNC
20-09-2012, 08:45 PM
ooh ... now you got me thinking ... Atari ST , or Amiga 1000 :) ... I wonder ...

Robin Hewitt
27-09-2012, 12:35 PM
I had a bit of a leap backwards when I discovered the STM32F103 doesn't take ARM instructions, it's all THUMB-2 and relative, icky pooh, so I'm now writing in C.

I had a bit of a leap forward when I discovered the port bit set reset register GPIOx->BSRR

It's a 32 bit register for a 16 bit port, set a bit in the top half and you set a pin, set a bit in the bottom half and you reset the pin. Fiendishly useful if you are sharing the port with other peripherals you don't want to touch.

The port control registers come in Low and High GPIOx->CRL GPIOx->CRH with 4 bits per port which is conveniently one digit in Hex so you can see what you are getting in the way of inputs and outputs at a glance. For example:-

GPIOB->CRL = 0x22222222; Gets you 8 push pull outputs b0-7 on Port B

Much easier to see what is going on a glance.

I have a rudimentary 4 axis stepper written, now I need to get data in to it. I've bought a 4Gb micro SD card. If I can dump the entire cut into it then I can stop worrying about drip feeding and comms errors, just have it send reports on a timer tick so I can do fancy graphics on the PC. Watch out, SD cards come with a "Class" number which is the transfer rate in MHz, if you don't see a Class number assume it's slow, I got a Class 4.

irving2008
27-09-2012, 04:20 PM
Running my Pi(s) on 16Gb class 10s now (yes my second Pi arrived), courtesy of SavaStore, cheap and improves performance and memepory issues are a thing of the past. 2.9Gbyte for the OS and 12Gb+ for a step buffer - can't see any job needing more than that! But other things are taking my time now so this is stalled a while.

Robin Hewitt
05-10-2012, 10:57 PM
Took me a while but I now have it stepping :yahoo:

Not usefully stepping, just moving back and forth in 4 axes at 4 different speeds, over and over again. Looking good.

I am running everything on one timer interrupt. The interrupt collects 4 absolute co-ordinates from the buffer, along with a couple of speeds. It moves there. It comes back for more. Simples.

I was thinking to make the Z and W axes optional but there is no point it's so blooming fast. 40kHz step rates look easy, I could probably wind it up to 70kHz mid line. I usually run at 3kHz top whack.

These ARM Coretex processors may have a bit of a vertical learning curve but are well worth the effort. They have so many built in goodies I am barely scratching the surface.

irving2008
05-10-2012, 11:54 PM
:) The only progress I have made is to put Pi #1 into a nice CNC'd case from Pimoroni

7076

Fivetide
06-10-2012, 12:39 AM
:) The only progress I have made is to put Pi #1 into a nice CNC'd case from Pimoroni

7076

That is sexy !

Robin Hewitt
06-10-2012, 10:26 AM
:) The only progress I have made is to put Pi #1 into a nice CNC'd case from Pimoron

Does that come in My Little Pony? :hysterical: