Trying to get started, manual control stops working - Appears Resolved

Trying to setup Octpi/Octoprint on a Pi4b. Via the Octoprint on FireFox, I can connect to either printer I have connected to the Pi USB ports. Pi connects to my PC via Ethernet link.

Seems to connect to either printer and I can usually get them to "auto home" and move in any axis, at least once. After that, things appear to stop working. That is, I can continue to send manual movement commands via Octoprint, but, the printer does not move. I can see in Terminal that the printer continues to send (Recv: T:26.56 /0.00 B:22.41 /0.00 T0:26.56 /0.00 T1:24.77 /0.00 @:0 B@:0 @0:0 @1:0), but no further motion commands are sent.

I have virtually zero experience with OctoPi and OctoPrint, so am lost at this point, trying to determine where the problem is. I tend to suspect the Pi. Octopi or Octoprint, as neither printer manifested any such issues using other control/slicer software.

Thanks for any assistance. I have attached latest system info.

octoprint-systeminfo-20230310115601.zip (287.8 KB)

It looks like your printer forgets to send an OK to the last command that OctoPrint sent, so OctoPrint can't send any more commands:

[... previous commands ...]
Send: G91
Recv: ok
Send: G0 X10 F6000
Recv: ok
Send: G90
< missing ok here >
Recv:  T:25.16 /0.00 B:22.09 /0.00 T0:25.16 /0.00 T1:23.91 /0.00 @:0 B@:0 @0:0 @1:0
Recv:  T:25.16 /0.00 B:22.16 /0.00 T0:25.16 /0.00 T1:24.06 /0.00 @:0 B@:0 @0:0 @1:0
[... repeated, as you identified ...]

You haven't said any details about your printers, but it could just be a broken/buggy firmware if it just doesn't send it. In the terminal tab, there is an option for 'fake acknowledgement' that you can try to press to see if you can send more commands. If you have to do that often however then there is definitely something broken.

I did see that feature and tried it, did not seem to make any difference. After power off/on the printer and reconnecting, did a "home" then tried a +X which worked and a second *X that did not. See below snipped. Attached is the "initial connection" dialog for the Big Box (E3D) printer.


Send: G28 X0 Y0
Recv: echo:Active Extruder: 0
[...]
Recv: echo:busy: processing
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:Active Extruder: 0
Recv: X:0.00 Y:0.00 Z:4.00 E:0.00 Count X:0 Y:0 Z:6524
Recv: ok
Send: G90
Recv: ok
Send: M113 S2
Recv: ok
[...]
Send: G91
Recv: ok
Send: G0 X10 F6000
Recv: ok
Send: G90
Recv: ok
[...]
Send: G91
Recv: ok
Send: G0 X10 F6000
Recv: ok
Send: G90
Recv: ok
[...]
Send: G91
Recv: ok
Send: G0 X10 F6000
[...]
Send: G90


Guess it could be. There is not much support for BB any longer it seems, sadly.

Hope this helps? Just a text file pasted from terminal, had to rename it to upload.

BB-init-info.log (3.2 KB)

What is the actual name of your printer?? What is BB?

The snippet you've shared has the same issue - the printer stops responding to the command again.

Sorry if it was not clear earlier. If the below is not what you are after, please help me understand what you mean by "actual name" of the printer.

I can add that, if I restart Octoprint, from the web paste "system" button and reconnect, it will move once, then stop. Occasionally, it will make 2 or 3 moves before it stops responding.

I read your post about 5 times looking for the name of the printer, apologies it appears I am blind.

I see what you mean about support for the printer - I found an E3D post from 2017 that says they will support the printer but that was 6 years ago now...

I am not sure what can be done if the printer's connection doesn't work properly. It is not something that looks like it can be worked around by OctoPrint, one of the only things OctoPrint absolutely needs is stable communication to the printer.

I would suggest potentially different firmware could help (often with buggy firmware this is the case) but I only managed to find older software on the internet than what your connection reports. There's no config example for a modern Marlin version available so unless you know the printer & in great detail you will find it very difficult to build your own config from scratch.

I did find a really old guide from E3D that suggested setting the baudrate to 23400, however I would guess that won't make a difference (and probably won't work at all) since it is able to get some communication on 115200 that you are connecting on. Perhaps worth a try but I doubt it will do anything.

Thanks for the input and research.

Turns out, the problem appears to be an iffy USB cable. A fundamental, well known problem, but one I did not think of, as I had no problems earlier.

After some simple cable swapping, I find that one cable, with good reviews online, works well on the Robo R1, but dislikes the Big Box. Another cable, interestingly with one of those "ferrite cores" at each end, works well with either one.

And me with decades of background in such things. For shame!

Now, back to the further adventures of . . . (fill in your favorite).