Teacup Firmware replicatorG & Skeinforge

Architect Wrote:
-------------------------------------------------------
> AHHHHH! calibration cubes!!!! I am having
> nightmares with being attacked by cubes!!!
> Lol looks like we are about the same based on cube
> output. I get pretty good results from things that
> don't have many tight corners.
> But the corners if these dame cubes and also
> bridging is driving me nuts. I've gone from a-z
> with each setting so far. It's gotta be something
> I'm just not seeing.

Have a look at my bridge settings, I still get a little droop in the first layer of the bridge but it is minimal. I think it would benefit by having the bridge feed rate increased by another .05 . I would also look at the perimeter feed/flow settings vs the normal speed, if you've had to lower the perimeter feed/flow by more than 25% I would think the normal speed is to high. Lastly if your running the machine at the extruders firmware speed limit during normal printing it would be hard to increase the flow for bridging.

---

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

Hello teacup guys. First of all thanks to all the developers for this good piece of software.

Ok, here's my setup and problems:

I have got a mendel reprap from grrf. The electronics is gen3. I tried many times to use the standard Fived firmware and it never worked. I tried teacup and i was finally able to make it move. So now i know that all the motherboard connections are ok, the motors are ok, and the opto stoppers do works.

Now i want to make the extruder work. When i try to make it heat with ReplicatorG it do nothing, it doesn't either turn the power switch on. Obviously i am not sure that all the connections works, and i am not sure the configuration is correct. So i want to debug. I want to send a command from the terminal and see a feedback from the extruder firmware.
I am trying to insert some debug M-commands in the gcode_process.c file.

So the question is: is there any standard way to debug the extruder? Is there any way already in the code to receive feedback from the extruder firmware?

roby

hariseldon78 Wrote:
-------------------------------------------------------
> So the question is: is there any standard way to
> debug the extruder? Is there any way already in
> the code to receive feedback from the extruder
> firmware?

sure, install teacup on the extruder - the main firmware, not the stuff in the extruder folder!

You have to disable some features for it to fit, such as PID (turn on bang-bang), and perhaps shrink the movebuffer so there's enough ram (not that it matters if you're just testing extruder hardware)

I think traumflug knows more about '168 support status than me at this point, I upgraded my arduino to a '328 after a nasty incident with a short circuit and some 12v turned my 168 into glowing slag.

---

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

of course you can't leave it like that.. the protocol between the main board and the extruder doesn't resemble gcode in the slightest. As you've probably already found out it's a fairly simple packed struct packet protocol, basic debug would include pulsing a led when a valid packet is received on both boards, and then perhaps use M253 to dump the received packet data and see if it looks sane

---

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

Hmm. Yes, reducing the buffer queue size to 4 grants sufficient RAM on an '168 and if one comments out enough pins, like X_MIN, X_MAX, etc., binary size will eventually fit as well.

However, what whould you do with the main firmware on the extruder, other than sending G-Code back and forth?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> However, what whould you do with the main firmware
> on the extruder, other than sending G-Code back
> and forth?

A simple yes/no on heater and thermistor function

---

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

I tried to put the main firmware on the extruder board. It wasn't easy, i had to comment a lot of things.. Probably my understanding of the code is not enough.. The problem is that i couldn't keep both the intercom and the serial connection, don't know why. The compiler complained about a "vector_17" already defined..

Anyway, i decided to change approach. I restored the extruder firmware. In the motherboard i changed a bit the code in order to keep the power switch always on. This caused the extruder to finally stay on and sending pwm signal to the heater, which in fact reach a temperature of about 35 °C. (EDIT: measuring with a finger, the motherboard still report 0°C)
Then i changed the intercom packet struct, adding a "debug" byte. In the extruder i set the tx.packet.debug value to a known value, 222. Then in the motherboard i added an output of the rx.packet.debug value from one of the informative M-commands. It is always at 0, even after using M109 S120.0 or something like that..

So the problems seems to be that the 2 boards don't speak one to the other. maybe i have some dead pin. I would like to debug with a blink. Is it ok to use something like:

#define DEBUG_PIN 13

digitalWrite(DEBUG_PIN, 1);
delay(10);
digitalWrite(DEBUG_PIN, 0);

?
or does the delay command interfere with the interrupt system? sorry but i'm not too skilled in microchip programming..

EDIT:
I don't know why, but every time i insert that blink command the LED6 stop blinking and the heater stop heating. maybe the blink slow down too much the program?

Edited 2 time(s). Last edit at 05/16/2011 08:39PM by hariseldon78.

don't use delays in interrupts. It should be fine in the main loop.

If you have access to an oscilloscope it would be great to see what's happening on the serial lines.

Failing that, hook some leds with suitable resistors to the serial lines so you can at least see when data is being transferred.


I can't test the intercom code myself as I don't have gen3 electronics, but those who have worked on it report success so the code is known to work.

---

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

Ok, I have made some testing, and at least i have been able to get one board react to the other and viceversa, but in a very strange way.
I used the base Teacup code and changed the extruder.c and mendel.c to add some debug modes. You can find them as attachment.
In both config.h files i just add a line like this

/*
debug modes:

1 blink a led
2 debug RX (use 3 on other side)
3 debug TX (use 2 on other side)
4 debug SERIAL
5 debug TX modified

*/
#define DEBUG_MODE 1

The extruder don't have the serial mode.
Here is what i found:

The led blinking mode showed that the DEBUG_LED pin is DI013 and not AI05 so it must be changed in the arduino_168_328p.h files.

Now the most strange thing:
If i set DEBUG_MODE 2 in one board and 3 in the other i can see the two leds blinking synchronised only if i DISCONNECT (=cut the cable!) the A cable in the RS485 connection.
Even more strange is that if i use the mode 5 instead of 3 (in both ways) it still works, as long as i don't connect the A cable.

Needless to say, if i use the standard code, by not defining DEBUG_MODE, the boards don't communicate.

Can anybody help me to solve this misteries?

Who are the people who reported success on gen3 electronics? Could i have their email address so i can ask for info directly?

Edited 1 time(s). Last edit at 05/21/2011 04:44PM by hariseldon78.

... i'm working and developing with a Gen3-set from GRRF (identical to the original RRRF-specs).

I had the boards communicating with the first prototype until the firmware in the extruder brake down and i couldn't flash it again.

The replacement with a newer extruder controller won't run as i can't program it ... but i'll get the reprogrammed old board the next days, so it should run again.

Maybe your findings have to do with the not running communication with the newer board?

I'll see if i can test this - the next plan is to activate my RAMPS board ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Please, could you publish the two config.h files that you used when it worked? And if you made any customization to the code could you please publish them too? Thanks

If you have to disconnect half of the differential serial bus for communication to work, there's something wrong with your electronics!

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

---

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

... i'm waiting until the old board is here again and the configuration works, then post the files and changes.

Actually it's adopted for RAMPS and i have previously made some changes to test the communication, so it's a more chaotic configuration ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Triffid_Hunter Wrote:
-------------------------------------------------------
> 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?

Edited 4 time(s). Last edit at 05/22/2011 09:46AM by hariseldon78.

Another little step forward:

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.

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!

---

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

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?

sliptonic Wrote:
-------------------------------------------------------
> 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.

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> 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 Wrote:
-------------------------------------------------------
> 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.

---

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

have you guys managed to run teacup firmware on gen3 with acceleration and run it on replicaorg? Have you manged to add lcd and interfaceboard also ?

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 play.

---

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

the most ideal case will be, splinter firmware on gen3 or ramps with makerbots interfaceboard. that interface board is sweet. hey can any body make the teacup or splinter build for me with absolutely no extruder or heatbed code (but with acceleration). i need it for my cnc mill build, the problem is the gcode created by software like v carve or cambam have some code that gives error on replicaotorg. I tried teacup firmware using arduino ide on sanguino but it gives me bunch or errors. can somebody give me the edited build for it or instrucations. again there is noting extruder or heatbed on my cnc mill

just don't put any DEFINE_TEMP_SENSOR or DEFINE_HEATER lines in your config and it'll leave out all the sensor/heater code.

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.

---

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

i dont have e axis , just xyz. so i remove that line it will compile and dont consider any m code ?

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 ?

what does this mean in instructions

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

we don't have tool changing implemented yet, but the parser supports it. Teacup should accept T1 M6 but do nothing. What do you experience it doing?
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.

---

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

i renamed config.h.dist to config.h and copied config.gen3 to config.h

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> 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

karandex Wrote:
-------------------------------------------------------
> /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

---

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