Teacup Firmware replicatorG & Skeinforge I've decided its time to graduate to a more complicated software package for my setup. I have been somewhat successful using 5D for Arduino and repsnapper. I was able to get everything I needed to work working. now its time for tweaking the gcode output. It seems to me that ReplicatorG has already many of the features i need so i am going to start tailoring my firmware hacks to its requirements. the first road block i have come to is the newly implemented checksum. I have checksum working quite well with the repsnapper code and it defiantly catches the few bad lines sent and requests the resend properly and the DDA waits for the correct line to come. I am wondering if Anyone out there is working with this exact setup and what other changes I need to be aware of . I also decided on downgrading to Skeinforge 31 as 35 and 39 both add a great deal of extras that 5D is not capable of handling. I hope to move up to those after I get 31 dialed in. So, any suggestions, tips and gotchas to look out for would be helpful. my current bug is that after about 1600 or so lines my machine goes haywire and does all kinds of bad things. my feeling is it received a noisy command and given no checksum the firmware just tried to process the command. hence the reason I want checksum back in there to handle this things as well as tell me when they happen. -regards and thanks trout [Edit: Changed name to "Teacup Firmware" for the purposes of not confusing folk, after irc discussion. --Sebastien] https://reprap.org/forum/read.php?147,71989,71989#msg-71989 Mon, 20 Jul 2026 09:47:12 -0400 Phorum 5.2.23 https://reprap.org/forum/read.php?147,71989,120620#msg-120620 Re: Teacup Firmware https://reprap.org/forum/read.php?147,71989,120620#msg-120620
/**
analog subsystem stuff
REFERENCE - which analog reference to use. see analog.h for choices
*/
#define REFERENCE REFERENCE_AVCC

what should i be doing to it to make it work?]]> Phoenixblack Firmware - experimental, borrowed, and future Fri, 24 Feb 2012 07:45:32 -0500 https://reprap.org/forum/read.php?147,71989,105245#msg-105245 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,105245#msg-105245
I believe you are interpreting what he is saying wrong. He is saying the settings in ReplicatorG effect how its buttons work. If his or Benjacksons RepG is used things work fine, but if you use the stock RepG it does not output an E code when you push the extrude button but rather DC extruder code.]]> Sublime Firmware - experimental, borrowed, and future Tue, 08 Nov 2011 12:55:12 -0500 https://reprap.org/forum/read.php?147,71989,105163#msg-105163 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,105163#msg-105163 Traumflug Firmware - experimental, borrowed, and future Tue, 08 Nov 2011 03:52:53 -0500 https://reprap.org/forum/read.php?147,71989,105066#msg-105066 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,105066#msg-105066 -------------------------------------------------------
> It's a software problem.
>
> Really? Teacup turns X, Y and E either all on or
> all off. Slightly different handling for Z, which
> is enabled when moved, only. So, PC software isn't
> involved here.
>
> To me this sounds like a misconfigured
> E_ENABLE_PIN or E_INVERT_ENABLE. Also: updating to
> the latest sources is always a good idea, if not
> done already. The default templates change from
> time to time to reflect code updates, so
> re-comparison between config.h and
> config.ramps-1.2.h is required.


Sorry I should have been more clear: it's a software problem with Replicatorg, not Teacup. There was a bug in the code for the control panel when the machine uses any variant of the Replicatorg RepRap driver.]]> Pointedstick Firmware - experimental, borrowed, and future Mon, 07 Nov 2011 11:30:47 -0500 https://reprap.org/forum/read.php?147,71989,105019#msg-105019 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,105019#msg-105019
Quote

It's a software problem.

Really? Teacup turns X, Y and E either all on or all off. Slightly different handling for Z, which is enabled when moved, only. So, PC software isn't involved here.

To me this sounds like a misconfigured E_ENABLE_PIN or E_INVERT_ENABLE. Also: updating to the latest sources is always a good idea, if not done already. The default templates change from time to time to reflect code updates, so re-comparison between config.h and config.ramps-1.2.h is required.]]> Traumflug Firmware - experimental, borrowed, and future Mon, 07 Nov 2011 03:03:44 -0500 https://reprap.org/forum/read.php?147,71989,104980#msg-104980 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,104980#msg-104980 bassman Firmware - experimental, borrowed, and future Sun, 06 Nov 2011 17:45:34 -0500 https://reprap.org/forum/read.php?147,71989,104952#msg-104952 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,104952#msg-104952 -------------------------------------------------------
> I am building a Prusa Mendel with Arduino Mega
> 1280 (clone), RAMPS 1.2, teacup firmware and, at
> the moment ReplicatorG software as this is the
> only one I seem to be able to get working reliably
> on my Macbook Pro OSX 10.6. Teacup is built with
> standard RAMPS 1.2 config file.
>
> The X, Y, and Z axes are moving OK from the
> ReplicatorG control panel (jogging) but I can't
> get the extruder to move. It seems as though there
> is no power to the extruder motor as it will turn
> easily by hand when main power is on while all
> other motors are locked. I have swapped the Pololu
> drivers about to confirm that there is no problem
> there and have swapped the X-axis and extruder
> motors over to confirm its not a motor problem. I
> don't yet have the limit switches or thermocouple
> and heater wired in - one step at a time...
>
> I have built a couple of cnc machines running on
> EMC before with home built electronics but this is
> my first foray into Arduinos and so I don't really
> know whether I have an electronic problem or just
> a lack of knowledge on driving the software...
>
> Is it just me or do I have a problem - if so,
> where?
>
> Thanks, Ian


It's a software problem. I've fixed this and it should be better in the next released Replicatorg version. In the meantime, this should help you: [www.thingiverse.com]

In short, remove the "stepper_axis" var in the extruder definition in your reprap.xml file.]]> Pointedstick Firmware - experimental, borrowed, and future Sun, 06 Nov 2011 14:23:43 -0500 https://reprap.org/forum/read.php?147,71989,104929#msg-104929 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,104929#msg-104929
The X, Y, and Z axes are moving OK from the ReplicatorG control panel (jogging) but I can't get the extruder to move. It seems as though there is no power to the extruder motor as it will turn easily by hand when main power is on while all other motors are locked. I have swapped the Pololu drivers about to confirm that there is no problem there and have swapped the X-axis and extruder motors over to confirm its not a motor problem. I don't yet have the limit switches or thermocouple and heater wired in - one step at a time...

I have built a couple of cnc machines running on EMC before with home built electronics but this is my first foray into Arduinos and so I don't really know whether I have an electronic problem or just a lack of knowledge on driving the software...

Is it just me or do I have a problem - if so, where?

Thanks, Ian]]> bassman Firmware - experimental, borrowed, and future Sun, 06 Nov 2011 08:47:05 -0500 https://reprap.org/forum/read.php?147,71989,97070#msg-97070 Re: Teacup Firmware https://reprap.org/forum/read.php?147,71989,97070#msg-97070 mikey Firmware - experimental, borrowed, and future Thu, 08 Sep 2011 00:32:06 -0400 https://reprap.org/forum/read.php?147,71989,95273#msg-95273 Re: Teacup Firmware https://reprap.org/forum/read.php?147,71989,95273#msg-95273 Triffid_Hunter Firmware - experimental, borrowed, and future Wed, 24 Aug 2011 11:01:23 -0400 https://reprap.org/forum/read.php?147,71989,95267#msg-95267 Teacup Firmware https://reprap.org/forum/read.php?147,71989,95267#msg-95267 Kilo6 Firmware - experimental, borrowed, and future Wed, 24 Aug 2011 10:14:40 -0400 https://reprap.org/forum/read.php?147,71989,88088#msg-88088 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88088#msg-88088 -------------------------------------------------------
> /config.h:479:2: error: #error this config is
> marginally, and may be incorrect! please post in
> forum or via git any corrections

So comment that line, and tell us which bits need changing : p]]> Triffid_Hunter Firmware - experimental, borrowed, and future Thu, 23 Jun 2011 00:51:06 -0400 https://reprap.org/forum/read.php?147,71989,88017#msg-88017 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88017#msg-88017 -------------------------------------------------------
> yes teacup runs on gen3 with acceleration.
>
> ReplicatorG has issues interpreting the returned
> serial data, so does reprap host and repsnapper.
> Kliment's pronterface seems to work nicely
> though.
>
> We don't have LCD support, but I do plan on adding
> it at some point. Now that I have a mega, I have
> enough I/O to hook one up and have a

I have my system set up this way kinda, except I'm not using gen3 board but more of a ramps style modular set up.
The drivers are polulo and I designed my own heater/thermister module as well as end stop module(still on my breadboard :-/)

All this is connected to a mega 2560.
I added an LCD via I2C. The LCD has a arduino tiny which does the display code and interrupts the signal from the I2c line.
It basically just gives me a temp graph which is invaluable.

I use skeinforge 41 open it it replicatorG and output to teacup firmware. I have an lcd wired into]]> Architect Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 08:21:11 -0400 https://reprap.org/forum/read.php?147,71989,88008#msg-88008 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88008#msg-88008
getting error












In file included from /analog.h:15,
from analog.c:1:
/config.h:479:2: error: #error this config is marginally, and may be incorrect! please post in forum or via git any corrections
In file included from /temp.h:4,
from analog.c:7:
/config.h:479:2: error: #error this config is marginally, and may be incorrect! please post in forum or via git any corrections
In file included from /temp.h:18,
from analog.c:7:
/config.h:479:2: error: #error this config is marginally, and may be incorrect! please post in forum or via git any corrections
In file included from analog.c:22:
/config.h:479:2: error: #error this config is marginally, and may be incorrect! please post in forum or via git any corrections]]> karandex Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 06:21:22 -0400 https://reprap.org/forum/read.php?147,71989,88006#msg-88006 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88006#msg-88006 You could always tell your gcode generator to use tool 0...

copying config.gen3.h is probably better, as you can then diff or revert vs your altered config.h. renaming or moving won't hur anything though.]]> Triffid_Hunter Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 06:17:11 -0400 https://reprap.org/forum/read.php?147,71989,88005#msg-88005 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88005#msg-88005
Copy config.h.dist or config.yourboardhere.h to the config.h file.

should i rename the config.gen3 to config.h or should i copy (not replace) contents of config.gen3 to config.h]]> karandex Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 06:11:27 -0400 https://reprap.org/forum/read.php?147,71989,88004#msg-88004 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,88004#msg-88004
in my gcode this line give me error
T1M6
its on start so i have to replce them by

G21
G90

every time, is there solution that it wont consider t1m6 ?]]> karandex Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 06:09:12 -0400 https://reprap.org/forum/read.php?147,71989,87998#msg-87998 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,87998#msg-87998
As for E axis, it's just another axis. if your gcode never says to move it, it may as well not exist as far as firmware is concerned.]]> Triffid_Hunter Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 05:42:19 -0400 https://reprap.org/forum/read.php?147,71989,87996#msg-87996 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,87996#msg-87996 karandex Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 05:34:15 -0400 https://reprap.org/forum/read.php?147,71989,87993#msg-87993 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,87993#msg-87993
ReplicatorG has issues interpreting the returned serial data, so does reprap host and repsnapper. Kliment's pronterface seems to work nicely though.

We don't have LCD support, but I do plan on adding it at some point. Now that I have a mega, I have enough I/O to hook one up and have a play.]]> Triffid_Hunter Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 05:20:13 -0400 https://reprap.org/forum/read.php?147,71989,87989#msg-87989 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,87989#msg-87989 karandex Firmware - experimental, borrowed, and future Wed, 22 Jun 2011 05:14:35 -0400 https://reprap.org/forum/read.php?147,71989,85224#msg-85224 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,85224#msg-85224 -------------------------------------------------------
> Just a question: i would like to add a lcd display
> to my electronics, and i was thinking to use the
> i2c port for this. Could it be possible to move
> the extruder motor communications in the intercom
> protocol? in that way we could free the 2 i2c pins
> and use them for other things..
> I could try to come out with an implementation..

you can use any spare pins you like, just edit your config.h and adjust your electronics to suit.

As far as LCDs go, if you're determined to run it from the main processor, I'd suggest adding a couple of new files (one for lcd library and the other for actual display format and data), and add a hook into clock.c. This might be a good time to make the functions in sersendf and sermsg a little more abstract, perhaps using avr-libc's FILE io system.]]> Triffid_Hunter Firmware - experimental, borrowed, and future Sun, 29 May 2011 23:00:39 -0400 https://reprap.org/forum/read.php?147,71989,85216#msg-85216 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,85216#msg-85216 -------------------------------------------------------
> the gen3 motherboard actually uses the 644p's
> USART1 for rs422 whereas the ftdi connects to
> USART0. It has two different usarts. So of course
> hooking your debug rig to USART0 then trying to
> talk via USART1 isn't having any effect!

Thanks Triffid for all the answers. I'm happy to say that i've been able to solve all my problems, and now motherboard and extruder communicate well. I was forced to use BANG_BANG because the extruder firmware froze in one of the eeprom calls, if you want i can try to debug better. Maybe is some problem in my extruder board..

When i have a bit of time i want to clean all the debug code that i inserted and keep only the actual code changes, and produce a patch to send to you. You will then evaluate if you think it's correct to include that code.

For now bye, and thanks again for the help in troubleshooting.

Just a question: i would like to add a lcd display to my electronics, and i was thinking to use the i2c port for this. Could it be possible to move the extruder motor communications in the intercom protocol? in that way we could free the 2 i2c pins and use them for other things..
I could try to come out with an implementation..]]> hariseldon78 Firmware - experimental, borrowed, and future Sun, 29 May 2011 20:08:37 -0400 https://reprap.org/forum/read.php?147,71989,85185#msg-85185 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,85185#msg-85185 -------------------------------------------------------
> Here's a little video of my mendel doing a print.
> [www.youtube.com]
> The gcode was generated with skeinforge 40.
> Retraction speed is set at 50 and retraction
> distance at 2mm. The firmware has
> E_STARTSTOP_STEPS set to 0. The retraction seems
> very clunky with long pauses. Setting retraction
> distance to 0 removes the stuttering but,
> obviously, causes the strings to reappear.
>
> What's 'best practice' for retraction in Teacup?
> Should I be using E_STARTSTOP_STEPS in conjunction
> with skeinforge retraction?


Turn off retraction in skeinforge entirely and don't use ozzebane either. Next set your max Maximum_E_feedrate to the fastest speed you can run your extruder at. Then set your E_STARTSTOP_STEPS to say 50 for normal extruder 200 for a bowden. The firmware will reverse every time it goes from an extruding move to a non-extruding move and add it to the start of the next extruding move.

I have heard that it does not work with acceleration disabled.

Skeinforge retraction and firmware retraction conflict so do not try and use both.]]> Sublime Firmware - experimental, borrowed, and future Sun, 29 May 2011 13:58:03 -0400 https://reprap.org/forum/read.php?147,71989,85177#msg-85177 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,85177#msg-85177 www.youtube.com]
The gcode was generated with skeinforge 40. Retraction speed is set at 50 and retraction distance at 2mm. The firmware has E_STARTSTOP_STEPS set to 0. The retraction seems very clunky with long pauses. Setting retraction distance to 0 removes the stuttering but, obviously, causes the strings to reappear.

What's 'best practice' for retraction in Teacup? Should I be using E_STARTSTOP_STEPS in conjunction with skeinforge retraction?]]> sliptonic Firmware - experimental, borrowed, and future Sun, 29 May 2011 10:45:26 -0400 https://reprap.org/forum/read.php?147,71989,84585#msg-84585 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,84585#msg-84585 Triffid_Hunter Firmware - experimental, borrowed, and future Sun, 22 May 2011 23:16:53 -0400 https://reprap.org/forum/read.php?147,71989,84551#msg-84551 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,84551#msg-84551
googling about the TXD high issue i found this command:

UCSR0B=0;

This let the user change the values of RXD and TXD pins. In fact if i put it in the initialization of the extruder code I am able to communicate from one board to the other by listening using the RXD and TXD pins on the extruder, and RXD1 and TXD1 pins on the motherboard.

But, if i insert that command in the init() of the extruder, and use the standard teacup code (not my debug modes) the boards are still not communicating. I suppose that the problem could be in the motherboard using incorrectly the RXD and TXD pins, instead of the RXD1 and TXD1 ones.
Anyway, i am not being able to find the used pins because grepping RXD and TXD in the teacup code gives no result. Probably they are used with binary bitwise operators, which i still have problems to decipher.

I'm sorry but now i cannot believe that anybody has got the intercom code working with Motherboard 1.2 and Extruder controller 2.2. If there is someone around please speak up so we can fix my problems or the code problems.]]> hariseldon78 Firmware - experimental, borrowed, and future Sun, 22 May 2011 11:41:30 -0400 https://reprap.org/forum/read.php?147,71989,84548#msg-84548 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,84548#msg-84548 -------------------------------------------------------
> If you have to disconnect half of the differential
> serial bus for communication to work, there's
> something wrong with your electronics!

I thought the same, but the more i debug, the more i think that it is a software problem. Now i'll explain why.

> That's some pretty invasive debug code you've
> generated there, kudos for keeping it simple.

maybe when the debug code is good enough we could insert it into the default teacup distribution, i think other people could be in my same situation. (All the people who buy from grrf for example..)

> Might I suggest in your RX debug, you test whether
> the correct data was received, and flash
> differently or something so you can see if the
> data is being corrupted?

ATM it is only a 1 / 0 debug, so corruption problems are more high level..

> Access to an oscilloscope or logic analyser would
> be ideal for sorting this out

I don't have any of them, but i am doing all i can with a precise autoranging multimeter. I'm very happy to have spent those 60 €!

Back to the troubleshooting: i think i am coming down to the source of the problem. In the extruder board i use this debug code:

//initialization code
WRITE(TX_ENABLE_PIN,1);
WRITE(RX_ENABLE_PIN,1);
SET_OUTPUT(TX_ENABLE_PIN);
SET_OUTPUT(RX_ENABLE_PIN);
SET_OUTPUT(TXD);
for( ; ; ){
WRITE(TXD,1);
WRITE(DEBUG_LED, 1);
delay_ms(30000);
WRITE(TXD,0);
WRITE(DEBUG_LED, 0);
delay_ms(30000);
}

i tried it with various initialization codes:
1) init();
//all the usual teacup initializations,

2) intercom_init();
io_init();
//a small subset, without interrupts enabling etc..

3) enable_transmit();

4) init();
enable_transmit();

5) //nothing

From what i understand the RXD and TXD pins are the same pin used by the ftdi cable to upload the program into the 168. I am able to upload without any problem, so i deduce they are not dead pins. Please correct me where i'm wrong.
So:
-i upload the program
-i disconnect the ftdi cable
-i connect the RS485 cable but with the A and B cables disconnected (i sacrificed an ethernet cable by adding some leds and jumpers.. But i tested it extensively, so i know it is not source of problems.)
-i use my multimeter with black lead on the GND coming from the RS485 and the red one on the TXD pin. I tested with the TXD pin on the ftdi connection, and the one on the sn75176b chip.

Result: the TXD pin is ALWAYS HIGH. Always at 5.00 V perfect and never changing. So the WRITE(TXD,0) command don't have any effect.

To summarize my foundings:
a) the TXD and RXD pins are NOT DEAD
b) the SET_OUTPUT(TXD);WRITE(TXD,0); commands have NO EFFECT

Is there any explanation to this behaviour? Maybe the chip has some "serial mode" activated (to be able to flash the program) that prevent the manipulation of TXD and RXD pins by the user?]]> hariseldon78 Firmware - experimental, borrowed, and future Sun, 22 May 2011 09:20:32 -0400 https://reprap.org/forum/read.php?147,71989,84538#msg-84538 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,84538#msg-84538
Actually it's adopted for RAMPS and i have previously made some changes to test the communication, so it's a more chaotic configuration ...]]> VDX Firmware - experimental, borrowed, and future Sun, 22 May 2011 04:07:35 -0400 https://reprap.org/forum/read.php?147,71989,84530#msg-84530 Re: Teacup Firmware replicatorG & Skeinforge https://reprap.org/forum/read.php?147,71989,84530#msg-84530
That's some pretty invasive debug code you've generated there, kudos for keeping it simple. Might I suggest in your RX debug, you test whether the correct data was received, and flash differently or something so you can see if the data is being corrupted?

Access to an oscilloscope or logic analyser would be ideal for sorting this out]]> Triffid_Hunter Firmware - experimental, borrowed, and future Sat, 21 May 2011 22:25:12 -0400