Why is everyone using arduinos to interpret gcode?

Re: Why is everyone using arduinos to interpret gcode?

treflip — Sat, 27 Dec 2014 20:25:50 -0500

@pete-theobald
So what was the end result of your test boards? I read through this topic in hopes of a resolution.

Re: Why is everyone using arduinos to interpret gcode?

Traumflug — Fri, 21 Sep 2012 06:21:55 -0400

Quote

Also, adding complex collision detection algorithms or lets say a toolpath creation and simulation is problematic because of the process speed a arduino has.

Controllers by definition don't do tool path generation. Neither Arduino based ones nor EMC(2).

Re: Why is everyone using arduinos to interpret gcode?

Mevon — Thu, 20 Sep 2012 16:46:11 -0400

Thanks for responding, but on the matter of the subject, I guess the keyword I was missing was "realtime", because all CNC CAM are actuating the motor drives in realtime, with some multiple threads or processes running at the same time. Now for the 3d printers, the realtime part is done in the Arduino/electronic with PWMs and such, with queued-in commands (gcode lines) and having a "realtime" response to the PC host is relative to the usb communication link. Also, adding complex collision detection algorithms or lets say a toolpath creation and simulation is problematic because of the process speed a arduino has. So maybe one way to go is to add an expansion connector, akin to the parallel port and have a more direct interface with the electronics/hardware. But then again, the parallel port is somewhat on the brink of extinction, am I right? So I'd say, let's make something that works on the pci-e, but then you'd need a really faster uC to do the job... All this is telling me is CNCs need to be a little more like 3d printers (usb connection part), and 3d printers need to be a little more like CNCs (CAM "realtime" part). I'm still a newb so tell me if I'm wrong, thank you.

Now, for the precedent post, I'm really grateful for the info and I will look into the GCodes more deeply because, from what I understand gEDA/pcb can produce "non advanced g-code". Maybe casting them in the Pronterface would give me a better flow to execute double sided boards milled PCBs but today I will be reading more on pyCAM, which seems suited to what I do. And from what I read around here, I guess its not so bad to throw the gcodes directly using the pronterface but I believe pyCAM will really help with the organisation, even if it's not driving the printer/cnc directly, I can still simulate after in emc2 and run the gcodes with Printrun. [sourceforge.net]

Thanks everyone,
MikE

Re: Why is everyone using arduinos to interpret gcode?

Traumflug — Thu, 20 Sep 2012 05:47:37 -0400

Quote

Now, where I fall short is the CAM are all made for CNC and not usb electronics, so using the printer/printer electronics to do some CNC work is kinda hard with Pronterface/Printrun and Slic3r...

Huh? G-code is G-code and a G-code compiler doesn't care the slightest how the electronics makes machine movement from that. I run G-code made on Catia with Teacup just fine. The same G-code simulates in EMC2 perfectly as well.

Quote

like mirror X or Y axis for double sided pcb milling

All G-code compilers making G-code for PCB milling I'm aware of do that already.

Re: Why is everyone using arduinos to interpret gcode?

Mevon — Wed, 19 Sep 2012 16:41:11 -0400

I thought GCodes were for CNCs and then adapted to Repraps...

Anyways, I don't know this seems obvious to me but, linuxCNC/emc2 uses drivers for steppers on the parallel port, while arduino based electronics also uses stepper drivers. Now, any CNC use a CAM that takes the .STL and produce gcodes or whatever signals on the parallel bus to control the drivers, but the reprap does no computing (else the PID for the heaters and maybe a little accel/decel for the movements). The point is, for a reprap, all is done in the slicing of the stl on the host pc, so the gcodes are not generated by the arduino, but simply interpreted and the printer is doing what its told to.. So for linuxCNC to "print", its just a matter of sending the gocodes on the usb serial connection, queue in 8 lines of gcode in advance and keep 'em flowing (sounds easier said then done... :S).

So what Im doing here will sound like heretic to y'all, I'm actually using Gen7 electronics to drive my tabletop Mantis to mill (eventually :P) PCBs. Now, where I fall short is the CAM are all made for CNC and not usb electronics, so using the printer/printer electronics to do some CNC work is kinda hard with Pronterface/Printrun and Slic3r... Though the gcodes come from the CAD I use for creating the pcb, getting the work done would be nicer with a CAM for cnc, so maybe a plug-in for linuxCNC/emc2 to use the Printrun's console API. Now I'm at the point where I will add gcodes in the firmware to do whats needed (like mirror X or Y axis for double sided pcb milling) but if anyone knows a good tutorial on printing a double sided pcb on a diy tabletop mil or anything on using reprap electronics to do some milling work would be nice.

Thanks in advance,
MikE

Re: Why is everyone using arduinos to interpret gcode?

Traumflug — Tue, 18 Sep 2012 06:10:33 -0400

I think you have to try. Without actually trying it's difficult to do a good judgement, as often hidden details, like the 32-bit division in the acceleration algorithm, turn out to be major obstacles.

Re: Why is everyone using arduinos to interpret gcode?

ChuckH — Sun, 16 Sep 2012 17:53:26 -0400

Hi, I am new here and have started working on a RepRap-related project for OSE [opensourceecology.org]. The first iteration has been done with grbl on Arduino

I have been thinking about converting G-Code to an intermediate PVT (position-velocity-time) waypoint format, then using Arduino to generate the step/direction (using cubic spline interpolation) from that. This is similar to some CANOpen DS402 motion control that Maxon, etc. do in their servo drive modules. PVT mode is designed for splicing together continuous smooth moves out of segments, unlike the trapezoidal point-to-point trajectory generators in L6740 etc. For attaining the same deviation from ideal path it takes a lot fewer PVT (spline) segments than linear segments so bandwidth to Arduino, buffer size, etc should be a non-issue.

Another thing I am contemplating is using ROS protocol to stream data to the Arduino (I have used [www.ros.org] successfully in a past project), ROS also provides a time sync service which could keep multiple Arduino slaves in sync if some grander multi-axis scheme materializes. (A 5-axis CNC torch table that pivots the torch head to do angle cuts would be cool...) I have tried rosserial in Raspberry Pi but I think the serial_node.py script needs optimization: [wiki.jigsawrenaissance.org]

Agreed that when we use big buffers to handle communication stack latency (e.g. in USB, serial, ethernet) that there has to be another route for homing and perhaps status feedback but that fits pretty cleanly into ROS comms architecture just by adding another topic or service.

All this is handwaving right now, any comments?

Chuck

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Wed, 15 Aug 2012 08:31:57 -0400

nophead Wrote:
-------------------------------------------------------
> 8 bit PICs run four times slower for a given clock
> speed. I.e. they need four clocks for each
> instruction. And the instructions are a lot more
> primitive than AVR so C runs considerably slower
> on a PIC18.

Yep, PICs run one instruction per 4 cycles so 20MHz is only 5MIPs. I think they're also a risc processor which means they don't have the benefit of specialist instructions. that said, they have DMA modules, lots of timers and PWM modules so you can keep a fair bit of stuff running in separate modules. I'm planning to use DMA to receive messages, PWM modules to run heated beds, extruders and fans and the rest can happen in code as it doesnt need to run so fast.

Pete

Re: Why is everyone using arduinos to interpret gcode?

nophead — Fri, 10 Aug 2012 14:27:03 -0400

8 bit PICs run four times slower for a given clock speed. I.e. they need four clocks for each instruction. And the instructions are a lot more primitive than AVR so C runs considerably slower on a PIC18.

Re: Why is everyone using arduinos to interpret gcode?

sam0737 — Fri, 10 Aug 2012 14:00:36 -0400

pete-theobald Wrote:
-------------------------------------------------------
> sam0737 Wrote:
> --------------------------------------------------
> -----
> > 1Mbps on UART is hard, I expect noise, clock
> > glitches may ruins the packets.
> >
> I'm a bit worried about that but most firmwares
> are running rs232 at 250Mbaud (except its a short
> hop from the ft232 to the avr, but I only need
> 500kbaud max and probably less most of the time
You must have miscounted the zero. Marlin default is 250Kbps, or 0.25Mbps, or 250000 bit per second.

> >...but does that mean now I
> > have to buy a RPi in additional to the
> > Arduino/AVR?
> >
> I never planned to have an AVR in my setup, just
> an 80p pic on each controller board.
PIC? It's just as fast as AVR - they are the same class of MCU.

Re: Why is everyone using arduinos to interpret gcode?

rhmorrison — Fri, 10 Aug 2012 02:42:02 -0400

G-code is the command protocol that most RepRaps use.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Thu, 09 Aug 2012 18:06:05 -0400

sam0737 Wrote:
-------------------------------------------------------
> 1Mbps on UART is hard, I expect noise, clock
> glitches may ruins the packets.
>
I'm a bit worried about that but most firmwares are running rs232 at 250Mbaud (except its a short hop from the ft232 to the avr, but I only need 500kbaud max and probably less most of the time

>...but does that mean now I
> have to buy a RPi in additional to the
> Arduino/AVR?
>
I never planned to have an AVR in my setup, just an 80p pic on each controller board. I sent a couple of boards off to production earlier this week. The cost of parts for a single board is about £9 and that includes pcb, a single stepper driver, a single power mosfet, 2 endstop headers and a fan header. 4 or 5 of those boardshooked up in parallel would run the average machine and cost £50-£60 (including the interface board at about the same cost). They all take commands from an interface board which is basically a board with an ATX connector, MCP2200 (usb to serial that can be reprogrammed) and an RS485 bus driver. The MCP2200 needs some revised firmware to handle sending commands at defined times, which takes the timing problem away from the host pc. If I combine that with a raspberrypi i've got a full set of electronics with a lot of processing power for less than £100 and I have a decent amount of power to run more complex algorithms (handling circles for instance).

Anniraks idea is a bit less dumb than mine as it takes commands defining paths rather than individual steps which would mean it should get away with lower bandwidth. I think bandwidth isn't really the big problem, its the lack of buffers, especially if usb is only sending packets at 1mS timeslots. SD card won't have that problem as its basically reading the gcode in using SPI which the avr has direct control of. Keeping the buffers full will be a lot easier with a binary protocol as (especially on the MCP2200 with 256bytes of DMA RAM) it will be easier to pick in a few mS of commands.

I'm not worried about using the host for something else. I have a mini-itx box I use for printing but a £25 raspberrypi should be more than enough and with £60 of electronics and a £15 ATX power supply you could have a full set of electronics for £100.

Pete

Re: Why is everyone using arduinos to interpret gcode?

hondalawnparts1 — Thu, 09 Aug 2012 17:22:38 -0400

What is the Gcode?

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Thu, 09 Aug 2012 16:05:44 -0400

My solution shouldn't require any additional controllers; just the RPi since I'm using SPI-based, fully integrated stepper motor motion controllers.

R2C2 looks pretty nice. My only complaint about it is the lack of modular expansion of stepper drivers. I'm constantly debating that tradeoff, but I think there's some significant benefits to be had by going with the RPi.

Re: Why is everyone using arduinos to interpret gcode?

sam0737 — Thu, 09 Aug 2012 13:19:32 -0400

1Mbps on UART is hard, I expect noise, clock glitches may ruins the packets.

People want print on SD for 2 reasons,
1. they need not to keep the computer running the host, connecting to the USB. Especially when Diablo 3 (insert your favorite CPU intensive program) and printing host doesn't mix well.
2. Performs better on small arc/corner because of the processing latency.
Why it prints better when prints from SD? I can't say for sure but believe the latencies are introduced in the host program. It has a high jitters (inconsistency latency) to read a wake up the host thread, read gcode line, send it down to the USB.

So if you take away the gcode->step calculation functions from the MCU, the host must do it. And if I want to print from SD because of reason 1 (free my computer from running the host because I want to play Diablo 3 while printing), there must be some other kind of hardware running the host. RPi would do the job...but does that mean now I have to buy a RPi in additional to the Arduino/AVR?

Then why not just take the R2C2 way...dump the AVR, just do everything with ARM. Sounds more cost effective, less problem (high speed communication), less complex to me.

Re: Why is everyone using arduinos to interpret gcode?

anwe79 — Tue, 07 Aug 2012 08:56:10 -0400

I think the point is not problems with bandwith between storage medium and host, more likely the problems would be because of latency between the host and arduino over USB.

USB (at least <=2) is not very well suited for low/guaranteed latency transfers.
This is (partially) why many prefer firewire for pro/prosumer audio "cards".

I don't have any direct insights about the communication in the reprap specific case, but unless it's operating in some low speed usb 1 mode, the bandwith should not be the issue.

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Mon, 06 Aug 2012 15:32:22 -0400

DeuxVis Wrote:
-------------------------------------------------------
> USB communication doesn't seem fast enough for a
> lot of little moves following each other - like in
> a tiny circles drawn using way too small lines.
>
> People had noticeable improvement in print quality
> using Sd card on the controller, instead of USB
> communication from the host - removes the short
> pauses.
> Note that Nophead solution - using ethernet - is
> probably good for that too.

I may be incorrect here, but it would seem to me that you're mixing a few different operating modes. The existing USB solution is USB->Serial conversion, while what I'm suggesting is using a CPU capable of being a USB host and using USB mass storage. USB Mass storage is limited at 480Mbps, though individual USB drives' real world read performances seem to range from 15 to 40 MBps (120-320Mbps) for name-brand USB flash drives. Considering the SPI data rate limit on an AVR is fosc/2, that means the absolute limit of performance would be 10Mbps with a 20MHz crystal.

Based on the above, I can't see a USB mass storage source being worse than a SD card.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Mon, 06 Aug 2012 08:31:07 -0400

Re: Why is everyone using arduinos to interpret gcode?

DeuxVis — Mon, 06 Aug 2012 08:27:34 -0400

Annirak Wrote:

> The printer raspberry pi has a pair of USB ports.
> Why do you need print from SD? You have print
> from USB.

USB communication doesn't seem fast enough for a lot of little moves following each other - like in a tiny circles drawn using way too small lines.

People had noticeable improvement in print quality using Sd card on the controller, instead of USB communication from the host - removes the short pauses.
Note that Nophead solution - using ethernet - is probably good for that too.

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Sun, 05 Aug 2012 15:30:15 -0400

sam0737 Wrote:
-------------------------------------------------------
> And there is a big "but" if the position
> computation is moved to the host - you lose the
> print by SD function! Or you need a host on the
> printer Raspberry Pi?

The printer raspberry pi has a pair of USB ports. Why do you need print from SD? You have print from USB.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Sun, 05 Aug 2012 13:13:09 -0400

sam0737 Wrote:
-------------------------------------------------------
> pete-theobald I think you have raised two
> questions-
> 1. Serial link between is too slow to transfer
> tons of GCode, especially during arc
> 2. Arduino CPU is not fast enough to compute the
> steps.
> I think we should move to a higher speed
> interface, be it normal USB (12Mbps instead of
> serial 0.25Mbps) or even Ethernet - that should be
> fast enough, and easy enough. Then also compute
> the steps on the host and buffered on the chip. I
> just wish Arduino could made a board based on a
> AVR chip with built-in USB support.
>
> I would imagine that the MCU would still need its
> own step execution logic of some sort, because
> otherwise homing would be very difficult to do.

I finished laying out my modular boards and I think it should just about work. What i've done is very reliant on a serial bus so if I can't get the baud rate up, I won't be able to get it to work. My calculations say that 250mm/s (along one axis) would need just over 1Mbps so this is going to be more than enough. Here's the calculations:

Max velocity (mm/s) 250
steps per revolution 3200 (200x16)
mm per revolution 40 (16tooth t2.5)
steps per mm 80
max steps/s 20,000
bits per byte 14 (uart with start, stop and 9th bit for addressing)
address bytes 1 (address bit + number hardwired into board using solder jumpers)
command bytes 1 (move to, change pid constants, control fan or whatever)
value bytes 3 (data value, i.e. absolute position to move to. 3 bytes would give me a total range of over 200 metres on each axis)
bits per packet 56
bits per second 1120000
Mbps 1.0681152344

I want to always transfer absolute positions as it allows for some error correction. It allows me to send the same message multiple times just in case without risking multiple steps. Also, it means that if a packet is completely missed, it just causes a glitch in the microstepping and the next value that comes through will pick it up (This seems like a benefit of microstepping as normal stepping might jump back a step if it missed a could of packets)

Here's an overview of what i've created and some maths that should help answer your points about communications speed.

Modular design
I laid out a single module which controls a single stepper motor, a single resistive load (heated bed or extruder), 2 end stops and a fan (2, 3 or 4 pin). The idea is that a number of modules can be positioned on a bus which supplies power and communications. The design has pins on one edge laid out on a 2.54mm grid so it can use veroboard as a backplane.

Inter module comms
Each module has an SN75176 bus driver so its effectively running an RS485 bus. I started off wanting to just wire the TX and RX pins directly to a bus but thought i'd struggle to get the bandwidth up high enough is I didn't use a proper line driver. Also, using the tristate on the pic pins to arbitrate the bus is asking for trouble!. I'm expecting the majority of the data to be going from the host computer to the module. The bus is attached using a 4 pin header. Wiring is
1, 2 - differential comms
3 - 5v for CPU
4 - GND

Power
I have a 6 pin header for supplying power. The wiring is as follows
1,2 - 12v
3,4 - 5v
56 - GND

Stepper driver
I copied the reference design for the A4982 stepper driver onto the board but i've created an exposed pad on the back for heatsinking instead of internal groundplanes. I added mounting holes for a slab of aluminium for a heatsink. The board is similar to a pololu in terms of driving the stepper, the price seems about the same but they're easy to wire in parallel and have a couple of extra modules as well.

Bed/extruder driver
I wired in a p channel MOSFET with a massive 12v plane. I reckon it could handle 5A to drive a heated bed. Its attached to a PWM capable pin on the pic but I don't think you need even medium frequency to run a bed or extruder. Once a second is probably fine.

end stops
2 end stops just to be sure.

Fan control
I added a 4pin header and a jumper to allow a PWM signal to either control the power line (mosfet) or onto the 4th wire for pwm control. The 3rd wire is connected to the timer0 clk line so we can measure fan speed. Not really important but it means we have a controllable fan for every board.

Controller board
The controller board is the cleaver part in all this. I decided I won't even attempt to handle the timing directly in the host pc, if usb really has 1ms resolution then i'm glad I haven't! I have a board which distributes power to the bus and also handles passing messages. The power is taken from an ATX connector and 2x disk drive connectors. That seems to be the lowest cost power supply for repraps. The comms are handled by a pic (18f14k50). This chips is used for the MCP2200 which are around £2 each and can connect as a full speed usb device. The chip needs to receive messages from the host pc and distribute them to the bus. The difference to a normal serial convertor is that it needs to handle the timing. I intend to send a stream of data equivalent to single steps, but I will also interleave specific wait periods. The wait commands are the clever bit in getting accurate time control. Its not really real time as it can only really playback a stream of data. If it wants to do any real time control it needs to give up the bus for modules to reply which means its only really useful for infrequent checks on temperatures. It might be possible to put pauses in the hosts control program to give some time to query all the modules for their status.

I'm going to get a few boards made up (Thank annirak for the tip about iteadstudio!). If I can get them to work i'll look at putting together a kit of parts for anyone whos interested.

Pete

Re: Why is everyone using arduinos to interpret gcode?

sam0737 — Sun, 05 Aug 2012 03:43:31 -0400

And there is a big "but" if the position computation is moved to the host - you lose the print by SD function! Or you need a host on the printer Raspberry Pi?

Re: Why is everyone using arduinos to interpret gcode?

sam0737 — Sat, 04 Aug 2012 22:48:04 -0400

Linux offering a high resolution timer doesn't mean you could have a thread sleep at precisely as much as you want, for that you will need a real-time kernel, in particular even if you could control your thread, you need to make sure the data sent to the hardware as fast as possible, for that you need real time drivers for the particular hardware.

That's exactly what EMC2 does when interfacing with drivers that compute acceleration profile and do the steps execution.
Because of the latency problem, USB is out of the game (it's not designed to support low latency data stream consistency). Parallel port and PCI (or ISA) is a popular choice because they are directly mapped IO of the CPU. In fact, EMC2 support a tons of "steps execution device" that use parallel EPP for data transfers (not direct pinout bit-bang), or PCI. Most, if not all, are made of FPGA.

Synchronization of the chip - not only you need to start all the execution precisely, you would need to change acceleration/deceleration profile in every steps execution to make sure they are in-sync. The communication channel would get real busy when drawing an arc.
I just wish the chip to include a "trigger pin" - for all chip to execute all the buffered profile at the same time. But still, profile computation and communication would still be a hard thing to solve.

Re: Why is everyone using arduinos to interpret gcode?

sam0737 — Sat, 04 Aug 2012 22:26:39 -0400

Repetier host sends binary GCode, but it's still GCode but not computed position.

EMC2 requires still relatively real-time operation for the position calculation, becasue EMC2 is not just designed for stepper but also servo motor, it is designed to compute the position every 1ms (or some other regular interval) and update the stepper driver.

The stepper driver could be an old day parallel port, or a PCI card of some sort. USB is out of the game because the highest resolution (interrupt command) is just 1ms (or 0.125ms for high speed IIRC), and we don't even talk about the latency or jitter of any sort here, it's just the highest resolution offered in the spec.

I understand that for steppers (not servo) we could precisely compute when to send out what steps signal.
IIRC, EMC2 does not support pre-computing all these and send them to a buffering device of steps execution. First, for the servo support, Secondly, logics (like end-stops, automatic Z-zeroing, or other tons of logic - because EMC2 even supports ladder) could be very tricky.

pete-theobald I think you have raised two questions-
1. Serial link between is too slow to transfer tons of GCode, especially during arc
2. Arduino CPU is not fast enough to compute the steps.
I think we should move to a higher speed interface, be it normal USB (12Mbps instead of serial 0.25Mbps) or even Ethernet - that should be fast enough, and easy enough. Then also compute the steps on the host and buffered on the chip. I just wish Arduino could made a board based on a AVR chip with built-in USB support.

I would imagine that the MCU would still need its own step execution logic of some sort, because otherwise homing would be very difficult to do.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Fri, 03 Aug 2012 18:57:45 -0400

Annirak Wrote:
-------------------------------------------------------
> With two spare GPIO, you can have enable-in and
> enable-out, which allows you to set up each device
> without jumpers, based on its position in the
> chain.

I moved a few pins around and freed up 8 pins (coupled with ICSP). You should be able to see the circuit diagram here [github.com]
and the pcb here [github.com].
The boards 50x50 and I don't see any reason to go smaller. I want to get a couple of mounting holes between the stepper driver and the big mosfet so I can fix a slab of aluminium to the back. I also need to think a bit more about the fan controller. It would only work with a 4 pin fan at the moment so I might need another mosfet to control the fan power so it can handle a two pin fan.
p

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Fri, 03 Aug 2012 09:55:54 -0400

With two spare GPIO, you can have enable-in and enable-out, which allows you to set up each device without jumpers, based on its position in the chain.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Fri, 03 Aug 2012 07:32:05 -0400

Its probably cheaper to get a pic with a higher pin count if i'm going to use dip switches but the board area goes up and I'm sure the switches cost £1 each as well. Soldered jumpers could be quite nice as its just as easy to read the value and its not as if they will be changed regularly.. I choose one based on cost to start with. The alternatives are to hard code the number into the firmware and recompile it each time or add a jumper to activate some form of address setting mode, i.e. the controller sends an address setting message and every board with the jumper connected gets that address.
p

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Wed, 01 Aug 2012 20:28:04 -0400

pete-theobald Wrote:
-------------------------------------------------------
> * Some way to set the nodes address. I was
> planning to use a dip switch but i've run out of
> pins. I could program it directly into eeprom but
> that needs the user to have a pic programmer which
> is another £25

If you have a spare ADC pin, you could make something like a R2R DAC with the DIP switches and measure the level to decide the address.

Re: Why is everyone using arduinos to interpret gcode?

pete-theobald — Wed, 01 Aug 2012 18:42:11 -0400

Annirak Wrote:
-------------------------------------------------------
> If you can keep the PCB size to 50mmx50mm or
> smaller, iteadstudio will manufacture 10 of them
> for $9.90.

Funny that you say that, I just managed to get the bulk of the components to fit onto 50x50. I've put it here [github.com] (eagle pcb).

There are loads of components missing (mainly capacitors) and I haven't quite figured out how I'm going to attach the modules to a serial bus yet. Ideally I want them to stack on top of each other, or maybe fit into a series of sockets soldered to veroboard. The main problem i've seen with pololus and my own electronics (gen6 with drivers soldered directly to pcb) is heat causing the motors to skip. I'm trying to layout the board so I can screw a strip of aluminium to the back to act as a big heatsink. An inch of aluminium sticking out either side would help alot. The board currently has:
* one pic
* a4982 microstepping driver with a 4 way header
* 2x 6 way headers with 5v, 12v, ground, switched ground and 2 analog connections. That should be enough for an extruder and a fan.
* communications using the uart. I'm hoping I can get the addressing handled using 9 bit serial and also use that as a start of frame header. I can also use the same scheme as a synchronisation signal.

What it still needs is
* a master node which can handle receiving signals from a host pc and sending them to the relevant address and making sure everything is kept in good time.
* Some way to set the nodes address. I was planning to use a dip switch but i've run out of pins. I could program it directly into eeprom but that needs the user to have a pic programmer which is another £25
* Some better routing - hopefully involving some forward planning rather than just getting stuck in. I'll have another look later in the week but i'd love to hear peoples views on how I could route around a large exposed ground plane on the underside.
* Possibly a transmit signal so the boards can talk back to the controller. It would need some form of tristating and arbitration so prob best avoided, but seems a shame to miss.
* A better way to connect the boards together. I've just wired in molex kk connectors as they're easy to find, but they aren't made for easy daisy chaining
* ICSP header routed in (not much use without it)

Let me know what you think.

Pete

Re: Why is everyone using arduinos to interpret gcode?

Annirak — Wed, 01 Aug 2012 15:22:31 -0400

If you can keep the PCB size to 50mmx50mm or smaller, iteadstudio will manufacture 10 of them for $9.90.