Project: Teacup Firmware

Quote
As hosts change often, and always without notice, such a list would be even less reliable.

Sure I agree, the usual technique for dealing with this is to publish a numbered release of your firmware and pick one hostware and version that definitely worked with it.

It will change for the next release but at least someone less skilled coming at this has the option to go with an older host/firmware combo that is likely to work.

I facilitate the Sheffield Reprap Users group and we have people within the group of varying skill levels. If we want to avoid discouraging the less able who are further down the learning curve than us I think a bit of helping folk get started would go a long way. Or at least avoiding misleading them.

Quote
I don't have an extruder yet, but PCB milling with terminal and XON/XOFF works reliably for thousands of lines of G-Code.

Ulp thats one up for my curious thoughts.

I am probably going to try to get similar working for an upcoming demo. Adrian is coming up to sheffield on march 28th to do a couple of talks and wants to loan some kit to demo and talk with. (all welcome)

It could be that this is the way to go and folk are advised to use Gcode files form host-ware they like.

A firmware without a compatible host ware for 3D printing though, is arguably a bit like a chocolate tea-pot.

Unfortunately (Unlike milling) 5D printing doesn't lend itself to hand coded G-Code files. Particularly as we don't currently support the programmatic Gcode constructs and stored programs within the firmware (Goto's and O codes).

macegr

The Teacup and replicator G topic within this firmware part of the forum is where there is a bit of discussion going on as to getting some stuff going and is perhaps worth a look. Architect over there is a mine of very useful suggestions and tips. Might be worth taking that one in too.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

PCB milling uses generated G-Code just like 3D printing.

Other than that, what's the particular issue now, aka47? Which hosts did you test, which ones fail and for which reasons do they fail? RepRap Host worked just fine half a year ago, but after Adrian stated he intentionally introduces incompatibilities just "to enforce developers to review their code over and over again", I gave up on keeping this compatibility. These days they release host and firmware only in pairs, obviously because RepRap host can't even deal with it's own firmware of a few weeks back.

Example: "Resend:" was changed to "resend:", then to "rs:" and perhaps something another in recent versions. Each of these changes resulted in a few angry disappointed users and of course Teacup was considered to be the faulty part each time. I don't want to blame anybody, but if people want faster and more reliable firmware, they should at least consider bugging host developers for their intentionally breaking/sloppy/useless changes as well.

Almost always incompatibilities are simple to fix, like an additional character required in the protocol. I'll gladly do the Teacup coding part. Please track the issues down to something like "Host expects 'XYZ', but Teacup delivers 'X,Y,Z'", I hope you don't expect me to do this for you.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

aka47 Wrote:
-------------------------------------------------------
> As a straw poll who reading here prints whole
> pieces successfully and using which host/slicing
> software to directly run the machinery ??

I printed dozens of part, one was quite big (250g ABS, 10h print, 200x200x15mm, 2.8MB gcode file).

OS: Win XP
slicer: Skeinforge 36
talker: send-gcode.exe
Electronics: standard Gen 3 with Extruder Controller v2.2
firmware: Teacup master, with attached patches (I didn't clean them up, just whats in my tree)
config: attached

Edited 1 time(s). Last edit at 03/19/2011 10:33AM by Markus Amsler.

hey markus, some of those patches look like they belong in master after a little cleanup

I've been trying to get repsnapper compiled, but it hates my system and keeps segfaulting. Apparently it doesn't talk to teacup too well. Anyone know what it expects vs what we're sending it?

---

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

my biggest changes to get repsnapper to work was the baud rate and start vr Start. also repsnappner sends neg. line numbers if it is gcode from the interactive tab. I think. other then that it works pretty good.

aka47 Wrote:
-------------------------------------------------------

> As a straw poll who reading here prints whole
> pieces successfully and using which host/slicing
> software to directly run the machinery ??

I have been printing whole parts for a few weeks now, which is partially why I haven't had much to say lately. I haven't upgraded teacup since I started printing for fear of breaking something that currently works for me. I think the commit I am on is from before the name change. I hope to try out the latest commit in the near future.

I am using skenforge 39 to slice the models and gtkterm to send the gcode to the printer. I have to modify the gcode generated by skeinforge slightly before sending it. It seems m101 or m103 causes the firmware to become unresponsive but I would like to test on the latest firmware before reporting it as a bug.

I really like the idea of using a serial terminal to send gcode because I am hoping that teacup with xon/xoff + openWRT router with usb port (which I already have) = networked reprap.

Just in case these words were missed in my previous posts :-

Quote
Teacup is great there is no doubt about it.

Quote
I intend to stay with teacup for a while,

Hey traumflug, if I have touched a nerve or in any place suggested other wise then I apologize.

I have tested repg24 with the current state of play for the teacup master branch, pulled down git wise and it don't work reliably. The issue looks to be one of protocol mismatch. All built and deployed on Ubuntu.

Looking at the results of the straw poll I am not seeing anyone succesfuly using any hostware to directly drive teacup.

This is not a criticism, simply an observed fact.

There are a number of RepRap compatible-ish hostwares available. Repsnapper, RepRap, ReplicatorG. Which one works with teacup I don't mind.

At the moment I guess I am looking for one to work, but actually am fairly agnostic as to which one. (Maybe even one I have'nt listed, or may not know about yet)

If none does (and it is starting to look a little bit that way, but I am more than happy for someone to tell me otherwise) then the route is perhaps to use a favored hostware to slice and turn out gcode then use the scripts or term software to drive the printer.

Personally I can handle this if that is the way it is. It will get me from A to B.

This being the situation I would have liked to know about it, without folk falling out with me, for asking.

It is cool, teacup is a work in progress and a most excellent one at that.

There are members of the Sheffield RepRap user group who are asking for my guidance as to the simplest way to get a tool chain up so that they can print reasonably seamlessly. Particularly their first object that gives them some confidence in their recently learned abilities and enables them to make it to the next screen.

For these folk I am gonna have to have a think about what advice I can offer. Many are not coders or linux users. For some it is the first time they have picked up a spanner or used a soldering iron. Working in a group together exchanging skills and learning on the job is how they climb up what is a very steep learning curve. They need most things to work reasonably easily at first but also to offer them the ability to dig into it as their capabilities increase.

So far having followed the great work that you have all been doing here for some time, I have been advocating teacup.

Although the situation that is becoming clear as we try to apply it, is that it is perhaps not the best choice for folk just starting out with their first machine who are low on the learning curve.

This is not a criticism of teacup, again I think teacup is great. For appropriately individuals it should be very high up on their list of choices.

My suggestion is that we lower the bar to entry.

In the mean time state what the situation is (again it is fine teacup is a most excellent work in progress) to save folk getting disillusioned, Maybe even invite folk to contribute solutions. (Solutions could reside in host-ware mods or firmware mods I am really not prescribing one over the other).

More than that I would like when sharing the results of testing and asking for help that this is accepted for what it is.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

spaztik Wrote:
-------------------------------------------------------
> It seems m101 or m103
> causes the firmware to become unresponsive but I
> would like to test on the latest firmware before
> reporting it as a bug.

m101 and m103 wait for temperatur, which is currently a bit buggy and may never happen. You can try to set the residency value in the config file to some high value.

Quote
Architect
my biggest changes to get repsnapper to work was the baud rate and start vr Start.

Just commited a lowercase "start". As I'm lazy for reviewing the last weeks of this thread: which baud rate does Repsnapper expect?

Quote

also repsnappner sends neg. line numbers if it is gcode from the interactive tab.

Does Teacup complain? A quick manual test showed negative line numbers are accepted just fine. Just resend requests won't work, because the number is stored unsigned.

Quote
aka47
Hey traumflug, if I have touched a nerve or in any place suggested other wise then I apologize.

No need to apologize, aka47. Just a bit steam to get the ship moving.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

As I'm lazy for reviewing the last weeks of this thread: which baud rate does Repsnapper expect?

Update on this part: a more recent version of Repsnapper apparently no longer has trouble with Teacup. Currently, there's only a binary Windows build: [www.kulitorum.com] . Anyways, a selectable baud rate will appear in config.h(.dist) soon.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yes, I just tried with master and gtk2 branches of RepSnapper, it worked. Just a ramps1.1 board, nothing attached. Config from the config.ramps.h, with changes from latest config.h.dist merged in.

Windows isn't abandoned, there just aren't any people around with windows building powers With version 2.0 (gtk2 branch) nightly builds for the three platforms are coming...

I'm on #repsnapper and #ProjectTeacup @freenode, can help with compatibility problems and installing on linux. Planning to use Teacup and repsnapper when I get my personal bot built, blocking on stepper drivers.

Also, for those wanting simple terminal gcode sending, I can recommend gcdump from [github.com]. It has cmake as a build time dep, but other than that, it will fit in any linux sytem. I can also help with this piece of software.

If someone can identify what was changed in RepSnapper that made it work with Teacup, please let me know...I have a working development setup of ReplicatorG.

Repsnapper did run Teacup pretty reliably. However, the STL>Gcode converter doesn't really work. Also, try to rotate a part...and laugh as it goes tumbling off the screen. Try to create a raft and then see your part's toolpath hovering 50mm above the build surface.

I want Repsnappers ability to talk to Teacup, combined with ReplicatorG's actual usable interface.

I pushed a big update last night, addition of doxygen style documentation. 'make doc' to build it, then point your browser at doc/html/

It still needs cleanup and polishing, tell me what you think

---

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

I rebased endstop branch against latest master, please test and help me get it ready for merging

also, please check out triffid.github.com/Teacup_Firmware where I have posted my local doxygen output. thanks github!

Edited 1 time(s). Last edit at 03/22/2011 02:24AM by Triffid_Hunter.

---

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

Here's a Teacup print. I've actually been trying to get something to print for a couple days (maybe 2 hours total work) and got only strange smears and blobs. One time I got a raft down and was pretty excited, until everything stalled for some reason. This print was the second one I tried using Skeinforge 40. I highly recommend using it for all reprap5d variants, because the stepper extrusion commands are now based on volumetric filament input instead of output length. With a little bit of calculation I got recognizable stuff on the first try.

So...there's still a lot of work to be done on the software end. I ended up NOT using Repsnapper, I may need to try again, but it kept stalling out (suddenly the toolhead would just sit there, clicking over by one step every second or two). It may have been something I changed in Skeinforge...I can test again, but it looked as if Teacup would crash if you gave it G1 E-0.0 (which happens when there is no reverse enabled).

But it seemed like ReplicatorG was MORE stable than Repsnapper at least when the print was underway. Here's my typical workflow:
1. Start up ReplicatorG, load prebaked Gcode from Skeinforge 40 (it's not integrated into repg yet)
2. Open machine control panel, set temperature, and either jog to home or RepG freezes and I kill java and restart
3. Repeat as necessary until toolhead is in the right position and zeroed (2-4 kill/restarts needed)
4. Start printing
5. When print is done, attempt to jog and RepG freezes, restart if you need to keep using it.

So, a lot of restarting ReplicatorG. It seems to be getting something, or not getting something, from Teacup that locks it up hard. Otherwise, when Skeinforge 40 is in, it'll be a perfect setup.

I also have a question about the acceleration method. It seems almost backwards. When the tool is moving a long enough distance to notice, it appears to start moving at the maximum speed, and slowly wind down to a stop at the end of the move, and then start on the next move with max speed. "BREEEEeeeeeooooo......." Is that just RepRap style acceleration? If so...yuck. No wonder people lose steps. Since the stepper axis is slaved to the toolhead motion, we should be able to play with smarter acceleration profiles. If we can figure out how to get reliable communications then maybe the next thing is lookahead. Accelerate UP to a speed sometimes. Maybe dial feedrate back if a lot of sudden motion reversals are ahead.

macegr, excellent news! Thanks for the photo, looks great!

As for the acceleration, that doesn't sound right... Reprap should smoothly scale speed from one move to the next, and ramping should start and finish every move at the same low speed, reaching a plateau at the supplied feed rate in the middle. Neither should start at a high speed and wind down over the course of a move, every move.

Which one is selected in your config? Personally I think ramping makes more sense, reprap tends to slam your steppers whenever direction changes between two moves, which is like 90% of the time.

I'm starting to get into the host software scene myself, to try and resolve some of the issues you report. Have you tried the gtk2 branch of repsnapper?

---

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

macegr Wrote:
-------------------------------------------------------

> So...there's still a lot of work to be done on the
> software end. I ended up NOT using Repsnapper, I
> may need to try again, but it kept stalling out
> (suddenly the toolhead would just sit there,
> clicking over by one step every second or two). It
> may have been something I changed in
> Skeinforge...I can test again, but it looked as if
> Teacup would crash if you gave it G1 E-0.0 (which
> happens when there is no reverse enabled).
>
Please test this in particular. This is bad behavior, which is probably easy to fix in Teacup, but could be fixed in skeinforge too. RepSnapper does some minimal transformation to the Gcode, but I don't think it should add any commands, just scale some lenghts (by a supposedly non zero factor). Please post the logs so this can be debugged, it should be a quick fix.

Quote

Is that just RepRap style acceleration?

Yupp, that is it, as designed. A movement like

G1 F100
G1 X10 F300

starts at 100 mm/min and ends at 300 mm/min, accelerating evenly. The idea is to split each path into a seperate acceleration, constant speed and deceleration part in the host. Like:

G1 F50
G1 X10 F500
G1 X90 F500
G1 X100 F50

So, for issueing single movements by hand ACCELERATION_REPRAP isn't a good fit. ACCELERATION_RAMPING is much better in this regard, as it does all three parts its self. Problem with ACCELERATION_RAMPING is, it stops after each movement, even if not neccessary. That slows down lots of short movements considerably.

Quote

No wonder people lose steps.

As some hosts have this three-part split implemented buggy (Skeinforge at least), you should set maximum speed to something the carriage can reach instantly. No problem with different max speeds for each axis, Teacup will handle it properly.

Quote

Maybe dial feedrate back if a lot of sudden motion reversals are ahead.

Look ahead ... now, if a firmware could do _that_, we'd have a major breakthrough.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
>> Maybe dial feedrate back if a lot of sudden motion
>> reversals are ahead.
>
> Look ahead ... now, if a firmware could do _that_,
> we'd have a major breakthrough.

well, we do have all the necessary information in the queue.. just need to work out how to decide when it's appropriate to do a bunch of trigonometry and on what bases to make the decision to alter host-provided flowrates.

The ultimate solution would be per-axis acceleration that somehow maintains geometry as well as giving less jitter than our current bresenham code. Altering flowrates based on look-ahead is a fine step towards this

---

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

Ok feedback

I have now built repg24 and repsnapper both under lucid ubuntu both 64 bit (laptop) and 32 bit (Desktop).

Since git fetching rebuilding and reloading the firmware I cannot get either hostwares to connect successfully to the firmware. Oh I generated a new set of thermistor values too using the python script.

I can see repg24 trying the resets and then timeing out.

Repsnapper does'nt seem to do the reset thing but returns connection attempt timed out in the communication log window.

This is the same for both 32 bit and 64 bit versions of ubuntu.

I have dropped the baud rate to 57600 by changing the baud rate constant at the top of serial.c

Just off to have a mess with direct connect and see what is being returned by the firmware.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Checking with cutecom serail comms is indeed running correctly at 57600.
The initialization string returned from the firmware is :-

Start
ok

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Interesting.

Although we were getting the initialization strings from the Firmware there was no response thereafter.

Having a thermistor LUT over a certain size (don't know what the critical size is) appears to crash the serial transmit and or firmware.

Having a Mega 1280/RAMPS setup I was not too worried about having a larger LUT and generated loads more values for the Extruder Thermistor.

Having changed it from the distribution LUT though I changed it back just on the off chance.

RepG24 and repsnapper now connects OK. and some degree of manual control works.

RepG24 has a habit of hanging as soon as you enable the extruder stepper and give it an RPM and instruct it to step forward.

RepG24 can be a bit flaky if you issue multiple manual moves, repsnapper sequences and completes them fine.

So not really intuitive but too big a Thermistor LUT screws with the firmware and the symptom is no return serial comms after an apparently successful power up and init string.


At the risk of appearing to suggest re-inventing the wheel or broadening the project beyond where folk want to go. I am wondering if there is'nt an opening to create a dumb host-ware app as part of the project, that uses the comms library to do manual control and diagnostics with the option to squirt a gcode file at the firmware, but that is it. No G-code generation etc. just a known good machine controller. Possibly even terminal/curses based so no gui. If folk wanted to do something more maybe G-code editing from the same app as an optional extra (spawning a chosen prefered editor). Perhaps to support this firmware only.

Just freewheeling/thinking-aloud a little on the last bit there....

---

Necessity hopefully becomes the absentee parent of successfully invented children.

but there is already a great one. in func.sh. I thought we suggested this already. since your using ubuntu just run the mendel_talk function in func.sh. theses days, i have to run mendel_setup then mendel_talk.

this gives you a command line interface directly to the firmware. very nice and very useful.

Yup I had found that, or use cute com or another such.

The draw back is that it requires the user to speak g-code.

A diagnostic MC (Machine Controller) would generate the standard G-code lines that we want to prove the firmware modifications against (bit like a menu driven test suite) for manual control. It would show what was sent to the machine, what was returned and idealy copy the bidirectional stream (on selection of a menu item) to a log file for posting excerpts etc back here.

The tester then would not have to be as clever as the developers in order to contribute to testing. They would also be able to use the tool as a known good item to pin back machine issues off the back of commissioning and testing a new build.

Commissioning is always helped by having a bunch of "Known Good" links in the chain.

I guess there is also traumflug's observation that it can over load a project trying to maintain compatibility with other projects (host wares) that are equally as likely to go their own way (that's open source).

Taking in that some folk here also do not want nor need 3d printing capability on every machine they build, Traumflug wants to use the firmware for 3D subtractive machinery. Host-ware that insists on packaging in the object slicing is arguably overkill.

There again it may be unwise or undesirable to extend this project with such an item. It could be better to run it up as a sister project etc. Or maybe on the other hand as you suggest not at all.

Overall what is driving my thinking (and by extension discussion, as it is only freewheeling ideas) is the concept of being able to present a pre sliced bunch of Gcode files to a low skilled newbie with a new build machine and for them to print them to gain confidence and prove the work they have done. Traumflug also has a point in that he isn't perhaps that interested (at the moment) in additive technologies.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

well...
not sure if its what you are suggesting. but next up on my development list is adding a joystick button controller like this one to my LCD screen circuit. this connects over I2C to my main board.
the game plan is to send the firmware direct gCode from the input of the joystick as well as output the coordinates to the LCD. of course this servers no real purpose if say Repsnapper or RepG is running on the host. but I would like control without having to run host applications to jog around the print head. is that what you mean by a MC? of course its not host based but its not firmware based either. :-)
Enjoy the day!

yeah pretty much a machine controller is something that controls the machine. As most don't have a console thingy.

Replicatorg and Repsnapper are examples of machine controlers that include the CAM (computer Aided Manufacturing) Layer of the design stack.

I guess I am thinking of a design stack here as CAD, CAM, Machine Controller, Machine.

If you take a look at CNC machine tooling (lathes, millers, borers, grinders etc) they tend to have a machine controller of of some capability or other attached (Sometimes it even looks built in) that allows the machinist to run stored procedures or manually drive the machine numerically rather than by turning the wheels and cranks etc.

The machine controller does not take or understand CAD output, just the code that runs the machine.

The CAM layer converts the CAD output (.STL) into something a machine can understand (G-Code). I am using G-Code here generically to include S, M, O and all the other letter grouped commands that are typically presented in a G-Code instruction sequence (Most of which are not implemented as yet in the reprap context).

The design stack can get a bit confusing as different implementations integrate different sequences of layers together. But they can all mostly be decomposed into relevant functions and bits. Correctly speaking it isn't called the design stack either it is CIM (Computer Integrated Manufacturing).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Maybe this is the machine controller you are looking for. It's based on HydraMMM's interface.

[www.contraptor.org]