# Gen7 Board -ARM 2.0 DIY build

Posted by Shank man
 Gen7 Board -ARM 2.0 DIY build December 31, 2016 02:51PM Registered: 7 years ago Posts: 203
I'm attempting to build a Gen7 board-ARM 2.0 by following the
instructions on the Wiki page. I'm not trying to save any money
but am only doing it in the pursuit of knowledge. If it works I'll
just use it to replace the RAMPS on my antique Prusa2.

So far everything is on order. I attached a list of my purchased parts from Mouser Electronics.
It pretty much covers everything with the exception of some resistors that I had
leftover from previous projects and the PCB. I ordered extra parts just in case I destroy something
during the assembly process.

I do have a couple of concerns. The connectors called out for the end stops & motors are listed
as Molex KK256 series. I couldn't find any info on these so ordered KK254 series with a 2.54mm
pitch. The hole spacing on the layout seem to justify this. I also ordered 25volt electrolytic caps.
After reading further I noticed larger ones could be used. Also my 0.1uF ceramic capacitors look a
little different than the ones shown. Hopefully they are okay to use.

Edited 2 time(s). Last edit at 12/31/2016 06:17PM by Shank man.
 Re: Gen7 Board -ARM 2.0 DIY build January 01, 2017 05:57AM Registered: 11 years ago Posts: 7,616
Quote
Shank man
The connectors called out for the end stops & motors are listed as Molex KK256 series. I couldn't find any info on these so ordered KK254 series with a 2.54mm pitch.

KK254 is correct. I just fixed the Wiki.

 Generation 7 Electronics Teacup Firmware RepRap DIY
 Re: Gen7 Board -ARM 2.0 DIY build January 02, 2017 10:31AM Registered: 7 years ago Posts: 203
Using the toner transfer method to create a usable PCB must take a special set
of skills. Skills in which I am severely lacking. It took me a 1/2 dozen tries to make
what I believe to be a usable Gen7 PCB. I repeated the steps I used for the last one to make a second
one. The second one turned out only slightly better. Both look kind of rough but I
verified continuity of all the traces and made sure none of the paths were shorting out. I wish they had
come out a little bit better. This method is not an ideal way to create them in the first place and maybe this is
as good as they get. I'm not very confident about these boards but I'm moving
forward. I'm going to assemble the less crappy of the two boards

 Re: Gen7 Board -ARM 2.0 DIY build January 08, 2017 12:05PM Registered: 7 years ago Posts: 203
Progress is slow but the board is coming together. I expected to be finished by now but
never having made a circuit board before this is all new to me.

I encountered a few setbacks along the way. I had soldered a dozen or so components to the
board and found out why the ceramic capacitors looked different than the ones pictured. I had
mistakenly ordered ceramic DISC capacitors instead of the multi-layer ones. The bigger head of
these disc capacitors prevent them from fitting under the drivers. Also the leads have a wider
spacing. I briefly considered mounting them on the underside of the PCB but decided against it.
That would have been a halfassed solution and I don't want to start cutting corners so early in the
build stage.

To replace the disc capacitors I ordered these....

The 0.1uF is now Mouser # 810-FG16C0G1H104JNT6
and the 22pF is now part #81-RCE5C1H220J0A2H3B.

Like a dummkopf I also ordered the wrong USB-TTL adapter chip. I wasn't paying close enough
attention when picking out the parts. I ordered a 579-MCP2200-I/SS (SS=super small package ??). I
reordered part 579-MCP2200-I/SO. They are only $2.00 each but$8.00 to ship the damn things if I
want to wait a week to get it. If I want it sooner I have to pay $15.00 for three day delivery. Ordering these wrong parts turned out for the best because it halted the assembly and forced me to take another look at my PCB. The nagging feeling of using a suspect PCB finally got the best of me and I aborted the build. The only thing good to come of this was that I got in a little soldering and board drilling practice. I went back to the ironing board to pursue a better etched PCB. Finally after 9 tries I have what I know is a good board. I printed off the earlier board circuit paths with the printer settings set at 600 dots per inch & 100% density. I believe this 100% density setting was depositing too much toner on the paper and when I ironed it down it melted and spread the toner and closed up the gaps between the traces. When I adjusted my printer settings to 1200 dots per inch and changed to density level to 50% it made a world of difference. I 'm very confident about this new board. There was a place in the upper LH corner where the toner didn't adhere to the board but this was easily fixed with a marker partially completed board Edited 1 time(s). Last edit at 01/08/2017 12:18PM by Shank man.  Re: Gen7 Board -ARM 2.0 DIY build January 08, 2017 12:29PM Registered: 11 years ago Posts: 7,616 Quote Shank man Like a dummkopf I also ordered the wrong USB-TTL adapter chip. I wasn't paying close enough attention when picking out the parts. I ordered a 579-MCP2200-I/SS (SS=super small package ??). I reordered part 579-MCP2200-I/SO. They are only$2.00 each but $8.00 to ship the damn things if I want to wait a week to get it. Such incidents are about the reason why one can order electronic components separately from the PCB on reprap-diy.com. Also take care of this 8-pin header supplying heaters. Apparently there are different ATX PSU versions out there. Some require this header to be soldered as shown, sometimes turned 180 deg. The only general rule I have is: 12V (yellow) wires have to be towards the board edge, GND (black) wires closer to MOSFETs. Other than that: well done!  Generation 7 Electronics Teacup Firmware RepRap DIY  Re: Gen7 Board -ARM 2.0 DIY build January 15, 2017 06:23PM Registered: 7 years ago Posts: 203 thank you Traumflug. I am grateful for the help I am becoming increasing enamored by this little board. One feature that stands out is the use of the ATX board connectors and using a ATX power supply as a power source. This is a clever approach, Not only does it eliminate any chance of making a wrong connection, the tight fitting receptacle connections will be less prone to long term failure as sometimes seen with screw terminal type connectors. Before soldering the MCP2200 on, I wanted to check the board once more for any opens or shorts. The assembly instructions have the USB chip being the first item to solder on but I was doubtful of my soldering abilities to get this done without any making shorts between the pins so I skipped this step and started in with the resistors. Doing this board check gave me a good excuse to put it off soldering on the USB chip a little bit longer. Using a 8 pin Pololu header, some motor connectors and a terminal strip I was able to make a breakout cable to check the 8 pin sockets. It made it a little easier to check these sockets for shorts, continuity to the motor headers, jumpers and connections to the MCU socket. Checking the board was a little tedious and took me a few hours but it did expose a bad solder joint on the MCU socket so it was overall a worthwhile effort. The breakout cable was also useful when it came time to do the voltage checks on the Pololu headers. I hooked the negative lead from voltage meter to a ground pin on one of the unused disc connectors coming from the power supply and used the red lead to probe the points on the terminal strip to check the voltage. After these checks I soldered on the MCP2200 and the Mofsets. I did have to file down the tip on my soldering iron to get to the MCP2200 leads but it turned out to be a relatively easy process. I held it in place with some kapton tape to keep it from moving and tacked down a corner lead with some solder. I didn't see any point with soldering down any of the unused leads so I left them alone. Once the soldering was finished, I scrubbed the back of the board with a toothbrush and some Isopropyl alcohol to get rid of any flux. All of the voltage checks came out fine. The LED's lit up like they were susposed to. I hooked up the ATX power supply and plugged in the USB cable to my PC and the board immediately showed up as a COM port in the device manager. Photos of completed controller Now this is where my progress comes to a halt. When it comes to uploading the firmware to the board i am totally flummoxed. I don't understand how Teacup, the GCC Arm compiler and the lpc21isp files tie together to get the firmware uploaded . When it comes to the Arduino IDE and Marlin i've never had a problem. There isn't support for the Gen7 ARM board in Marlin so this rules out using the Arduino IDE. My only choice left is to figure this out. I don't have any Linux PC's so I'm trying to do all this on a old Windows XP PC. I tried using a Raspberry PI3 to do this but it couldn't find the gcc-arm library or something to that effect. *********************************************************************** When i launch the the gcc-arm- program I'm greeted with a terminal window with a blinking cursor. I'm not sure what to do with this. I admit to not being a computer savy person. C:\Program Files\GNU Tools ARM Embedded\5.4 2016q3> ********************************************************************* When I launch the LPC21isp file, it flashes on the screen and promptly dissappears. *************************************************************************** When I try to build the file in Teacup I get this error code............... C:\Program Files\GNU Tools ARM Embedded\5.4 2016q3\bin -c -DF_CPU=12000000UL -mmcu=lpc1114 -Wall -Wstrict-prototypes -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Winline -fno-move-loop-invariants -fno-tree-scev-cprop -Os -ffunction-sections -finline-functions-called-once -mcall-prologues -Wa,-adhlns="C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\build\analog-arm.al" -save-temps=obj -o "C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\build\analog-arm.o" "C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\analog-arm.c" Exception occurred trying to run C:\Program Files\GNU Tools ARM Embedded\5.4 2016q3\bin -c -DF_CPU=12000000UL -mmcu=lpc1114 -Wall -Wstrict-prototypes -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Winline -fno-move-loop-invariants -fno-tree-scev-cprop -Os -ffunction-sections -finline-functions-called-once -mcall-prologues -Wa,-adhlns="C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\build\analog-arm.al" -save-temps=obj -o "C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\build\analog-arm.o" "C:\Documents and Settings\Marcus Welby\Desktop\Tea_cup\Teacup_Firmware-master\Teacup_Firmware-master\analog-arm.c" Build terminated abnormally. ********************************************************************************************************* I know I'm missing a step somewhere but I can't figure it out. I'm flying blind. My next course of action is to reformat my hard drive, install Ubuntu and give it another try using Linux instead of Windows. Edited 1 time(s). Last edit at 01/15/2017 07:08PM by Shank man.  Re: Gen7 Board -ARM 2.0 DIY build January 15, 2017 09:11PM Registered: 11 years ago Posts: 7,616 Quote Shank man Photos of completed controller Nice work! Quote Shank man When i launch the the gcc-arm- program I'm greeted with a terminal window with a blinking cursor. I'm not sure what to do with this. Gcc is a command line tool. Which means, you can't "launch" it like e.g. Word, Photoshop or Internet Explorer. You're expected to change directory into the folder with Teacup source files and type make -f Makefile-ARM there. Then to fix missing pieces as they appear. Installing a GNU Make executable, editing Makefile-ARM for the right serial port, such things. Running Make should in turn run a number of other commands and after that, there should be a file "teacup.hex". That's the compiled firmware. Quote Shank man My next course of action is to reformat my hard drive, install Ubuntu and give it another try using Linux instead of Windows. Given your partitioning setup on the hard drive allows to create additional partitions, Ubuntu will happily install alongside Windows in a dual-boot fashion. All done by the Ubuntu installer it's self, including shrinking existing partitions as necessary. In general, using some Linux distribution is much more fun when dealing with Open Source software. Developers use such OSs (or Macintoshes, which are also Unix-like), so you see what they see. The only use of Windows in the open source world is the ability to install kind of a Linux on top of it (by installing a plentitude of packages manually). Edited 1 time(s). Last edit at 01/15/2017 09:11PM by Traumflug.  Generation 7 Electronics Teacup Firmware RepRap DIY  Re: Gen7 Board -ARM 2.0 DIY build January 22, 2017 04:26PM Registered: 7 years ago Posts: 203 Thanks again Traumflug. This time for pointing me in the right direction. After flailing about and wasting 5+ hours trying to get the Windows programs to compile and upload the firmware, I was becoming a little frustrated and decided to give Ubuntu a try. I burned 3 versions of boot disks, ubuntu V8.04.0, V11.10 & V11.04. All old versions I know but all I have is a 13 year old Sony Vaio PC. My first try was with V8.04.0 and it turned out to only have Python 2.6.5 and it needed to be at least 2.7.X. Trying to upgrade it was futile. My second try with V11.10 it turned out to be a little too much for my PC to load. It locked up three times in a row so I loaded in V11.04. This one had Python 2.7.9 loaded as a default but no wxPython and every attempt to install that ended in failure. Teacup won't load without the wxPython installed. Its needed to bring up the Teacup configure screen GUI. And to top it all off I still couldn't get the GNU tools loaded in. Every sudo apt-get resulted in a no repository found or some other kind of error. I decided to give my RaspberryPI3 one more try. It only has the NOOBS operating system loaded on it. This is the same one that I had no success loading the GNU tools with earlier on. Every try resulted in more" no repositories found" until I landed on this site. [www.whence.com] I copied and pasted this little gem and it loaded right up.. sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded sudo apt-get update sudo apt-get install gcc-arm-none-eabi Once this was installed everything fell into place. I had loaded in Pronterface a few months ago so all of the needed Python files were already there. I installed the lpc21isp from [installion.co.uk] I ran the Teacup configure tool from the script, selected my board and saved the config.h file. The Makefile-Arm file was renamed and saved. I ran the make command from the terminal window and the file compiled with no errors. Uploading the now compiled firmware only took a few seconds. Pronterface connected to the controller immediately. This RaspberryPI is proving be an ideal candidate when it comes to running Teacup, GNU tools, and the printer host Pronterface. If only I could slice STL files with it. Now that the board is hooked up to the printer I find myself confronted with a couple more dilemmas. The end stops are always triggered. I'm using a lever style endstop and even if I disconnect it from the board and run a M119 they still show as being triggered. I tried uncommenting the pull up & pull down resistors but it didn't seem to make any difference. Also, when I plug in the jumper to upload the firmware my hot end activates. I have to remove the jumper and power down the board in order to shut it off. I'll have to take a closer look at the board. I might have a shorted trace somewhere Edited 1 time(s). Last edit at 01/22/2017 04:30PM by Shank man.  Re: Gen7 Board -ARM 2.0 DIY build January 23, 2017 03:44AM Registered: 6 years ago Posts: 5,232 Quote This RaspberryPI is proving be an ideal candidate when it comes to running Teacup, GNU tools, and the printer host Pronterface. If only I could slice STL files with it. I'm running Octopi on my RasPi3 and have a WiFi connection to my main PC. I can send .gcode files directly to the RasPi without being in the same room as my printer.  Re: Gen7 Board -ARM 2.0 DIY build January 23, 2017 05:51AM Registered: 7 years ago Posts: 203 I now have Octopi installation next on my to do list. looking at the circuit diagram, I have a better understanding on how the end stops work. Unlike a RAMPS1.4 board where each switch is assigned a pin on the MCU, the Gen7 board assigns one MCU pin for all three switches. The RAMPS board allows testing for the condition of each individual switch where as the Gen7 tests them as a whole. The Gen7 circuit have all the switches wired in series and if X & Y are closed and Z is open, running a M119 command will report that all of the switches are open. I could be wrong about this When I hooked up my switches to the RAMPS board I had them as normally closed and didn't think about it when I connected them to the Gen7. No matter what I did the M119 would report back as all being triggered of course.  Re: Gen7 Board -ARM 2.0 DIY build January 23, 2017 06:59AM Registered: 11 years ago Posts: 7,616 Quote Shank man The Gen7 circuit have all the switches wired in series and if X & Y are closed and Z is open, running a M119 command will report that all of the switches are open. I could be wrong about this That's correct, Gen7-ARM requires all endstops to be normally closed types. The somewhat misguiding M119 report doesn't matter, because if you do a homing movement, you know which axis is moving, so you can also easily figure which endstop caused the trigger. The only thing you can't do is to home several axes at the same time. If you still need more detailed control you can use pins on the SPI connector. Data bus pins there can be used as simple I/O pins, too.  Generation 7 Electronics Teacup Firmware RepRap DIY  Re: Gen7 Board -ARM 2.0 DIY build January 23, 2017 08:23PM Registered: 7 years ago Posts: 203 I need some help with the end stops. I hate to ask stupid questions but I'm stumped My limit switches are wired in a normally closed state. With the RAMPS/Marlin combo whenever I pressed the home button in Pronterface the homing sequence has always been X first , Y second & Z last. With the switches wired in series and if Y was already homed ( opening up the circuit ) how does the X know when it reaches its orgin or home point ? Doesn't a signal need to be sent to the MCU to tell it to stop? right now when I home any single axis the carriages move in the opposite direction very very slowly almost like stuttering. Ray  Re: Gen7 Board -ARM 2.0 DIY build January 23, 2017 10:54PM Admin Registered: 10 years ago Posts: 6,277 "With the switches wired in series and if Y was already homed ( opening up the circuit ) how does the X know" It doesn’t. You should not have any axis homed before you hit home. The homing procedure is It will home an axis then move it off home (so it still knows where it really is), and repeat for next axis  Re: Gen7 Board -ARM 2.0 DIY build January 24, 2017 06:31PM Registered: 7 years ago Posts: 203 Thanks Dust, that makes perfectly good sense. But I'm back begging for even more help. I think this is more of a firmware issue I'm using Pronterface to control the motors. When I hit +10 the motors move in positive direction 10mm & when is -10 pressed they move in the reverse direction 10mm But when I home the motors they move away from the end stops . I've attached my firmware if anybody wants to take a look and venture a guess any help is appreciated. Sincerely Ray /***************************************************************************\ * * * 1. CPU * * * \***************************************************************************/ /** \def CPU_TYPE CPU types a user should be able to choose from in configtool. All commented out. */ //#define CPU_TYPE lpc1114 /** \def CPU CPU actually present on the board. */ #define CPU lpc1114 /** \def F_CPU_OPT CPU clock frequencies a user should be able to choose from in configtool. All commented out. */ //#define F_CPU_OPT 12000000UL /** \def F_CPU Actual CPU clock rate. #ifndef required for Arduino compatibility. */ #ifndef F_CPU #define F_CPU 12000000UL #endif /** \def MOTHERBOARD This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware. */ #define MOTHERBOARD /***************************************************************************\ * * * 2. PINOUTS * * * \***************************************************************************/ //#define TX_ENABLE_PIN xxxx //#define RX_ENABLE_PIN xxxx #define X_STEP_PIN PIO1_5 #define X_DIR_PIN PIO1_4 #define X_MIN_PIN PIO1_8 //#define X_MAX_PIN PIO1_8 //#define X_ENABLE_PIN xxxx //#define X_INVERT_DIR //#define X_INVERT_MIN //#define X_INVERT_MAX //#define X_INVERT_ENABLE #define Y_STEP_PIN PIO1_3 #define Y_DIR_PIN PIO1_2 #define Y_MIN_PIN PIO1_8 //#define Y_MAX_PIN PIO1_8 //#define Y_ENABLE_PIN xxxx //#define Y_INVERT_DIR //#define Y_INVERT_MIN //#define Y_INVERT_MAX //#define Y_INVERT_ENABLE #define Z_STEP_PIN PIO0_1 #define Z_DIR_PIN PIO0_2 #define Z_MIN_PIN PIO1_8 //#define Z_MAX_PIN PIO1_8 //#define Z_ENABLE_PIN xxxx //#define Z_INVERT_DIR //#define Z_INVERT_MIN //#define Z_INVERT_MAX //#define Z_INVERT_ENABLE #define E_STEP_PIN PIO0_3 #define E_DIR_PIN PIO0_7 //#define E_ENABLE_PIN xxxx //#define E_INVERT_DIR //#define E_INVERT_ENABLE #define PS_ON_PIN PIO0_4 //#define PS_INVERT_ON //#define PS_MOSFET_PIN xxxx #define STEPPER_ENABLE_PIN PIO0_4 #define STEPPER_INVERT_ENABLE /** \def DEBUG_LED_PIN Enable flashing of a LED during motor stepping. Disabled by default. Uncommenting this makes the binary a few bytes larger and adds a few cycles to the step timing interrrupt in timer.c. Also used for precision profiling (profiling works even without actually having such a LED in hardware), see [reprap.org] */ //#define DEBUG_LED_PIN PIO1_9 /** \def SD_CARD_SELECT_PIN Chip Select pin of the SD card. SD cards work over SPI and have a Chip Select or Slave Select (SS) pin. Choose this pin according to where on the board your SD card adapter is connected. Disabling this pin also disables SD card support and makes the firmware binary about 4.5 kB smaller. Connecting a device to SPI actually uses 4 signal lines, the other three pins are choosen by Teacup automatically. */ //#define SD_CARD_SELECT_PIN xxxx /** \def MCP3008_SELECT_PIN Chip Select pin of the MCP3008 ADC. MCP3008/4 analog-digital converter works over SPI and has a Chip Select pin. Choose this pin according to where the MCP3008 is connected. Setting this pin is required only if at least one temperature sensor of type MCP3008 is configured. Else it's ignored. */ //#define MCP3008_SELECT_PIN xxxx /***************************************************************************\ * * * 3. TEMPERATURE SENSORS * * * \***************************************************************************/ #ifndef DEFINE_TEMP_SENSOR #define DEFINE_TEMP_SENSOR(...) #endif /** \def TEMP_MAX6675 TEMP_THERMISTOR TEMP_AD595 TEMP_PT100 TEMP_INTERCOM \def TEMP_MCP3008 Which temperature sensor types are you using? Leave all used ones uncommented, comment out all others to save binary size and enhance performance. */ //#define TEMP_MAX6675 #define TEMP_THERMISTOR //#define TEMP_AD595 //#define TEMP_PT100 //#define TEMP_INTERCOM //#define TEMP_MCP3008 /** \def TEMP_SENSOR_PIN Temperature sensor pins a user should be able to choose from in configtool. All commented out. */ //#define TEMP_SENSOR_PIN PIO1_0 //#define TEMP_SENSOR_PIN PIO1_1 /** \def DEFINE_TEMP_SENSOR Define your temperature sensors here. One line for each sensor, only limited by the number of available ATmega pins. Name must match the name of the corresponding heater. If a heater "extruder" exists, a temperature sensor of that name has to exist as well. Same for heater "bed". There can be one sensor without corresponding heater, name it "noheater". Types are same as TEMP_ list above - TT_MAX6675, TT_THERMISTOR, TT_AD595, TT_PT100, TT_INTERCOM, TT_MCP3008. See list in temp.c. The "additional" field is used for TT_THERMISTOR and TT_MCP3008 only. It defines the name of the table(s) in thermistortable.h to use. This name is arbitrary, often used names include THERMISTOR_EXTRUDER and THERMISTOR_BED. Also, several sensors can share the same table, which saves binary size. For a GEN3 set temp_type to TT_INTERCOM and temp_pin to AIO0. The pin won't be used in this case. */ //DEFINE_TEMP_SENSORS_START // name type pin additional DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, PIO1_1,THERMISTOR_EXTRUDER) DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, PIO1_0,THERMISTOR_BED) // Beta algorithm r0 beta r2 vadc // Steinhart-Hart rp t0 r0 t1 r1 t2 r2 //TEMP_TABLE EXTRUDER (100000, 4092, 1000, 5.0) //TEMP_TABLE BED (100000, 4092, 4700, 5.0) //DEFINE_TEMP_SENSORS_END /***************************************************************************\ * * * 4. HEATERS * * * \***************************************************************************/ #ifndef DEFINE_HEATER #define DEFINE_HEATER(...) #endif /** \def HEATER_PIN Heater pins a user should be able to choose from in configtool. All commented out. */ //#define HEATER_PIN PIO0_10 //#define HEATER_PIN PIO1_9 /** \def DEFINE_HEATER Define your heaters and devices here. To attach a heater to a temp sensor above, simply use exactly the same name - copy+paste is your friend. Some common names are 'extruder', 'bed', 'fan', 'motor', ... names with special meaning can be found in gcode_process.c. Currently, these are: HEATER_extruder (M104) HEATER_bed (M140) HEATER_fan (M106) Devices don't neccessarily have a temperature sensor, e.g. fans or milling spindles. Operate such devices by setting their power (M106), instead of setting their temperature (M104). Also note, the index of a heater (M106 P#) can differ from the index of its attached temperature sensor (M104 P#) in case sensor-less devices are defined or the order of the definitions differs. The first defined device has the index 0 (zero). Set 'invert' to 0 for normal heaters. Setting it to 1 inverts the pin signal for this pin, e.g. for a MOSFET with a driver. Set 'pwm' to ... frequency in Hertz (Hz) on ARM based controllers to set PWM frequency of this pin's output. Frequency isn't always accurate, Teacup will choose the closest possible one. FAST_PWM is ignored on such controllers. Valid range is 2 to 200'000 Hz. 1 on AVR based controllers for using Pulse Width Modulation (PWM) on a pin supporting it. PWM frequency can be influenced only somewhat and only globally with FAST_PWM. 0 for using a PWM-able pin in on/off mode. Using PWM usually gives smoother temperature control but can conflict with slow switches, like solid state relays. A too high frequency can overheat MOSFETs; a too low frequency can make your heater to emit audible noise; so choose wisely. Pins which don't allow PWM are always operated in on/off mode. */ //DEFINE_HEATERS_START // name pin invert pwm DEFINE_HEATER(extruder, PIO0_10, 0, 20000) DEFINE_HEATER(bed, PIO1_9, 1, 10) #define HEATER_EXTRUDER HEATER_extruder #define HEATER_BED HEATER_bed //DEFINE_HEATERS_END /***************************************************************************\ * * * 5. COMMUNICATION OPTIONS * * * \***************************************************************************/ /** \def BAUD Baud rate for the serial RS232 protocol connection to the host. Usually 115200, other common values are 19200, 38400 or 57600. Ignored when USB_SERIAL is defined. */ #define BAUD 115200 /** \def XONXOFF Xon/Xoff flow control. Redundant when using RepRap Host for sending G-code, but mandatory when sending G-code files with a plain terminal emulator, like GtkTerm (Linux), CoolTerm (Mac) or HyperTerminal (Windows). */ //#define XONXOFF /** \def USB_SERIAL Define this for using USB instead of the serial RS232 protocol. Works on USB-equipped ATmegas, like the ATmega32U4, only. */ //#define USB_SERIAL /***************************************************************************\ * * * 6. DISPLAY SUPPORT * * * \***************************************************************************/ /** \def DISPLAY_BUS_4BIT DISPLAY_BUS_8BIT DISPLAY_BUS_I2C DISPLAY_BUS_SPI The bus used to connect the display to the controller. This is a property of the display. With most displays there can be only one correct choice. Comment in the one in use, comment out all others. If there is no display, comment out all of them to remove display code for better performance. */ //#define DISPLAY_BUS_4BIT //#define DISPLAY_BUS_8BIT //#define DISPLAY_BUS_I2C //#define DISPLAY_BUS_SPI /** \def DISPLAY_RS_PIN DISPLAY_RW_PIN DISPLAY_E_PIN \def DISPLAY_D4_PIN DISPLAY_D5_PIN DISPLAY_D6_PIN DISPLAY_D7_PIN Pins necessary for the 4-bit parallel display bus. Taken into account with DISPLAY_BUS_4BIT defined, only. */ //#define DISPLAY_RS_PIN xxxx //#define DISPLAY_RW_PIN xxxx //#define DISPLAY_E_PIN xxxx //#define DISPLAY_D4_PIN xxxx //#define DISPLAY_D5_PIN xxxx //#define DISPLAY_D6_PIN xxxx //#define DISPLAY_D7_PIN xxxx /** \def DISPLAY_TYPE_SSD1306 DISPLAY_TYPE_HD44780 The type of display in use. There can be only one choice. Taken into account only if one of DISPLAY_BUS_xxx is defined. Comment in the display in use, comment out all others. If there is no display, comment out all of DISPLAY_BUS_xxx. */ //#define DISPLAY_TYPE_SSD1306 //#define DISPLAY_TYPE_HD44780 ************************************************************************************configuration h ************************* ********************************************************** /***************************************************************************\ * * * 6. MECHANICAL/HARDWARE * * * \***************************************************************************/ /** \def KINEMATICS_STRAIGHT KINEMATICS_COREXY This defines the type of kinematics your printer uses. That's essential! Valid values (see dda_kinematics.h): KINEMATICS_STRAIGHT Motors move axis directions directly. This is the traditional type, found in many printers, including Mendel, Prusa i3, Mendel90, Ormerod, Mantis. KINEMATICS_COREXY A bot using CoreXY kinematics. Typical for CoreXY are long and crossing toothed belts and a print head moving on the X-Y-plane. */ #define KINEMATICS_STRAIGHT //#define KINEMATICS_COREXY /** \def STEPS_PER_M_X STEPS_PER_M_Y STEPS_PER_M_Z STEPS_PER_M_E Steps per meter ( = steps per mm * 1000 ), calculate these values appropriate for your machine. All numbers are integers, so no decimal point, please :-) Valid range: 20 to 4'0960'000 (0.02 to 40960 steps/mm) */ #define STEPS_PER_M_X 80000 #define STEPS_PER_M_Y 80000 #define STEPS_PER_M_Z 2560000 #define STEPS_PER_M_E 690000 /** \def MAXIMUM_FEEDRATE_X MAXIMUM_FEEDRATE_Y MAXIMUM_FEEDRATE_Z MAXIMUM_FEEDRATE_E Used for G0 rapid moves and as a cap for all other feedrates. */ #define MAXIMUM_FEEDRATE_X 1000 #define MAXIMUM_FEEDRATE_Y 1000 #define MAXIMUM_FEEDRATE_Z 100 #define MAXIMUM_FEEDRATE_E 25 /** \def SEARCH_FEEDRATE_X SEARCH_FEEDRATE_Y SEARCH_FEEDRATE_Z Used when doing precision endstop search and as default feedrate. No SEARCH_FEEDRATE_E, as E can't be searched. */ #define SEARCH_FEEDRATE_X 300 #define SEARCH_FEEDRATE_Y 300 #define SEARCH_FEEDRATE_Z 100 /** \def ENDSTOP_CLEARANCE_X ENDSTOP_CLEARANCE_Y ENDSTOP_CLEARANCE_Z When hitting an endstop, Teacup properly decelerates instead of doing an aprupt stop to save your mechanics. Ineviteably, this means it overshoots the endstop trigger point by some distance. To deal with this, Teacup adapts homing movement speeds to what your endstops can deal with. The higher the allowed acceleration ( = deceleration, see #define ACCELERATION) and the more clearance the endstop comes with, the faster Teacup will do homing movements. Set here how many micrometers (mm * 1000) your endstop allows the carriage to overshoot the trigger point. Typically 1000 or 2000 for mechanical endstops, more for optical ones. You can set it to zero, in which case SEARCH_FEEDRATE_{XYZ} is used, but expect very slow homing movements. Units: micrometers Sane values: 0 to 20000 (0 to 20 mm) Valid range: 0 to 1000000 */ #define ENDSTOP_CLEARANCE_X 1000 #define ENDSTOP_CLEARANCE_Y 1000 #define ENDSTOP_CLEARANCE_Z 100 /** \def X_MIN X_MAX Y_MIN Y_MAX Z_MIN Z_MAX Soft axis limits. Define them to your machine's size relative to what your G-code considers to be the origin (typically the bed's center or the bed's front left corner). Note that relocating the origin at runtime with G92 will also relocate these limits. Not defining them at all will disable limits checking and make the binary about 250 bytes smaller. Enabling only some of them is perfectly fine. Units: millimeters Sane values: according to printer build room size Valid range: -1000.0 to 1000.0 */ //#define X_MIN 0.0 #define X_MAX 155.0 //#define Y_MIN 0.0 #define Y_MAX 175.0 //#define Z_MIN 0.0 #define Z_MAX 60.0 /** \def E_ABSOLUTE Some G-code creators produce relative length commands for the extruder, others absolute ones. G-code using absolute lengths can be recognized when there are G92 E0 commands from time to time. If you have G92 E0 in your G-code, define this flag. This is the startup default and can be changed with M82/M83 while running. */ #define E_ABSOLUTE /** \def ACCELERATION_REPRAP ACCELERATION_RAMPING ACCELERATION_TEMPORAL Choose optionally one of ACCELERATION_REPRAP, ACCELERATION_RAMPING or ACCELERATION_TEMPORAL. With none of them defined, movements are done without acceleration. Recommended is ACCELERATION_RAMPING. */ //#define ACCELERATION_REPRAP #define ACCELERATION_RAMPING //#define ACCELERATION_TEMPORAL /** \def ACCELERATION How fast to accelerate when using ACCELERATION_RAMPING. Start with 10 for milling (high precision) or 1000 for printing. Units: mm/s^2 Useful range: 1 to 10'000 */ #define ACCELERATION 1000 /** \def LOOKAHEAD Define this to enable look-ahead during *ramping* acceleration to smoothly transition between moves instead of performing a dead stop every move. Enabling look-ahead requires about 3600 bytes of flash memory. */ #define LOOKAHEAD /** \def MAX_JERK_X MAX_JERK_Y MAX_JERK_Z MAX_JERK_E When performing look-ahead, we need to decide what an acceptable jerk to the mechanics is. Look-ahead attempts to instantly change direction at movement crossings, which means instant changes in the speed of the axes participating in the movement. Define here how big the speed bumps on each of the axes is allowed to be. If you want a full stop before and after moving a specific axis, define MAX_JERK of this axis to 0. This is often wanted for the Z axis. If you want to ignore jerk on an axis, define it to twice the maximum feedrate of this axis. Having these values too low results in more than neccessary slowdown at movement crossings, but is otherwise harmless. Too high values can result in stepper motors suddenly stalling. If angles between movements in your G-code are small and your printer runs through entire curves full speed, there's no point in raising the values. Units: mm/min Sane values: 0 to 400 Valid range: 0 to 65535 */ #define MAX_JERK_X 200 #define MAX_JERK_Y 200 #define MAX_JERK_Z 0 #define MAX_JERK_E 200 /***************************************************************************\ * * * 7. MISCELLANEOUS OPTIONS * * * \***************************************************************************/ /** \def USE_INTERNAL_PULLUPS Most controller chips feature internal pullup resistors on their input pins, which get used for endstops by turning on this switch. Don't turn it on when using endstops which need no pull resistor, e.g. optical endstops, because pull resistors are counterproductive there. One can't use USE_INTERNAL_PULLUPS and USE_INTERNAL_PULLDOWNS at the same time, of course. */ //#define USE_INTERNAL_PULLUPS /** \def USE_INTERNAL_PULLDOWNS Some controller chips feature internal pulldown resistors on their input pins, which get used for endstops by turning on this switch. Don't turn it on when using endstops which need no pull resistor, e.g. optical endstops, because pull resistors are counterproductive there. One can't use USE_INTERNAL_PULLDOWNS and USE_INTERNAL_PULLUPS at the same time, of course. */ #define USE_INTERNAL_PULLDOWNS /** \def Z_AUTODISABLE Automatically disable Z axis when not in use. This is useful for printers with a self-locking Z axis, e.g. the various Mendel derivates. Other printers have a heavy Z axis or a not self-locking spindle. In that case you should not activate this. This option has no effect on controllers with a common stepper enable pin. */ #define Z_AUTODISABLE /** \def TEMP_HYSTERESIS Actual temperature must be target +/- this hysteresis before target temperature is considered to be achieved. Also, BANG_BANG tries to stay within half of this hysteresis. Unit: degree Celsius */ #define TEMP_HYSTERESIS 10 /** \def TEMP_RESIDENCY_TIME Actual temperature must be close to target (within set temperature +- TEMP_HYSTERESIS) for this long before target is achieved (and a M116 succeeds). Unit: seconds */ #define TEMP_RESIDENCY_TIME 60 /** \def TEMP_EWMA Smooth noisy temperature sensors. Good hardware shouldn't be noisy. Set to 1000 for unfiltered data (and a 140 bytes smaller binary). Instrument Engineer's Handbook, 4th ed, Vol 2 p126 says values of 50 to 100 are typical. Smaller is smoother but slower adjusting, larger is quicker but rougher. If you need to use this, set the PID parameter to zero (M132 S0) to make the PID loop insensitive to noise. Valid range: 1 to 1000 */ #define TEMP_EWMA 1000 /** \def REPORT_TARGET_TEMPS With this enabled, M105 commands will return the current temperatures along with the target temps, separated by a slash: ok T:xxx.x/xxx.x B:xxx.x/xxx.x With this disabled, only temps will be returned: ok T:xxx.x B:xxx.x Enabling adds 78 bytes to the image. */ #define REPORT_TARGET_TEMPS /** \def HEATER_SANITY_CHECK Check if heater responds to changes in target temperature, disable and spit errors if not largely untested, please comment in forum if this works, or doesn't work for you! */ //#define HEATER_SANITY_CHECK /** \def EECONFIG Enable EEPROM configuration storage. Enabled by default. Commenting this out makes the binary several hundred bytes smaller, so you might want to disable EEPROM storage on small MCUs, like the ATmega168. */ #define EECONFIG /** \def BANG_BANG Drops PID loop from heater control, reduces code size significantly (1300 bytes!). */ //#define BANG_BANG /** \def BANG_BANG_ON PWM value for Bang Bang 'on'. */ //#define BANG_BANG_ON 200 /** \def BANG_BANG_OFF PWM value for Bang Bang 'off'. */ //#define BANG_BANG_OFF 45 /** \def MOVEBUFFER_SIZE Move buffer size, in number of moves. Note that each move takes a fair chunk of ram (107 bytes as of this writing), so don't make the buffer too big. However, a larger movebuffer will probably help with lots of short consecutive moves, as each move takes a bunch of math (hence time) to set up so a longer buffer allows more of the math to be done during preceding longer moves. */ #define MOVEBUFFER_SIZE 8 /** \def DC_EXTRUDER DC_EXTRUDER_PWM If you have a DC motor extruder, configure it as a "heater" above and define this value as the index or name. You probably also want to comment out E_STEP_PIN and E_DIR_PIN in the Pinouts section above. */ //#define DC_EXTRUDER HEATER_motor //#define DC_EXTRUDER_PWM 180 /** \def USE_WATCHDOG Teacup implements a watchdog, which has to be reset every 250ms or it will reboot the controller. As rebooting (and letting the GCode sending application trying to continue the build with a then different Home point) is probably even worse than just hanging, and there is no better restore code in place, this is disabled for now. */ //#define USE_WATCHDOG /** \def TH_COUNT Temperature history count. This is how many temperature readings to keep in order to calculate derivative in PID loop higher values make PID derivative term more stable at the expense of reaction time. */ #define TH_COUNT 8 /** \def FAST_PWM Teacup offers two PWM frequencies, 76(61) Hz and 78000(62500) Hz on a 20(16) MHz electronics. The slower one is the default, as it's the safer choice and reduces MOSFET heating. Drawback is, in a quiet environment you might notice the heaters and your power supply humming. Uncomment this option if you want to get rid of this humming and can afford a hotter MOSFET or want faster PWM for other reasons. See also: [reprap.org] */ //#define FAST_PWM /** \def PID_SCALE This is the scaling of internally stored PID values. 1024L is a good value. */ #define PID_SCALE 1024L /** \def ENDSTOP_STEPS Number of steps to run into the endstops intentionally. As endstops trigger false alarm sometimes, Teacup debounces them by counting a number of consecutive positives. Use 4 or less for reliable endstops, 8 or even more for flaky ones. Valid range: 1...255. */ #define ENDSTOP_STEPS 8 /** \def CANNED_CYCLE G-code commands in this string will be executed over and over again, without user interaction or even a serial connection. It's purpose is e.g. for exhibitions or when using Teacup for other purposes than printing. You can add any G-code supported by Teacup. Note: don't miss these newlines (\n) and backslashes (\). */ /* #define CANNED_CYCLE "G1 X100 F3000\n" \ "G4 P500\n" \ "G1 X0\n" \ "G4 P500\n" */ Edited 1 time(s). Last edit at 01/24/2017 06:59PM by Shank man.  Re: Gen7 Board -ARM 2.0 DIY build January 24, 2017 08:21PM Admin Registered: 10 years ago Posts: 6,277 Need more information, details on your machine, in particular what axis move and where physically are the endstops? (On re reading thread I see you have Prusa2, its the same as a I3 movement wise) Eg a I3 type machine X min endstop is on left, X max endstop is on right, Y min is at back and Y max is at the front and Z min is at down position and z max is up top. I suspect you have some max endstops You have to configure the firmware with what endstops you have From another post "If you mean 'I want to use max endstops rather than min endstops' then undefine the minimum endstop pins and define maximum endstop pins, teacup will home to the max endstops if there are no min endstops." eg if your using X max endstop, find: #define X_MIN_PIN PIO1_8 //#define X_MAX_PIN PIO1_8 and change it to //#define X_MIN_PIN PIO1_8 #define X_MAX_PIN PIO1_8 NB if its your Y axis, You probably have movement wrong, since the bed moves and not the hot end, so its backwards from what you think. Y + moves should move the bed forward and Y - moves should move the bed back. Edited 1 time(s). Last edit at 01/24/2017 08:29PM by Dust.  Re: Gen7 Board -ARM 2.0 DIY build January 25, 2017 06:15PM Registered: 7 years ago Posts: 203 Dust many many thanks for the response It turns out the X_MIN_PIN was set correctly all I had to do was uncomment the # define X_INVERT_MIN lines and now the printer homes like its supposed to. I know its hard to diagnose a printer sight unseen but you got me looking in the right area and now the problem is no more. I'm one step closer to wrapping this up. #define X_STEP_PIN PIO1_5 #define X_DIR_PIN PIO1_4 #define X_MIN_PIN PIO1_8 //#define X_MAX_PIN PIO1_8 //#define X_ENABLE_PIN xxxx //#define X_INVERT_DIR #define X_INVERT_MIN //#define X_INVERT_MAX //#define X_INVERT_ENABLE #define Y_STEP_PIN PIO1_3 #define Y_DIR_PIN PIO1_2 #define Y_MIN_PIN PIO1_8 //#define Y_MAX_PIN PIO1_8 //#define Y_ENABLE_PIN xxxx //#define Y_INVERT_DIR #define Y_INVERT_MIN //#define Y_INVERT_MAX //#define Y_INVERT_ENABLE #define Z_STEP_PIN PIO0_1 #define Z_DIR_PIN PIO0_2 #define Z_MIN_PIN PIO1_8 //#define Z_MAX_PIN PIO1_8 //#define Z_ENABLE_PIN xxxx //#define Z_INVERT_DIR #define Z_INVERT_MIN //#define Z_INVERT_MAX //#define Z_INVERT_ENABLE best regards Ray  Re: Gen7 Board -ARM 2.0 DIY build January 28, 2017 05:49PM Registered: 7 years ago Posts: 203 The very first print from the new board came out pretty good. I still have to fine tune some firmware settings but that should be a simple matter. First Gen7 board print The total build cost ended up being a little over$ 125.00. This includes
a new 450 watt ATX power supply and 4 - DRV8825 stepper drivers from
Amazon. Not a bad price for a 32 bit printer controller. Also it is user serviceable in the event
a part should fail. How many other control boards could make that claim?

I've attached a finalized parts list if anyone is thinking about building one of these.
It should help to ease up the selection of parts through a local distributor.
I choose Mouser because they had every single part in stock to ship the same
day.

one final question..... Why are not more people building these boards?
I firmly believe that this board is grossly underrated.
This board and the Teacup firmware make for a formidable duo.

over and out

Ray

Edited 1 time(s). Last edit at 01/28/2017 06:27PM by Shank man.
 Re: Gen7 Board -ARM 2.0 DIY build January 28, 2017 07:43PM Admin Registered: 10 years ago Posts: 6,277
"Why are not more people building these boards?"

They are lazy and cheap.

Well not quite.. making pcbs is fraught with issues. Chemicals, getting and disposing of those is problematic for many.
This also takes lots of time.. you have to actually check the pcbs for shorts etc
Even drilling is quite time consuming, most don’t have the drill sizes needed.

Soldering.. many people have never soldered before! (shocking I know) so this puts people off. And then there is the SMD

Firmware, many have the mind set if it can't run marlin its no good..

Cost. You can get a mega and ramps for \$15!! assembled, and working.. (if your luckly)

Even now that there are a few 32 bit boards, most still build machines with ramps... resistance to change I guess

Edited 1 time(s). Last edit at 01/28/2017 07:47PM by Dust.
 Re: Gen7 Board -ARM 2.0 DIY build April 27, 2017 07:31AM Registered: 8 years ago Posts: 23
Hi,
I have a ATmega 1284 based Gen 7 AVR 1.5 which has been running on Marlin 1.0.2 firmware without issues for a few years. I tried to updated to Marlin 1.1.0 RC8. using Arduino IDE 1.8.1 All went fine with the update and everything seems to work except the X endstop is not recognised with a M119. See below

SENT: M119