Project: Teacup Firmware
Posted by Triffid_Hunter
|
Re: Project: Teacup Firmware June 09, 2015 03:28PM |
I noticed an interesting behavior and was wondering if it was something peculiar in my setup. When homing via G28, I notice that the extruder is turning ever so slowly. It's not a big deal - it's just a bit more filament ooze that I need to clean up at the start of the print. I just thought it odd enough to bring up here. Maybe I'm just the only one who noticed 
|
Re: Project: Teacup Firmware June 19, 2015 01:10PM |
Here's where I've gotten so far in the configtool.
board.CNC_Shield_V3_UNO.h is attached at the bottom.
I'm using
AIO2 (UNO) / Resume (CNC Shield) for the Hotend Seven Switch Connection,
and
AIO3 (UNO) / Coolant En (CNC Shield) for the thermistor
I had to manually set the CPU by editing the board file. It would be nice is all the CPU's were listed. Does the CPU part look right?
board.CNC_Shield_V3_UNO.h is attached at the bottom.
I'm using
AIO2 (UNO) / Resume (CNC Shield) for the Hotend Seven Switch Connection,
and
AIO3 (UNO) / Coolant En (CNC Shield) for the thermistor
I had to manually set the CPU by editing the board file. It would be nice is all the CPU's were listed. Does the CPU part look right?
/***************************************************************************\ * * * 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 * * * \***************************************************************************/ #define X_STEP_PIN DIO2 #define X_DIR_PIN DIO5 #define X_MIN_PIN DIO9 //#define X_MAX_PIN DIO21 #define X_ENABLE_PIN DIO8 //#define X_INVERT_DIR #define X_INVERT_MIN #define X_INVERT_MAX #define X_INVERT_ENABLE #define Y_STEP_PIN DIO3 #define Y_DIR_PIN DIO6 #define Y_MIN_PIN DIO10 //#define Y_MAX_PIN DIO26 #define Y_ENABLE_PIN DIO8 //#define Y_INVERT_DIR #define Y_INVERT_MIN #define Y_INVERT_MAX #define Y_INVERT_ENABLE #define Z_STEP_PIN DIO4 #define Z_DIR_PIN DIO7 #define Z_MIN_PIN DIO11 //#define Z_MAX_PIN DIO31 #define Z_ENABLE_PIN DIO8 //#define Z_INVERT_DIR #define Z_INVERT_MIN #define Z_INVERT_MAX #define Z_INVERT_ENABLE #define E_STEP_PIN DIO12 #define E_DIR_PIN DIO13 #define E_ENABLE_PIN DIO8 //#define E_INVERT_DIR //#define E_INVERT_ENABLE //#define PS_ON_PIN DIO14 //#define PS_MOSFET_PIN xxxx //#define STEPPER_ENABLE_PIN DIO25 //#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 DIO21 /***************************************************************************\ * * * 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 AIO3 /** \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(Hotend, TT_THERMISTOR, AIO3, THERMISTOR_HOTEND) // Beta algorithm r0 beta r2 vadc // Steinhart-Hart rp t0 r0 t1 r1 t2 r2 //TEMP_TABLE HOTEND (100000, 4066, 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. */ /** \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(Hotend, AIO2, 1) #define HEATER_HOTEND HEATER_Hotend //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: Project: Teacup Firmware June 19, 2015 01:52PM |
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?
I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.
For the record, I'm not an [censored], actually I'm quite a nice guy
And a developer, so if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it Because then it will be perfect (for my selfish needs) .
|
Re: Project: Teacup Firmware June 19, 2015 03:25PM |
Quote
thetazzbot
I'm quite a nice guy
That's an excellent combination :-)
Quote
thetazzbot
if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it
Doing a fork will just increase the likelyness this stuff gets lost sooner or later. I'll happily give you write access to the main repo, just drop me a line in this issue: [github.com] You can create as many branches as you see use for, as long as the others are kept intact. Having branches (known as "topic branches" in Git documentation) is a very powerful method to keep track of developments on other branches, you simply rebase on them from time to time. As commits are
Edited 1 time(s). Last edit at 06/19/2015 03:49PM by Traumflug.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware July 10, 2015 07:05AM |
Quote
thetazzbot
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?
I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.
For the record, I'm not an [censored], actually I'm quite a nice guy
have you done anything with this? i'm curious as i'm also looking at the possibility of lcd support now that the sdcard stuff is working
-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-
|
Re: Project: Teacup Firmware July 14, 2015 05:24PM |
Quote
Traumflug
Quote
thejollygrimreaper
Quote
thetazzbot
Quote
Traumflug
Quote
thetazzbot
How about the ultralcd support?
I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.
For the record, I'm not an [censored], actually I'm quite a nice guy
have you done anything with this? i'm curious as i'm also looking at the possibility of lcd support now that the sdcard stuff is working
Maybe he did, but certainly nothing publicly visible. That much to "I'm a nice guy" and "I'm not an [censored]".
Would you guys consider trying out bounties? It seems like bounties could make this a win-win situation for everyone. People yelling wishlists could put up a little cash if they were really serious, and the developer(s) could get incentives for things they are not immediately interested in working on. In addition, developer(s) might be able to drum up a little funding to work on things they are immediately interested in.
(Tangent: I am trying to revitalize interest in the bounty system so I am going around finding places where it might be useful.)
Sorry, only registered users may post in this forum.