Generation 7 Electronics Development

after Gen6 being an industry-optimized design, the emphasis in Generation 7 Electronics is on collaboration, community driven
development and easy replication. For example, one major design goal is a single-sided PCB.

Hi,
Great start on an electronics collaboration page, I have been planning and working on a similar draft spec (Entitled Reprap Community Electronics 2011)

It's nice to see an open community effort on this, too many electronic designs are being worked on by just one person, this usually leads to limited future expansion /flexibility or innovation.

It's worth thinking about the firmware and host software at the same time, or you may just end up with yet another Atmel Mega+Pololu remix design with little future thought. That said I really like the RAMPS design as a starting point for anyone looking towards developing a single PCB for Reprap.

A few initial comments -
Calling it Gen7 may confuse new-reprappers, we have so many choices and I bet someone is already working on Gen 8 /9 /23 - emphasise the community spec aspect of it.

The ATmega644 may run out of speed if using 1/16 microstepping on all 4+ steppers, you want to make sure it can run steppers faster for the future and high resolution so maybe think about using the new Mega 2560 or better.

Think about having 2 x Extruders as standard, you don't have to populate the components on the PCB if you don't need the 2nd ext, but it's going to be a pain if it's missing.

Set a target works cost price so you don't get spec-swell (maybe £80 / $110 / e120)

I will dig out my spec and try to throw in a few more ideas shortly. -

Lots more people need to get involved with this project, it could be great.

QuoteThe ATmega644 may run out of speed if using 1/16 microstepping on all 4+ steppers, you want to make sure it can run steppers faster for the future and high resolution so maybe think about using the new Mega 2560 or better.

I fear we're pretty limited here, as all ATmega processors are 8 bit, running at 20 MHz max. The Mega 2560 gives a lot of room for firmware, but it can't make steppers running faster. Moving to an entirely different processor like the AVR32 or AMD Cortex should be postponed until this PCB replicating thing works, IMHO.

QuoteThink about having 2 x Extruders as standard, you don't have to populate the components on the PCB if you don't need the 2nd ext, but it's going to be a pain if it's missing.

Looking at how Gen7 should communicate to the host, I think relying on RS-232 is a bit backwards oriented, especially as this would need an 3.3V to 5V converter. Such level converter chips exist, but they cost, need passive elements and anyways, many modern computers no longer feature serial ports.

Another advantage of using USB is, one can run the entire logics off USB power, only requiring 12...24 Volts for motors and heaters. The big and expensive ($2) ATX20 connector could vanish entirely.

Searching for something better I've found the MAX232 used by Arduino and Gen6 is obviously available in SMD packages only *sigh*. However, there seems to exist a solution without any extra chip: V-USB Did anybody try this? Does this still allow to send firmware to the chip?

> Another advantage of using USB is, one can run the entire logics off USB power, only requiring 12...24 Volts for motors and heaters. The big and expensive ($2) ATX20 connector could vanish entirely.

I did this, and the voltage was 4 V at my board, so there was a 1 V voltage drop. It's not that it didn't work, but I'm not sure if it's the best idea.

Anyway, you could get rid of the connector by putting 3 clamps on the board and simply cutting off the connector, because the ATX Power Supplies provides 5V.

Or you can use a converter 12 => 5 V as Gen6 does. The MC34063 is a cheap and universal voltage converter chip in a DIL package which can be used for this purpose. Or an 78L05, cheap and easy.

> solution without any extra chip: V-USB

That exists indeed, but I'd doubt that it is possible to do time-sensitive USB-stuff at the same time as time-sensitive stepping-stuff.
But I never used that interesting library myself, and it might still be possible. But I'd not put my development effort into that path at this time when finishing this board is a priority. Once it works, it will certainly evolve due to more people using it.

Getting a MAX232 to work and using a RS232-USB converter cable is easy and cheap and certainly less of a hassle: no tricky software development needed for that part because the Rx/Tx already works fine like that.

Admittedly I'm more familiar with FiveD for Arduino which features a buffer for 8 movements, so pausing communications for a second doesn't really matter. Also I think "low speed USB" is still faster than high speed serial.

QuoteNudelwhy use the bulky ATX20 connector in the first place? If a standard connector is needed, why not use the 4pin molex plug to get 12v,5v and ground?

On advantage of this bulky connector it the PS_ON pin to switch the PSU on and off. Another one is, you don't have to swap pins in and out of the housing. As some people request using wall wart power supplies, using the 4 pin connector would be yet another option :-}

The problem might arise if the USB spec requires a certain reaction speed (not baud rate) which can not be met because of steps being executed.

But it might be solvable.

You could add the circuit to your FiveD on Arduino board and test it.
There are many examples, libraries, etc. on the vUSB site, and infos about the requirements. Maybe they also have a forum/IRC channel to ask questions, or maybe there is even an example with steppers.

You can just enumerate any micro with direct USB to look like a serial port and work in a similar way to the ftdi device, make it look like a standard HID device and it will be happy with win/Linux
many examples exist, microchip has a whitepaper app-note on doing inside most PIC's

serial speed is not really the issue.

But a decision on what Micro to use is. Or actually it's a firmware and tool-chain decision really, most small Micro's would do the job just fine.

The atmel mega has 16mips @ 16mhz which is more than enough to run any reprap at full-speed, but it may take a bit better programming than Arduino to get there.

If a move away from atmel and Arduino is prefered then the smart choice is ARM. But that's quite a bit of development just to get to the point we are already at with the mega.

QuoteTraumflug
I fear we're pretty limited here, as all ATmega processors are 8 bit, running at 20 MHz max. The Mega 2560 gives a lot of room for firmware, but it can't make steppers running faster. Moving to an entirely different processor like the AVR32 or AMD Cortex should be postponed until this PCB replicating thing works, IMHO.

I have been looking at the Atmel 32 microcontrollers, and I think we should start a design group for one of these. It not only helps solve the problem of microstepping multiple axes at once, it also makes USB interface easier, and adds Ethernet 10/100. But it certainly will not work on a single sided PCB, so it does not belong in the Gen 7 approach, which I agree is good for getting a board that a Mendel could possibly make. However, the 32 bit machines would allow for MANY extra interfaces, faster processing, more axes, more motors, more heaters. So I suggest we also start a "Gen X" working group to work on a 100 pin LQFP based design with lots of expansion built in. It will be longer before a reprap can build such a board, but for pre-purchased electronics it will open up whole new vistas for extra functions and capabilities for next generation repraps.

Regarding these opto endstop PCBs, I find them rather useless.
One can eliminate the LED1 + R3 and display the value via firmware / host.
R1 and R2 can be integrated onto the controller PCB, then there is no need for another endstop PCB.
The opto endstops themselves can be screwed directly to the machine (the flag might need some apatation).
I guess it's what was done for Gen6, too.

I used simpler endstops, models without integrated schmitt trigger, but I put a 74HC14 schmitt trigger on my controller PCB. That way, I could use simpler (easier to get) models of the opto endstops.

I am keen to start milling PCBs with my repstrap for my mendel build, so this forum thread attracted me. I have also been looking at the reprap BEEF electronics due to their flexibility and expandability, with a view to creating each tab as a single sided PCB which can be produced using a reprap machine.

My question therefore is why should I choose the Gen7 scheme over the BEEF scheme for my electronics?

Once you can mill your PCBs and design them with a PCB layout software you know how to use fluently, the differences are probably becoming unimportant. You can then adapt things to your special use case.

I am using ubuntu Lucid with RTAI above all because I use it to run my 6040 CNC router with emc2 (http://www.linuxcnc.org).
This machine, like most, has a native configuration in mm, but the gcode generated by pcb2gcode begins with a g20, so all the following in the file is in inches (this means it is translated in real time, and what I see on screen is still in mm).

Haven't yet tried actually engraving it, since I am short of H21LOBs, and it this piece is flagged in mouser as an "end of life product". This probably means we should look for a suitable replacement, and eventually adapt the pcb.

I know some people prefer to have a dedicated machine for their router/engraver, but I am using mine also as a general purpose machine, and the RTAI interface is no problem in that aspect, when not in use it just stays out of the way.

The install is quick and easy: basically I installed stock Ubuntu Lucid, updated it, then ran the script provided here:

But now it is even easier since they have an installable10.04 livecd. There's an apt repository for linuxcnc that pushes all the updates to emc2 et al. Just say no to stock kernel updates from other sources, and that's it.

It definitely is a 32 bit version, while compiling RTAI with 64 bit kernels is possible under some conditions, with "only" 2 GB RAM it isn't justified, and I do not feel like dealing with the x86_64 (shrinking) set of incompatibilities.

I love the power of emc2 and would love to try some emcrep(st)rap at some point in the future when I gain some mastery of it: I have a stash of discarded desktop machines that are crying for some new use, and their cost was way less than that of a single ARM Cortex

But in more immediate pursuits I am itching to try routing your great little "Generation 7" board. Do you think it is mature enough to try as is? Is it currently usable with an FTDI TTL-232 usb cable? Any recommendations for burning the bootloader?

- IIRC, the analog inputs still must be routed to A/D capable pins, otherwise the Thermistors cannot work.
- As there is no ISP on that version of the board, the bootloader must be programmed externally.
- If there is a bootloader, I'm not sure that the reset mechanism will work automatically, which is very inconvenient if it does not work.
- The sanguino bootloader would probably be fine if the ATmega644p is used. (But I don't know if it works with the ATmega644 (without p) as well.)

I posted some more items in the german thread (linked on the wiki page).

The ICMP header should probably go back onto the board. It's still in the schematic, just disconnected. A more distant target would be to get either direct USB (e.g. V-US working or finding some USB to serial converter chip with 2.57 mm spacing. Also, an appropriate stepper driver chip, the DRV8811 (and a different, similar one I've lost track of?) has appeared. But heck, getting something working is more important than just dreaming ...

My self I'm currently pretty busy hacking pcb (the application) it's self to improve the G-code exporter. I'm satisfied with the isolation milling stuff, drilling G-code currently lacks just tool changer commands and the board outline can't be milled. Also, different and user configurable feed rates for vertical and horizontal movements would be fine. Not super difficult stuff, still it has to be done :-)

Instructions on how to install the patches are somewhere towards the end of the PCB milling Wiki page.

Thanks Sebastian. I think I will step out of the current sequential numbers being used by various 8bit AVR/arduino designs and jump to a new naming/numbering scheme for 32bit processor based controllers. Lets use 32GenX1..2..3 for 32bit microcontrollers on custom boards (eXperimental), 32GenS1..2..3 for SBC (single board computer) based designs, and 2GenP1..2..3 for pentium based designs that may also have built in graphics, keyboard, GUI interface. So as first generation of 32bit microcontroller on a custom board with all the goodies built in, I will rename it to 32GenX1.

Time sensitivity:
According to the V-USB documentation (the comments in usbdrv.h), the USB interrupt handler can take up to 100us (though this includes waiting for the host, so typical times may be shorter; for comparison, one X or Y step = approx 2000us), and must not be disabled for longer than 2us (25-40 clock cycles). However if this is not possible while printing, V-USB does allow the device to pretend to be unplugged (usbDeviceDisconnect()), so it could store some Gcode in RAM then disconnect and print it, though this would probably require changes to the host software.

Loading firmware:
If the chip already has a V-USB capable bootloader on it (USnooBie, AVRUSBBoot, etc), it can load other firmware via V-USB, so the user would still be able to upgrade/modify the RepRap firmware.
If the chip is completely blank (which it normally is when bought), it can't use V-USB, but can't use a hardware USB-TTL converter either; for that, you need either a parallel port, or another already-programmed chip (USBtinyISP, USBasp, etc).

Needing a programmed chip to program a chip suggests using the parent RepRap to program the child; it looks possible to use the same connector for programming and being programmed, with a reset jumper selecting which (ie no extra hardware, though if those pins have a normal RepRap function it might be necessary to unplug that), and USBasp looks like it already uses that setup.

I corrected the ISP header pinout (it was still wrong like in Gen2OnABoard) and connected it back, I think too it will certainly be of some use.
New pinout:
5 3 1
6 4 2
I realized too late that the correction should have been done in the component in the library, which is still untouched (to do). I fear the name of the component disappeared, and the trials of auto-routing were all wrong (short-circuits everywhere). So the track layout was 100% manual. Couldn't avoid the vias, there must be some cleverer layout.

This is my very first forage into geda/gscheme/pcb, so I hope not to have made too much of a mess. Hopefully the board is usable. Advice welcome and much needed.
Cheers,
L.

Lanthan,
Your schematic has the limits stops as ground, signal, power, but your PCB layout has them ground, power signal. When I ran optimize rats, it showed many shorts and missing connections, basically bridging that whole side of the chip. You need to decide if you want to use the schematic choice of signal on the middle pin, or the PCB choice of power on the middle pin. Sticking with the PCB design and changing the schematic to power in the middle will help reduce vias and cross overs.

I think we can reduce the number of vias and cross overs once the above question is resolved. To get a single sided board, you can use a few 'zero ohm resistors' to bridge across where needed. Also, I would fix the ISP header wiring using super skinny lines and going between pins. That is still easier than doing a double sided board and getting everything to match up correctly.