Teacup Firmware replicatorG & Skeinforge

I had lowered the bridge feed to .65 It a multiplier so I figured that would slow it down to drop more plastic. I just finished swapping out my drivers for the z axis and E stepper. Got rid of the easystepprr drivers so I'm now running all 4 polulo drivers at 1/16 so now I need to recalibrate.

I found one thing that was creating issues for me in the stock replicatorg - whenever I printed or opened the control panel replicatorg locked up. it seems whenever replicatorg grabs a temperature reading it expects it in the form:

M105
ok
T:bla B:bla =this needs to be on its own line



Before Teacup would print out "ok T:bla B:bla" which replicatorg cannot parse (the parser is a little hairy)
Quick fix is to put a \n when we print out the temp - in temp.c
IE

sersendf_P(PSTR("\nT:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

After I did this I am printing without replicatorg-24 freezing on me at all!

Edited 4 time(s). Last edit at 04/17/2011 12:34PM by kiram9.

kiram9 Wrote:
-------------------------------------------------------
> I found one thing that was creating issues for me
> in the stock replicatorg - whenever I printed or
> opened the control panel replicatorg locked up. it
> seems whenever replicatorg grabs a temperature
> reading it expects it in the form:
> >M105
> > 2, c);
>
> After I did this I am printing without
> replicatorg-24 freezing on me at all!


Did you modify teacup or RepG?

Yup Nice prints Sublime. I hope I can get mine to be as good when I have got everything working.

Triffid Sir,

Re M6 T0, I wasn't aware either. It is what Skeinforge 39 is turning out though (Could be a makerbotism). Thanks for the tip I can probably use the replace csv thingy to change these.

Will fetch down Bens latest too.

Can't be far off now.

Most of the issues so far appear to be getting things to generate sensible G-Code (For teacup that is) and Host-ware stability. Through out most of this so far Teacup appears to have been very stable and consistently builds well.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Wow it was late last night and my post got mangled - I made the change to Teacup and didnt change Replicatorg at all... It seems easier to change teacup
See the edits above so you can actually read the post.... sorry everyone
I put a pull request to triffid_Hunter so hopefully it gets merged back into the main branch soon.

kiram9 Wrote:
-------------------------------------------------------
> Before Teacup would print out "ok T:bla B:bla"
> which replicatorg cannot parse (the parser is a
> little hairy)

It can parse that for temperature just fine. It looks like Erik de Bruijn fixed a bug in RepG in January where it would not see the "ok" part of that ("ok T" didn't count as "ok") which is what led to the lockup.

You should probably be trying my github branch: [github.com] which has many improvements to the driver Teacup uses. There are binaries at [ben.com] .

The newline version is also acceptable to RepG, but I think it's backwards: Any other firmware would print "T: ... \nok\n" (temperature, then "ok" the command). I know I rely on that order for M114 (although Teacup's M114 format is not currently supported).

--Ben

Hey Ben thanks for touching base here. I've been using your release sense your email a few weeks ago. We chatted a bit about it then. It's been very stable for me since. All except when my electronics are turned off. Really saved me alot of time and effort and put me well ahead of schedule for this project. I'm now getting useful prints with pretty reliable and repeatable results from repG. Thanks again.

just touching base. I've been side tracked by printing calibration cubes, skeinforge testing and learning openscad, all's going pretty well, my tolerances are within .25 mm as of now but I can not figure out bridging and getting a good top layer. I'm doing some more hardware work this weekend on my endstops. everything is completely modular with my electronics so far so I decided to build an end stop module board for the mins I was able to trace down and correct some more noise so that's all good. teacup and repG has been very stable for me over the last 3-4 weeks so I'm more on to other pieces of the chain. still lots to do thought before this is done, but I am printing nicely now and even took a quick design from thought to openscad to skeinforge to repG to teacup to finished piece last night. big big step. i'm smiling and encouraged to make more progress.

great to hear! keep up the good work

---

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

I've been running klimentkip firmware on my mendel but I wanted to try Teacup. I have most things working but I'm seeing two bits of oddness:

I'm using Ben's ReplicatorG and the bed temperature isn't showing in the control panel. Extruder temp is fine and if I issue a M105 (from repsnapper) I see both the bed and extruder temperatures reported back from the firmware. The same version of ReplicatorG works fine with klimentkip. Did I miss a configuration step someplace?

Second. Below is my start.gcode file. I'm turn the extruder and bed on first so they can be warming up during the homing routine. When it hits the M109 at line 14, it turns the extruder heater off and waits. My expectation is that since the extruder is warming up, it would leave it on and just wait for it to reach temp before moving on to the next line. This also works in klimentkip. Does teacup handle m109 differently?

(beginning of start.txt)
G21 (Metric FTW)
G90 (Absolute Positioning)
M104 S230 (preheat the extruder)
M140 S100 (preheat the bed)
G1 Z15 F70
G1 X-200 F800
G1 Y-200 F800
G92 X0 Y0
G1 Y75 F800
G1 Z-100 F70
G92 Z-2.35
G1 Z12 (Move to purge plate for warmup)
M109
G92 E0 (Reset extruder position)
G1 E5 F30(Extrude 500mm onto purge plate)
G1 E4 F300
G1 X0 Y150 F4000 (wipe)
G1 X20 Y150
G1 Z.2 F70
(G92 X0 Y0)
G92 E0 (Reset extruder again for print)
(end of start.txt)

Hmm I'm not using a heated bed yet so haven't seen the output from teacup for that. do you have debug on in the REPLICATORG machine.xml file so you can see the communications in the output window? you can set this then load the two different firmwares and see the different return values if you post that we can see pretty easily where the mistake may be.

sliptonic Wrote:
-------------------------------------------------------
> I'm using Ben's ReplicatorG and the bed
> temperature isn't showing in the control panel.
> Extruder temp is fine and if I issue a M105 (from
> repsnapper) I see both the bed and extruder
> temperatures reported back from the firmware. The
> same version of ReplicatorG works fine with
> klimentkip. Did I miss a configuration step
> someplace?

In reprap.xml in the machines folder of Bens repG did you change heatedplatform="false" to heatedplatform="true"

heatedplatform is set 'true' in the driver section.

The console output with debug on is this for klimentkip

INFO: Sending: N9 T0 M105 *74
Apr 28, 2011 5:54:05 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << t:35.00
Apr 28, 2011 5:54:05 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << ok t:35.00 b:35.00
Apr 28, 2011 5:54:05 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: FW Accepted: N9 T0 M105 *74
Apr 28, 2011 5:54:06 PM replicatorg.drivers.reprap.RepRap5DDriver _sendCommand
INFO: Sending: N10 T0 M105 *114
Apr 28, 2011 5:54:06 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << t:32.00
Apr 28, 2011 5:54:06 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << ok t:32.00 b:35.00
Apr 28, 2011 5:54:06 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: FW Accepted: N10 T0 M105 *114

This for teacup

INFO: FW Accepted: N9 T0 M105 *74
Apr 28, 2011 5:52:26 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << t:34.25 b:28.50
Apr 28, 2011 5:52:27 PM replicatorg.drivers.reprap.RepRap5DDriver _sendCommand
INFO: Sending: N10 T0 M105 *114
Apr 28, 2011 5:52:27 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << ok
Apr 28, 2011 5:52:27 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: FW Accepted: N10 T0 M105 *114
Apr 28, 2011 5:52:27 PM replicatorg.drivers.reprap.RepRap5DDriver serialByteReceivedEvent
INFO: << t:27.75 b:24.0

It looks like the bed temp is showing up in both log files. Can you set the temp in the control panel and have it heat up, and you are just not getting any feedback through the control panel?

In reprap.xml set your debug level to "2"
In repG's preferences turn debug to "all"

This will give a little more info from teacup at least.

Sublime Wrote:
-------------------------------------------------------
> Can you set the temp in the control
> panel and have it heat up, and you are just not
> getting any feedback through the control panel?

Yes. This is correct. Setting the temp will cause the heatbed to turn on. I haven't let it heat all the way up, but I assume it will stop at the target temp. Just no feedback in the control panel.


> In reprap.xml set your debug level to "2"
> In repG's preferences turn debug to "all"
>
> This will give a little more info from teacup at
> least.

I set up the debugging this way but I don't see any change to the output. The only thing that stands out to me is the leading 'ok' on the output line in klimentkip and on a separate line in teacup.

sliptonic Wrote:
-------------------------------------------------
> The only thing that
> stands out to me is the leading 'ok' on the output
> line in klimentkip and on a separate line in
> teacup.

Sounds like the latest commit of teacup (fixed temperature reading problem where ReplicatorG would freeze because there is no newline before the temperature prints out...) but if you read Ben Jacksons comment above it is not needed. I would try the previous one [github.com]

sliptonic Wrote:
-------------------------------------------------------
> I set up the debugging this way but I don't see
> any change to the output. The only thing that
> stands out to me is the leading 'ok' on the output
> line in klimentkip and on a separate line in
> teacup.

There's a tender irony in the fact that on the actual serial line, teacup puts the temperatures after 'ok' on the same line... either you're running a /very/ old version, or RepG's debug output is less than representative of what it's actually seeing.

> Second. Below is my start.gcode file. I'm turn the
> extruder and bed on first so they can be warming
> up during the homing routine. When it hits the
> M109 at line 14, it turns the extruder heater off and
> waits. My expectation is that since the extruder is
> warming up, it would leave it on and just wait for
> it to reach temp before moving on to the next line.
> This also works in klimentkip. Does teacup
> handle m109 differently?

Teacup expects a temperature with M109, since the command is 'set temp and wait'. If none is provided, it sets target temperature to zero then waits for the heater to reach zero!

Perhaps it would be more sensible to check if a temp has been provided? Try this:

--- gcode_process.c~    2011-04-26 20:55:01.000000000 +1000
+++ gcode_process.c     2011-04-29 10:03:35.000000000 +1000
@@ -363,7 +363,8 @@
 
                        // M109- set temp and wait
                        case 109:
-                               temp_set(next_target.P, next_target.S);
+                               if (next_target.seen_S)
+                                       temp_set(next_target.P, next_target.S);
                                if (next_target.S) {
                                        power_on();
                                        enable_heater();

Will commit the above soon

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> either you're
> running a /very/ old version, or RepG's debug
> output is less than representative of what it's
> actually seeing.

Or someone pushed a teacup patch to solve a RepG problem which was being fixed elsewhere.. If that patch is the issue, post and I'll reverse it

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> Triffid_Hunter Wrote:
> --------------------------------------------------
>..... If that
> patch is the issue, post and I'll reverse it


I tried this commit: [github.com]
and I get temperature readings for both the extruder and the bed.

I also tried your patch for the M109 issue and it no longer turns the extruder heater off, but it never comes back even when the temp is reached. I also tried it passing a target temp: M109 S220 and it also doesn't come back. The extruder reaches and holds at the target temp but never goes on.

Just out of a curiosity, Looking at the gcodes as defined on the wiki, it looks like the intent of M109 is to set the extruder temp and wait. Maybe I'm misusing M109 in this context and should be using M116. Is that implemented yet?

As for debugging, I'm running the latest commit from Ben's ReplicatorG with debugging set to ALL. Here's what shows in the output window:

[11:30:03] Building...
[11:30:03] Estimating build time...
[11:30:03] Loaded axis X: (Length: 205.0mm, max feedrate: 5000.0 mm/min, scale: 31.496 steps/mm)
[11:30:03] Loaded axis Y: (Length: 195.0mm, max feedrate: 5000.0 mm/min, scale: 31.496 steps/mm)
[11:30:03] Loaded axis Z: (Length: 140.0mm, max feedrate: 200.0 mm/min, scale: 1133.858 steps/mm)
[11:30:04] Estimated build time is: 27 minutes
[11:30:04] Beginning build.
[11:30:04] Machine state changed to BUILDING
[11:30:04] sending: N3 M114 *4
[11:30:04] Running warmup commands.
[11:30:04] Running build.
[11:30:04] sending: N4 G21 *62
[11:30:05] sending: N5 G90 *53
[11:30:05] sending: N6 M104 S230 *66
[11:30:05] sending: N7 M140 S100 *67
[11:30:05] sending: N8 G1 Z15.0 F70 *1
[11:30:05] sending: N9 G161 X0 *78
[11:30:05] Supports RC
[11:30:19] sending: N10 G161 Y0 *119
[11:30:20] sending: N11 G92 X0 Y0 *3
[11:30:20] sending: N12 G1 Y75.0 F800 *0
[11:30:20] sending: N13 G161 Z0 F70 *22
[11:30:50] sending: N14 G92 Z-3 *99
[11:30:50] sending: N15 G1 Z12.0 *91
[11:30:50] sending: N16 G92 E0 *80
[11:31:01] sending: N17 M109 S220 *126
[11:31:01] sending: N18 G1 E5 F30 *4
[11:31:01] sending: N19 G1 E4 F300 *52
[11:31:01] sending: N20 G1 X0.0 Y150.0 F4000 *93
[11:31:01] sending: N21 G1 X20.0 Y150.0 *12
[11:31:01] sending: N22 G1 Z0.2 F70 *15
[11:31:01] sending: N23 G92 E0 *86

yes M116 is implemented, however it should give the same behaviour as M109 with either that patch or a temperature specified.

What are your hysteresis and residency values set to? Basically, it should wait until the temperature has been within target +/- hysteresis for residency seconds so if it never quite reaches the set temp or you have some oscillation, you need to either increase your hysteresis or improve your PID parameters

---

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

I didn't know it did that - That means that if there's noise in your thermistor readings that vary the temp by more than the hysteresis amount, then M109 will never ever return.

Perhaps the default config should have a relatively high hysteresis setting? Like ±20° or so? Would that cause unneeded oscillation for those of us who don't have noisy thermistors?

---

--
I'm building it with Baling Wire

Triffid_Hunter Wrote:
-------------------------------------------------------
> yes M116 is implemented, however it should give
> the same behaviour as M109 with either that patch
> or a temperature specified.

M109 is only waiting on the extruder to reach temperature. M116 is supposed to wait on everything, no?

> What are your hysteresis and residency values set
> to? Basically, it should wait until the
> temperature has been within target +/- hysteresis
> for residency seconds so if it never quite reaches
> the set temp or you have some oscillation, you
> need to either increase your hysteresis or improve
> your PID parameters

Yes. This makes sense. I didn't think my thermistor was noisy but I had to set residency quite low (5 seconds) and increase temp_hysteresis to 8 but it works. I'm not sure a default of 60 for residency time is reasonable.

I'm just starting to play with skeinforge tuning in this config. I've been using SF40 but have seen posts saying to turn off firmware acceleration. Is that possible in Teacup? Any advice on general configuration certainly appreciated.

jgilmore Wrote:
----------------------------------------
> That means that if there's noise in your
> thermistor readings that vary the temp
> by more than the hysteresis amount,
> then M109 will never ever return.

that's true, however I see that as a tunable for the user to sort out. If the temp sensor has +/-5c noise (the default hysteresis) then we're not gonna get good prints since that's wider than the optimum temperature zone!

sliptonic Wrote:
----------------------------------------
> M109 is only waiting on the extruder
> to reach temperature. M116 is supposed
> to wait on everything, no?

perhaps, but they do the same in teacup. Any temp wait waits on all temperatures. Feel free to send me a pull request if this bugs you enough to sort it out

> I'm just starting to play with skeinforge
> tuning in this config. I've been using SF40
> but have seen posts saying to turn off
> firmware acceleration. Is that possible
> in Teacup? Any advice on general
> configuration certainly appreciated.

you can turn off acceleration if you like (define none of reprap, ramping and temporal), but I suspect that what those posts mean is to disable /reprap style/ acceleration which is a great idea- use ramping instead.

The ramping accel still needs a little work particularly in enforcing axis accel limits and properly calculating c0, but it's significantly better than both no accel and reprap accel.

With no accel, you're limited to whatever speed your motors can achieve within a couple of steps from a dead stop. With ramping, the host doesn't need to think about it but we can still achieve much higher speeds than no accel.

---

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

It seems that everyone is looking for some pre-configuration to start off with. I have created just such a thing for everyone to try. I was planning on releasing this information after all my testing was done, but due to a faulty pololu driver my machine is out of commission for a while.

I have written a quick over view of my settings here and have a down-loadable set of Skeinforge profiles and a ramps config file available with it.

Hope this helps and let me know if you find anything that needs to be changed ( I worked backwards to achieve some of the mendel values from my oddball configuration )

Edited 1 time(s). Last edit at 04/29/2011 09:18PM by Sublime.

---

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

Grrrr Help ya'll
I've spent the last few weeks working on various things (one of them being getting a new job) so I have not done anything specific but. through it all I've been tweaking skeinforge to get me the best output quality I can. I've been pretty happy with the results so far but I cannot for the life of me solve this problem no mater what I tweak. in the attached photo you will see a .5mm wall and corner. The blobbing in the corner is my problem. it seems that something is causing my machine to stop and wait for a split second at every corner and during this time it still puts pt plastic as well as melt the surrounding plastic downward and blob it. I'm using sk0einforge 39. with these settings for best results
w/t 2.1
layer height 3.0
flow-rate 35-40
feed-rate 65-70
temp (pla) 203

those seem to be the only contributing factors.
I also have ramping turned on for acceleration in teacup.

I had/have the same problem with blobby corners and the way I dealt with it was to use the fillet modifier to cut the corners slightly. I did it that way as opposed to using oozebane which allows you to stop your extruder before the corners because oozebane adds more lines of code which slows down the machine. I also have acceration set to 250000 from the original 500000 because of how slow it made circles and corners.

My settings are enabled and set to Bevel with a corner feed ratio of 1.5, fillet radius of 0.7


I printed this Prusa Mendel using the settings on my blog.

---

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

Thanks sublime, I had used fillet too. I'll check my settings to what you had posted here.
I also had ramping turned down to 175000 I just went through some calibration runs with it turned down to 75000. Man that sped up my machine. :-) lol but nothing worked out and I still had blobs on the corners. Just checked my fillet is 1.5 .35 radius and .5 reversal with using intermediate federate checked.

@Architect

Glad to hear we came to the same conclusion. I notice that my fillet radius is double that of yours and may be why mine look slightly less bulgy in the corners. I have not eliminated the blobs entirely either and I think the new acceleration algorithm they are working on should help with this. I also think that having my E_startstop_steps set to 10 may help, so something even higher may be the answer. I will do more testing once I get a new pololu driver. I will also have to try increasing/decreasing? the ramping speed now that I have a proper extruder printed (gregs accessible).

While printing 10mm cubes I was able to get the sides of the cube to 10.04mm

While the corners only bulged .5 making for a cube with a total size of 10.14mm

Close up under microscope.


Edited 1 time(s). Last edit at 05/01/2011 08:27PM by Sublime.

---

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

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.