Triffid.

Thanks for the pointers to libreprap, yup source to your invocation of socat would be useful. Although I don't intend to use socat to keep the dependencies low'ish (although might do yet as it is early days yet, just seeing where it goes).

ncurses and cdk are calculated hits on the dependencies thing. They arguably contribute more forward progress than they cost and are pretty much standards in most linux repositories.

For the config etc I will be putting key items into global variables for now and it will be targeted solely at Teacup, but once there is a functional version that folk can use, it will be time perhaps to add a more complex config file that has mappings for Motion-function -> G-Code-sequence.

Hoping to get some more time to do work on the TTeacup hostware over the next week.

What I do need right now is some thought and contribution on a definitive set of Motion-function -> G-Code-sequence sequences for Teacup.

In particular not how we think Teacup should do it to work with something else. The actual it was writ to work this way ones.

I guess there can be a gap between the two, It may actually be expanding (for whatever reasons). This host-ware is intended to work out of the box though with Teacup. (Perhaps even with a small number of test/calibration pieces provided in G-Code)

Example Motion-Functions to map G-Code to.

1. Physical Go To Home Min, X, Y, Z, ALL
2. Physical Go To Home Max, X, Y, Z, ALL
3. Consider this as home, ie change zero or origin to current position
4. Fast Move
5. Slow/extruding Move
6. Set Extruder n Temp
7. Set Bed Temp
8. Set fan on/speed
9. Wait for Extruder n, Bed etc to come up to speed, individually or all together.
10. Composites, Machine setup, Purge, Machine shutdown.
11. Any others that can be thought of or are going to be useful etc.

On compatibility, this is something of a moving target. Chasing everyone else's idea of what the Host-Machine protocol should be and what G-code should do is going to lead to more trouble than it is worth.

For Host-Machine protocols libreprap should perhaps be the adopted standard/guide. (Maybe, what do you guys think)

As most tools use Skeinforge for the slicer it could be worth picking on supporting a stated version of skeinforge and the G-code it generates as a slicer. (Pick your version) Ie an essential set of G-Code and how it functions.

Then adding in extensions to make up a superset for what ever you want a degree of compatibility with.

All in all to get from CAD to Physical object we are using a tool chain. Any user (newbie or oldbie) needs access to a reasonably good out of the box solution. At least to get them going and prove their firmware/machinery.

I guess this is taken care for makerbot folk as Makerbot Inc control their tool chain end to end starting with the slicer ie Hostware/Firmware/Hardware. This is good for their accessibility and uptake. Consequently good for their business.

Perhaps there is something to be learned from this.....

Bit of a mixed posting, sorry, just emptying out some thinking.

Cheers

AKA47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi all,

Just posted some initial work on SD card support in new branch 'sdcard'.

I've been testing the modules (ff.c, mmc.c and friends) in a separate project and they seem to work well enough, however in combination with the rest of teacup they're too big to fit on my '328 so those of you with '644 and bigger chips will have to take it from here until I can upgrade my electronics a bit

The implementation is far from complete. The commits contain a few todos as notes to whoever wants to take this forward (including myself).

I have deliberately kept dda_create() in the loop because I want to save some of the stuff it calculates into the gcode, so we can afford to take a really long time to calculate it properly without jeopardising a print, while at the same time support files without this information eg that have been copied via another route.

sersendf_P and friends will be really handy here, we'll have to work out if it's better to duplicate some code or decouple them from the serial subsystem.

Just for laughs, here's my SD card socket

---

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

Teacup doesn't work on an UNO because the optiboot loader leaves timer 1 partially configured. This can be fixed by updating the UNO bootloader or by doing "TCCR1B = 0;" before doing any other timer initialization in Teacup code.

Jeremy

jv4779 Wrote:
-------------------------------------------------------
> Teacup doesn't work on an UNO because the optiboot
> loader leaves timer 1 partially configured. This
> can be fixed by updating the UNO bootloader or by
> doing "TCCR1B = 0;" before doing any other timer
> initialization in Teacup code.
>
> Jeremy

thanks, commit pushed.

Strangely, my '328 has optiboot and I haven't noticed any issues

---

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

I home my Z axis by dropping the extruder down at the dump location where there's a gap in the bed. The switch is tripped when the tip is actually below the level of the bed. Then I do a G92 Z-2.9 to set the current position relative to the bed. This way I don't have to be accurate in mounting the switch, I just fine tune it with the G92 in the home routine.

Anyway, it seems that Teacup doesn't like negative values in G92. I can work around it by moving Z up to 1.9 and then doing a G92 Z0 so it isn't a big deal. Just thought I'd mention it in case I'm doing something incorrectly.

sliptonic Wrote:
-------------------------------------------------------
> Anyway, it seems that Teacup doesn't like negative
> values in G92. I can work around it by moving Z
> up to 1.9 and then doing a G92 Z0 so it isn't a
> big deal. Just thought I'd mention it in case I'm
> doing something incorrectly.


Its because you have the soft limits of Z set to min 0, just set your Z min to -2.9

---

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

Sublime,

I have the Z min set to -3 and I guess this is working. You can see from below why I'm confused though. After setting G92 Z-1.9 the M114 shows an absurdly large value for Z. Moving up ten does move it positive to the correct height and after that it seems to report a correct position. It's just strange.

N4 G161 Z0*97
ok 
ok 
N5 M114*34
ok 
ok X:0.000,Y:75.350,Z:0.000,E:0.000,F:2000
N6 G92 Z-1.9*101
ok 
ok 
N7 M114*32
ok 
ok X:0.000,Y:75.350,Z:10322.536,E:0.000,F:2000
N8 G1 Z10*91
ok 
ok 
N9 M114*46
ok 
ok X:0.000,Y:75.350,Z:10.016,E:0.000,F:2000

sliptonic Wrote:
-------------------------------------------------------
> After setting G92 Z-1.9 the M114 shows
> an absurdly large value for Z.
>
> ok X:0.000,Y:75.350,Z:10322.536,E:0.000,F:2000

I think you found a bug in my M114 fractional millimeter code- looks like it doesn't handle negatives too well at all!

I'll investigate shortly, tell me if this helps:

diff --git a/gcode_process.c b/gcode_process.c
index 45cb5dd..098a978 100644
--- a/gcode_process.c
+++ b/gcode_process.c
@@ -393,7 +393,7 @@ void process_gcode_command() {
                                // M113- extruder PWM
                        // M114- report XYZEF to host
                        case 114:
-                               sersendf_P(PSTR("X:%lq,Y:%lq,Z:%lq,E:%lq,F:%ld"), current_position.X * UM_PER_STEP_X, current_position.Y * UM_PER_STEP_Y, current_position.Z * UM_PER_STEP_Z, current_position.E * UM_PER_STEP_E, current_position.F);
+                               sersendf_P(PSTR("X:%lq,Y:%lq,Z:%lq,E:%lq,F:%ld"), current_position.X * ((int32_t) UM_PER_STEP_X), current_position.Y * ((int32_t) UM_PER_STEP_Y), current_position.Z * ((int32_t) UM_PER_STEP_Z), current_position.E * ((int32_t) UM_PER_STEP_E), current_position.F);
                                // newline is sent from gcode_parse after we return
                                break;
                        // M115- capabilities string

If not, it's time to start digging around in sersendf.c[case 'q'] and sermsg.c[serwrite_int32_vf()]

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
>
> I'll investigate shortly, tell me if this helps:
> diff --git a/gcode_process.c b/gcode_process.c

It helps, but I'm not sure it's there yet. I would expect Z to be at -1.9 not -1.584. However, moving from the position below to Z = 0 puts it right on the bed where it should be though.

N4 G92 Z-1.9*103
ok 
ok 
N5 M114*34
ok 
ok X:0.000,Y:72.324,Z:-1.584,E:0.000,F:2000

sliptonic Wrote:
-------------------------------------------------------
> Triffid_Hunter Wrote:
> --------------------------------------------------
> -----
> >
> > I'll investigate shortly, tell me if this
> helps:
> > diff --git a/gcode_process.c b/gcode_process.c
>
> It helps, but I'm not sure it's there yet. I
> would expect Z to be at -1.9 not -1.584.
> However, moving from the position below to Z = 0
> puts it right on the bed where it should be
> though.
>
> N4 G92 Z-1.9*103
> ok
> ok
> N5 M114*34
> ok
> ok X:0.000,Y:72.324,Z:-1.584,E:0.000,F:2000
>

That's probably an artefact of arithmetic precision loss at the conversion in M114, I'm trying a more thorough conversion right now, specifically:

diff --git a/gcode_process.c b/gcode_process.c
index 098a978..d707902 100644
--- a/gcode_process.c
+++ b/gcode_process.c
@@ -393,7 +393,27 @@ void process_gcode_command() {
                                // M113- extruder PWM
                        // M114- report XYZEF to host
                        case 114:
-                               sersendf_P(PSTR("X:%lq,Y:%lq,Z:%lq,E:%lq,F:%ld"), current_position.X * ((int32_t) UM_PER_STEP_X), current_position.Y * ((int32_t) UM_PER_STEP_Y), current_position.Z * ((int32_t) UM_PER_STEP_Z), current_position.E * ((int32_t) UM_PER_STEP_E), current_position.F);
+                               do {
+                                       int32_t x_um, y_um, z_um, e_um;
+                                       // we can't multiply by 1000 if position is bigger than 2^22 or we'll overflow
+                                       if (current_position.X & 0x7FC00000) // labs(current_position.X) >= 2^22
+                                               x_um = (current_position.X / ((int32_t) STEPS_PER_MM_X)) * 1000L;
+                                       else
+                                               x_um = current_position.X * 1000L / ((int32_t) STEPS_PER_MM_X);
+                                       if (current_position.Y & 0x7FC00000) // labs(current_position.Y) >= 2^22
+                                               y_um = (current_position.Y / ((int32_t) STEPS_PER_MM_Y)) * 1000L;
+                                       else
+                                               y_um = current_position.Y * 1000L / ((int32_t) STEPS_PER_MM_Y);
+                                       if (current_position.Z & 0x7FC00000) // labs(current_position.Z) >= 2^22
+                                               z_um = (current_position.Z / ((int32_t) STEPS_PER_MM_Z)) * 1000L;
+                                       else
+                                               z_um = current_position.Z * 1000L / ((int32_t) STEPS_PER_MM_Z);
+                                       if (current_position.E & 0x7FC00000) // labs(current_position.E) >= 2^22
+                                               e_um = (current_position.E / ((int32_t) STEPS_PER_MM_E)) * 1000L;
+                                       else
+                                               e_um = current_position.E * 1000L / ((int32_t) STEPS_PER_MM_E);
+                                       sersendf_P(PSTR("X:%lq,Y:%lq,Z:%lq,E:%lq,F:%ld"), x_um, y_um, z_um, e_um, current_position.F);
+                               } while (0)
                                // newline is sent from gcode_parse after we return
                                break;
                        // M115- capabilities string

I'm open to other ideas if you have them

---

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

2^22 means 2 exclusive ORed with 22 in C, not 2 to the power of 22.

---

[www.hydraraptor.blogspot.com]

it's in comments, but probably should change to be clearer, thanks

---

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

Hi,

I wonder if someone could help me with this problem please.

I am trying to compile the Teacup Firmware with the Gen7 config.h file in Arduino 0022 (following the Generation 7 Firmware instructions) but receive the following error:

In file included from gcode_process.c:20:
pinio.h:42:20: error: macro "power_off" passed 1 arguments, but takes just 0

When I replace the Gen7 config.h file with one included in the Teacup distribution it compiles fine. I have also tried this on both Windows 7 and Kubuntu 11.04.

I am looking for any idea as to what is going wrong, and more importantly what I could do to fix it?

Thanks in advance,

This may be the issue.
[forums.reprap.org]

---

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

Different problem.

The gen7 provided config.h file defines a macro for power_off, which clashes with the declaration for power_off in pinio.h.

It looks like there are a variety of incompatibilities between the gen7 config.h file and the current version of the Teacup firmware. I think someone more familiar with the gen7 hardware will have better luck addressing the problem.

try commenting that line in gcode_process.c out ( line 20 ) to move forward. looks like your config may be from an older release.

there's no gen7 config in our repository.

We keep all the repository configs updated vs changes to how things are done, so you have an old config that doesn't match the latest changes.

Teacup has gone through significant changes in terms of configuration lately.

If you link the config you're using, we can probably point out most of the stuff that needs changing, and we should add a config.gen7.h to our repository.

Alternatively, you could grab one of the configs that is in our repository (ramps is fairly similar to gen7 afaik) and copy the gen7-specific information into it then post it here for us

---

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

Quote

there's no gen7 config in our repository.

There's one in the Gen7 repo which is outdated. My mistake, I've removed it.

Try with the one appended to this post, as soon as Teacup is compilable again I'll post one into the Tecup repo.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

kiram9 Wrote:
-------------------------------------------------------
> So I got my machine working with Teacup (and only
> teacup)! It prints objects and no longer freezes!
> I am super happy
> I put up some pics and descriptions here
> The Knot was the first successful print I made. So
> far all my custom electronics and extruder are
> working wonderfully! Special thanks to
> Triffid_Hunter who helped me hunt down strange
> issues in the firmware.

Hi.
I'm experiencing the same issue -- printer freezes after few moves.
kiram9 (or anyone else), could you please describe your solution to this problem?

My setup:
Electronics: gen3 electronics, DC motor extruder.
Software: teacup tweaked to work with DC extruder + send.py.
After this g-code printer ceases to accept commands.

By the way: I think temp_residency in temp.c should be increased (if temperature achieved) on each call to temp_sensor_tick() (i.e. each 10ms) and not only next_read_time*10ms. With TEMP_INTERCOM defined temp_residency gets updated each 250ms. Here is a patch.

Thanks.

hm, what happens when the timer compare triggers before dda_step finishes? the timer interrupt is disabled for that duration, but we re-enable it near the bottom while global interrupts are also enabled, at which point the interrupt will fire instantly- maybe this is smashing our stack? A call to cli() before set_timer at the bottom of dda_step should solve it if that's the issue.

We probably should make checking movebuffer[mb_tail].live atomic in a few places too, like this:

diff --git a/dda_queue.c b/dda_queue.c
index 5bc87be..8a37ae1 100644
--- a/dda_queue.c
+++ b/dda_queue.c
@@ -28,12 +28,20 @@ DDA movebuffer[MOVEBUFFER_SIZE] __attribute__ ((__section__ (".bss")));
 
 /// check if the queue is completely full
 uint8_t queue_full() {
-       return (((mb_tail - mb_head - 1) & (MOVEBUFFER_SIZE - 1)) == 0)?255:0;
+       uint8_t sreg = SREG, r;
+       cli();
+       r = (((mb_tail - mb_head - 1) & (MOVEBUFFER_SIZE - 1)) == 0)?255:0;
+       SREG = sreg;
+       return r;
 }
 
 /// check if the queue is completely empty
 uint8_t queue_empty() {
-       return ((mb_tail == mb_head) && (movebuffer[mb_tail].live == 0))?255:0;
+       uint8_t sreg = SREG, r;
+       cli();
+       r = ((mb_tail == mb_head) && (movebuffer[mb_tail].live == 0))?255:0;
+       SREG = sreg;
+       return r;
 }
 
 // -------------------------------------------------------
@@ -95,9 +103,15 @@ void enqueue(TARGET *t) {
 
        mb_head = h;
 
+       uint8_t sreg = SREG;
+       cli();
        // fire up in case we're not running yet
-       if (movebuffer[mb_tail].live == 0)
+       if (movebuffer[mb_tail].live == 0) {
+               SREG = sreg;
                next_move();
+       }
+       else
+               SREG = sreg;
 }
 
 /// go to the next move.
@@ -144,6 +158,9 @@ void queue_flush() {
        mb_tail = mb_head;
        movebuffer[mb_head].live = 0;
 
+       // disable timer
+       setTimer(0);
+
        // restore interrupt flag
        SREG = sreg;
 }
diff --git a/dda.c b/dda.c
index 952c86b..846af3a 100644
--- a/dda.c
+++ b/dda.c
@@ -565,6 +545,8 @@ void dda_step(DDA *dda) {
                z_disable();
        }
 
+       cli();
+
        setTimer(dda->c >> 8);
 
        // turn off step outputs, hopefully they've been on long enough by now to register with the drivers

I have pushed this patch to master, let me know how it goes.

---

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

I've also tried to clean up the delay stuff a bit, let me know if what I did works for everyone.

---

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

Sergey Batalov Wrote:
-------------------------------------------------------
> Hi.
> I'm experiencing the same issue -- printer freezes
> after few moves.
> kiram9 (or anyone else), could you please describe
> your solution to this problem?

please check if latest head still locks your queue. The atomics patch above may well address the issue.

> Software: teacup tweaked to work with DC extruder

how well does the dc extruder work with teacup? I put the code in, but never tested it. Did it take much tweaking, or just the relevant config entries?

> By the way: I think temp_residency in temp.c
> should be increased (if temperature achieved) on
> each call to temp_sensor_tick() (i.e. each 10ms)
> and not only next_read_time*10ms. With
> TEMP_INTERCOM defined temp_residency gets updated
> each 250ms. Here is a patch.

patch pushed, thanks!

---

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

Hi Triffid!

I pulled/merged your patches. Unfortunately it does not help.. Symptoms are the same.

I narrowed down freezing g-code to the following:

M111 S6
G21                             ;metric is good!
G90                             ;absolute positioning
G92 X0 Y0 Z0 			(You are now at 0,0,0)
G1 F2000
G1 X38.9 Y40.73 Z0.85 F180.0           ( problem here? )
G1 X37.81 Y39.98 Z0.85 F1920.0
G4
G1 X0 Y0 F2000

and here is the resulting conversation between host and motherboard. I found that changing F180.0 to F1080.0 (or something like) solves the problem. But this G1 line alone do not cause any freezing even with F180.0. Strange..

This happens when ACCELERATION_REPRAP used. Without acceleration or if ACCELERATION_RAMPING used, this g-code do not cause problems (I did not tried big prints with this type of acceleration yet). For unknown reason ACCELERATION_TEMPORAL gives acceptable speeds only for feedrates above 10000. Maybe something wrong with my config.h?

>how well does the dc extruder work with teacup? I put the code in, but never tested it. Did it take
>much tweaking, or just the relevant config entries?

DC motor extruder seems working now. Note that my extruder controlled via intercom rather than wired directly to the motherboard. I've implemented intercom queue to be able to send different kinds of packets to extruder controller (such as M101/103, not only M105) "asynchronously", i.e. M105, M101 (extruder on), M103 (extruder off) enqueue tx packets which are sent by generalized start_send() function in a fast loop. Not sure it is strictly necessary but I feel myself more comfortable with buffering than without it.

Thanks for reply.

Hy Triffid,

on my way of getting Teacup/Ramps/ReplicatorG playing nicely together, I had to change the following in "gcode_process.c", because else the homing G codes would be executed BEFORE the rest of the queue, which is not the way it should be, IMHO.

Regards,



case 161:
queue_wait(); <-------- INSERTED THIS
if (next_target.seen_X)
home_x_negative();
if (next_target.seen_Y)
home_y_negative();
if (next_target.seen_Z)
home_z_negative();
break;
// G162 - Home positive
case 162:
queue_wait(); <-------- INSERTED THIS
if (next_target.seen_X)
home_x_positive();
if (next_target.seen_Y)
home_y_positive();
if (next_target.seen_Z)
home_z_positive();
break;

case 161:
queue_wait(); <-------- INSERTED THIS
if (next_target.seen_X)
home_x_negative();

Looking at home_x_negative() in home.c, there is already a queue_wait(), so I wonder what makes the difference?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

cloudmaker Wrote:
-------------------------------------------------------
> Hy Triffid,
>
> on my way of getting Teacup/Ramps/ReplicatorG
> playing nicely together, I had to change the
> following in "gcode_process.c", because else the
> homing G codes would be executed BEFORE the rest
> of the queue, which is not the way it should be,
> IMHO.

That was fixed a month ago, with queue_wait() calls in the various functions in home.c. Thanks for the bug report, but please check if your repository is stale

Post again when you've decided whether your repository was old, or whether homing is still broken vs the queue- let us know either way!

---

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

Sergey Batalov, could you post a copy of your config.h file?

I checked my repository, was from april 6, so, yes, it was *not* up to date and didn't contain those fixes.

Will try the latest version the weekend.

Regards & thanks for the quick reply

Sergey Batalov, I've identified the problem in the firmware. From the trace you linked to:

{DDA:CA end_c:12907, n:2, md:24782000, ssq:2025, esq:230400, dsq:57093, msbssq:10, msbtot:5}

In the step acceleration code (dda.c) there is a line that reads:

dda->c = (int32_t) dda->c - ((int32_t) (dda->c * 2) / dda->n);

The n value reported in the trace is taken from dda->n. When n==2, c is set to 0, which turns off the step interrupt timer so stepping grinds to a halt (as you've observed).

What follows is a hack to limit the damage when the acceleration code over/underflows (which is what is effectively happening in this case).

I'll make a patch available to the repository soon, but if you want to try it out before it gets added: In dda.c, replace

	#ifdef ACCELERATION_REPRAP
		// linear acceleration magic, courtesy of [www.embedded.com]
		if (dda->accel) {
			if (
					((dda->n > 0) && (dda->c > dda->end_c)) ||
					((dda->n < 0) && (dda->c < dda->end_c))
				) {
				dda->c = (int32_t) dda->c - ((int32_t) (dda->c * 2) / dda->n);
				dda->n += 4;
			}
			else if (dda->c != dda->end_c) {
				dda->c = dda->end_c;
			}
			// else we are already at target speed
		}
	#endif

with

	#ifdef ACCELERATION_REPRAP
		// linear acceleration magic, courtesy of [www.embedded.com]
		if (dda->accel) {
			if ( (dda->c > dda->end_c) && ( dda->n > 0) ) {
				uint32_t increment = (dda->c * 2) / dda->n;
				if( increment < dda->c ) {
					dda->c = dda->c - increment;
					if( dda->c < dda->end_c ) {
						dda->c = dda->end_c;
					}
					else {
						dda->n += 4;
					}
				}
				else {
					dda->c = dda->end_c;
				}
			}
			else if ( (dda->c < dda->end_c) && ( dda->n < 0) ) {
				uint32_t increment = (dda->c * 2) / (-dda->n);
				if( dda->c + increment >= dda->c ) {
					dda->c = dda->c + increment;
					if( dda->c > dda->end_c ) {
						dda->c = dda->end_c;
					}
					else if( dda->n < -5 )	{
						dda->n += 4;
					}
				}
				else {
					dda->c = dda->end_c;
				}
			}
			else if (dda->c != dda->end_c) {
				dda->c = dda->end_c;
			}
			// else we are already at target speed
		}
	#endif

I was able to reproduce the problem and was able to verify that the above fixes the specific problem.

Edit: Fixed a bug in the speed increasing case.

Edited 1 time(s). Last edit at 05/12/2011 12:05AM by madscifi.

madscifi Wrote:
-------------------------------------------------------
> Sergey Batalov, could you post a copy of your
> config.h file?

Hi.
Here is my config.h. As a workaround I use ramping acceleration and disable oozebane in skeinforge (which seems useless with acceleration anyway) to avoid such small feed rates in g-code. Nevertheless it would be great to find a bug.

Thanks.