Project: Teacup Firmware

By the way, I needed a way to debug the endstops, and it looks like the endstop check is commented out in the movement routine.

diff --git a/gcode_process.c b/gcode_process.c
index 76a3c3c..4727388 100644
--- a/gcode_process.c
+++ b/gcode_process.c
@@ -469,6 +469,31 @@ void process_gcode_command() {
                                power_off();
                                break;
 
+                        // report endstop status
+                        case 200:
+                                #if defined(X_MIN_PIN)
+                                   sersendf_P(PSTR("x_min:%d "), x_min());
+                                #endif
+                                #if defined(X_MAX_PIN)
+                                   sersendf_P(PSTR("x_max:%d "), x_max());
+                                #endif
+                                #if defined(Y_MIN_PIN)
+                                   sersendf_P(PSTR("y_min:%d "), y_min());
+                                #endif
+                                #if defined(Y_MAX_PIN)
+                                   sersendf_P(PSTR("y_max:%d "), y_max());
+                                #endif
+                                #if defined(Z_MIN_PIN)
+                                   sersendf_P(PSTR("z_min:%d "), z_min());
+                                #endif
+                                #if defined(Z_MAX_PIN)
+                                   sersendf_P(PSTR("z_max:%d "), z_max());
+                                #endif
+                                #if !(defined(X_MIN_PIN) || defined(X_MAX_PIN) || defined(Y_MIN_PIN) || defined(Y
+                                   sersendf_P(PSTR("no endstops defined"));
+                                #endif
+                               break;
+
                        #ifdef  DEBUG
                        // M240- echo off
                        case 240:

M200 prints the status of the available endstops. I picked the command number pretty much at random, maybe there is a more sensible one.

Jens_R Wrote:
-------------------------------------------------------
> I picked the command number pretty much at random,
> maybe there is a more sensible one.

heh nope, allocation of numbers is rather arbitrary, and becomes "official" (or as close as we get) when you add it to the wiki page

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
> heh nope, allocation of numbers is rather
> arbitrary, and becomes "official" (or as close as
> we get) when you add it to the wiki page

I was thinking about that... I was searching for the commands to home the axes on [reprap.org] and the Wiki page seems to be already out of sync with the firmware. Would it make sense to inline Doxygen-style documentation comments in gcode_process.c and generate that page automatically? It could be already Wiki-syntax and use a different marker to Doxygen to avoid confusion.

Jens_R Wrote:
-------------------------------------------------------
> I was thinking about that... I was searching for
> the commands to home the axes on
> [reprap.org] and the Wiki page
> seems to be already out of sync with the firmware.
> Would it make sense to inline Doxygen-style
> documentation comments in gcode_process.c and
> generate that page automatically? It could be
> already Wiki-syntax and use a different marker to
> Doxygen to avoid confusion.


sure, I did a big chunk of doxygen a bit back, generating G- and M-code documentation with doxygen is an excellent idea! Feel like sending a pull request?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
> generating G- and M-code documentation with
> doxygen is an excellent idea!

Does Doxygen support mediawiki output?

What I had in mind was something like this:

iff --git a/gcode_process.c b/gcode_process.c
index 76a3c3c..124c873 100644
--- a/gcode_process.c
+++ b/gcode_process.c
@@ -182,6 +182,21 @@ void process_gcode_command() {
 
                                //      G28 - go home
                        case 28:
+                               //? ==== G28: Move to Origin ====
+                               //? 
+                               //? Example: G28
+                               //? 
+                               //? This causes the RepRap machine to move back to its X, Y and Z zero endstops.  
+                               //? accelerating, so as to get there fast.  But when it arrives it backs off by 1 
+                               //? direction slowly, then moves back slowly to the stop.  This ensures more accur
+                               //? 
+                               //? If you add coordinates, then just the axes with coordinates specified will be 
+                               //? 
+                               //? G28 X0 Y72.3
+                               //? 
+                               //? will zero the X and Y axes, but not Z.  The actual coordinate values are ignor
+                               //? 
+
                                queue_wait();
 
                                if (next_target.seen_X) {

The //? lines can be easily filtered with a script, and you could probably set up a 3-way merge using git with the mediawiki version to avoid losing edits. How different are the firmware currently in development? Would it make sense to make a merged or a separate Wiki page? I'm still in the process of getting my first machine working, so I'm focussing on Teacup.

> Feel like sending a pull request?

On git? Or where?

Jens_R Wrote:
-------------------------------------------------------
> Triffid_Hunter Wrote:
> > generating G- and M-code documentation with
> > doxygen is an excellent idea!
>
> Does Doxygen support mediawiki output?

no idea, I'm sure there's converters somewhere, at worst html->mediawiki

> How different are the firmware
> currently in development? Would it make sense to
> make a merged or a separate Wiki page?

We should make a separate wiki page. Teacup doesn't implement all the gcodes on the main page, and we have some slightly different implementations of some of the gcodes on there, and we implement quite a few others that other firmwares don't implement.

I pushed the doxygen output to [triffid.github.com] a bit back so you can see what we have already. We could always rerun doxy and upload and simply point the wiki across.

> > Feel like sending a pull request?
>
> On git? Or where?

Yes, on github. Google will turn up at least a dozen git crash courses. Basically the process is fork, push your commits to your fork then send pull request from there.

It's best if you split your changes up into logical blocks, so each commit does one specific thing (affecting as many or as few files as necessary), and the firmware works equally well before and after the commit (preferably better afterwards! ). In the case of documenting all the gcodes, I think one big commit would be fine.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I'm already using the git checkout version though I'm far from a fluent git user, unfortunately.

This patch adds documentation from [reprap.org] for the commands implemented by Teacup. It includes a tiny tool to extract the documentation into a separate file. That tool could probably be easily replaced with a sed script, but we can't assume a proper unix-style environment for all users. It gives the option to implement more advanced processing in the future, and there is already a significant number of tools written for RepRap in pyhton that we can assume a working installation for most users.

I made the choice to document this outside of Doxygen, because it isn't particularly suited for documenting features inside a function. Of course, with a bit of search+replace the documentation I added can be reformatted to any other style.

A small tool is included (extract.py) to extract comments starting with "//?" and writing them into a new file gcode_doc.txt . That file should be a suitable format to upload to a wiki.
A more complete solution could automatically upload and download this page from the Wiki whenever gcode_process.c is modified. With git this could be handled with two branches, one to track changes on the wiki, and one to track changes from the code, and use merge operations to move changes from the code into the wiki.
(An even more advanced solution could merge changes from the wiki back into the source.. but that would be a bit more tricky to set up safely.)

There was a bit of an alignment problem in the switch instruction for gcode-parsing, which means the patch is slightly bigger than it should be,

looks great, and we certainly need some better documentation of teacup's gcode specifics!

A few suggestions before I commit to the repository:
* You've mis-titled G162, instead labelling it as G161 again
* Your discussion on feedrates in G1 doesn't really apply to teacup as we suggest using ramping by default rather than reprap acceleration, as reprap accel has numerous issues and is only effective when combined with hostware that's rather smarter than any of the current offerings.
* Add a comment to M101/M103 noting that teacup only uses these for reversals rather than proper extrusion support
* Add notes to M104/M105/M109 regarding teacup supporting an optional P parameter as a sensor index to address (eg M104 P1 S100 will set bed temperature rather than extruder temperature)
* Teacup uses totally different debug flags to those listed on the wiki, instead we have DEBUG_PID, DEBUG_DDA etc as listed in debug.h, so the help for M111 is not at all helpful
* In M115, may as well use Teacup's own response string as an example since we're keeping this separate from reprap wiki main gcode article!
* Add some documentation for the 'Undocumented' entries- just because they're teacup specific and not listed in reprap wiki main gcode article doesn't mean they shouldn't be documented in our source. If you don't want to take the time to work out exactly how something works, leave it- I'll understand

In summary, grafting reprap wiki's gcode page into teacup source isn't quite as useful as documenting teacup's own gcode cruncher.

Thanks for your work, and thanks for the work you're about to do!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

> * You've mis-titled G162, instead labelling it as
> G161 again
Easy fix, done.

> * Your discussion on feedrates in G1 doesn't
> really apply to teacup as we suggest using ramping
> by default rather than reprap acceleration, as
> reprap accel has numerous issues and is only
> effective when combined with hostware that's
> rather smarter than any of the current offerings.
I removed the discussion of feedrate. I don't actually have my own extruder working, yet, or even run Skeinforge without problems, so I'm not qualified to fill in more information.

> * Add a comment to M101/M103 noting that teacup
> only uses these for reversals rather than proper
> extrusion support
See above. I can put that statement into the documentation but it doesn't mean anything to me, yet.

> * Add notes to M104/M105/M109 regarding teacup
> supporting an optional P parameter as a sensor
> index to address (eg M104 P1 S100 will set bed
> temperature rather than extruder temperature)
Done.

> * Teacup uses totally different debug flags to
> those listed on the wiki, instead we have
> DEBUG_PID, DEBUG_DDA etc as listed in debug.h, so
> the help for M111 is not at all helpful
Done.

> * In M115, may as well use Teacup's own response
> string as an example since we're keeping this
> separate from reprap wiki main gcode article!
Changed the response string.

> * Add some documentation for the 'Undocumented'
> entries- just because they're teacup specific and
> not listed in reprap wiki main gcode article
> doesn't mean they shouldn't be documented in our
> source. If you don't want to take the time to work
> out exactly how something works, leave it- I'll
> understand
I documented the ones I could guess from context, the remaining ones should really be documented by someone who knows what he is talking about.

> In summary, grafting reprap wiki's gcode page into
> teacup source isn't quite as useful as documenting
> teacup's own gcode cruncher.
It was mainly meant as starting point. And maybe someone can think of a good way to cross-reference a global reference with firmware-specific documentation, maybe with some kind of feature matrix.

thanks for that, patches pushed to master since they're just documentation changes. I'll fix up other branches in a bit

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> thanks for that, patches pushed to master since
> they're just documentation changes. I'll fix up
> other branches in a bit

Did you notice it includes my endstop report command from earlier as well?

i haven't posted in awhile as I've been doing a lot of tinkering with my extruder hot end and SF41 settings but I just wanted to post to you guys my latest output. not possible with out all there work done here.
system specs:
Mendel "Beast' with Wades extruder
MakerGear Grovemount, Barrel and "experimental" .35mm mini BigHead Nozzle
w/ Nophead resistor style heater.

my own electronics setup (basically polulu drivers and custom plug-able heater unit)
LCD for fun and indespensible for temp readings

SkeinForge 41 ->ReplicatorG 24 -> teacup (god only knows what version as I haven't dune an update in 2 months)

My outputs are now very consistant, and worry free. i set it up hit print after the first layer or so I go get a beer.
anyways check out the pict or the geared heart, this came out this weekend.

@Architect

Amazing prints.
What speeds are you printing at?
Are you using acceleration? What setting?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Jens_R Wrote:
-------------------------------------------------------
> Did you notice it includes my endstop report
> command from earlier as well?

ah yes forgot about that, hopefully it doesn't break anything

Architect Wrote:
-------------------------------------------------------
> My outputs are now very consistant, and
> worry free. i set it up hit print after the first
> layer or so I go get a beer.

That's excellent news! Thanks for the report and photo! I'd love to know which commit you're using in case our current master is less than perfect. git log | head should do it

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Hi all, I've merged eeconfig, sdcard and multi-extruder into devel branch for you all to play with. It's not a complete merge, ie there's no provision in eeconfig for multiple extruders or sdcard re-pinning just yet, but please have a play anyway!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

So when can teacup make the official jump from experimental to mainstream?

I've been having the same success as architect. Damn near perfect prints.

[i211.photobucket.com]

Now if only there were a way to slow down the really short infill so it doesn't shake my worktable...


Keep up the good work!

Andrew Diehl Wrote:
-------------------------------------------------------
> So when can teacup make the official jump from
> experimental to mainstream?

when we get a heap of people documenting their successes on blogs and wiki and irc

> I've been having the same success as architect.
> Damn near perfect prints.

lovely! thanks for the report!

> Now if only there were a way to slow down the
> really short infill so it doesn't shake my
> worktable...

drop your acceleration, that way it can't hit full speed on short moves

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Quote

Now if only there were a way to slow down the really short infill so it doesn't shake my worktable...

Reduce acceleration ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Now if only there were a way to slow down the
> really short infill so it doesn't shake my
> worktable...
>
> Reduce acceleration ...


Unfortunately reducing the acceleration makes curves really really really slow. We actually need a minimum constant speed to be ramping up from so the acceleration can be set somewhere usable. I tried the new acceleration algorithm and had to have it set to at least 750mm/s^2 to have anything close to reasonable speeds around corners. With that said I have gone back to using the old acceleration as it gives me better prints. (also set really high 50,000)

The other reason we need a constant speed is at least in my case using a bowden cable I get small blobs (faceting) at every point in the gcode because the pressure in the cable does not drop off as quickly as with a direct extruder. It only happens during the milliseconds when it comes to a complete stop before accelerating. I know this is why you want the extruder pressure curve to dictate the acceleration curve but until then a constant minimum would help.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

The current acceleration makes the rest of the print slow if there are a lot of curves, so I currently run without any acceleration.

After considering the issue and a lot of googling, I think it is a g-code solution as opposed to a firmware one. I think Nophead had the same issue as I am with high frequency infill. [hydraraptor.blogspot.com]

Edited 1 time(s). Last edit at 06/04/2011 03:03PM by Andrew Diehl.

Hello. I'm having a strange problem with teacup: when i print something the print goes well for 300-350 commands, then the board stop printing, without sending ok again to replicatorg. This happens at random time, there isn't a repeatable gcode which makes it hang..

If i close replicatorg and open the terminal i'm able to send commands to the firmware, the temperatures are still stable, the calibration is still perfect, and the printer will correctly move if i send for example a "G1 Z20 E10" or "G1 X0 Y0 Z0". I don't have watchdog activated, and i'm sure that the board has not been resetted, because i insert some flash-led at the boot of the firmware..

That is very frustrating because until the stop the printer is going very well and precise.. I even tried to slow down a lot in the skeinforge 40 "speed" module, and this happens even at very slow speeds, but usually after the near-300-commands mark. So for example all the calibration cubes come out quite well and without interruptions.

Anyone has got any idea how to debug better this thing? In the while i'm going to insert some debug commands to explore the dda queue, to try to understand what's happening.

Sublime Wrote:
-------------------------------------------------------
> Unfortunately reducing the acceleration makes
> curves really really really slow. We actually need
> a minimum constant speed to be ramping up
> from so the acceleration can be set somewhere
> usable.

I'm in the process of preparing myself to write exactly that. The reprap acceleration already has the math, although I'll probably work it out again so I can wrap my head around it. Unfortunately it requires lots of squaring things so we have to be really careful about overflow.

hariseldon78 Wrote:
-------------------------------------------------------
> Hello. I'm having a strange problem with teacup:
> when i print something the print goes well for
> 300-350 commands, then the board stop printing,
> without sending ok again to replicatorg.

We've frequently had this problem with graphical host talkers. Please try one of the command-line ones such as send.py or pronsole before you decide that firmware isn't sending an ok for some reason

Also, this may be a protocol/noise issue. Serial is a less than reliable data transport, and there is currently no facility in the protocol for either host or firmware to detect that an 'ok' hasn't been received correctly. Ideally we need a bidirectional retry mechanism like tcp, but implementing this in a backwards-compatible fashion will be an interesting puzzle.

> Anyone has got any idea how to debug better this
> thing? In the while i'm going to insert some debug
> commands to explore the dda queue, to try to
> understand what's happening.

That's a great idea! Investigating and debugging code is a great way to learn Hopefully there's enough documentation for you to find your way around, if not ask here

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Which version of replicatorG are you on? If not 24 I'd upgrade grade first. 25 just was released but I haven't tried it yet.
@Sublime sorry it took so long getting back to ya. I'm printing at 17 for feed and flow the new dimension stuff in skeinforge has really proved my consistency.
I'm using ramps acceleration but tuned it way down. 30 for travel.

@triffid this is all I get from git log. (not very good at checking things in. )

commit dd1468e6c470b3f53b537ee600991758d62d5e59
Author: karltrout
Date:   Mon Feb 14 21:13:53 2011 -0500

    Initial first go

Last thing I did was inject my LCD stuff we talked about.

I tried with both versions, same behaviour.

Now, i tried debugging all around to understand what can cause my problem, and i stumbled into this:

m114
ok X:0,Y:0,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

g1 x0.1
ok 
m114
ok X:100,Y:0,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

g1 y0.1
ok 
m114
ok X:100,Y:200,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

g1 x0
ok 
m114
ok X:0,Y:200,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

g1 x0.2
ok 
m114
ok X:200,Y:400,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

g1 y0.2
ok 
m114
ok X:200,Y:800,Z:0,E:0,F:80
UMX:100,UMY:100,UMZ:1,UME:22

and so on. The current_position.X affect the current_position.Y in a sort of exponential way. The X and Z axis are not affected by any other, and the Z axis don't affect Y.

i changed a bit the m114 command to use the integer print, thinking that the floating point print could be causing the problem:

			case 114:
				//? ==== M114: Get Current Position ====
				//?
				//? Example: M114
				//?
				//? This causes the RepRap machine to report its current X, Y, Z and E coordinates to the host.
				//?
				//? For example, the machine returns a string such as:
				//?
				//? ok C: X:0.00 Y:0.00 Z:0.00 E:0.00
				sersendf_P(PSTR("X:%ld,Y:%ld,Z:%ld,E:%ld,F:%ld\n"), ((int32_t)current_position.X) * ((int32_t) UM_PER_STEP_X), ((int32_t)current_position.Y) * ((int32_t) UM_PER_STEP_Y), ((int32_t)current_position.Z) * ((int32_t) UM_PER_STEP_Z), ((int32_t)current_position.E) * ((int32_t) UM_PER_STEP_E), current_position.F);
				sersendf_P(PSTR("UMX:%ld,UMY:%ld,UMZ:%ld,UME:%ld\n"), ((int32_t) UM_PER_STEP_X),((int32_t) UM_PER_STEP_Y),  ((int32_t) UM_PER_STEP_Z), ((int32_t) UM_PER_STEP_E));
 				// newline is sent from gcode_parse after we return
				break;

Anyway the x and y positions on the phisical machines are correct, but maybe this could be related to my problem causing an overflow somewhere.. Could somebody please try to replicate this? Is my sanguino board gone mad? Maybe the ram is full or something?

Edited 1 time(s). Last edit at 06/04/2011 10:41PM by hariseldon78.

that looks toally wrong, I'll see if I can reproduce

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

cannot reproduce:

start
ok
M114
ok X:0.000,Y:0.000,Z:0.000,E:0.000,F:50
X:0,Y:0,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

G1 X0.1
ok 
M114
ok X:0.100,Y:0.000,Z:0.000,E:0.000,F:50
X:100,Y:0,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

G1 Y0.1
ok 
M114
ok X:0.100,Y:0.100,Z:0.000,E:0.000,F:50
X:100,Y:100,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

G1 X0
ok 
M114
ok X:0.000,Y:0.100,Z:0.000,E:0.000,F:50
X:0,Y:100,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

G1 X0.2
ok 
M114
ok X:0.200,Y:0.100,Z:0.000,E:0.000,F:50
X:200,Y:100,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

G1 Y0.2
ok 
M114
ok X:0.200,Y:0.200,Z:0.000,E:0.000,F:50
X:200,Y:200,Z:0,E:0,F:50
UMX:100,UMY:100,UMZ:1,UME:1

on commit b39a7b8 (current master HEAD), atmega 328 NOT connected to my reprap motherboard

so I don't know what's going on for you there, but it's not good :/

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

The git version be81a1358450fb9b9faff02e4ac8cd99ecddafeb is ok.
The next version 3e32a8f634cb5f5c2ea8e69130d716acfcd82665 gives me those behaviour..

Anyway, it seems just a problem confined to the M114 command, so i'm not confident that this was causing my machine to stop printing

Edited 1 time(s). Last edit at 06/05/2011 04:46AM by hariseldon78.

floating point is not forbidden in steps_per_mm defines, mine were as follows to generate the output above:

#define STEPS_PER_MM_X        10.0
#define STEPS_PER_MM_Y        10.0
#define STEPS_PER_MM_Z        1000.0

#include  
#define STEPS_PER_MM_E        (3200.0 * 39.0 / 11.0 / 6.75 / M_PI)

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> floating point is not forbidden in steps_per_mm
> defines, mine were as follows to generate the

you are right it's something other. i edited the message, please look it. is it possible to talk on irc or google chat or something? my google chat is hariseldon78@googleDOTcom

This remains a mistery, but i've been able to work around it by changing the m114 command like this:

case 114:
				//? ==== M114: Get Current Position ====
				//?
				//? Example: M114
				//?
				//? This causes the RepRap machine to report its current X, Y, Z and E coordinates to the host.
				//?
				//? For example, the machine returns a string such as:
				//?
				//? ok C: X:0.00 Y:0.00 Z:0.00 E:0.00
				sersendf_P(PSTR("X:%lq,"), current_position.X * ((int32_t) UM_PER_STEP_X));
				sersendf_P(PSTR("Y:%lq,"), current_position.Y * ((int32_t) UM_PER_STEP_Y));
				sersendf_P(PSTR("Z:%lq,"), current_position.Z * ((int32_t) UM_PER_STEP_Z));
				sersendf_P(PSTR("E:%lq,"), current_position.E * ((int32_t) UM_PER_STEP_E));
				sersendf_P(PSTR("F:%ld"), current_position.F);
				// newline is sent from gcode_parse after we return
				break;

The problem is related to sersendf_P. Maybe something is going wrong in my compiler handling of the va_args, anyway, no need to understand while we can work around