How can I receive G code output as a client

I find the browser-based client to have issues if it remains active for too long. I don't know if the problem is with the G Code viewer, or with the web cam, but at times I find the system to be very unresponsive after a long print. This is exacerbated because I have two printers; I would like to bring up 2 clients simultaneously, and I have at times, but the problems become even more apparent.

As a result, I would like to implement my own client that is not browser-based. Probably using python, but perhaps even c++. The REST api makes this fairly straight-forward, but for some functionality - such as modifying EPROM settings - I need to capture the output stream from the printer and have it delivered to the client. I believe there is a way to do it - after the browser-based clients need to utilize the same interface - but I can't find how to do it from the documentation. If there is an example I could use, I'd appreciate some pointers.

Thanks

1 Like

No response to this after all this time. I know what I'm asking for is possible because the terminal tab of the browser based gui displays the printer output. I just need to know the mechanism that is used to have that output delivered to the client.

I guess I could implement my client without this, but I'm interested in this just from a technical point of view.

Somehow that fell off my radar.

So, the problem is that you can't easily receive the output to a specific command. There are a whole bunch of firmware forks out there that suffer from a bug that makes output not be generated in the same order as commands were sent and so OctoPrint isn't able to match things up reliably. Hence there's also no API for that.

What you see in the existing web interface is simply what goes over the line, pushed through the sockjs backed websocket. There is a python client and a JS client for that available in the repository. The latter is also what is used by the frontend itself.

Thanks for the reply. I realize I can't see the output for a specific command, but I should be able to 1) turn it "on", 2) issue my command, 3)parse the output until I am satisfied with the results, and 4) turn it "off". I realize I'll also add some safeguards.

Thanks again.

For that you'll need to connect to the websocket. Or alternatively write a companion plugin that offers what you are planning to do and adds a dedicated API for it (for example).

I surrounded this with just enough code to make sure that I knew how to do it. It works perfectly and is exactly what I was looking for. Now if I could just find the opportunity to do what I want!!!

Thanks again.

BTW - I like the idea of writing a plugin. Does the Octo-print server have the ability to add a plug-in to augment the REST interface? I'd consider writing an API to retrieve firmware settings. My biggest issue is that I'm basically only conversant with Marlin firmware.

Two ways actually :wink:

Simple: http://docs.octoprint.org/en/master/plugins/mixins.html#simpleapiplugin

More involved: http://docs.octoprint.org/en/master/plugins/mixins.html#blueprintplugin

I said earlier that this works perfectly - and it does work well - there seems to be one quirk that I would like to find a graceful solution for.

When I make my initial connection, I can see the temperature probes as everything just sits there idle. Next, I bring down my client. As it's shutting down, it calls the SocketClient disconnect and then wait methods and everything seems to shut down fine.

If I start my client again later and then connect again, the first message I receive contains every temperature probe message that has occurred since the original connection - or at least it seems so - it completely filled up the console buffer inside of eclipse and I had to enlarge it just to see the output from that single message.

I need a way to ignore all of these previous messages. Preferably to suppress them in the first place. In other words, when I connect to the websocket, I am only interested in the events from that time forward. Is there a way to do this that I am missing?

Just ignore the history message sent on initial connect (which is probably what you got there) and only react to the current messages.

That sounds like a graceful way of doing it :blush:. I was looking for a way to distinguish the message and didn't spot that. Thanks.