<p>I can get down to 13(14) lines using 6 commands, one of which is optional: <a href="https://marlinfw.org/docs/gcode/G000-G001.html" rel="nofollow noreferrer">G1 movements,</a> <a href="https://marlinfw.org/docs/gcode/G028.html" rel="nofollow noreferrer">G28 homing,</a> <a href="https://marlinfw.org/docs/gcode/M140.html" rel="nofollow noreferrer">M140 setting the bed temperature without pause</a>, <a href="https://marlinfw.org/docs/gcode/M109.html" rel="nofollow noreferrer">M109 to set the hotend temperature</a>, <a href="https://marlinfw.org/docs/gcode/G004.html" rel="nofollow noreferrer">G4 dwell to pause</a>, and <a href="https://marlinfw.org/docs/gcode/M300.html" rel="nofollow noreferrer">M300 to beep.</a></p>
<p>The line in [] is optional, but the nozzle isn't safe to touch right away - waiting for the cooldown ensures touch safety.</p>
<pre><code>G1 Z20 F1000 ; Movement Test Z
G1 X20       ; Movement Test X
G1 Y20       ; Movement Test Y
G28          ; Homing Test
G1 Z20       ; Movement up (safety measure)
M140 S50     ; Set Bed temperature to 50, directly goto next line
M109 R180    ; Set Nozzle temperature to 180, wait for achieving
G4 S60       ; Wait a minute (to see if nozzle temperature is held)
M140 S0      ; &quot;turn off&quot; bed
[ M109 R25     ; set nozzle temperature to 25C, wait for achieving ]
M109 S0      ; actually turn off nozzle!
M300 S440 P200 ; Beep
G4 P200      ; short pause
M300 S660 P200 ; Beep
</code></pre>

CC BY-SA 4.0
2021-01-08T03:01:31.753Z
... and this could be put into one line, and added as a "Self-test" [custom menu item](https://3dprinting.stackexchange.com/questions/7676/how-to-add-menu-options-to-the-marlin-firmware-lcd-menu) for easy access. Maybe this was an origin of "in the least amount of lines" requirement. I like this idea :) it helps to implement PDCA cycle into printer improvements. This could be even built into Marlin, which is aware of current position (risk of gcode raise on start) and hardware (speaker vs buzzer).
octopus8
CC BY-SA 4.0
2021-01-05T21:40:54.890Z
2022-05-12T09:58:17.823Z
2022-05-12T09:58:17.823Z
Trish
<p>I want to write a couple of very simple G-code test cases in Marlin-Style to make sure my printer works properly. The idea is to test the movement system, then the end-stops, then the heating and ability to hold temperature. But Marlin already runs large, so I can't spare too many lines in the basic setup, if I want to integrate it into the firmware.</p>
<p>The test I have in mind is this order of operations, covering the basis of each axis and the thermal control:</p>
<ul>
<li>The printhead shall move up 20 mm, then right and forward the same.</li>
<li>the printhead shall home.</li>
<li>the printhead shall rise again by 20 mm.</li>
<li>The preheating shall be done (50°C bed, 180°C head).</li>
<li>The printer shall do nothing for 2 minutes.</li>
<li>The printer shall cool down.</li>
<li>Beep twice to signal that the test is concluded.</li>
</ul>
<p>What is the best way to set up such a test code in the least amount of lines? Did I forget a crucial test command?</p>

CC BY-SA 4.0
2021-01-06T08:56:01.327Z
I do not think this question is a good fit for stackexchange. It is basically a "do-my-homework" question and it [shows no effort](https://3dprinting.stackexchange.com/help/how-to-ask). It is also incredibly specific (and thus useless to anybody else), focussing on a very specific test script that you want.
Tom van der Zanden
CC BY-SA 4.0
2021-01-06T10:30:59.943Z
@TomvanderZanden you *DO* realize that a) I put it in [tag:knowledgebase] - where *BASICS* are explained b) I wrote an answer, which took me a little longer than expected c) the extreme specificity here is wanted because it *is* a very specific test case: do the motors work, does homing work, does the heating work. d) the G-code could be ran on basically *every* printer, no matter the size.
Trish
CC BY-SA 4.0
2021-01-06T11:04:26.440Z
I did see you wrote an answer, but that doesn't change how the question should be evaluated.
Tom van der Zanden
CC BY-SA 4.0
2021-01-06T11:05:47.417Z
I think that for a "knowledge base" question "How to write G-code to do movement?" or "How to command the heated bed to warm?" or "How to pause a print?" might be more suitable as isolated question (even though these are still very basic questions, of course).
Tom van der Zanden
CC BY-SA 4.0
2021-01-06T11:07:46.150Z
I think that for a programming stackexchange, a question on "I want to write a program that does A, then B, then C" wouldn't be considered appropriate. But a question "How to do B?" might be. This seems to be the equivalent of that?
Tom van der Zanden
<troubleshooting><g-code><knowledgebase>
Writing G-Code: length-optimized Test code
Trish
# Writing G-Code: length-optimized Test code

(Asked by: username_0 on 2021-01-05)

I want to write a couple of very simple G-code test cases in Marlin-Style to make sure my printer works properly. The idea is to test the movement system, then the end-stops, then the heating and ability to hold temperature. But Marlin already runs large, so I can't spare too many lines in the basic setup, if I want to integrate it into the firmware.

The test I have in mind is this order of operations, covering the basis of each axis and the thermal control:

* The printhead shall move up 20 mm, then right and forward the same.
* the printhead shall home.
* the printhead shall rise again by 20 mm.
* The preheating shall be done (50°C bed, 180°C head).
* The printer shall do nothing for 2 minutes.
* The printer shall cool down.
* Beep twice to signal that the test is concluded.

What is the best way to set up such a test code in the least amount of lines? Did I forget a crucial test command?

**Tags:** troubleshooting, g-code, knowledgebase
> **Comments:**
> **username_1**: I do not think this question is a good fit for stackexchange. It is basically a "do-my-homework" question and it [shows no effort](https://3dprinting.stackexchange.com/help/how-to-ask). It is also incredibly specific (and thus useless to anybody else), focussing on a very specific test script that you want.  
> **username_0**: @TomvanderZanden you *DO* realize that a) I put it in [tag:knowledgebase] - where *BASICS* are explained b) I wrote an answer, which took me a little longer than expected c) the extreme specificity here is wanted because it *is* a very specific test case: do the motors work, does homing work, does the heating work. d) the G-code could be ran on basically *every* printer, no matter the size.  
> **username_1**: I did see you wrote an answer, but that doesn't change how the question should be evaluated.  
> **username_1**: I think that for a "knowledge base" question "How to write G-code to do movement?" or "How to command the heated bed to warm?" or "How to pause a print?" might be more suitable as isolated question (even though these are still very basic questions, of course).  
> **username_1**: I think that for a programming stackexchange, a question on "I want to write a program that does A, then B, then C" wouldn't be considered appropriate. But a question "How to do B?" might be. This seems to be the equivalent of that?  

---

## 1 answers

### Answer by username_0 on 2021-01-05. Score: 2 | Accepted answer

I can get down to 13(14) lines using 6 commands, one of which is optional: G1 movements, G28 homing, M140 setting the bed temperature without pause, M109 to set the hotend temperature, G4 dwell to pause, and M300 to beep.
The line in [] is optional, but the nozzle isn't safe to touch right away - waiting for the cooldown ensures touch safety.
G1 Z20 F1000 ; Movement Test Z
G1 X20       ; Movement Test X
G1 Y20       ; Movement Test Y
G28          ; Homing Test
G1 Z20       ; Movement up (safety measure)
M140 S50     ; Set Bed temperature to 50, directly goto next line
M109 R180    ; Set Nozzle temperature to 180, wait for achieving
G4 S60       ; Wait a minute (to see if nozzle temperature is held)
M140 S0      ; "turn off" bed
[ M109 R25     ; set nozzle temperature to 25C, wait for achieving ]
M109 S0      ; actually turn off nozzle!
M300 S440 P200 ; Beep
G4 P200      ; short pause
M300 S660 P200 ; Beep

> **Comments:**
> **username_2**: ... and this could be put into one line, and added as a "Self-test" [custom menu item](https://3dprinting.stackexchange.com/questions/7676/how-to-add-menu-options-to-the-marlin-firmware-lcd-menu) for easy access. Maybe this was an origin of "in the least amount of lines" requirement. I like this idea :) it helps to implement PDCA cycle into printer improvements. This could be even built into Marlin, which is aware of current position (risk of gcode raise on start) and hardware (speaker vs buzzer).  

---

