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.

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.

Smoothieware v1 firmware

{:/nomarkdown}

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:

Most active development has shifted to Smoothieware v2. See the v2 section below for current focus areas.

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. {::nomarkdown}

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.

This improvement has been fully implemented in Smoothieware v2, with a maximum step rate of 200 kHz (vs 100 kHz in v1), supporting up to 1/256 microstepping with interpolation, and configurable pulse width. The v2 firmware enables advanced features like true S-curve acceleration planning and parallel motor support.

</sl-alert> {:/nomarkdown}

S-curve acceleration Jim Morris is planning on implementing 7th order acceleration into Smoothie. {::nomarkdown}

See Jerk-Controlled Motion Explained for an explanation of what this is.

See also this proposed implementation: 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.

S-curve acceleration is planned for Smoothieware v2 but has not yet been implemented. The v2 motion planner currently uses junction deviation-based planning with configurable xy and z junction deviation values. Future work is expected to build on the improved step generation foundation in v2 to implement true S-curve motion control.

</sl-alert> {:/nomarkdown}

{::nomarkdown} 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 : recursive. 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.

{:/nomarkdown}

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. {::nomarkdown}

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 : 6-axis support This is now in current edge.

Smoothieware v2 maintains support for multiple kinematics (Cartesian, Linear Delta, Rotary Delta, CoreXY, CoreXZ, SCARA) with configurable axis control. Full 6-axis XYZABC support is supported through the Extruder module configuration, leveraging the improved step generation in v2. However, dedicated ABC axis support as distinct motion types (vs extruder-based) is still a potential enhancement for future versions.

</sl-alert> {:/nomarkdown}

{::nomarkdown} 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 PanelDue support. 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 : File-based panel system 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 : Support mixing nozzles and 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 : Fix thermocouple SPI problem 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 : Extruder JKN advance 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 : 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 occurrences 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 consistent 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.

Smoothieware v2 firmware

{:/nomarkdown}

Smoothieware v2 is the firmware for the Smoothieboard 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.

Core features are now fully implemented including serial communication, configuration, motion planning, step generation, temperature control, USB, Ethernet, and SD card support. The firmware is actively maintained and improved with new features like lathe threading (G33), StealthChop2 silent steppers, OTA updates, dual motor support, and enhanced display drivers.

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: [Smoothie2 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](mailto:wolf.arthur@gmail.com), we really need help on these. USB Like the v1 board, the v2 board has a USB port. {::nomarkdown}

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.

The v2 board implements USB with dual ports: USB Device (for serial CDC/ACM and mass storage MSC with improved safety via pushbutton/command mode selection) and USB Host via a dedicated USB-A connector (J2, not yet firmware-implemented). MTP (Media Transfer Protocol) support is planned as a future enhancement for safer SD card access and virtual file presentation, but is not yet implemented.

Besides simply implementing basic Serial/USB (CDC) functionality, we’d like the firmware to support MTP: Media Transfer Protocol. That’d be a much safer way for the computer to access the card. </sl-alert> {:/nomarkdown}

Ethernet The v1 board has an Ethernet port, the v2 board too. {::nomarkdown}

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.

Ethernet has been fully implemented in Smoothieware v2 with significant improvements over v1. The v2 firmware includes FreeRTOS+TCP stack (vs v1’s uIP), HTTP web interface (hosted on SD), Telnet access for remote G-code sending, SFTP file transfer, NTP time synchronization, auto-update capability over the network, and mDNS hostname resolution (smoothieboard.local). The 10/100 Mbps interface provides fast network control and file management.

If you have know-how related to this, please help! :) </sl-alert> {:/nomarkdown}

SD card {::nomarkdown}

SD card support in v1 uses SPI interface with typical speeds of 400-500 KB/s, which has been a common user complaint about slow file loading.

SD card support in v2 is fully implemented with SDIO interface, providing 10-25 MB/s typical speeds (20-50× faster than v1). The v2 firmware supports standard microSD cards up to 32 GB (FAT32 formatted) and includes a pre-loaded SD card with firmware and configuration. Cards can hold G-code files, web interface files, documentation, and logs, with operations including boot configuration, runtime G-code playback, direct computer access via MSD mode, and network access via HTTP/SFTP. Adam Green did initial work on this: SDCard

</sl-alert> {:/nomarkdown}

## Smoothie2 hardware [Mark Cooper](https://github.com/logxen) 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](mailto:wolf.arthur@gmail.com). Other projects related to the v2 hardware: {::nomarkdown} 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 ).

We plan to have a very varied set of 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: Extension boards

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: Infinite extruders Kliment Yanev ( of Pronterface and Teacup fame ) is currently working on this.

Any help welcome!

Documentation

The Smoothieware website contains all documentation for Smoothie firmware and Smoothieboard hardware.

Improvements to documentation are always welcome, and you can help by editing pages to make them clearer, adding new content, or fixing errors.

See Editing the Wiki for information on how to contribute to the documentation.

This is a wiki! If you'd like to improve this page, you can edit it on GitHub.