1
$\begingroup$

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 and examples of them in use in the code. This line is the "command, which is to be excecuted right now", but I think that would be the just one command not the full line.

The cardreader or SdBaseFile 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 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!

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
$\begingroup$

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:

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ 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. $\endgroup$
    – NickDGreg
    Dec 12, 2020 at 9:53
  • $\begingroup$ @NickDGreg if you don't print from the serial, the serial is pretty much ignored in most things. $\endgroup$
    – Trish
    Dec 12, 2020 at 11:13
  • $\begingroup$ @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 $\endgroup$
    – NickDGreg
    Dec 12, 2020 at 11:16
  • $\begingroup$ 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. $\endgroup$
    – Trish
    Dec 12, 2020 at 11:19
  • $\begingroup$ I was unclear then, I connect to serial port before beginning the print so that it doesn't reset $\endgroup$
    – NickDGreg
    Dec 12, 2020 at 17:37
0
$\begingroup$

In cmdqueue.h the CMDBUFFER_DEBUG macro is defined (see here) 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: 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.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .