G-Code Interpreter


I discovered this last night: https://github.com/zethra/rusty-print I think it would be great to combine efforts. Maybe @zethra could chime in? What I’d like to see would be a group of crates (or perhaps sub-crates within one repo) that implemented things like PID control, motion planning, gcode interpretation, fs, lcd interface, etc. Some kind of scripting interface would be nice as well, plugins could be written to support custom features, and could possibly simplify configuration, hopefully avoiding 123+ forks like Marlin.


Hmm, it looks like that repo no longer exists…

I totally agree with you there! Having a group of crates for doing common embedded tasks would be great.

I know @japaric has done a lot of work to make Rust a first class citizen in the embedded world (if you haven’t already, check out his Embedded in Rust blog!), so it’d be nice if we could build an ecosystem around what he’s already done.

Additionally there is the rust-embedded organisation which might be a good place to group these small commonly used crates.


Hello, thank you for the mention. That’s actually an old version of the project, this is current https://github.com/zethra/wasp.


That definitely sounds like an interesting proposal. Wasp is still in the early stages of development but it could be a good idea to break some of the functionality like PID control, motion planning into separate creates at some point. At the moment we are using @Michael-F-Bryan 's G-Code crate. Another design goal of wasp is to seperate the application logic from the hardware as much as possible. ATM wasp is a library that can be implemented on top of hardware. For now we are targeting the Teensy 3.2 because we could find a working library to interface with it. https://github.com/zethra/wasp_teensy32


Just stick a rams head in a rusty gear and call it “RAM”, Rusty Additive Manufacturing.

Is the WASP work pure-low-level, or is there any interest in using something like RTFM?


Oh nice! I wasn’t sure many people would end up using it so I haven’t put it up on crates.io (yet). Do you have any feature requests or things I can do to make it nicer to use?


The library largely does what we want, when we started work on this project a month ago we were very happy to find a working no_std gcode library had already been written, so thank you for that. The most notable thing missing is (last time I checked) N line numbers weren’t parsed out and I believe M70 isn’t handled properly. Besides that, it’d be nice if I didn’t need a bunch of large match statements to decided what to do with the output but I think that’s probably unavoidable.


maybe emmath? as embedded-math.


(I am working with @zethra on wasp)
@DanielJoyce Wasp is currently high level. We are working on hardware-rs as an abstraction for the low level hardware. This also lets us do fun things like make a simulator for wasp with a GUI. At the moment, there are not really any implementations of hardware-rs for real hardware.

One of the things we were going for with hardware-rs was compile time checking. By defining a list of available Pins on a hardware, then handing out mutable or immutable references to the pins to peripherals, the compiler will check that pins are not reused.


@zethra @chickenchuck040 I’d be happy to help wherever possible! I have multiple printers (a delta and various cartesians) and a couple of Teensy boards. I’ll try to set up a build environment for the Teensy in the next couple of days. Maybe I should put together a Dockerfile to make it easier for me and others to get up and running with development?


Sounds great, help is much appreciated. A Dockerfile would be useful; the requirements for building wasp on a teensy as described on the github page. If you have any trouble getting it to build We’d be happy to help.


You should check out @japaric’s embedded-hal project, which has similar goals to hardware-rs I think. Might pay off to try to reuse that API and adjust it as needed rather than start from scratch. Link: https://github.com/japaric/embedded-hal