@pause and @resume take a long time to execute

[BearWithMe]

What is the problem?

Using the @pause and @resume commands usually take around 6 to 8 seconds to execute.
Can it be that the Ramps 1.4 board gets a hiccup whenever Octoprint eats @pause or @resume?

Some additional information from the Serial log:
Did not receive parseable position data from printer within 10.0s, continuing without it

Context:

2022-05-01 16:41:23,432 - Recv: X:25.00 Y:5.00 Z:24.00 Count X:2000 Y:400 Z:1440
2022-05-01 16:41:23,433 - Recv: ok
2022-05-01 16:41:33,430 - Did not receive parseable position data from printer within 10.0s, continuing without it
2022-05-01 16:41:33,537 - Send: N10 G92 X25 Y5*16
2022-05-01 16:41:33,542 - Recv: X:25.00 Y:5.00 Z:24.00 Count X:2400 Y:1600 Z:1440

What did you already try to solve it?

I do know that the issue isn't appearing on the machines with an SKR 1.4 + Raspberry Pi Zero 2 W
The issue only appears on my Ramps 1.4 + Raspberry Pi Zero 2 W machine

I did try using a different Ramps board and also swapped out for a RPi 4 2Gb. But no combination worked well.

Have you tried running in safe mode?

No, as this issue doesn't happen on the SKR 1.4 + Pi combination I think the issue is with the Ramps board. The pause also happens when I hardcore the @pause into my gcode files.

Did running in safe mode solve the problem?

n.a.

Systeminfo Bundle

octoprint-systeminfo-20220501162400.zip (80.6 KB)

Additional information about your setup

• RPi Zero 2 W

• Ramps 1.4 (converted to 24v, separate 5v line to power the Mega 2560 <- the issues were also present in the 12v setup)

• Enclosure Plugin for physical GPIO controls

• Marlin flavored GCODE

• Firefox

• Windows 10

I'm using a Ramps 1.4 with a Raspberry Pi Zero 2 W to control my machine.
I have been using a "I2C-UART Bi-Directional Logic Level Converter 5V-3.3V 2-channel with supply" to handle the 5v to 3.3v logic level conversion. However, I am having some issues with the communication in a way that I haven't been able to fix in two years.

Further I used this setup to control the Ramps 1.4:

RAMPS 1.4 serial communication to OctoPrint via UART/GPIO

This guide applies to Raspberry Pi 3 B+ and may need some modification if you're using a different setup. The main reason I did this was because my USB-serial on my mega died. Another reason to do this is you might want to put your RPi inside your control box and don't want a bulky USB cable. Step 1: Make an arduino AVR to program the Mega2560 Refer to https://www.arduino.cc/en/tutorial/arduinoISP You can ignore this step if you can upload by USB. My original reason for embarking on this was b…

I am using the Enclosure plugin which allows users to add physical buttons to an Octoprint machine. I'm using this on three machines, one uses an SKR 1.3, one uses an SKR 1.4 and the last one uses a Ramps 1.4 board.

The SKR boards perform wonderfully, but the machine with the Ramps board has a latency between pressing a button and actually processing the request. It's roughly 6 to 8 seconds between pressing the button and actually seeing something happen in the machine.

I have further narrowed the latency down to only happening when I am using the @pause and @resume commands that Octoprint offers. Any other button presses are handled fine, like moving axes around while paused etc.

The only two other reasons I can think of are that either the Ramps 1.4 board has problems handling the @pause and @resume commands. Or the Logic Level Converter is somehow influencing something, however I do not suspect the logic level converter because GCODE is streamed perfectly fine.

[Charlie_Powell]

@BearWithMe

Have you tried running in safe mode?

No, as this issue doesn't happen on the SKR 1.4 + Pi combination I think the issue is with the Ramps board. The pause also happens when I hardcore the @pause into my gcode files.

Safe mode is about disabling 3rd party plugins to rule out them being the issue. They are both unlikely to be exactly identical, so there is no reason to not test it in safe mode. So you can test it to see if there is an issue with the plugin/configuration or not.

The issue is not really communication with the printer - it makes no difference what is on the end of the line, because @pause and @resume are never sent to the printer, they are only handled directly by OctoPrint to start the relevant action. It could be an issue with the actual pausing taking a long time, for example if the buffers need to run out or OctoPrint doesn't receive a position report.

[BearWithMe]

Hi, indeed, I had just added a snippet from the serial log where I found out that there is an issue with something.

I will try safe mode while running serial logging to see if the issue persists. Even though I don't see how this would make a difference since both machines are running the same cloned image. That should make them identical right?

Edit:
It seems the issue persists also in safe mode:

2022-05-01 16:51:31,833 - Recv: ok
2022-05-01 16:51:31,837 - Send: N10 M114*22
2022-05-01 16:51:31,841 - Recv: X:25.00 Y:5.00 Z:24.00 Count X:2000 Y:400 Z:1440
2022-05-01 16:51:31,843 - Recv: ok
2022-05-01 16:51:41,840 - Did not receive parseable position data from printer within 10.0s, continuing without it
2022-05-01 16:51:41,908 - Changing monitoring state from "Pausing" to "Paused"

[Charlie_Powell]

Waiting for the pause position would explain the delay switching from 'pausing' to 'paused'.

That would also be reproduceable with the regular 'Pause' button in the UI.

What is interesting is that a response is received from the printer - maybe it is not of the right format or something? Presumably it's a Marlin build?

[BearWithMe]

Yes that's what I'm starting to think. Could it be that Marlin is sending this:
2022-05-01 16:51:31,843 - Recv: ok

And that Octoprint tries to read the position from that line?

[BearWithMe]

Okay, I've made some progress and found out that turning off these three options makes it so that the machine doesn't experience the 10 second hangups:

2022-05-01 17:38:14,771 - Recv: ok
2022-05-01 17:38:14,774 - Changing monitoring state from "Printing" to "Pausing"

However, the serial monitor doesn't show a difference in output, so I'm unsure as to why this changed the behaviour.

Secondary problem is that I disabled all three settings at once, so now I have to go and turn them back on to see when the 10 second hangup reappears to find out which one actually caused the problem.

Solution:
It seems "Support position autoreporting by firmware, if detected" was the culprit!