Project: Teacup Firmware
Posted by Triffid_Hunter
|
Re: Project: Teacup Firmware February 22, 2016 02:25AM |
Registered: 12 years ago Posts: 7,616 |
Quote
Wurstnase
For example, filament diameter can change while printing and it could be needed to change the flow (or e-steps).
Yes, an E steps override sounds like a good idea. Should work reasonable without EEPROM, too.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware February 24, 2016 10:27PM |
Registered: 7 years ago Posts: 75 |
I think I'll try adding some delta-specific parameter setting to Configtool. Hope it helps with the initial setup.
For those without EEPROM, M-codes should works to check calibration, but the user needs to recompile using Configtool to make the changes permanent.
Another workaround is to configure the host software to execute those M-codes at initial connect, but I don't think Repetier-Host is able to do that.
For those without EEPROM, M-codes should works to check calibration, but the user needs to recompile using Configtool to make the changes permanent.
Another workaround is to configure the host software to execute those M-codes at initial connect, but I don't think Repetier-Host is able to do that.
|
Re: Project: Teacup Firmware February 25, 2016 03:29AM |
Registered: 12 years ago Posts: 7,616 |
Quote
rollingdice
For those without EEPROM, M-codes should works to check calibration, but the user needs to recompile using Configtool to make the changes permanent.
Sounds like a good plan!
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware February 27, 2016 08:13AM |
Registered: 7 years ago Posts: 7 |
|
Re: Project: Teacup Firmware February 27, 2016 08:53AM |
Registered: 12 years ago Posts: 7,616 |
Quote
bisky
What am I doing wrong?
You're using Arduino IDE, that's wrong. Arduino 1.6 added new barriers, breaking things again and Teacup developers are no longer willing to play this game.
A much better way is to use Configtool: [reprap.org]
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware February 27, 2016 02:04PM |
Registered: 7 years ago Posts: 7 |
|
Re: Project: Teacup Firmware February 27, 2016 03:47PM |
Registered: 12 years ago Posts: 7,616 |
What exactly "doesn't work"? What's the error message?
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware February 28, 2016 04:35AM |
Registered: 7 years ago Posts: 7 |
|
Re: Project: Teacup Firmware February 28, 2016 06:04AM |
Registered: 12 years ago Posts: 7,616 |
I see, thanks.
- The file analog-arm.c should be treated as empty when compiling for AVR. There's a #if ... defined __ARMEL__ at the beginning of this file, which is always untrue when using avr-gcc.
- The atmega328 is likely an atmega328p, the additional 'p' matters.
- There is no file 'board.sinaptec_at328.h' in the repo, which raises the question where you got it from or which sources you use. As it's apparently an existing board it should be added to the Teacup repo, which I'll happily do.
- Glad to see Configtool its self works :-)
- The file analog-arm.c should be treated as empty when compiling for AVR. There's a #if ... defined __ARMEL__ at the beginning of this file, which is always untrue when using avr-gcc.
- The atmega328 is likely an atmega328p, the additional 'p' matters.
- There is no file 'board.sinaptec_at328.h' in the repo, which raises the question where you got it from or which sources you use. As it's apparently an existing board it should be added to the Teacup repo, which I'll happily do.
- Glad to see Configtool its self works :-)
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware February 28, 2016 08:29AM |
Registered: 7 years ago Posts: 7 |
The board is on reprap:
[reprap.org]
this is where i got the file [github.com]
So what must i do to compile this properly?
Thanks!
[reprap.org]
this is where i got the file [github.com]
So what must i do to compile this properly?
Thanks!
|
Re: Project: Teacup Firmware February 28, 2016 10:14AM |
Registered: 12 years ago Posts: 7,616 |
Thanks. This repo got stuck before Configtool was introduced, so I wonder a bit on how you could use Configtool with it.
Anyways. As the Sinaptec guy disn't respond, I made a Configtool compatible file myself and pushed it to branch experimental. Please get this branch from the original Teacup repo and give it a try. It looks a bit like you previously mixed several things, so please remove all the old stuff before doing so.
It compiles fine here, so it should work for you as well. Please report back wether it does, especially if you had to change something in the board configuration.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 01, 2016 02:10AM |
Registered: 7 years ago Posts: 7 |
This original teacup repo dos not contain the board which I try to upload the firmware to. I inserted the board.sinaptec_at328.h and tried to compile same problem as before. So I edit the config it now saying at328p, the build goes pas this, only to get the next error :
D:\teacup\Teacup_Firmware-master\config\board.sinaptec_at328.h:208: error: expected ',' or '}' before 'DEFINE_HEATER'
D:\teacup\Teacup_Firmware-master\config\board.sinaptec_at328.h:209:33: error: macro "DEFINE_HEATER" requires 4 arguments, but only 3 given
avr-gcc.exe: unrecognized option '-save-temps=obj'
RC = 1 - Build terminated
Build terminated abnormally.
I understand that other boards do not use the same pinout.
D:\teacup\Teacup_Firmware-master\config\board.sinaptec_at328.h:208: error: expected ',' or '}' before 'DEFINE_HEATER'
D:\teacup\Teacup_Firmware-master\config\board.sinaptec_at328.h:209:33: error: macro "DEFINE_HEATER" requires 4 arguments, but only 3 given
avr-gcc.exe: unrecognized option '-save-temps=obj'
RC = 1 - Build terminated
Build terminated abnormally.
I understand that other boards do not use the same pinout.
|
Re: Project: Teacup Firmware March 01, 2016 04:18AM |
Registered: 8 years ago Posts: 4,977 |
Please upload you board. Looks like your define for the heater missed one value.
| Triffid Hunter's Calibration Guide | --> X <-- Drill for new Monitor | Most important Gcode. |
|
Re: Project: Teacup Firmware March 01, 2016 07:19AM |
Registered: 7 years ago Posts: 7 |
|
Re: Project: Teacup Firmware March 01, 2016 07:50AM |
Registered: 12 years ago Posts: 7,616 |
Quote
bisky
This original teacup repo dos not contain the board which I try to upload the firmware to.
This is exactly what I changed yesterday. And it's not on the default branch master, but on branch experimental (where every new code goes until there's some proof it actually works).
Quote
bisky
The file and pinout included in attachment.
This is an old, pre-Configtool configuration. Heater definitions have changed since then (got an additional "inverted" parameter).
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 01, 2016 11:46AM |
Registered: 7 years ago Posts: 7 |
|
Re: Project: Teacup Firmware March 01, 2016 11:50AM |
Registered: 12 years ago Posts: 7,616 |
|
Re: Project: Teacup Firmware March 05, 2016 09:46AM |
Registered: 7 years ago Posts: 75 |
Okay, I'm looking on heater.c code to get a hint on EEPROM implementation on Teacup firmware. Currently I'm very confused as the code does not explicitly define EEPROM starting address, etc. Will the compiler auto-allocate which values goes where, just like using RAM? I did some AVR programming years ago, and I've never encounter something like this...
|
Re: Project: Teacup Firmware March 05, 2016 02:37PM |
Registered: 12 years ago Posts: 7,616 |
AVRs have a Harvard architecture, so three separate address spaces for each type of memory. There's some magic behind the scenes, because gcc doesn't really support Harvard architectures.
The secret lies in the usage of EEMEM, which instructs the compiler to use EEPROM memory. Also in using eeprom_read_xxx() and eeprom_write_xxx(), which is mandatory. Without these you read/write from/to RAM at the same address, which works, but doesn't fetch the results you expect. A pitfall easy to trap into.
More details here: [www.nongnu.org]
The secret lies in the usage of EEMEM, which instructs the compiler to use EEPROM memory. Also in using eeprom_read_xxx() and eeprom_write_xxx(), which is mandatory. Without these you read/write from/to RAM at the same address, which works, but doesn't fetch the results you expect. A pitfall easy to trap into.
More details here: [www.nongnu.org]
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 05, 2016 08:42PM |
Registered: 7 years ago Posts: 75 |
|
Re: Project: Teacup Firmware March 06, 2016 05:02AM |
Registered: 12 years ago Posts: 7,616 |
Do you have a Github account? I'll happily give you write access to the public repo, so your work doesn't get lost for future generations. We usually commit to topic branches there, so it's not neccessary to fine-tune the code before publishing it.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 06, 2016 10:10AM |
Registered: 7 years ago Posts: 75 |
|
Re: Project: Teacup Firmware March 09, 2016 08:39AM |
Registered: 7 years ago Posts: 75 |
I think I got it nailed:
A little drawback is the decimal precision of the constants when using built-in calculator is limited to 6 digits after decimal point. I haven't found a way to make it more precise.
So if you want more precision, launch your good old calculator, calculate it there and paste the result.
A little drawback is the decimal precision of the constants when using built-in calculator is limited to 6 digits after decimal point. I haven't found a way to make it more precise.
So if you want more precision, launch your good old calculator, calculate it there and paste the result.
|
Re: Project: Teacup Firmware March 09, 2016 09:36AM |
Registered: 12 years ago Posts: 7,616 |
Looks great!
Regarding this precision thing ... is it actually neccessary to calculate them in Configtool? At the first glance it looks to me as if they could be calculated inside the Teacup source code just as well. Can even be done with floating point math, as float calculations with constants are optimised away.
Regarding this precision thing ... is it actually neccessary to calculate them in Configtool? At the first glance it looks to me as if they could be calculated inside the Teacup source code just as well. Can even be done with floating point math, as float calculations with constants are optimised away.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 09, 2016 10:14AM |
Registered: 7 years ago Posts: 75 |
Quote
Traumflug
Looks great!
Regarding this precision thing ... is it actually neccessary to calculate them in Configtool? At the first glance it looks to me as if they could be calculated inside the Teacup source code just as well. Can even be done with floating point math, as float calculations with constants are optimised away.
Hmm, I never know of that. But I think you're right.
This way, I could eliminate less-straightforward variables on Configtool.
Edit:
I get warnings when compiling:
D:\Dropbox Banitama\Dropbox\Project\3D Printer\Teacup_Firmware\dda.c:46:32: warning: initializer element is not a constant expression const int32_t delta_tower1_x = (int32_t)(cos(DegToRad(TOWER_X_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
I don't know whether the output is optimized or not, but no noticeable program size increase though.
Edited 1 time(s). Last edit at 03/09/2016 11:43AM by rollingdice.
|
Re: Project: Teacup Firmware March 10, 2016 06:58AM |
Registered: 12 years ago Posts: 7,616 |
Quote
rollingdice
I get warnings when compiling:
D:\Dropbox Banitama\Dropbox\Project\3D Printer\Teacup_Firmware\dda.c:46:32: warning: initializer element is not a constant expression const int32_t delta_tower1_x = (int32_t)(cos(DegToRad(TOWER_X_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
The preprocessor can do the very basic math functions, only. This is addition, substraction, multiplication, division, shifts. Everything else has to be calculated at runtime, so it can't be used as initialiser. This should work without warning:
int32_t delta_tower1_x; delta_tower1_x = (int32_t)(cos(DegToRad(TOWER_X_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
There are ways to deal with this. If DegToRad() is a macro (defined with a #define) it'll be computed at compile time. An example is ACCELERATE_RAMP_LEN(speed) in dda_maths.h.
One can also do recursive macros to boild more complex math down to simple math. An example is in preprocessor_math.h: SQRT().
Branch thermistortable2 also has an exponen function: [github.com]
A preprocessor-compatible sine could look like this:
#define SIN(x) x - (x * x * x) / (2 * 3) + (x * x * x * x * x) / (2 * 3 * 4 * 5) ... (add a few more terms)This is simply a taylor series, like found here: [schools-wikipedia.org] Such preprocessor math isn't too complicate to write, but needs some testing (comparison with a proven function), as some of the traditional algorithms have pitfalls.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: Teacup Firmware March 10, 2016 07:39AM |
Registered: 8 years ago Posts: 4,977 |
Don't forget to put any x in the macro in his own brackets.
| Triffid Hunter's Calibration Guide | --> X <-- Drill for new Monitor | Most important Gcode. |
|
Re: Project: Teacup Firmware March 10, 2016 09:17AM |
Registered: 11 years ago Posts: 44 |
Quote
Traumflug
The preprocessor can do the very basic math functions, only. This is addition, substraction, multiplication, division, shifts. Everything else has to be calculated at runtime, so it can't be used as initialiser. This should work without warning:
int32_t delta_tower1_x; delta_tower1_x = (int32_t)(cos(DegToRad(TOWER_X_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
I don't think it matters whether you do this as an initializer or not. The result should be the same in either case.
Quote
Traumflug
There are ways to deal with this. If DegToRad() is a macro (defined with a #define) it'll be computed at compile time. An example is ACCELERATE_RAMP_LEN(speed) in dda_maths.h.
I understand what you mean, but be careful how you say it . Not all macros result in compile-time calculated values. Macros are _expanded_ at compile-time, but it is a simple text-expansion. It has no bearing on whether the resulting expression is computed at compile-time.
But after I read this a few times, I realized you were referring to this specific example and trying avoid the function call forcing the runtime action. But I could see new programmers being confused.
For example, you can say
#define PRECOMPUTED_EXP(x) exp(x) double foo = PRECOMPUTED_EXP(0.5)but the machine will still call the exp function at runtime. Some expressions are pre-computed, but it is a compiler-dependent feature. gcc pre-computes sqrt(CONSTANT), for example, but not exp(CONSTANT). The compile-time sqrt feature is relatively recent in gcc, but I think it pre-dates Arduino toolchains.
|
Re: Project: Teacup Firmware March 10, 2016 09:54AM |
Registered: 7 years ago Posts: 75 |
Quote
Traumflug
There are ways to deal with this. If DegToRad() is a macro (defined with a #define) it'll be computed at compile time. An example is ACCELERATE_RAMP_LEN(speed) in dda_maths.h.
A preprocessor-compatible sine could look like this:
#define SIN(x) x - (x * x * x) / (2 * 3) + (x * x * x * x * x) / (2 * 3 * 4 * 5) ... (add a few more terms)This is simply a taylor series, like found here: [schools-wikipedia.org] Such preprocessor math isn't too complicate to write, but needs some testing (comparison with a proven function), as some of the traditional algorithms have pitfalls.
Yes, DegToRad()) a macro-defined function.
I've tested the error between Taylor series estimated trigonometric values and traditionally computed ones in Excel. I use x = pi/6 and pi/3 (or 30 and 60 degrees, both are in quadrant 1). For angles in another quadrant, it will be computed accordingly. Here it is in case anyone is interested:
It seems that 4 iteration is practical for this implementation, since DEFAULT_DELTA_RADIUS rarely goes bigger that 1,000,000 um (1 meter).
I'm gonna add the macros in dda_maths.h.
Edited 1 time(s). Last edit at 03/10/2016 10:34AM by rollingdice.
|
Re: Project: Teacup Firmware March 10, 2016 10:53AM |
Registered: 12 years ago Posts: 7,616 |
Quote
rollingdice
It seems that 4 iteration is practical for this implementation, since DEFAULT_DELTA_RADIUS rarely goes bigger that 1,000,000 um (1 meter).
I'm gonna add the macros in dda_maths.h.
Looks quite good! I wouldn't mind having 8 iterations, because that's done at compile time, so it doesn't matter wether it takes an additional tenth of a second.
As a tidbit from history: with the SQRT() macro I actually managed to bring the compiler to its knees. When the expanded line goes beyond the 1 Megabyte range, compilation becomes tedious ... :-)
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
Sorry, only registered users may post in this forum.