<p>In <code>cmdqueue.h</code> the <code>CMDBUFFER_DEBUG</code> macro is defined (<a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cmdqueue.h#L47" rel="nofollow noreferrer">see here</a>) which will log lots of information related to the commands being processed. Probably more information than you need...</p>
<p>To log only the commands as they are processed (i.e. when the printer moves and extrudes etc.) you need <a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L3696" rel="nofollow noreferrer">this line from marlin_main.cpp</a>: <code>SERIAL_ECHO(cmdbuffer+bufindr+CMDHDRSIZE);</code>.</p>
<p>You can copy this outside of the <code>#ifdef CMDBUFFER_DEBUG</code> condition and compile the firmware then when you connect to the serial port each G-code line the printer processes will be logged.</p>

CC BY-SA 4.0
2020-12-12T17:50:04.923Z
2020-12-12T17:50:04.923Z
NickDGreg
<p>If you have the hardware at hand, you can use OctoPrint to collect the data you require. It's common for users to create an OctoPrint server on a Raspberry Pi, but it can be installed easily on a Windows or Linux machine as well. Once in place, logging is available for various types of information.</p>
<p>From the <a href="https://community.octoprint.org/t/where-can-i-find-octoprints-and-octopis-log-files/299" rel="nofollow noreferrer">OctoPrint blog</a>:</p>
<p>The logs are crucial instruments of analysis and debugging, so it's usually in your best interest to provide them when asking for help or reporting a bug, even if not explicitly prompted for them:</p>
<blockquote>
<p>octoprint.log: OctoPrint's main application log file. Contains a
general log of everything that happens while OctoPrint is running.
Includes version information, installed plugins and a myriad of more
data points.</p>
<p>This must always be included when reporting a bug 47 to allow for
further analysis and reproduction. It is also a very good idea to
provide this when asking for help :wink:</p>
<p>serial.log: A log of all of the communication going on between
OctoPrint and your printer. Usually disabled for performance reasons,
enable it through Settings &gt; Serial Connection.</p>
<p>Either that or at the very least the output in OctoPrint's Terminal
tab is crucial for analysis of any kind of communication issues or
misbehaviours observed with your printer, so it's important to include
it when discussing such issues.</p>
<p>plugin_pluginmanager_console.log: A log of the command line activity
of the plugin manager. Very important for analysis of such questions
like &quot;Why can't I install plugin $xyz?&quot;, so if you have such a
problem, best include this.</p>
<p>plugin_softwareupdate_console.log: A log of the command line activity
of the software updater. Very important for analysis of such questions
like &quot;Updating OctoPrint always fails, why?&quot;, so if you have such a
problem, best include this.</p>
</blockquote>
<p>Third party plugins might also have special log files here. If a plugin author asks you to provide a special log created by their plugin for further analysis, this should be where you can find it.</p>
<p>The above selection is from the linked site, which also includes embedded links for more information regarding the log files. Note that serial.log is specifically referenced to collect data between OctoPrint and your printer, although it defaults to disabled on install.</p>

CC BY-SA 4.0
2020-12-12T09:53:44.843Z
I was aiming to do it directly from the firmware as part of this project I'm doing is to understand more about 3D printers. I believe Octoprint controls the printer via the USB which I didn't want. It also adds another system that I would need to understand before I can start fiddling around and experimenting.
NickDGreg
CC BY-SA 4.0
2020-12-12T11:13:24.373Z
@NickDGreg if you don't print from the serial, the serial is pretty much ignored in most things.
Trish
CC BY-SA 4.0
2020-12-12T11:16:40.657Z
@Trish What do you mean? The printer prints from a file on the SD card, I connect my laptop to the printer via the serial port and can process its logs in a program running on my laptop. Its just a project I'm doing, so the serial isn't ignored in this case
NickDGreg
CC BY-SA 4.0
2020-12-12T11:19:02.887Z
and your proposed operation just reset the board mid print: Connecting anything to the serial port triggers the reset of the board to establish some things, You can log *some* things (temperatures) but not all.
Trish
CC BY-SA 4.0
2020-12-12T17:37:05.253Z
I was unclear then, I connect to serial port before beginning the print so that it doesn't reset
NickDGreg
CC BY-SA 4.0
2020-12-11T21:50:06.133Z
2020-12-11T21:50:06.133Z
fred_dot_u
<p>I would like to log each line of G-code to the serial port as it is processed.</p>
<p><strong>Steps to achieve</strong>:</p>
<ul>
<li>the printer reads a file from the SD card</li>
<li>each line it reads will be serial logged (this I can't figure out)</li>
<li>those lines can then read via the serial monitor on a laptop</li>
</ul>
<p>So by the end of the print, on my laptop I would have the reconstructed G-code file (plus whatever other logs the printer outputs).</p>
<p>The printer runs the Prusa Firmware. Ideally I would like to achieve the logging from altering the firmware rather than adding an extra plugin/server (For understanding and experimenting purposes).</p>
<p><strong>What I tried</strong></p>
<p>I have looked in code and found <a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin.h#L99" rel="nofollow noreferrer">the print functions</a> and examples of them in use in the code. This line is the &quot;<a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cmdqueue.h#L43" rel="nofollow noreferrer">command, which is to be excecuted right now</a>&quot;, but I think that would be the just one command not the full line.</p>
<p>The <a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cardreader.cpp" rel="nofollow noreferrer">cardreader</a> or <a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/SdBaseFile.cpp" rel="nofollow noreferrer">SdBaseFile</a> are where I would expect a G-code line to be read such that I could add a print statement after it but I did not see where.</p>
<p>Would it be as easy as setting this <a href="https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cardreader.cpp#L30" rel="nofollow noreferrer">card.logging</a> bool to true?</p>
<p>I imagine this is quite an easy thing to do and that I have just overcomplicated it by trying to understand the firmware. Any advice would be great!</p>

<marlin><g-code><serial-connection>
How to log each G-code line read from the SD card to serial on marlin firmware
NickDGreg
# How to log each G-code line read from the SD card to serial on marlin firmware

(Asked by: username_0 on 2020-12-11)

I would like to log each line of G-code to the serial port as it is processed.

**Steps to achieve**:

* the printer reads a file from the SD card
* each line it reads will be serial logged (this I can't figure out)
* those lines can then read via the serial monitor on a laptop

So by the end of the print, on my laptop I would have the reconstructed G-code file (plus whatever other logs the printer outputs).

The printer runs the Prusa Firmware. Ideally I would like to achieve the logging from altering the firmware rather than adding an extra plugin/server (For understanding and experimenting purposes).

**What I tried**

I have looked in code and found [the print functions](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin.h#L99) and examples of them in use in the code. This line is the "[command, which is to be excecuted right now](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cmdqueue.h#L43)", but I think that would be the just one command not the full line.

The [cardreader](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cardreader.cpp) or [SdBaseFile](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/SdBaseFile.cpp) are where I would expect a G-code line to be read such that I could add a print statement after it but I did not see where.

Would it be as easy as setting this [card.logging](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cardreader.cpp#L30) bool to true?

I imagine this is quite an easy thing to do and that I have just overcomplicated it by trying to understand the firmware. Any advice would be great!

**Tags:** marlin, g-code, serial-connection


---

## 2 answers

### Answer by username_0 on 2020-12-12. Score: 0 | Accepted answer

In `cmdqueue.h` the `CMDBUFFER_DEBUG` macro is defined ([see here](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/cmdqueue.h#L47)) which will log lots of information related to the commands being processed. Probably more information than you need...

To log only the commands as they are processed (i.e. when the printer moves and extrudes etc.) you need [this line from marlin\_main.cpp](https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L3696): `SERIAL_ECHO(cmdbuffer+bufindr+CMDHDRSIZE);`.

You can copy this outside of the `#ifdef CMDBUFFER_DEBUG` condition and compile the firmware then when you connect to the serial port each G-code line the printer processes will be logged.


---

### Answer by username_1 on 2020-12-11. Score: 1

If you have the hardware at hand, you can use OctoPrint to collect the data you require. It's common for users to create an OctoPrint server on a Raspberry Pi, but it can be installed easily on a Windows or Linux machine as well. Once in place, logging is available for various types of information.

From the [OctoPrint blog](https://community.octoprint.org/t/where-can-i-find-octoprints-and-octopis-log-files/299):

The logs are crucial instruments of analysis and debugging, so it's usually in your best interest to provide them when asking for help or reporting a bug, even if not explicitly prompted for them:

> octoprint.log: OctoPrint's main application log file. Contains a
> general log of everything that happens while OctoPrint is running.
> Includes version information, installed plugins and a myriad of more
> data points.
>
> This must always be included when reporting a bug 47 to allow for
> further analysis and reproduction. It is also a very good idea to
> provide this when asking for help :wink:
>
> serial.log: A log of all of the communication going on between
> OctoPrint and your printer. Usually disabled for performance reasons,
> enable it through Settings > Serial Connection.
>
> Either that or at the very least the output in OctoPrint's Terminal
> tab is crucial for analysis of any kind of communication issues or
> misbehaviours observed with your printer, so it's important to include
> it when discussing such issues.
>
> plugin\_pluginmanager\_console.log: A log of the command line activity
> of the plugin manager. Very important for analysis of such questions
> like "Why can't I install plugin $xyz?", so if you have such a
> problem, best include this.
>
> plugin\_softwareupdate\_console.log: A log of the command line activity
> of the software updater. Very important for analysis of such questions
> like "Updating OctoPrint always fails, why?", so if you have such a
> problem, best include this.

Third party plugins might also have special log files here. If a plugin author asks you to provide a special log created by their plugin for further analysis, this should be where you can find it.

The above selection is from the linked site, which also includes embedded links for more information regarding the log files. Note that serial.log is specifically referenced to collect data between OctoPrint and your printer, although it defaults to disabled on install.

> **Comments:**
> **username_0**: I was aiming to do it directly from the firmware as part of this project I'm doing is to understand more about 3D printers. I believe Octoprint controls the printer via the USB which I didn't want. It also adds another system that I would need to understand before I can start fiddling around and experimenting.  
> **username_2**: @username_0 if you don't print from the serial, the serial is pretty much ignored in most things.  
> **username_0**: @username_2 What do you mean? The printer prints from a file on the SD card, I connect my laptop to the printer via the serial port and can process its logs in a program running on my laptop. Its just a project I'm doing, so the serial isn't ignored in this case  
> **username_2**: and your proposed operation just reset the board mid print: Connecting anything to the serial port triggers the reset of the board to establish some things, You can log *some* things (temperatures) but not all.  
> **username_0**: I was unclear then, I connect to serial port before beginning the print so that it doesn't reset  

---

