Project: Teacup Firmware

Quote
paula
Teacup seems to be oriented toward the more experienced users which is unfortunate because there are significant advantages over other firmware and it would benefit mainstream big time.

It's as simple as we, the developers, can think of without giving up the small size. Other firmwares make everything configurable at runtime, which allows to require firmware uploads for upgrades, only, but that's not easier (one still has to configure and upload a file) and whould also bloat the binary considerably.

But yes, we expect one is allowed to run Python. Same prerequisites as Pronterface.

Before the editing the post you mentioned Make.exe, so you apparently run Windows. This explains things a bit. The situation is similar to controller hardware: most Open Source developers, including me, run some Linux variant, while most non-developing users run Windows.

Quote
paula
If I make headway getting this to compile it might be a good idea to start another thread "Teacup for Dummies"

If you can think of finding ways to build even easier (or more precisely: more reliable), I'm all for it. Ideally implemeted as an application or written into the RepRap wiki.

Quote
paula
BTW it's strange as you said config-wrapper.h is found

The error message above says so. It complains about an #include in config_wrapper.h, so it did read config_wrapper.h.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
paula
BTW it's strange as you said config-wrapper.h is found when referenced directly but generates errors accessed through those "attic" files. I suppose it could be a bug in the IDE but other packages that are far bigger compile fine. More likely I suspect a problem with code. For example sometimes the difference between quotes and <> wreaks havoc when referencing include files. I hope I can resolve these issues one way or another before end of school year which is funding deadline.

None of the "attic" files should be compiled. They are placed in the attic to keep them handy for reference but on a shelf where they will not be compiled. Maybe your Arduino IDE is recursively searching and compiling all the source it can find. What version is your IDE?

The quick fix for this is to delete the subfolders of the Teacup project which contain *.c files and try the build again. (I think these would be attic, simulator, extruder, and research). Do not delete all the subfolders. You will need the "config" folder, for example.

The Arduino IDE is always doing silly things like this. It doesn't have any rules, it seems. Instead it is a random collection of things someone thought to try out. The "things" change from version to version as the developers find out why their experiment was a bad idea.

Quote
phord
The quick fix for this is to delete the subfolders of the Teacup project which contain *.c files and try the build again. (I think these would be attic, simulator, extruder, and research).

Deleting folders made no sense to me at all but it does compile without errors now. I was expecting a lot more errors instead of fewer but surprise-surprise. I will try downloading to 2560/RAMPS as soon as I get access. To answer your question it is 1.6.7 which is one of the latest. I must agree there is a big element of chaos and insanity to Arduino but it has become a defacto toolset standard and by some miracle manages to make a complicated process ridiculously easy. Usually.

Quote
Traumflug
Before the editing the post you mentioned Make.exe, so you apparently run Windows.

Yes, that should have been obvious from my first post and then the attachments. I was surprised to see that Make.exe is deleted from the latest Arduino packages. This also makes it impossible to compile bootloaders now too. What goes through those guys heads?

Quote
Traumflug
If you can think of finding ways to build even easier (or more precisely: more reliable), I'm all for it. Ideally implemeted as an application or written into the RepRap wiki.

I'm not sure about "easier" because apparently Configtools does accomp[lish that for many. Maybe a line about deleting the folders for those who might want the procedure to more closely resemble that of Marlin. It is considerably more popular and what people are used to.



In any case huge progress. Thanks guys. I will keep you tuned in.

Quote
paula
Deleting folders made no sense to me at all but it does compile without errors now.

OMG, so it does look into subfolders now. Half a year ago I tried to seperate out CPU-specific stuff into subfolders and failed miserably, because Arduino 1.0.5 ignored these files. *sigh*

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I updated the wiki, it's #4: [reprap.org]

Well catched, @phord!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yes, phord has saved the day. I've discovered you can delete ALL directories if you copy the board and printer files out in the open. Like phord said any without .c which includes them all (or should I say NOT include ).

I have received confirmation of somebody else who was having trouble compiling ok now. Next step to see if the Geeetech hardware behaves. Then strip pins down to the minimum 25 and finally see if it can be ported to Mega328. Things are looking up.

when i started to play with Teacup and Arduino IDE, i had to copy my config files (board and printer) to the root of firmware source code and change paths to them inside config.h generated by configtool, to eliminate those pesky errors.

due to arduino-ide quirks, it's more-or-less usable on windows this way only. i also renamed .pda file to a .ino file with the name of directory.
after i did so, i had no problem with firmware compiling except of my own origin.
And i even could use Configtool after that.

I must admit there's not much more effort needed to compile teacup in this particular environment, than any marlin flavour. And considering Configtool - it's even easier to configure initially than any marlin flavour. First time i did successful marlin firmware upload after week-long of googleing and trying (thank god for long holidays).

Marlin took me about 5 minutes to get running, most of which was download time. No file editing or configuration required to get a test cube printed. The only tuning was later on to turn down some A4988 pots for quieter operation. I did have previous experience with downloading the blink program which might account for our difference.

For hundreds if not thousands of 3d printer users it's simply a matter of unzipping and running the ino file. This is the standard method used by millions of Arduino users. Maybe those who are new to that environment have a hard time but that's hard to believe. The concept of editing a config file is common for many applications unrelated to 3d printers too. Maybe Configtool does make the tuning procedures easier but I know of at least a handful of others besides me who were thrown off by the need for additional programs and language runtime packages. People tend to have an easier time with things they are familiar with. YMMV

Quote
paula
No file editing or configuration required to get a test cube printed.

Then you were simply in luck to have a printer and a controller sufficiently compatible with Marlins default settings. With dozens of different controllers, different stepper drivers, different microstepping settings, different printer mechanics, different extruders, different thermistors, that's the exception.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Actually it wasn't luck so much as hard work from those generous souls who took time to configure, tune, and distribute firmware packages for the popular printer setups (thanks Rippa and Dboy). Fortunately an ad hoc standard seems to be emerging in these low cost kits from China (ie Geetech, Tarantuala, Sintron, etc). Leave it up to the Chinese to cut to the chase and boil down to economical, efficient, and available common denominator parts out of the previous Tower of Babel. Even domestic producers like Folger seem to be stepping in line and I hope the trend continues. Judging by local enthusiasts I estimate 90% or more of new builds seem to follow this basic i3 architecture.

Very good for the scratch build DIY crowd too. I have designed a unit that is up and running with parts so far totaling under $100 that couple years ago would have cost 5x -10x that in parts. Improved performance to boot. In fact if I can get this Mega328 part implemented and a few other ideas work out then all up may come in under $60. Obviously Teacup plays a key role here.

Three have been built so far, two by me and one by a friend and soon maybe a dozen or so others from local Makerspace. PLA results are quite good and soon I may give that spool of styrene I have kicking around a try.

How can one build a $60 printer if one can barely get four steppers for that price?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

New Chinese NEMA17 almost always available on Ebay for $8-$10 or much higher quality Matsushita etc refurbs for $5-$7 range. Last month me and a pal each picked up 5 for $35 shipped and that's WITH pulleys and hardware(see attached snapshot). Even cheaper bid or b.o. and of course generally from Aliexpress always 25%-30% lower because with no Paypal or Ebay fee. Another area not worth skimping is hotend where complete ready to bolt on Bowden E3D type with teflon feed and fan for $5-$7. Same goes for all other critical parts. Of course buying 5 or 10 at at time instead of just one cuts cost about in half. Bargains are there if you are open to them. Granted 99% of buyers are unaware or simply too snobby to hunt deals.

However most of the cost cutting is a result of design considerations. For example you really only need 2 not 4 (or 5). I've just had success replacing 3 of the $10 type NEMA17 with a couple $1 geared steppers. You really don't need speed for e and z so those work a treat there. Same 5mm shaft. Also using a couple 10 cent plastic crown gears means one instead of two z steppers. Replacing RAMPS with wire and an IRLB3034 knocks a few more bucks off. It's down to $82 actual expenditure so far and not done yet. Still plenty room for improvement.



ps. Is there an easy way to make attached pics show up as photos? I made several attempts w/o success.
pps. Nevermind. I see now that create button does it by itself.

Edited 10 time(s). Last edit at 02/04/2016 11:37PM by paula.

Quote
paula
For example you really only need 2 not 4 (or 5). I've just had success replacing 3 of the $10 type NEMA17 with a couple $1 geared steppers.

Well done! At that point you most likely have a different steps/mm and you need to do configuration, a one-size-fits-all firmware no longer matches.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks. You are definitely right about configuration. Days of ready-to-go settings are long gone. As mentioned that worked for getting started with standard commercial printer kits but after the test cube stage life was not so simple. As you hint things do get a lot more tricky when we deviate into experimental setups. I suspect there will be another level of trial and error associated with different software like Teacup too. Let's see how things go this weekend when I try this stuff out on actual hardware.

Hi, I'm trying to get the delta branch configured. So far, I cloned the Git repo and switched branch to delta. But when I open configtool.py, delta kinematics is not listed on the selection (only options available are straight and coreXY). Furthermore, printer .h config file for delta variant does not exist. Do I have to make my own printer configuration file, or did I dp something wrong when branching the cloned repo?

Thanks in advance!

Quote
rollingdice
Do I have to make my own printer configuration file

Yes. The delta branch was made when Configtool was still very young and that particular developer didn't entirely trust it. There's a file config.ramps-v1.3.h which contains all possible settings. Well, AFAIK. In doubt, looking through the commits of June 7th should tell how all this stuff was meant to work: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Alright then. Thanks for your quick reply.

Edit: I have another question, what's the differences between delta and delta-temporal?

Edited 1 time(s). Last edit at 02/11/2016 03:01AM by rollingdice.

Okay, I got it compiled for Mega2560 with some help from Cygwin and avr-gcc 4.9.2. Anyway, is there a way to adjust endstop offset via software, just like in Repetier firmware? My printer doesn't have adjustable endstop.

Looks like the Delta-tree should have M666.
[github.com]

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
rollingdice
Anyway, is there a way to adjust endstop offset via software, just like in Repetier firmware? My printer doesn't have adjustable endstop.

As Teacup is used for printers as well as for milling machines, we couldn't agree on the ideal solution, yet. There are commits like these: [github.com] and if you want to tackle this, you're welcome.

Until this changes, send a G92 after homing. G92 sets where the print head actually is, so if your endstop is 2 mm outside the print area in negative X direction, send a G92 X-2.00. A following G0 X0 will move the head to the edge of the print area, then.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi Traumflug, on a Delta you need to set the endstops exactly, as it's important for calibration. There you need an offset to the endstop. Not for the X, Y or Z-Position.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
on a Delta you need to set the endstops exactly, as it's important for calibration.

OK, so this calibration math has to take such an offset into account. Code welcome, I have a large backlog (display, STM port review, I2C support, etc.) already, so no boredom here.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

As I've said. Code is already in the delta-branch. [github.com]

As for the STM port, I'm stucking at the ADC. But I think I will solve this soon(tm).

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
As I've said. Code is already in the delta-branch. [github.com]

As for the STM port, I'm stucking at the ADC. But I think I will solve this soon(tm).

Thanks, didn't notice that before.
I've compiled Teacup with ATmega328p CPU option, compilation report says that it uses 74% RAM.
This is gonna be good

Okay, got it running on Mega 2560 + RAMPS 1.4. Tested M666 command, reply from printer was "Bad M-code". Then I checked out the source, found out that M666 response was commented in gcode_process.c.
I tried to solve it by uncommenting them, but then error occured in compiling with message "undeclared delta_radius in gcode_process.c". The I declared it in dda.h, on the same line where endstop adjustment variables declared.
Now it compiles perfectly. Let's see M666 in action.

One more thing, is it possible to set tower angle correction on this firmware?

Edit: M666 is running good, but the settings does not persist between reboot despite EECONFIG being defined in my config.h.

Edited 1 time(s). Last edit at 02/20/2016 10:44PM by rollingdice.

Delta support in Teacup isn't complete, yet. If you happen to find out which parts work and which not, I'd be glad if the working parts could be forwarded to the experimental branch. I have no such hardware, so I can only guess.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

If you write code, please try to follow the Teacup strategy. Teacup doesn't do configuration via M-codes, but with #defines. The value of these #defines is set in Configtool (or via editing printer.xxx.h until the corresponding fields appear in Configtool). This makes the firmware smaller and faster and is also the reason why there is almost no support for EEPROM. Some controllers, like the ARM Cortex-M0, don't even have an EEPROM.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
If you write code, please try to follow the Teacup strategy. Teacup doesn't do configuration via M-codes, but with #defines. The value of these #defines is set in Configtool (or via editing printer.xxx.h until the corresponding fields appear in Configtool). This makes the firmware smaller and faster and is also the reason why there is almost no support for EEPROM. Some controllers, like the ARM Cortex-M0, don't even have an EEPROM.

I see. But since the current configtool does not support delta kinematics configuration, user need to set the values matching their printer's configuration in config.xxx.h. When they've done with the calibration, they need to re-edit the .h file, recompile, and reupload. For another user, these steps might look less straightforward as they need to setup arduino, disconnect the printer from Repetier-Host or Pronterface or whatever software they use, load the sketch, and so on. I think it's less time-consuming if you could enter calibration value via M-codes.

And about EEPROM support, this is where EECONFIG flag comes useful. I think I can modify the the g-code processor to store the values if that flag is defined. I'll try to make it as clean as possible.

Edited 1 time(s). Last edit at 02/21/2016 10:41AM by rollingdice.

Quote
rollingdice
But since the current configtool does not support delta kinematics configuration.

Adding such support is entirely possible. One can even add calibration procedures there; Configtool knows how to talk to the printer, so it's possible to send G-code and read back results. Which means, one can drop the need for Pronterface/Repetier/whatever during calibration, one can add guides, help texts, custom calculators, all such stuff.

Quote
rollingdice
For another user, these steps might look less straightforward as they need to setup arduino, disconnect the printer from Repetier-Host or Pronterface or whatever software they use, load the sketch, and so on. I think it's less time-consuming if you could enter calibration value via M-codes.

Marlin went this way and you can see the result. Making Teacup a Marlin clone is a bit pointless, it'd end up as the same bloated code. There should be better, more efficient procedures.

That said, using Arduino IDE for compilation/uploading isn't recommended, this IDE is a can of worms for more sophisticated projects like Teacup. Configtool should do the same much faster and more convenient.

Hmmm. I'd like to encourage you to find more convenient ways than this calibration chaos around Marlin/Repetier. Not sure wether this answer was a good one in this regard.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
rollingdice
For another user, these steps might look less straightforward as they need to setup arduino, disconnect the printer from Repetier-Host or Pronterface or whatever software they use, load the sketch, and so on. I think it's less time-consuming if you could enter calibration value via M-codes.

Marlin went this way and you can see the result. Making Teacup a Marlin clone is a bit pointless, it'd end up as the same bloated code. There should be better, more efficient procedures.

In the last month I think more and more about Teacup and I'm with you at the most points. Teacup has much less M-Codes and this makes it much easier to handle. But some codes for calibrating and things need to change while printing, could be necessary.

For example, filament diameter can change while printing and it could be needed to change the flow (or e-steps).

I've took a look into the attic folder and I think EEPROM is a really clean way to handle most cases. But we should take a lot of care to not blow Teacup up. For example, 256 code should be more than enough and I see no need to go to uint16 or more.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.