Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 12:21PM |
Registered: 11 years ago Posts: 654 |
Quote
Pchiok
Muchachos me sumo a las felicitaciones por el emprendimiento, la placa, la wiki. Excelente!
Ahora una consulta a los experimentados. Estoy planificando y juntando las cosas para hacerme mi primera impresora. Consideran que podría arrancar con esta placa o para hacer la primera mejor la solución clásica Arduino 2560 + ramps? Por lo que llevo leído (que es bastante) no debería tener problemas con una Sinaptec como primer acercamiento. Que dicen?
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 12:43PM |
Registered: 9 years ago Posts: 20 |
Quote
SinapTec
Quote
Pchiok
Muchachos me sumo a las felicitaciones por el emprendimiento, la placa, la wiki. Excelente!
Ahora una consulta a los experimentados. Estoy planificando y juntando las cosas para hacerme mi primera impresora. Consideran que podría arrancar con esta placa o para hacer la primera mejor la solución clásica Arduino 2560 + ramps? Por lo que llevo leído (que es bastante) no debería tener problemas con una Sinaptec como primer acercamiento. Que dicen?
Gracias por las felicitaciones, lo de la wiki es todo gracias a Tatubias que se sumó y le está poniendo muchas ganas y trabajo.
Te comentó que mi placa todavía no está muy probada, pero si querés animarte a probarla bienvenido.
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 01:47PM |
Registered: 11 years ago Posts: 654 |
Quote
tatubias
Actualizaciones:
1 - Le agregue links externos a la pagian del wiki con este thread y tambien el thread the firmware (obio con las traduccion en ingles y castellano)
2 - Pude generar un pull request para que ageguen la placa al firmware oficial por el momento se puede descargar desde aca. [github.com]
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 02:17PM |
Registered: 10 years ago Posts: 792 |
Quote
SinapTec
Quote
tatubias
Actualizaciones:
1 - Le agregue links externos a la pagian del wiki con este thread y tambien el thread the firmware (obio con las traduccion en ingles y castellano)
2 - Pude generar un pull request para que ageguen la placa al firmware oficial por el momento se puede descargar desde aca. [github.com]
Muy groso Tatubias.
Veo que la cambiaste a KINEMATICS_STRAIGHT.
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 05:16PM |
Registered: 10 years ago Posts: 792 |
Thank you very much for the contribution. The issue with it is, these config.h templates are deprecated and removed from the experimental branch already, so it's no longer possible to commit them. Please check out this experimental branch. You'll find Configtool there, which can be started with ./configtool.py. You can also find a config/ folder which contains the new board descriptions. They're pretty much a subset (without printer specific stuff) of the old ones, so it shouldn't be too difficult to adapt. I'll happily commit such a modern board description. We're currently working on the last few knowns bugs of Configtool, this will be moved to master in a week or two.
Muchas gracias por el aporte. El problema con él es, estas plantillas config.h están en desuso y se retira de la rama experimental ya, por lo que ya no es posible para cometerlos. Por favor revise esta rama experimental. Encontrarás ConfigTool allí, que se puede iniciar con ./configtool.py. También puede encontrar una config / carpeta que contiene las nuevas descripciones de mesa. Son más o menos un subconjunto (sin material específico de la impresora) de los antiguos, por lo que no debe ser demasiado difícil adaptarse. Voy felizmente comprometo una descripción bordo tales moderna. Actualmente estamos trabajando en los últimos datos conocidos errores de ConfigTool, esta se moverá a dominar en una semana o dos.
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 06:55PM |
Registered: 9 years ago Posts: 20 |
Quote
tatubias
Me contesto lo siguiente la gente que desarrolla el firmware.
Thank you very much for the contribution. The issue with it is, these config.h templates are deprecated and removed from the experimental branch already, so it's no longer possible to commit them. Please check out this experimental branch. You'll find Configtool there, which can be started with ./configtool.py. You can also find a config/ folder which contains the new board descriptions. They're pretty much a subset (without printer specific stuff) of the old ones, so it shouldn't be too difficult to adapt. I'll happily commit such a modern board description. We're currently working on the last few knowns bugs of Configtool, this will be moved to master in a week or two.
traduccion al español por google.
Muchas gracias por el aporte. El problema con él es, estas plantillas config.h están en desuso y se retira de la rama experimental ya, por lo que ya no es posible para cometerlos. Por favor revise esta rama experimental. Encontrarás ConfigTool allí, que se puede iniciar con ./configtool.py. También puede encontrar una config / carpeta que contiene las nuevas descripciones de mesa. Son más o menos un subconjunto (sin material específico de la impresora) de los antiguos, por lo que no debe ser demasiado difícil adaptarse. Voy felizmente comprometo una descripción bordo tales moderna. Actualmente estamos trabajando en los últimos datos conocidos errores de ConfigTool, esta se moverá a dominar en una semana o dos.
Vamos a tener que investigar como agregar la al nuevo firmware (experimental). ya que es lo que va a salir ahora y ya no es mas como era antes.
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 06:59PM |
Registered: 10 years ago Posts: 792 |
Quote
Pchiok
Quote
tatubias
Me contesto lo siguiente la gente que desarrolla el firmware.
Thank you very much for the contribution. The issue with it is, these config.h templates are deprecated and removed from the experimental branch already, so it's no longer possible to commit them. Please check out this experimental branch. You'll find Configtool there, which can be started with ./configtool.py. You can also find a config/ folder which contains the new board descriptions. They're pretty much a subset (without printer specific stuff) of the old ones, so it shouldn't be too difficult to adapt. I'll happily commit such a modern board description. We're currently working on the last few knowns bugs of Configtool, this will be moved to master in a week or two.
traduccion al español por google.
Muchas gracias por el aporte. El problema con él es, estas plantillas config.h están en desuso y se retira de la rama experimental ya, por lo que ya no es posible para cometerlos. Por favor revise esta rama experimental. Encontrarás ConfigTool allí, que se puede iniciar con ./configtool.py. También puede encontrar una config / carpeta que contiene las nuevas descripciones de mesa. Son más o menos un subconjunto (sin material específico de la impresora) de los antiguos, por lo que no debe ser demasiado difícil adaptarse. Voy felizmente comprometo una descripción bordo tales moderna. Actualmente estamos trabajando en los últimos datos conocidos errores de ConfigTool, esta se moverá a dominar en una semana o dos.
Vamos a tener que investigar como agregar la al nuevo firmware (experimental). ya que es lo que va a salir ahora y ya no es mas como era antes.
Y/o dejar la placa funcional con el firmware que está andando ahora. Por las dudas guardar una copia, no?
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 08:06PM |
Registered: 11 years ago Posts: 654 |
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 09:49PM |
Registered: 11 years ago Posts: 67 |
Re: Desarrollo de electrónica MUY ECONOMICA May 19, 2015 10:23PM |
Registered: 9 years ago Posts: 69 |
Re: Desarrollo de electrónica MUY ECONOMICA May 20, 2015 09:09PM |
Registered: 11 years ago Posts: 246 |
Re: Desarrollo de electrónica MUY ECONOMICA May 21, 2015 12:19PM |
Registered: 11 years ago Posts: 31 |
Re: Desarrollo de electrónica MUY ECONOMICA May 21, 2015 12:40PM |
Registered: 11 years ago Posts: 654 |
Quote
elaerico
Muy buena iniciativa Sinaptec y Tatubias. Espero ansioso ver la placa con patrones VORONOI jejej
Re: Desarrollo de electrónica MUY ECONOMICA May 21, 2015 11:19PM |
Registered: 9 years ago Posts: 1 |
Re: Desarrollo de electrónica MUY ECONOMICA May 22, 2015 06:30AM |
Registered: 9 years ago Posts: 20 |
Quote
alfoon
Saludos, estoy desarollando mi impresora 3d totalmente casera con unidades de cd y me gustaria utilizar arduino nano pero el mio es nano 168
quien me puede ayudar?
mañana subo las fotos de lo que llevo
Re: Desarrollo de electrónica MUY ECONOMICA May 25, 2015 06:32PM |
Registered: 10 years ago Posts: 792 |
Re: Desarrollo de electrónica MUY ECONOMICA May 26, 2015 08:14AM |
Registered: 10 years ago Posts: 792 |
Re: Desarrollo de electrónica MUY ECONOMICA May 26, 2015 09:52PM |
Registered: 11 years ago Posts: 654 |
Re: Desarrollo de electrónica MUY ECONOMICA May 26, 2015 11:32PM |
Registered: 10 years ago Posts: 792 |
Re: Desarrollo de electrónica MUY ECONOMICA May 27, 2015 09:16AM |
Registered: 11 years ago Posts: 654 |
Re: Desarrollo de electrónica MUY ECONOMICA May 28, 2015 02:01PM |
Registered: 10 years ago Posts: 792 |
/***************************************************************************\ * * * 1. CPU * * * \***************************************************************************/ /** \def CPU_TYPE CPU types a user should be able to choose from in configtool. All commented out. */ //#define CPU_TYPE ATmega328 /** \def CPU CPU actually present on the board. */ #define CPU atmega328 /** \def F_CPU_OPT CPU clock frequencies a user should be able to choose from in configtool. All commented out. */ //#define F_CPU_OPT 16000000UL /** \def F_CPU Actual CPU clock rate. #ifndef required for Arduino compatibility. */ #ifndef F_CPU #define F_CPU 16000000UL #endif /** \def MOTHERBOARD This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware. */ #define MOTHERBOARD /***************************************************************************\ * * * 2. PINOUTS * * * \***************************************************************************/ #include "../arduino.h" #define X_STEP_PIN DIO12 #define X_DIR_PIN DIO11 #define X_MIN_PIN AIO0 //#define X_MAX_PIN xxxx #define X_ENABLE_PIN DIO10 #define X_INVERT_DIR #define X_INVERT_MIN //#define X_INVERT_MAX xxxx #define X_INVERT_ENABLE #define Y_STEP_PIN DIO9 #define Y_DIR_PIN DIO8 #define Y_MIN_PIN AIO1 //#define Y_MAX_PIN xxxx #define Y_ENABLE_PIN DIO10 #define Y_INVERT_DIR #define Y_INVERT_MIN //#define Y_INVERT_MAX xxxx #define Y_INVERT_ENABLE #define Z_STEP_PIN DIO4 #define Z_DIR_PIN DIO2 #define Z_MIN_PIN AIO2 //#define Z_MAX_PIN xxxx #define Z_ENABLE_PIN DIO7 #define Z_INVERT_DIR #define Z_INVERT_MIN //#define Z_INVERT_MAX xxxx #define Z_INVERT_ENABLE #define E_STEP_PIN AIO4 #define E_DIR_PIN AIO5 #define E_ENABLE_PIN AIO3 //#define E_INVERT_DIR xxxx #define E_INVERT_ENABLE //#define PS_ON_PIN DIO9 //#define PS_MOSFET_PIN xxxx //#define STEPPER_ENABLE_PIN DIO8 //#define STEPPER_INVERT_ENABLE xxxx /** \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 DIO13 /***************************************************************************\ * * * 3. TEMPERATURE SENSORS * * * \***************************************************************************/ #ifndef DEFINE_TEMP_SENSOR #define DEFINE_TEMP_SENSOR(...) #endif /** \def TEMP_MAX6675 TEMP_THERMISTOR TEMP_AD595 TEMP_PT100 TEMP_INTERCOM 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 /** \def TEMP_SENSOR_PIN Temperature sensor pins a user should be able to choose from in configtool. All commented out. */ //#define TEMP_SENSOR_PIN AIO0 //#define TEMP_SENSOR_PIN AIO1 /** \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. See list in temp.c. The "additional" field is used for TT_THERMISTOR 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, AIO7, THERMISTOR_EXTRUDER) DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO6, THERMISTOR_BED) // r0 beta r2 vadc //TEMP_TABLE EXTRUDER (100000, 4092, 4700, 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 DIO8 //#define HEATER_PIN DIO9 //#define HEATER_PIN DIO10 /** \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 'pwm' to ... 1 for using PWM on a PWM-able pin and on/off on other pins. 0 for using on/off on a PWM-able pin, too. Using PWM usually gives smoother temperature control but can conflict with slow switches, like solid state relays. PWM frequency can be influenced globally with FAST_PWM, see below. */ //DEFINE_HEATERS_START // name port pwm DEFINE_HEATER(extruder, PD3, 1) DEFINE_HEATER(bed, PD6, 1) DEFINE_HEATER(fan, PD5, 1) #define HEATER_EXTRUDER HEATER_extruder #define HEATER_BED HEATER_bed #define HEATER_FAN HEATER_fan //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
Re: Desarrollo de electrónica MUY ECONOMICA May 28, 2015 02:40PM |
Registered: 10 years ago Posts: 792 |
* 3. TEMPERATURE SENSORS Old CFG //#define TEMP_SENSOR_PIN AIO0 //#define TEMP_SENSOR_PIN AIO1 New CFG //#define TEMP_SENSOR_PIN AIO7 //#define TEMP_SENSOR_PIN AIO6 * 4. HEATERS Old CFG //#define HEATER_PIN DIO8 //#define HEATER_PIN DIO9 //#define HEATER_PIN DIO10 New CFG //#define HEATER_PIN PD3 //#define HEATER_PIN PD6 //#define HEATER_PIN PD5
/***************************************************************************\ * * * 1. CPU * * * \***************************************************************************/ /** \def CPU_TYPE CPU types a user should be able to choose from in configtool. All commented out. */ //#define CPU_TYPE atmega328 /** \def CPU CPU actually present on the board. */ #define CPU atmega328 /** \def F_CPU_OPT CPU clock frequencies a user should be able to choose from in configtool. All commented out. */ //#define F_CPU_OPT 16000000UL /** \def F_CPU Actual CPU clock rate. #ifndef required for Arduino compatibility. */ #ifndef F_CPU #define F_CPU 16000000UL #endif /** \def MOTHERBOARD This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware. */ #define MOTHERBOARD /***************************************************************************\ * * * 2. PINOUTS * * * \***************************************************************************/ #include "../arduino.h" #define X_STEP_PIN DIO12 #define X_DIR_PIN DIO11 #define X_MIN_PIN AIO0 //#define X_MAX_PIN xxxx #define X_ENABLE_PIN DIO10 #define X_INVERT_DIR #define X_INVERT_MIN //#define X_INVERT_MAX xxxx #define X_INVERT_ENABLE #define Y_STEP_PIN DIO9 #define Y_DIR_PIN DIO8 #define Y_MIN_PIN AIO1 //#define Y_MAX_PIN xxxx #define Y_ENABLE_PIN DIO10 #define Y_INVERT_DIR #define Y_INVERT_MIN //#define Y_INVERT_MAX xxxx #define Y_INVERT_ENABLE #define Z_STEP_PIN DIO4 #define Z_DIR_PIN DIO2 #define Z_MIN_PIN AIO2 //#define Z_MAX_PIN xxxx #define Z_ENABLE_PIN DIO7 #define Z_INVERT_DIR #define Z_INVERT_MIN //#define Z_INVERT_MAX xxxx #define Z_INVERT_ENABLE #define E_STEP_PIN AIO4 #define E_DIR_PIN AIO5 #define E_ENABLE_PIN AIO3 //#define E_INVERT_DIR xxxx #define E_INVERT_ENABLE //#define PS_ON_PIN DIO9 //#define PS_MOSFET_PIN xxxx //#define STEPPER_ENABLE_PIN DIO8 //#define STEPPER_INVERT_ENABLE xxxx /** \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 DIO13 /***************************************************************************\ * * * 3. TEMPERATURE SENSORS * * * \***************************************************************************/ #ifndef DEFINE_TEMP_SENSOR #define DEFINE_TEMP_SENSOR(...) #endif /** \def TEMP_MAX6675 TEMP_THERMISTOR TEMP_AD595 TEMP_PT100 TEMP_INTERCOM 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 /** \def TEMP_SENSOR_PIN Temperature sensor pins a user should be able to choose from in configtool. All commented out. */ //#define TEMP_SENSOR_PIN AIO7 //#define TEMP_SENSOR_PIN AIO6 /** \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. See list in temp.c. The "additional" field is used for TT_THERMISTOR 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, AIO7, THERMISTOR_EXTRUDER) DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO6, THERMISTOR_BED) // r0 beta r2 vadc //TEMP_TABLE EXTRUDER (100000, 4092, 4700, 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 PD3 //#define HEATER_PIN PD6 //#define HEATER_PIN PD5 /** \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 'pwm' to ... 1 for using PWM on a PWM-able pin and on/off on other pins. 0 for using on/off on a PWM-able pin, too. Using PWM usually gives smoother temperature control but can conflict with slow switches, like solid state relays. PWM frequency can be influenced globally with FAST_PWM, see below. */ //DEFINE_HEATERS_START // name port pwm DEFINE_HEATER(extruder, PD3, 1) DEFINE_HEATER(bed, PD6, 1) DEFINE_HEATER(fan, PD5, 1) #define HEATER_EXTRUDER HEATER_extruder #define HEATER_BED HEATER_bed #define HEATER_FAN HEATER_fan //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
Re: Desarrollo de electrónica MUY ECONOMICA May 28, 2015 05:40PM |
Registered: 10 years ago Posts: 792 |
/***************************************************************************\ * * * 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 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 167600 #define STEPS_PER_M_Y 167600 #define STEPS_PER_M_Z 4571428 #define STEPS_PER_M_E 678400 /** \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 7200 #define MAXIMUM_FEEDRATE_Y 7200 #define MAXIMUM_FEEDRATE_Z 200 #define MAXIMUM_FEEDRATE_E 960 /** \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 1200 #define SEARCH_FEEDRATE_Y 1200 #define SEARCH_FEEDRATE_Z 72 /** \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, in mm. Define them to your machine's size relative to what your host considers to be the origin. */ #define X_MIN 0 #define X_MAX 110 #define Y_MIN 0 #define Y_MAX 110 #define Z_MIN 0 #define Z_MAX 85 /** \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 120 #define MAX_JERK_Y 120 #define MAX_JERK_Z 24 #define MAX_JERK_E 120 /***************************************************************************\ * * * 7. MISCELLANEOUS OPTIONS * * * \***************************************************************************/ /** \def USE_INTERNAL_PULLUPS The ATmega has internal pullup resistors on it's input pins which are counterproductive with the commonly used eletronic endstops, so they should be switched off. For other endstops, like mechanical ones, you may want to uncomment this. */ #define USE_INTERNAL_PULLUPS /** \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 2 /** \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 10 /** \def TEMP_EWMA Smooth noisy temperature sensors. Good hardware shouldn't be noisy. Set to 1.0 for unfiltered data (and a 140 bytes smaller binary). Instrument Engineer's Handbook, 4th ed, Vol 2 p126 says values of 0.05 to 0.1 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: 0.001 to 1.0 */ #define TEMP_EWMA 1.0 /** \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 255 /** \def BANG_BANG_OFF PWM value for Bang Bang 'off'. */ //#define BANG_BANG_OFF 0 /** \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 4 /** \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" */
/***************************************************************************\ * * * 1. CPU * * * \***************************************************************************/ /** \def CPU_TYPE CPU types a user should be able to choose from in configtool. All commented out. */ //#define CPU_TYPE atmega328 /** \def CPU CPU actually present on the board. */ #define CPU atmega328 /** \def F_CPU_OPT CPU clock frequencies a user should be able to choose from in configtool. All commented out. */ //#define F_CPU_OPT 16000000UL /** \def F_CPU Actual CPU clock rate. #ifndef required for Arduino compatibility. */ #ifndef F_CPU #define F_CPU 16000000UL #endif /** \def MOTHERBOARD This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware. */ #define MOTHERBOARD /***************************************************************************\ * * * 2. PINOUTS * * * \***************************************************************************/ #include "../arduino.h" #define X_STEP_PIN DIO12 #define X_DIR_PIN DIO11 #define X_MIN_PIN AIO0 //#define X_MAX_PIN xxxx #define X_ENABLE_PIN DIO10 #define X_INVERT_DIR #define X_INVERT_MIN #define X_INVERT_MAX False #define X_INVERT_ENABLE #define Y_STEP_PIN DIO9 #define Y_DIR_PIN DIO8 #define Y_MIN_PIN AIO1 //#define Y_MAX_PIN xxxx #define Y_ENABLE_PIN DIO10 #define Y_INVERT_DIR #define Y_INVERT_MIN #define Y_INVERT_MAX False #define Y_INVERT_ENABLE #define Z_STEP_PIN DIO4 #define Z_DIR_PIN DIO2 #define Z_MIN_PIN AIO2 //#define Z_MAX_PIN xxxx #define Z_ENABLE_PIN DIO7 #define Z_INVERT_DIR #define Z_INVERT_MIN #define Z_INVERT_MAX False #define Z_INVERT_ENABLE #define E_STEP_PIN AIO4 #define E_DIR_PIN AIO5 #define E_ENABLE_PIN AIO3 #define E_INVERT_DIR False #define E_INVERT_ENABLE //#define PS_ON_PIN DIO9 //#define PS_MOSFET_PIN xxxx //#define STEPPER_ENABLE_PIN DIO8 #define STEPPER_INVERT_ENABLE False /** \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 DIO13 /***************************************************************************\ * * * 3. TEMPERATURE SENSORS * * * \***************************************************************************/ #ifndef DEFINE_TEMP_SENSOR #define DEFINE_TEMP_SENSOR(...) #endif /** \def TEMP_MAX6675 TEMP_THERMISTOR TEMP_AD595 TEMP_PT100 TEMP_INTERCOM 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 /** \def TEMP_SENSOR_PIN Temperature sensor pins a user should be able to choose from in configtool. All commented out. */ //#define TEMP_SENSOR_PIN AIO7 //#define TEMP_SENSOR_PIN AIO6 /** \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. See list in temp.c. The "additional" field is used for TT_THERMISTOR 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, AIO7, THERMISTOR_EXTRUDER) DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO6, THERMISTOR_BED) // r0 beta r2 vadc //TEMP_TABLE EXTRUDER (100000, 4092, 4700, 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 PD3 //#define HEATER_PIN PD6 //#define HEATER_PIN PD5 /** \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 'pwm' to ... 1 for using PWM on a PWM-able pin and on/off on other pins. 0 for using on/off on a PWM-able pin, too. Using PWM usually gives smoother temperature control but can conflict with slow switches, like solid state relays. PWM frequency can be influenced globally with FAST_PWM, see below. */ //DEFINE_HEATERS_START // name port pwm DEFINE_HEATER(extruder, PD3, 1) DEFINE_HEATER(bed, PD6, 1) DEFINE_HEATER(fan, PD5, 1) #define HEATER_EXTRUDER HEATER_extruder #define HEATER_BED HEATER_bed #define HEATER_FAN HEATER_fan //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 /** \def USB_SERIAL Add help text here. */ #define USB_SERIAL
Re: Desarrollo de electrónica MUY ECONOMICA May 28, 2015 08:11PM |
Registered: 11 years ago Posts: 654 |
Re: Desarrollo de electrónica MUY ECONOMICA May 29, 2015 04:56PM |
Registered: 10 years ago Posts: 792 |
Re: Desarrollo de electrónica MUY ECONOMICA May 29, 2015 08:28PM |
Registered: 11 years ago Posts: 654 |
Quote
tatubias
Entre toda mi locura anoche me quede hasta tarde y me puse s ver dio nos pines para dejar libre el i2c y si quedan libres el tx y rx que son d0 y d1.
Lo que si por el momento para el i2c no esta implementados en teacup
Re: Desarrollo de electrónica MUY ECONOMICA May 30, 2015 09:38AM |
Registered: 11 years ago Posts: 654 |
Re: Desarrollo de electrónica MUY ECONOMICA May 30, 2015 11:06AM |
Registered: 9 years ago Posts: 21 |
Re: Desarrollo de electrónica MUY ECONOMICA May 30, 2015 05:21PM |
Registered: 10 years ago Posts: 792 |
Quote
Muscles
Desde la absoluta ignorancia, que diferencia pratica presenta utilizar el nuevo firmware de TeaCup?
Re: Desarrollo de electrónica MUY ECONOMICA May 31, 2015 09:21AM |
Registered: 11 years ago Posts: 654 |