Gen7 Board -ARM 2.0 DIY build

Re: Gen7 Board -ARM 2.0 DIY build

parto — Thu, 27 Apr 2017 07:31:43 -0400

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
READ: Reporting endstop status
READ: y_min: TRIGGERED
READ: z_min: open
READ: ok

I know the problem is firmware related because when I go back to ver 1.0.2 the x endstop is reported as expected. I have checked the pin file in both firmware versions and pin 0 is assigned to X endstop in both. Can anyone throw some light on what might be happening?

Re: Gen7 Board -ARM 2.0 DIY build

Dust — Sat, 28 Jan 2017 19:43:40 -0500

"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

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Sat, 28 Jan 2017 17:49:55 -0500

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

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Wed, 25 Jan 2017 18:15:06 -0500

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

Dust — Tue, 24 Jan 2017 20:21:38 -0500

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.

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Tue, 24 Jan 2017 18:31:36 -0500

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"
*/

Re: Gen7 Board -ARM 2.0 DIY build

Dust — Mon, 23 Jan 2017 22:54:57 -0500

"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

Shank man — Mon, 23 Jan 2017 20:23:12 -0500

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

Traumflug — Mon, 23 Jan 2017 06:59:07 -0500

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.

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Mon, 23 Jan 2017 05:51:34 -0500

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

o_lampe — Mon, 23 Jan 2017 03:44:12 -0500

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

Shank man — Sun, 22 Jan 2017 16:26:17 -0500

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

Re: Gen7 Board -ARM 2.0 DIY build

Traumflug — Sun, 15 Jan 2017 21:11:13 -0500

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).

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Sun, 15 Jan 2017 18:23:31 -0500

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.

[attachment 88975 cable_1.JPG]

[attachment 88976 cable_2.JPG]

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

[attachment 88977 completedTop.JPG]

[attachment 88978 compltedBot.JPG]

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.

Re: Gen7 Board -ARM 2.0 DIY build

Traumflug — Sun, 08 Jan 2017 12:29:09 -0500

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!

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Sun, 08 Jan 2017 12:05:40 -0500

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

[attachment 88535 number9a.JPG]

[attachment 88536 number9.JPG]

partially completed board

[attachment 88537 top.JPG]

[attachment 88539 soldered.JPG]

Re: Gen7 Board -ARM 2.0 DIY build

Shank man — Mon, 02 Jan 2017 10:31:52 -0500

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

[attachment 88182 number6.JPG]

Re: Gen7 Board -ARM 2.0 DIY build

Traumflug — Sun, 01 Jan 2017 05:57:16 -0500

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.

Gen7 Board -ARM 2.0 DIY build

Shank man — Sat, 31 Dec 2016 14:51:59 -0500

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.