smoothieware-website-v1

Basics

Smoothieboard

In its most basic form, the job of Smoothie is to receive G-code commands and translate those into actual movement for a robot.

This is done in several steps:

Now let’s get into more detail for each part:

GcodeDispatch

GcodeDispatch

It is interesting to note that here we are interested only in G-code commands, but the on_console_line_received event actually gets called with any new line, to any module that registered for it (see Kernel, Module and the Module example). This can, for example, be used to handle command-line-like instructions.

The Gcode object is just a wrapper around the actual string; it provides helper functions to retrieve values from that string.

Robot

Robot

Again here we are interested only in movement G-codes, but any module that registers for the on_gcode_received event will be called with that G-code and gets a chance to use it. Even this module (Robot) actually recognizes not only movement G-codes but also mode-changing G-codes (absolute/relative, inch/millimeter, etc.).

The Robot also converts the Cartesian coordinates (in the machine coordinate system) into actuator-specific coordinates; this transform is done in the arm solution, which takes machine coordinates and spits out actuator coordinates. In the case of a simple Cartesian mechanical system, this is a one-to-one transform.

The segment cutting part is a port of grbl, more specifically, chamnit’s ameliorations to edge.

Planner

Planner

Contrary to previous module-to-module transfer, we did not here use an event call/event handler. This is because the new line segment the Planner receives really only matters for the Planner, so an event call here would be superfluous. However, if you have a use case where plugging in here would make sense, just ask.

Again here, the math-heavy acceleration curves planning part is a port of grbl, more specifically, chamnit’s ameliorations to edge.

At the end here, we add the new Block to the queue. Now the goal of this is for the Stepper to use this Block and move the stepper motors according to it. But we don’t need to call the Stepper to tell it to step this Block: it is probably busy stepping a Block we previously added to the queue. We just push the Block to the top of the queue, and it will be executed by the Stepper when it reaches the bottom of the queue because all of the previous Blocks have been executed.

Stepper

Stepper

So the first, most important loop in the Stepper module is the stepping loop. It is the one that actually makes the stepper motor move. It also, if necessary, gets a new Block from the Planner’s queue when it has finished stepping the previous one.

This is the very speed-critical part of Smoothie: everything is done using integer math, and the speed here determines the maximum speed at which the robot can move. At the time of this writing, Smoothie is comfortable with stepping speeds of up to 110kHz, which is much higher than what most uses require.

The other loop is the acceleration loop. The work of the Planner is done for this loop: depending on where we are inside the current Block/line segment, it raises or lowers the current stepping speed (the speed of the previous loop), thus accelerating or decelerating.

If any of this is not clear enough or if you need precisions, please don’t hesitate to contact.