What is the problem?
I am observing unexpected behavior in Terminal window and trying to understand if this a bug or a "feature". With all 3 Suppress checkboxes selected and with Auto scroll mode on, the content of terminal window eventually gets moved up and ends up being empty even when nothing is being printed and no commands are entered manually. This is very inconvenient during troubleshooting. I'd expect to see all unfiltered lines to be present until the buffer is full. Then as new lines come in, the oldest line(s) should disappear. It worth mentioning also that there is no clear visible pattern of when this starts happening. Most often vertical scroll bar starts to get taller when the number of filtered messages reaches 300.
What did you already try to solve it?
Run Octoprint in Safe mode and manually executed several M117, M114 and M119 commands. Observed the same as in non-safe mode. Attached extract from serial log is collected while running Safe mode
Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
OctoPrint 1.3.12 running on OctoPi 0.16.0 Raspberry Pi 3B
Repetier 1.0.4
Chrome browser
Observed on 2 different printers each running with dedicated RPI.
This behavior remained the same over many releases and I've not seen any specific mention that it was addressed in 1.4. So yes, I know, you will tell me to upgrade to 1.4 and retest, but if this part of the code has not been touched since 1.3.12, the upgrade won't change much.
I'm pretty sure this is just by design, not necessarily a feature. My assumption is that the received commands are coming in constantly and checking the boxes are just applying a regular expression to the array of the last x number of commands received. That's why you are seeing the showing 40 lines (204 of 244 total lines filtered). I'm not sure what that total buffer is, but this would be a feature request to change the logic.
Agree, and if nothing passes the filter, nothing should be added to the textbox field. The way it behaves gives impression that some kind of timing is involved and oldest messages are removed.
As I said, the only major inconvenience I had with this was while doing maintenance work on the printer. You run number of test commands, get results, then spend some time tuning the printer, come back to run the same commands and compare the results, but previous results moved up and went away and you end up "digging" log files to find what was erased from the screen.
Not sure if @foosel considers this important, or has time to work on this, but if this part ever is re-written, I'd also rather see Suppress filters applied only to newly received messages and Autoscroll state indicator be more prominent, maybe another checkbox.
Thanks
I can haz feature request ticket on Github please? Stuff like this otherwise simply will get forgotten.
As the implementation is right now it would be somewhat tricky to do. And I'm also a tad reluctant to mess around with the regular terminal contents too much (as in, in a way that lines could actually get lost) since often it's about the only thing that's available for debugging purposes. It's always a bit of a fight between what makes sense from a ux point of view vs negative effects on helping users in the field.
Created 2 separate requests #3429 for autoscroll button and #3430 for textbox content disappearing.
As a workaround I could use command line interface - SSH to RPI and run tail -f serial.log | grep -vi wait (more filters can be added). This will show the same as textbox on Terminal tab.
The thought about using CLI brought up a new question - is there a script or executable that can be run from RPI CLI and accept/execute GCODE commands? I found octocmd https://github.com/vishnubob/octocmd and yet have to try it, but after reading the description looks like it was designed to run gcode files rather than handle the commands typed in by user.
Combine this with, for example, ~/scripts/postbody/M115:
{
"command": "M115"
}
And then call it with... ~/scripts/sendgcode M115. You'd want to be careful since the bash script parsing would only include the first argument in this case. So if you wanted something really "ad hoc" then change things so that the body is built rather than pulled from a file like this.
Yes, I've thought about that but decided to ask 1st to make sure I am not reinventing the wheel. I will definitely share the code if I come up with something. Testing of Repetier firmware version 2 keeps me busy at the moment.
For what it's worth, today I just reinvented "the wheel" in the form of Python's rpc, Queue, FIFO and other interprocess communications that are available. I wrote my own because, frankly, all the options sucked with respect to a fast, fault-tolerant solution to two different programs trying to communicate Python's dict objects between them. It's like the respective authors only covered the scenarios where a parent process creates a child and wants to talk to it. And the named pipes version of this wasn't forgiving of the other side getting restarted.
So sometimes rolling your own solution is just the way to go.
It's a tricky one to figure out what the right solution is, so a contribution would probably be accepted if done well.
If you filter the commands, you still have to keep them in memory for when you need them again. Do you still limit it to 300? But then you would get nothing, implying it was broken. Or increase that, but make the performance of the UI a bit slower.
Creating an alternative terminal view was one of the things I've done to learn React front-end code, it is not a very complex thing and the code is easy to read. So if you, or someone else wants to jump in I can recommend it.
Stuff like this otherwise simply will get forgotten.