Why is everyone using arduinos to interpret gcode?

Hi Everyone,

I had a look at electronics yesterday, thinking about what I would need to build a new reprap (possibly a mendel 90 or similar). I noticed that almost all are based on the arduino, they usually convert gcode into movement using the 16/20MHz arduino and are also limited on pins. I had an idea for a different approach which would be lower cost and higher performance.

As far as I see it, there are two operations involved in controlling a CNC machine. The first is converting gcode into actual positions at particular times. The second is to toggle various pins at the right times to make the stepper motors move to the required position at the right time (I've ignored the heater control here as it isn't going to be limited by the processor speed). I don't understand why the gcode conversion is done in the arduino and not on the host pc as its pretty unsuited to the task. Its also not necessary to do the gcode conversion just in time as it looks pretty deterministic.

When processing gcode, the task is to make sure that the different motors run at the correct relative speeds to follow the right path. gcode is roughly made up of a series of positions and max speeds (ignoring the heaters again) which just needs to be converted into a waveform to be applied to a series of parallel pins. When the resoultion gets too high - i.e. when I export an STL file with 0.1mm resolution without thinking - the printer judders as it can't keep up. I'm guessing this is related to the processing power of the arduino, and also the requirement to do that processing just in time as there's limited space in the buffer, accentuated by needing to convert text to numbers because we're using a text protocol. As an alternative, I wanted to build the conversion part of the firmware to run on a pc, and then pipe the actual motor commands to the electronics using a raw binary format. This way, I'd get the benefit of massive amounts of memory and processing power when interpreting gcode and also be able to do all the work in advance, so no juddering as we'd have a very constant stream of commands. Has this been done before? It would be the equivalent of a software modem which is a good example of a low cost device.

Thinking about electronics and firmware, I would just need a basic firmware that handles updating motor positions at regular intervals (timed interrupt) from some sort of fifo buffer and a background task that handles keeping the buffer full. Some of the higher pin count pics (£2-3) look like they could control 8 steppers and 6 heaters/fans pretty easily. Stepper drivers are relatively cheap if you buy the chips rather than pololus (£2-3x8=£16-24) so we might be able to hit ~£50 for a complete board, with hopefully much better performance than the arduino based boards, and space for many more steppers and extruders.

If anyone's tried this I'd be interested to hear how you got on.

Regards
Pete

Yes I have been operating my machines this way since 2007. Also Makerbot interpret the gcode on the host and send binary and I think the Repetier host and firmware can operate this way.

---

[www.hydraraptor.blogspot.com]

Thanks Nophead,

What have you used to interpret the gcode? I need to convert the gcode into a series of points and maximum velocities before I start building the driver waveform. Do you only handle a small number of gcodes? I can't see anything obvious other than G1 so it should be pretty easy (G1 X90.6 Y13.8 E22.4).

Also, what do you use for a driver? Pololus or just chips? I'm thinking of putting together 8-10 stepper drivers (probably won't solder them all on to start with), a number of half bridges driven by PWM for heaters and attached to ADC chips, PC power supply control and either an FT232 or a direct USB connection. does that compare to what you're doing. If I had enough stepper ports I could add 3 or 4 steppers to the bed and make it self levelling...

Pete

I'm working on a variant of this approach: I'm going to use L6470 stepper drivers, which are massively integrated drivers: you give them target position, velocity, acceleration, and deceleration arguments, and they do the rest. I'll control these with a Raspberry Pi. I'm about 50% done the design work; I'll let you know how it goes.

pete-theobald Wrote:
-------------------------------------------------------
> Thanks Nophead,
>
> What have you used to interpret the gcode? I need
> to convert the gcode into a series of points and
> maximum velocities before I start building the
> driver waveform. Do you only handle a small number
> of gcodes? I can't see anything obvious other than
> G1 so it should be pretty easy (G1 X90.6 Y13.8
> E22.4).

I just look at G1 and extruder on off M commands with a few lines of Python lifted from Skeinforge.

>
> Also, what do you use for a driver? Pololus or
> just chips? I'm thinking of putting together 8-10
> stepper drivers (probably won't solder them all on
> to start with), a number of half bridges driven by
> PWM for heaters and attached to ADC chips, PC
> power supply control and either an FT232 or a
> direct USB connection. does that compare to what
> you're doing.

Most of my machines use Pololus. I use Ethernet instead of USB.

>If I had enough stepper ports I
> could add 3 or 4 steppers to the bed and make it
> self levelling...
>

I probe the bed at three points and then incline the model to match: [hydraraptor.blogspot.co.uk]. No need for extra motors. This is one of the big wins from interpreting the G-code on the PC instead of a tiny micro.

---

[www.hydraraptor.blogspot.com]

Annirak Wrote:
-------------------------------------------------------
> I'm working on a variant of this approach: I'm
> going to use L6470 stepper drivers, which are
> massively integrated drivers: you give them target
> position, velocity, acceleration, and deceleration
> arguments, and they do the rest. I'll control
> these with a Raspberry Pi. I'm about 50% done the
> design work; I'll let you know how it goes.

The L6470 look like clever devices, do you have an idea of cost of a system vs typical arduino/pololu system?

Annirak Wrote:
-------------------------------------------------------
> I'm working on a variant of this approach: I'm
> going to use L6470 stepper drivers, which are
> massively integrated drivers: you give them target
> position, velocity, acceleration, and deceleration
> arguments, and they do the rest. I'll control
> these with a Raspberry Pi. I'm about 50% done the
> design work; I'll let you know how it goes.


How do you plan on synchronizing the axis to each other so they step at the same time?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

pete-theobald Wrote:
-------------------------------------------------------
> I had a look at electronics yesterday, thinking
> about what I would need to build a new reprap
> (possibly a mendel 90 or similar). I noticed that
> almost all are based on the arduino, they usually
> convert gcode into movement using the 16/20MHz
> arduino and are also limited on pins. I had an
> idea for a different approach which would be lower
> cost and higher performance.

When I first got involved, someone told me he needed a CPU faster than Arduino, that could handle floating point, to process the Gcode faster. I immediately wondered why on Earth would anyone transfer MB of ASCII data from a 3GHz PC with an FPU to a 20 Mhz AVR in order to process the data on the AVR? That is a crazy design, but it turns that is how RepRap was designed and bad designs become "standards" and almost impossible to change.

Amazingly, people still transfer GCode complete with spaces, comments, repeated Z and F values and complain that the Arduino is too slow to keep up at high res. A few lines of Python would cut the size by 50%, but there is no attempt to compress the data at all. Preferred solution is faster comms?? Really bizarre.

One of the few advantages of GCode parsing in the controller is to allow standalone printing from SD, which I think not many RepRappers actually do. Even there, the Gcode could be compressed before storing on SD.

Anyway, if starting with a blank sheet there is plenty of room for a radically improved architecture. The printer controller could be greatly simplified, the main thing I would keep is for the controller to handle the steppers with accel/decel profiles provided by the host.

Having said that, I am not sure how much cost reduction could be obtained, a full electronics kit costing around $180, maybe $10 is the cost of the CPU.

bobc Wrote:
-------------------------------------------------------
> The L6470 look like clever devices, do you have an
> idea of cost of a system vs typical arduino/pololu
> system?

The bare chip costs $9.23 in 10 unit quantities. It is small enough to fit two on a 5cm x 5cm board, so the PCB cost is $0.50/axis. Add about $2.50 per axis in connectors, discretes, and passives. Total cost is around $13/axis, which is on par with Pololu's. Gen7T will still be cheaper at $3.60/axis.

The RPi is $35, so that's going to add about $30 to the cost as compared to Gen7. I anticipate a total cost of around $100. I will post more info about development when I have a little more to add.

Sublime Wrote:
-------------------------------------------------------

> How do you plan on synchronizing the axis to each
> other so they step at the same time?

Amazingly, this is the easy part. The L6470 supports daisy-chaining on SPI. Which means that all L6470's in a chain share a single SSEL pin, so all commands on all L6470's take effect simultaneously. They also support daisy-chaining of their PWM clocks (the step clocks are derived from the PWM clock), so you can be sure that all clocks are synchronized.

@Pete-Theobald:
Curiously i got a steam generator with that name, is that too much to think that you may be from that company - and from which country ?
Sry for the offtopic, couldnt help myself

Edited 1 time(s). Last edit at 07/31/2012 06:54PM by NoobMan.

Hi Annirak,

SPI would seem practical but I'm not sure the data rate would be up to it. If we assume we have 5 motors, and we want a max speed of 160mm/s. With a 16 tooth t2.5 pulley we'd have 40mm/rev, 200 steps on the motor x16 say, so 1600 steps per second. If we need to send a 16 bit integer to each driver at the exact right time, we'd have a data rate of 256kHz. That's only per motor. I don't see how you could get the timing right on that. Remember that you aren't trying to get the motors to step in sync, you are specifically trying to get them to step out of sync. If you imagine a grid made up in x,y where each point is an integer number of steps, the line you want to trace is very unlikely to go through all the intersections. You want to step each motor at the point where the desired path crosses the relevant line.

I'm also not sure about whether the pi would be suitable. The main reason is the timing issue above, but I also think getting a real time process running will be very hard. As far as I remember, linux uses a 1uS tick so thats your maximum resolution, and you're also not guaranteed control.
There are real time kernels, but hacking the kernel is not where i'd start if I could just build an add on board to handle the real time stuff. PIC or AVR interrupts can be scheduled much more precisely, and I can also keep the position counts in memory so I don't need a complex chip, direction, step and enable should be enough.

p

Thanks nophead, thats a much better idea and sounds just like a pretty easy matrix transform. Are the pololus difficult to find though? I saw the chips are getting hard to find and the heatsink issue is a bit concerning, but they are relatively cheap. I was just going to make my own board and I could easily make the stepper drivers as daughter boards.
p

I use EMC2 to drive my 3D printer/router combo, it's based on a real-time Linux kernel and outputs the step and dir signals directly to the parallel port.
But parallel port is outdated and inputs/outputs are limited (12 outputs and 5 inputs).
Mach3 (the closed source equivalent of EMC2) can work with dedicated USB adapters, I would be very interested by an USB adapter for EMC2.

Hi Pete,
I don't want to completely hijack your thread with my design work, so I'll try to be brief.

pete-theobald Wrote:
-------------------------------------------------------
> Hi Annirak,
>
> SPI would seem practical but I'm not sure the data
> rate would be up to it. If we assume we have 5
> motors, and we want a max speed of 160mm/s. With a
> 16 tooth t2.5 pulley we'd have 40mm/rev, 200 steps
> on the motor x16 say, so 1600 steps per second. If
> we need to send a 16 bit integer to each driver at
> the exact right time, we'd have a data rate of
> 256kHz. That's only per motor. I don't see how you
> could get the timing right on that. Remember that
> you aren't trying to get the motors to step in
> sync, you are specifically trying to get them to
> step out of sync. If you imagine a grid made up in
> x,y where each point is an integer number of
> steps, the line you want to trace is very unlikely
> to go through all the intersections. You want to
> step each motor at the point where the desired
> path crosses the relevant line.

In fact, the L6470 works a little differently than that. While it can be driven one step at a time, it's really designed to be given a target position, an acceleration profile and a maximum speed. It has an internal position counter. In other words, the L6470 contains a full trapezoidal movement generator.

Many firmwares slice curves into small segments, then move at a constant speed for each segment. I've read through the code for handling curves in Marlin and it appears to do this.

Let's assume that you've set the acceleration profile in the L6470 to infinite, so that there's a minimum of slow-down and speed-up between each segment, and the firmware/software of the controller is managing acceleration. Then, each move takes a command to set the maximum velocity, and a command to set the target position. The max speed command is 3 bytes. The move and goto commands are 4 bytes (either/or don't need both). So, each segment requires a total of seven bytes per motor, so 35 bytes for a chain of 5. The SPI port on the L6470 works at 5MHz, so the time between moves is (35 * 8)/5MHz = 56us. Accounting for the the chipselect high time, that's more like 62us.

To address the issue of the grid, the momentum of the system ensures that the steps are smooth, but setting that aside, the L6470 does 1/128 microstepping, which means that in your above example, the resolution of the grid is 40mm / (200 * 128) = 1.5625 um/microstep. I think that resolution should be adequate even without the smoothing given by momentum.

>
> I'm also not sure about whether the pi would be
> suitable. The main reason is the timing issue
> above, but I also think getting a real time
> process running will be very hard. As far as I
> remember, linux uses a 1uS tick so thats your
> maximum resolution, and you're also not guaranteed
> control.
> There are real time kernels, but hacking the
> kernel is not where i'd start if I could just
> build an add on board to handle the real time
> stuff. PIC or AVR interrupts can be scheduled much
> more precisely, and I can also keep the position
> counts in memory so I don't need a complex chip,
> direction, step and enable should be enough.
>
> p

The L6470 gives a busy flag, which can be OR'd between all drivers. To make use of this, I think the best option is to use a kernel driver and initiate the next set of SPI transactions when the busy flag turns off. This will make the total time between moves somewhat dependent on the interrupt processing latency in Linux.

With regards to the system timer resolution, the Linux kernel now includes (since 2006) a high resolution timer which counts in nanoseconds.



Now, with all that said, I'm still concerned about the timing and resolution. To prevent myself from ending up with unusable electronics, I'm placing footprints for a microcontroller on each of my boards. I don't think I'll need the microcontrollers, but if it turns out that the plain RPi + L6470 solution doesn't pan out, I have a backup plan.

Annirak Wrote:

> > How do you plan on synchronizing the axis to
> each
> > other so they step at the same time?
>
> Amazingly, this is the easy part. The L6470
> supports daisy-chaining on SPI. Which means that
> all L6470's in a chain share a single SSEL pin, so
> all commands on all L6470's take effect
> simultaneously. They also support daisy-chaining
> of their PWM clocks (the step clocks are derived
> from the PWM clock), so you can be sure that all
> clocks are synchronized.

This daisy chaining idea got me thinking. I was originally trying to build cheap electronics that supported lots of steppers as most are limited to 5 at the moment, as well as 1 extruder on the whole.I'd still be limited to ten in practice and its not the most useful thing anyway. Building a module with a single stepper motor driver, pwm driver, ADC, end stop and fan but that could be daisy chained together would be much more efficient. You could buy as many modules as you need and as the volumes are higher and the pcbs smaller they'd be cheaper as well. I'm going to knock up a design using a single stepper driver (A4982), ADC (tbc) and half bridge driver and controlled by a single low cost pic. If each one has its own address (dip switches, links or solder joints) it can sit on a serial bus. For normal motors, we don't need to solder on all components so we have a range of functionalities with only one pcb. If I use a pic costing £1 (PIC16F1516), A4982 costing £3 and MOSFETS costing very little for the h_bridge. A 40x30 PCB would be around £4 in moderate quantity so it might be possible to make a whole board for under £20, and a 5 channel electronics set would be under £100 just like current electronics, but able to support more.

p

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

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

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.

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

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.

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

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.

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.

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?

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

Edited 1 time(s). Last edit at 08/05/2012 04:24PM by pete-theobald.

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.

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.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

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.

If sdcard works but usb doesnt then its clearly bandwidth rather than time taken to interpret text based gcode. I'm planning to send binary packets made up of 4-5 bytes for each step. I think I can get decent speeds at 500kbps so USB should be plenty.

p

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.

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.