Print through the API - how much can it take?

Get Help
1

What is the problem?

More actually a question, or a couple of them.

I'm trying out things with the API and the POST /api/printer/command which allows to send arbitrary commands to the printer. That works like a charme with everything I tried before but that was mostly a single line of GCODE like M997 or M117 hello world

Now I'm trying to use that to actually print stuff. Think of a hollow cylinder, later, when things work out, the plan is to programmatically modulate the print but right now its actually a GCODE from Cura, split into several files like pre, base,body,end which are read by a program, and fed line by line to the API.

I activated and connected to the virtual printer to save some plastic from premature death, the main page shows the printer as Operational but on the terminal tab I see the GCODE flowing through,

G1 X74.83 Y148.614 E715.08595
Not SD printing
T:205.00/ 205.00 B:60.00/ 60.00 @:64
ok
G1 X75.096 Y148.915 E715.09263
Not SD printing
Not SD printing
ok

So far so good. Currently all this is moving in slow mode, the program triggers reading and processing a new line of GCODE every 500 milliseconds. This is arbitrary, nothing stops me from setting that to 50 or 5 ms.
The questions include:

  • how does the virtual printers performance relate to a physical one, say, an ender 2 or 3?
  • how will I know/how to check programmatically that it's coming in to fast?
  • does the API send or offer some sort of feedback about success / failure of transmitted commands?
  • does it buffer the stuff I push over?
  • there is command and commands. Obviously commands would save lots of http protocol overhead, but how many lines are recommended in a commands list? Is there a maximum- of course - where?

What did you already try to solve it?

See above, I could simply crash test the settings and see where it gets me but I felt like asking first.

Actually set it to 50 ms interval now and I see the printer issues wait now and then. That could be a marker commands come in to fast.

Have you tried running in safe mode?

no, it doesn't apply

Did running in safe mode solve the problem?

see above

Systeminfo Bundle

octoprint-systeminfo-20211023005030.zip (207.2 KB)

Additional information about your setup

browser.user_agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 connectivity.connection_check: 136.243.14.151:80 connectivity.connection_ok: true connectivity.enabled: true connectivity.online: true connectivity.resolution_check: octoprint.org connectivity.resolution_ok: true env.hardware.cores: 4 env.hardware.freq: 1200 env.hardware.ram: 914006016 env.os.bits: 32 env.os.id: linux env.os.platform: linux env.plugins.pi_support.model: Raspberry Pi 3 Model B Rev 1.2 env.plugins.pi_support.octopi_version: 0.18.0 env.plugins.pi_support.throttle_state: 0x0 env.python.pip: 20.3.3 env.python.version: 3.7.3 env.python.virtualenv: true octoprint.safe_mode: false octoprint.version: 1.7.0 printer.firmware: Virtual Marlin 1.0 systeminfo.generator: systemapi
2

Virtual printer runs faster than any printer, since it doesn't actually do anything with the commands it is receiving.

Coming in too fast for what? OctoPrint? The printer itself? Something else? The API request will block (as far as I can tell) until every command is processed.

There's no way to get feedback on if the command sent and the printer didn't do it or reported an error - it's a one-way street.

Not through this API directly, no. The commands are sent as soon as they are received since there's no job for them to be buffered against as far as I can read from the code.

OctoPrint does not impose a limit on the number of commands, it will just iterate through them one at a time until the list is finished. The only difference is saving a HTTP round trip for every command.

This seems like a horribly inefficient way to print things, and especially if you're printing cylinders I would not be a fan. Theoretically, OctoPrint can handle it and all would be ok, even if it is not designed to be abused this way.

Then you move on to the practical side - sending commands via HTTP to OctoPrint, for it to then process the request, send a command and generate a response is (relatively) extremely slow. We already see some people with problems stuttering on their regular print jobs which are read from files, added to queues and buffered in the communication layer to avoid this problem as much as possible. Doesn't really seem like it will work well to me.

3

thanks for your thoughts and all the info you shared!

I give you that, it's part of an experiment and personally I quite expect it to turn into a structured spaghetti generator. And many challenges, like Cura gives G1 commands with 5 decimals precision (at least for E) but the C Compiler I'm using supports about 2.
I'm not expecting this to be useful when printing Baby Yodas or soap holders.

4

This is definitely not what this API was meant it optimized for and I'd also expect quite bad results from abusing it like this.

I'd rather suggest you maybe rather look into plugin development (http taken out if the equation) and maybe dynamic file generation through that as well.

The wait you saw already meant you seeing buffer underruns on the printer side (though those are also automatically forced in the first 100 lines on the virtual printer, for debugging reasons). A wait doesn't mean "please wait" but rather "I'm waiting, send more"

1 Like
5

Thanks about the wait, I saw it from the virtual printer so it may well have been the debugging response you mentioned. In any case I know now how to interpret it when I encounter it with the real printer, later.

Now please do not feel like I'm abusing your brain child. She is such a reliable, good natured companion on this research expedition to the fringe areas of 3D printing. :slight_smile:

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.