It would be so interesting(and I think not so difficult) to view in a frame on the right (or another tab in the browser) the actual position of the line being printed in the gcode file.
The current sent line could be highlighted (or an arrow in front, or a scroll, or other), and other format could be possible. (or the choice of seeing only z-positions or other...)
I think for the plugin makers, this would be quite usefull too, unless it already exists of course.
So you can see what's to come, and what has been done, and for debugging, this would be sooooo usefull.
thx
Johan
The current sent line is always the last line in the terminal window.
It ill be difficult to display the actual active line that is printed because of the input buffer of the printer.
And depending on what to print, it can be grow smaller faster or slower.
In other words: OctoPrint really does not know what the printer is printing at a certain moment.
As a matter a fact, Octoprint does know what is being printed, since it sends commands and receives an 'ok' when executed (Marlin fw) e.g. the ok comes only after the command is executed.
A scrolling text file, with, let's say, the 40 previous and the 40 next lines, would be doable. There is no big buffer necessary, and only two strings need to be compared.
If one wants to see in realtime what the printer has done and will be doing in text format, I already wrote a small app in xojo, capturing the serial communication (read-only), and scrolling cells in an excel-like grid.
No, the ok is a confirmation of a correct received command line.
``ok - The RepRap machine is ready to receive the next line from the host.
from:
https://reprap.org/wiki/G-code#Replies_from_the_RepRap_machine_to_the_host_computer
I think I would object to something like this on performance grounds, so it would be a good candidate for a plugin you could make since not everyone will need it.
OctoPrint's UI performance is not great while printing (and I've not yet looked at how to make it better) as it constantly updated the gcode viewer and terminal with possibly hundreds of lines per second of gcode. So I would not want to add more to it. But that doesn't stop it being a plugin so it is optional. Unless it could be integrated as part of the gcode viewer efficiently.
@Ewald_Ikemann is right - the commands go in to the buffer on the firmware's side. You can look at the gcode viewer while printing to see how OctoPrint sees it is ahead of the physical printer movements.