Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
queue-refactor [2017/01/25 18:55] arthur |
queue-refactor [2017/09/01 22:29] 77.100.94.53 |
||
---|---|---|---|
Line 9: | Line 9: | ||
== The problem with the queue | == The problem with the queue | ||
- | So essentially, Smoothie was originally coded with no consideration whatsoever for RAMÂ usage. Yes. Sue me. | + | So essentially, Smoothie was originally coded with no consideration whatsoever for RAM usage. Yes. Sue me. |
It ended up not too bad, but still very very far from optimal. | It ended up not too bad, but still very very far from optimal. | ||
Line 15: | Line 15: | ||
I guess we can start by explaining the problem the queue tries to solve before explaining the problem with the way we currently do it. | I guess we can start by explaining the problem the queue tries to solve before explaining the problem with the way we currently do it. | ||
- | A pretty good explanation can be found here :Â [[howitworks]] | + | A pretty good explanation can be found here: [[howitworks]] |
=== How it now works | === How it now works | ||
- | In short, when we get say, a G-code for a movement, the following happens ( oversimplified ) :Â | + | In short, when we get say, a G-code for a movement, the following happens ( oversimplified ) : |
* Robot interprets the G-code and makes a line from it | * Robot interprets the G-code and makes a line from it | ||
Line 36: | Line 36: | ||
* Go to first step | * Go to first step | ||
- | Now what this means for a module is there are two different processes/loops :Â | + | Now what this means for a module is there are two different processes/loops : |
* The one in which you receive an instruction | * The one in which you receive an instruction | ||
* The one in which you have to execute an instruction | * The one in which you have to execute an instruction | ||
Line 94: | Line 94: | ||
Then when the time comes, they get that information back. | Then when the time comes, they get that information back. | ||
- | This has so many advantages :Â | + | This has so many advantages : |
* Much lower RAMÂ usage | * Much lower RAMÂ usage | ||
* Can be about as simple to the coder as we do now | * Can be about as simple to the coder as we do now | ||
Line 100: | Line 100: | ||
* Fixed-size ( in bytes not Blocks ) Queue for **all** the data ( including non-movement data ), for easier RAM management | * Fixed-size ( in bytes not Blocks ) Queue for **all** the data ( including non-movement data ), for easier RAM management | ||
- | Here is the proposed format for the new Blocks ( now called "Actions" to differentiate them from the movement Blocks ( which become just another kind of Action ) ) :Â | + | Here is the proposed format for the new Blocks ( now called "Actions" to differentiate them from the movement Blocks ( which become just another kind of Action ) ) : |
* 1 byte : Owner module ID | * 1 byte : Owner module ID | ||
- | * 1 byte :Â Length in bytes <kbd>n</kbd> | + | * 1 byte : Length in bytes <kbd>n</kbd> |
* <kbd>n</kbd> bytes : Data | * <kbd>n</kbd> bytes : Data | ||
The queue is composed of a series of those Actions. When a module tries to add an Action to the Queue, and the Queue does not have enough room, we wait until there is room ( similar to what the current movement queue does ). | The queue is composed of a series of those Actions. When a module tries to add an Action to the Queue, and the Queue does not have enough room, we wait until there is room ( similar to what the current movement queue does ). | ||
- | Example queue ( random non-real-life actions ) :Â | + | Example queue ( random non-real-life actions ) : |
||~ Byte ||~ Length ||~ Value ||~ Explanation || | ||~ Byte ||~ Length ||~ Value ||~ Explanation || | ||
- | || 0 || uint8 || 2 || Action owner IDÂ 2 :Â Laser module || | + | || 0 || uint8 || 2 || Action owner ID 2 : Laser module || |
|| 1 || uint8 || 1 || 1 byte long Action || | || 1 || uint8 || 1 || 1 byte long Action || | ||
|| 2 || uint8 || 127 || Laser module understands this as : set laser power to 50% || | || 2 || uint8 || 127 || Laser module understands this as : set laser power to 50% || | ||
|| 3 || uint8 || 5 || Action owner ID 5 : Extruder module || | || 3 || uint8 || 5 || Action owner ID 5 : Extruder module || | ||
|| 4 || uint8 || 1 || 1 byte long Action || | || 4 || uint8 || 1 || 1 byte long Action || | ||
- | || 5 || uint8 || 3 || Extruder module understands this as :Â Extruder action ID 3 :Â do unretract || | + | || 5 || uint8 || 3 || Extruder module understands this as : Extruder action ID 3 : do unretract || |
|| 6 || uint8 || 5 || Action owner ID 5 : Extruder module || | || 6 || uint8 || 5 || Action owner ID 5 : Extruder module || | ||
|| 7 || uint8 || 3 || 3 bytes long Action || | || 7 || uint8 || 3 || 3 bytes long Action || | ||
Line 143: | Line 143: | ||
* When there is enough room in the Queue, the Action is added | * When there is enough room in the Queue, the Action is added | ||
- | And it sleeps there for a while, until, in another context :Â | + | And it sleeps there for a while, until, in another context : |
* All Actions in the queue have been executed up to our Action | * All Actions in the queue have been executed up to our Action | ||
Line 182: | Line 182: | ||
</code> | </code> | ||
- | So now, per module, here is what needs to change :Â | + | So now, per module, here is what needs to change : |
=== Planner | === Planner | ||
Line 228: | Line 228: | ||
</code> | </code> | ||
- | can here too be replaced with :Â | + | can here too be replaced with : |
<code> | <code> | ||
on_gcode_received{ | on_gcode_received{ | ||
Line 242: | Line 242: | ||
There are only two possible actions ( Spindle ON, Spindle OFF ), and one bit of data ( Spindle Speed ) | There are only two possible actions ( Spindle ON, Spindle OFF ), and one bit of data ( Spindle Speed ) | ||
- | So the action data is, for a Spindle OFF event :Â | + | So the action data is, for a Spindle OFF event : |
- | * <kbd>0x0</kbd> ( 1Â byte ) | + | * <kbd>0x0</kbd> ( 1 byte ) |
For a Spindle ON event : | For a Spindle ON event : | ||
Line 250: | Line 250: | ||
* <kbd>0x1</kbd> ( 1 byte ) | * <kbd>0x1</kbd> ( 1 byte ) | ||
- | And for a Spindle set speed :Â | + | And for a Spindle set speed : |
* <kbd>0x2</kbd> ( 1 byte ) | * <kbd>0x2</kbd> ( 1 byte ) | ||
Line 257: | Line 257: | ||
Those are simply added to the action queue [[https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/spindle/Spindle.cpp#L198|Here]] | Those are simply added to the action queue [[https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/spindle/Spindle.cpp#L198|Here]] | ||
- | Then [[https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/spindle/Spindle.cpp#L204|on_gcode_execute]] becomes simply :Â | + | Then [[https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/spindle/Spindle.cpp#L204|on_gcode_execute]] becomes simply : |
<code> | <code> |