The Smoothie project's TODO list

This page lists all of the projects the community is working on, and those that are planned.

This includes improvements on the existing, new features, refactors, new hardware and documentation efforts.

If you are looking to help the project, but do not know where to start, this is the place to get an idea what is going on within the project right now.

Contributing

If you have an idea for a new feature or any kind of improvement, please contact the community via IRC or the mailing lists to discuss it. You can also contact wolf.arthur@gmail.com with any questions or to chat about implementation details.

You likely also want to read the following pages : coding-standards, contribution-guidlines, developers-guide and github.

The Smoothieware firmware that runs on the Smoothieboard v1 ( Smoothieware v1 ) has a lot of features, and has received a lot of love over the years. But there are many things we want to improve, and new features we want to implement or experiment with :

Step generation improvements

Jim Morris is working on several improvements on the step generation in Smoothie, including removing on_gcode_execute and doing acceleration every step instead of on a fixed clock as we do now, as well as many other small changes.

This is expected to result in a much saner codebase, smoothness/performance improvements, and to make it easier to implement some new features, like S-curve acceleration, 6-axis support and some extruder features. This is going to require, amongst other things, a massive rewrite of the Extrude and Laser modules.

This is also possibly going to solve the problem Simplify3D and Smoothie have with each other.

Update : This was merged into edge beginning of July 2016, and is now being tested by the community in the wild.

S-curve acceleration

Jim Morris is planning on implementing 7th order acceleration into Smoothie.

See https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained for an explanation of what this is.

See also this proposed implementation: https://github.com/PymZoR/S-curve-Planner

Also, there has been some discussions of implementing a PNP-specific planner, that would loose axis sync ( not required on Pick and Place machines ), but thanks to this simplifying it a lot, would then be much easier to implement S-curve for.

Recursive file playing

This new feature would allow users to call the play command from within currently playing files.

Not only would it be convenient, it'd also make it much easier to implement macros and tool changing routines.

The current status of this work can be seen at : https://github.com/Smoothieware/Smoothieware/compare/recursive?expand=1

New debug commands

One feature that's been requested and that would be neat to have in some situations, is a “pin” command, allowing you to set/read any pin, even if it's not defined in a switch. This would not be meant for “normal” day-to-day use (you have switch for this), but would save some time/effort when debugging some hardware or config issues.

This Arduino sketch could be good inspiration.

6-axis support

Once the step generation improvements and s-curve support have been implemented, it will be much easier to add proper 6-axis ( XYZABC ) support into Smoothie. This is currently done by using the Extruder module, which has some limitations, doing it properly would be a good improvement.

This issue keeps track of that feature : https://github.com/Smoothieware/Smoothieware/issues/120

This is now in current edge

PanelDue support

Chris Brent is working on implementing support for the Paneldue into Smoothie ( specifically the M408 G-code, which will also be useful for web interface projects ).

You can follow the progress at https://github.com/Smoothieware/Smoothieware/pull/798

Soft endstops

Soft endstops is a feature in which the machine is aware of it's physical limits, and does not go past these, without the need for a physical switch to actually detect this.

This feature is more complex to implement than what one might think, and the need to actually implement it “cleanly” and discussion on how to do so, has delayed actual coding work on it.

A proposed implementation is described here.

If you want to help with this, don't hesitate to ping the community.

File-based panel system

There is a project to explore using files on the SD card to describe the panel menu system, instead of using code.

This would allow for multi-language, user customization, richer menus with more options, and new features.

However, it's not clear yet if this would be fast enough to be comfortable to use, and it's not possible to use files while a file on the SD card is playing, so that is a problem that would need to be solved ( possibly by having a separate, simpler system while playing files ).

You can see a specification for this new idea here : https://is.gd/VlsYq3

Jarek SzczepaÅski is currently looking into implementing this, but any help is very very welcome.

Support mixing nozzles

Mixing hotends like the Diamond, require extruding using several different extruders at the same time, which Smoothie doesn't know how to do yet.

There is discussion of implementing this in this issue : https://github.com/Smoothieware/Smoothieware/issues/875 and https://github.com/digiexchris is working on implementing it.

Fix thermocouple SPI problem

There is a problem in Smoothie right now where SPI thermocouple boards is called in interrupts, when it shouldn't. Amongst other things it prevents using several thermocouple boards at the same time.

Grey Christoforo has worked on fixing the issue here : https://github.com/Smoothieware/Smoothieware/pull/891 but his work needs testing. If you have a Max31855 thermocouple board, please test his work so it can be merged !

Extruder JKN advance

Extruder advance is a technique of managing the pressure of the extruder relative to the head's motion so that the plastic is more regularly applied to the part.

You can see some talk of implementing it in Smoothie here for example : https://github.com/Smoothieware/Smoothieware/issues/645

Several persons have written implementations, but they were too complex to be merged. The work on step generation ( per-step accel, s-curve, 6-axis etc ) will involve some refactors that would then make this simpler to implement.

If you are interested in helping with this, don't hesitate to ping us.

Queue refactor

There is a planned refactoring ( or at least an exploration to see if it would be practical ) of the “queue” system in Smoothie, that would make the code saner, would use less ram, and would allow for more performance/new features.

You can read about it at : http://smoothieware.org/queue-refactor

It is likely this will not be tried before a lot of other things happen ( including Smoothie2 firmware ) because it would change a lot of things in the firmware. It is also possible we will move step by step towards this, at least for part of it ( Jim Morris already started this by removing occurences of on_gcode_execute ).

NOTE this is no longer required after the motion control merge. It basically is not an issue now.

Tool changing

There is some work that needs to be done in order to properly support automated tool changing.

Arthur is planning on working on this sometime around July 2016. Any help is extremely welcome.

A first step towards tool changing is to implement recursive file playing. Work on that is ongoing here.

Serial chaining

This would allow forwarding of Gcode strings to other Smoothieboards over serial, therefore allowing use of boards as “slaves”. This would be a very powerful tool. The specification is available here If you want to help with this, don't hesitate to contact us

LUA scripting

Lua is a very simple programming language. It's quite commonly used to add “scripting” support to applications. An idea that has been floating around ( for v2 Smoothie ) would be to experiment with ( we don't know if it's possible ) adding a LUA interpreter to Smoothie. It'd have to be simple enough that it doesn't take too much RAM, but if it were made to work, it'd add the ability to create scripts that Smoothie would trigger when it receives specific Gcodes, or when specific internal events occur. Those scripts could check for variables, send Gcodes internally, activate external peripherals etc. This would be an extremely powerful tool, but we don't know if it's feasible, and would like to find out.

New error reporting system

We are working on a new system to report errors in a more consistant and useful manner, see the specification here.

Additionally, a complete list of all firmware errors has been drafted, and the page along with a bit of javascript magic, is intended to allow the firmware to link ( via short-form links ) directly to complete documentation about any error that just occurred ( as well as to log said errors, also in short-form manner ).

M1 support

Support for a Gcode that pauses until user input. User input can be a button or a Gcode. We possibly only need a Gcode, since a button can then be created with Switch.

( note this might be partially supported, just with M600 instead ).

Panel baby steps

Add a panel-based tool to do micro-adjustments to the Z height live.

Smoothie2 is a port of the Smoothieware firmware to the Smoothieboard v2 hardware. Second update on v2 hardware

Basic functions such as serial communication, configuration, planning and step generation, have been ported, but many others like temperature control, USB, Ethernet, SD card support, etc, are still missing. We need your help moving the project forward.

Many have already offered to help, and at this point, several are at the point where they have hardware to work on, and are starting to get familiar with the codebase. But this is a huge project, and here more is better ! So come join the effort :)

You can find a list of the things to do for this project in the ReadMe : https://github.com/Smoothieware/Smoothie2/blob/master/README.md

Below are a few of the ones that need the most work. Because these are difficult to implement, it's hard finding people to work on them. If you think you are capable of doing any of those, please please please contact us, we really need help on these.

USB

Like the v1 board, the v2 board will have a USB port.

On the v1 board, that port exposes a composite device ( Serial + Mass storage ) to the host computer. However, Mass Storage just plain sucks. The computer can mess things up anytime without the board being able to prevent it, the board can't safely write to it's own SD card, corruption of the card is a common thing, etc.

Besides simply implementing basic Serial/USB ( CDC ) functionality, which would already be awesome, we'd like the firmware to support MTP : https://en.wikipedia.org/wiki/Media_Transfer_Protocol

That'd be a much safer way for the computer to access the card, it'd allow the board to have control, write to the SD card itself ( which would allow for implementation of many new features ), present virtual files, etc.

But implementing MTP is a really huge task. If you think you could do this, please please contact us. There are even some companies likely ready to pay some money for this to encourage implementation.

Ethernet

The v1 board has an Ethernet port, the v2 board too. We need Ethernet, TCP/IP, a web and telnet server, to be implemented in the v2 firmware, the same way it was on the v1.

I ( Arthur ) have no idea how much work it'd be. There is a few implementations of web servers for LPC4337 available on the net, so it may simply be a matter of mashing that together with the v1 implementation.

The v1 Ethernet implementation has some limitations and problems, it's possible with the better v2 hardware, a better implementation could be done.

If you have know-how related to this, please help ! :)

SD card

Adam Green is already working on this : https://github.com/adamgreen/SDCard

Thank you so much Adam Green!

If you want to help with this, I believe testing can help greatly.

Mark Cooper is designing the Smoothieboard v2, v2-pro, and v2-mini boards, in Kicad, so that is pretty much covered for now.

The boards are now in alpha, once the alpha board has been tested, a beta board will be designed, and the files for it will be published. At that time we'll need help reviewing the design. If you are interested, contact us.

Other projects related to the v2 hardware :

Extension boards

The Smoothie firmware is trying very hard to be as modular as possible, and to make it easy to do weird things. In v2, we want to make the hardware even more modular/hackable than it already is.

To do this, we plan on having a set of standard connectors ( based on the gadgeteer pinout ) :

» –> <img src=“/_mediaexternal/http.files.channel9.msdn.com.wlwimages.1932b237046e4743a4e79e6800c0220f.image.5b2.5d.3.png” class=“img-responsive center-block” undefined> </html>

and a very varied set and extension boards that'd plug easily into those connectors, for a very large variety of sensors, actuators, and peripherals.

You can find more information on this project at this link : https://plus.google.com/+ArthurWolf/posts/GPF7hSGQiew

We are looking for help with this, if you know PCB design, you are very welcome to contribute, most extension boards are quite easy to design.

Infinite extruders

There is a project to create a system of chainable boards that would connect to a Smoothieboard v2. You would be able to chain as many as you want, and each board would control a separate tool. We plan on implementing several different tools, but the first one that is currently being worked on is the Extruder board.

You can find the specification for this project here : https://is.gd/peaDqc

Kliment Yanev ( of Pronterface and Teacup fame ) is currently working on this. Any help welcome !

Preview : http://i.imgur.com/TFH1bHX.png

The http://smoothieware.org website, which contains the documentation for the project, is a wiki. This means you can edit any page to add information or make it clearer.

Help on the documentation is extremely welcome. We want the best documentation possible. The documentation is extremely complete, compared to what is common in the community, but there are plenty of things that are missing still, and probably even more important, there are parts of the documentation that need to be made clearer.

Graphics, diagrams, and videos, are also very welcome.

A few documentation-related projects you might be interested in :

Bouni makes very nice Smoothie graphics.
Anthony made a very complete definition file for the configuration options for use in software : https://github.com/arthurwolf/fabrica/pull/4

Video tutorials

We are working on synopses for a series of tutorial videos : https://github.com/Smoothieware/Smoothie-video-tutorials . We hope maybe we can get Thomas to work on these at some point.

If you have an interest in helping with this, mostly by writing synopses for the videos ( graphics would also be useful once the synopses are further along ), please contact us, help is very much needed.

This is a great way of helping the project that does not require knowing how to code or how to design PCBs. Actually, having the point of view of a complete beginner is a good thing for this project, so everybody, pro or newbie, is extremely welcome to help. If you feel like Smooothie helped you, this is a great way of helping back.

Wiki

The Smoothie wiki has a todo list all of it's own, here it is :

Make a more «commercial» homepage and see if *this time* people don't complain about the doc not being on the homepage
Move the DNS from the old wiki to the new wiki
Make sure the forum still works
Do a guide for users coming from Repetier
Add smoke detector to warnings if missing
Document homing multiple axes in parallel with switch
Do a javascript warning redirect for people coming from bad pages
Document config.default
Update Editing the wiki
Document new mini OLED panels
Guides need a section on turning on/off power supplies
We want an actual servo page
Actually have a page for more of each thing in the switch page
Add more links to modules from the guides
Extruder wiring guide
Switch page needs improvement
Add example configs to more module, check all of them
Do example configuration section so users can post their configuration for standard machines
Add wiring notes for all 3 methods ( direct, open-drain, mosfet ) to the laser documentation
Do a pick and place guide
Add links to the datasheets for microcontrollers ( ex LPC1769 ) on pages where it would help like pinout, make a dokuwiki plugin to make this and other linking easier ( with options such as specifying page )
Add email to the “community and help” list, make it two column, add a contact page to the site
Add a donate link to each page, and to the download links
Figure out contributors to the wiki from the database, make a page thanking them
Remove all the weird AÀ characters from all the pages, presumably with a script
Fix all the broken images, possibly do a script to find all of them

Dokuwiki TODO:

Move email away from current postfix setup, and install dokuwiki SMTP plugin
Add Google and Facebook auth: https://www.dokuwiki.org/plugin:authgoogle and https://www.dokuwiki.org/plugin:authfacebook
Set the blog back up from the old pages: https://www.dokuwiki.org/plugin:blog
Auto-generate ( on a regular basis ) PDF guides from the main “machine” guides: https://www.dokuwiki.org/plugin:bookcreator
Do backups on top of the current whole-site backups: https://www.dokuwiki.org/plugin:backup
Some of the scripts might be helped by using https://www.dokuwiki.org/plugin:api
Use github plugin to embed configuration and other files: https://www.dokuwiki.org/plugin:gh
Create a Dokuwiki plugin that automatically displays Gcodes ( be it in code, key or otherwise ) as Monospace links to those Gcode's page ( maybe even with a tooltip ). This could actually be even more easily done as a javascript plugin for all pages.
Replace the code tags with config tags and have those display the config options properly, with links etc
Fix the /gallery page, in particular youtube embeds seem outdated

Deep Integration

Deep Integration refers to the idea of making the Wiki page interactive directly with the users' Smoothieboard, using the network interface.

As an example, say the documentation talks about using M119 to read the endstop's status.

A box on the side in the page will offer the user to do this interactively.

When clicked, if the user has never used this type of feature, a small/short wizard will offer the user the opportunity to enter the board's IP (additionally, ideally we'd also be, on every page/all the time, scanning the network to try to find this ourselves without any user interaction).

Once things are setup, the page will then be working directly with the board to make the user's life easier, for example displaying the status of the endstops live, or letting the user send commands and see the answer.

This could be used in *many* places on the wiki, and would completely change the way users interact with their boards. In particular the ability to change config options live like this would be a game changer.

( This is an extension of the older debug_vbb-is-getting-power-type choose-your-own-adventure troubleshooting guide idea, whose implementation was not completed )

Smoothieboard has an Ethernet port, and we have huge ambitions for it. The current web interface it serves is a bit limited. But there are several projects being worked on to replace it, and other ethernet-related projects within the community :

Better web UI

Jarek is working on an improved version of the current Smoothie web interface.

There is a plan to have the Smoothieboard auto-detect if an interface is present on the SD card, and display that if it is present. And also to start shipping this interface with the SD cards. This way we'd save on flash on the card, and we'd have a better web interface for users.

Fabrica

Fabrica is a project for a simple to use, panel-type GUI to control Smoothieboards. It's web-based, has very ambitious goals, and is intended to be used on android tablets or smartphones, which are about the same price as the current LCD screens, but are much better.

You can find more information on fabrica here : https://github.com/arthurwolf/fabrica , and any help is very welcome !

You can see what it looks like here : https://www.youtube.com/watch?v=XeQumaNShpM or try it here : http://arthurwolf.github.io/fabrica/

If you know any of these : web design, html, css, js, ux, gui design, graphic design, and want to help us make a kick-ass interface, please contact us :)

[[discontinued|]] - Smoothie-Happy ( Smoothie API )

Sebastien is working on an awesome, very complete API to talk to a Smothieboard over network from a web interface : https://github.com/lautr3k/Smoothie-Happy

You can see a demo here : https://lautr3k.github.io/smoothie-happy/dist/demo/ and documentation here: https://lautr3k.github.io/smoothie-happy/docs/

Contact him if you want to help.

Smoothie-Commands ( aka Smoothie-Happy v2 )

Onl'Fait is working on an awesome, very complete API to talk to a Smothieboard over network and serial from a web interface : https://github.com/onlfait/smoothie-commands

You can see a demo here : http://smoothie-commands.surge.sh/

Contact him if you want to help.

ESP8266 support

Liam Jackson is working on implementing a firmware for the ESP8266 that would make it behave exactly like the Ethernet port on the Smoothieboard, essentally adding Wifi support to the board transparently. Github repository. If you want to help, contact us.

Android App

Damien Flety is working on an Android app to control Smoothieboards : https://gitlab.com/damfle/SmoothieControl If you know Android and are interested, don't hesitate to ping him.

You can try the app on the play store : https://play.google.com/store/apps/details?id=com.siberiangoldfish.damfle.smoothiecontrol&hl=en

Visicut

Thomas Oster is working on adding support for Smoothieboard to visicut : http://hci.rwth-aachen.de/visicut

You can help by testing it with your Smoothieboard, reporting issues, or improving compatibility.

LaserWeb

Peter Van Der Walt is working on the awesome LaserWeb, which supports Smoothie : https://github.com/openhardwarecoza/LaserWeb3

It's a really great project, don't hesitate to help if you can.