Connecting to OctoPrint from another browser causes USB reconnect to RAMPS


#1

Recently upgraded to latest stable on both my printers, everything appears to be working fine, but when I login from another browser or another computer during a print the USB connection quickly disconnects and reconnects, this causes the printer to miss steps and then everything is a mess.

At first I though it was a power issue or bad g-code, but i'm able to reproduce by opening a new browser session from a different browser / computer / cell phone - as soon as I login it shows disconnected and then connects to the printer and continues printing, but it will be off but a number of steps.

Printer is a RAMPS1.4 i3 design
FIRMWARE_NAME:Marlin 1.1.2
OctoPrint: 1.3.10
Running on raspberry pi 2B with wifi dongle

There is a print running at the moment so I can't login to get logs.

This setup has been working great <1yr now, just updated to latest stable and updated plugins and python and now getting this odd behavior.


#2

I routinely watch the load on the four cores of my Raspberry Pi 3B using Conky. Each and every time I open a browser it slams one of the cores 100% in processing load. So it's perhaps one of the most intensive things that you can do in OctoPrint.

That said, you're on a 2B at 900Mhz versus 1200Mhz for the 3B. At least it does have four cores. As you've seen, though, it's not up to the challenge of slamming two cores (two browsers) at once plus everything else that it needs to do.

I would suggest that this is too much work for the 2B, in my humble opinion. Will it work with a 3B? Possibly. I've done it on my own printer before when I needed to test Safari versus Chrome output.


#3

It's been working this way fine on the previous releases for over a year on both my printers, updating to this latest release is causing the problems. There is no reason for it to disconnect / reconnect the USB serial connection. You could easily "wait" for CPU. Something is causing the entire serial bus to re establish. Throwing more hardware at this - when it shouldn't require anything more that a pi 0 to run correctly doesn't make any sense.


#4

The zero has one core, for what it's worth.

I suppose one option is to revert to the previous version of OctoPrint.


#5

I'm just here to see the logs. You can ssh to get them.


#6

Print finished - I started another print - just waiting for the heating, login on another browser and this pops up in the serial.log file
2019-02-25 17:49:19,602 - Recv: ok T:225.00 /225 B:38.00 /60 @:51 B@:127
2019-02-25 17:49:21,583 - Send: M105
2019-02-25 17:49:21,602 - Recv: ok T:225.00 /225 B:38.33 /60 @:54 B@:127
2019-02-25 17:49:23,585 - Send: M105
2019-02-25 17:49:23,596 - Recv: ok T:225.00 /225 B:38.65 /60 @:56 B@:127
2019-02-25 17:49:25,586 - Send: M105
2019-02-25 17:49:25,688 - Recv: ok T:225.44 /225 B:38.81 /60 @:45 B@:127
2019-02-25 17:49:27,587 - Send: M105
2019-02-25 17:49:27,600 - Recv: ok T:226.00 /225 B:39.02 /60 @:34 B@:127
2019-02-25 17:49:29,603 - Send: M105
2019-02-25 17:49:29,689 - Recv: ok T:225.69 /225 B:39.33 /60 @:47 B@:127
2019-02-25 17:49:31,603 - Send: M105
2019-02-25 17:49:31,630 - Recv: ok T:225.00 /225 B:39.67 /60 @:64 B@:127
2019-02-25 17:49:33,604 - Send: M105
2019-02-25 17:49:33,629 - Recv: ok T:225.00 /225 B:39.71 /60 @:60 B@:127
2019-02-25 17:49:33,861 - Send: M504
2019-02-25 17:49:33,882 - Recv: ok
2019-02-25 17:49:33,913 - Send: M501
2019-02-25 17:49:33,924 - Recv: echo:Hardcoded Default Settings Loaded
2019-02-25 17:49:33,927 - Recv: echo: G21 ; Units in mm
2019-02-25 17:49:33,934 - Recv: echo: M149 C ; Units in Celsius
2019-02-25 17:49:33,938 - Recv:
2019-02-25 17:49:33,942 - Recv: echo:Filament settings: Disabled
2019-02-25 17:49:33,946 - Recv: echo: M200 D3.00
2019-02-25 17:49:33,949 - Recv: echo: M200 D0
2019-02-25 17:49:33,952 - Recv: echo:Steps per unit:
2019-02-25 17:49:33,955 - Recv: echo: M92 X80.50 Y80.50 Z1600.00 E418.50
2019-02-25 17:49:33,958 - Recv: echo:Maximum feedrates (units/s):
2019-02-25 17:49:33,960 - Recv: echo: M203 X300.00 Y300.00 Z5.00 E25.00
2019-02-25 17:49:33,964 - Recv: echo:Maximum Acceleration (units/s2):
2019-02-25 17:49:33,967 - Recv: echo: M201 X3600 Y3600 Z100 E10000
2019-02-25 17:49:33,970 - Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
2019-02-25 17:49:33,972 - Recv: echo: M204 P2400.00 R2400.00 T2400.00
2019-02-25 17:49:33,975 - Recv: echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
2019-02-25 17:49:33,979 - Recv: echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.40 E5.00
2019-02-25 17:49:33,982 - Recv: echo:Home offset:
2019-02-25 17:49:33,983 - Recv: echo: M206 X0.00 Y0.00 Z0.00
2019-02-25 17:49:33,986 - Recv: echo:Auto Bed Leveling:
2019-02-25 17:49:33,988 - Recv: echo: M420 S0
2019-02-25 17:49:33,992 - Recv: echo:Material heatup parameters:
2019-02-25 17:49:33,995 - Recv: echo: M145 S0 H180 B70 F0
2019-02-25 17:49:33,998 - Recv: M145 S1 H240 B100 F0
2019-02-25 17:49:34,000 - Recv: echo:PID settings:
2019-02-25 17:49:34,003 - Recv: echo: M301 P22.20 I1.08 D114.00
2019-02-25 17:49:34,006 - Recv: echo:Z-Probe Offset (mm):
2019-02-25 17:49:34,008 - Recv: echo: M851 Z-2.61
2019-02-25 17:49:34,011 - Recv: ok
2019-02-25 17:49:35,606 - Send: M105
2019-02-25 17:49:35,631 - Recv: ok T:225.06 /225 B:40.00 /60 @:56 B@:127
2019-02-25 17:49:37,607 - Send: M105
2019-02-25 17:49:37,634 - Recv: ok T:225.56 /225 B:40.29 /60 @:43 B@:127
2019-02-25 17:49:39,609 - Send: M105
2019-02-25 17:49:39,625 - Recv: ok T:226.00 /225 B:40.51 /60 @:35 B@:127
2019-02-25 17:49:41,611 - Send: M105
2019-02-25 17:49:41,639 - Recv: ok T:225.44 /225 B:40.64 /60 @:53 B@:127
2019-02-25 17:49:43,612 - Send: M105
2019-02-25 17:49:43,638 - Recv: ok T:225.00 /225 B:40.88 /60 @:61 B@:127


#7

serial.log (250.1 KB)

Here is the serial log and a picture of what happens - line 2292 is where i login with another browser.


#8

So, who is initiating these two commands?

2019-02-25 19:03:16,332 - Send: N854 M504*43
2019-02-25 19:03:16,344 - Send: N855 M501*47

These are usually not inside a GCODE model file to print.

M501 reads the EEPROM
and
M504 validates the EEPROM


#9

? not sure - BL Touch Plugin?


#10

Then try the whole thing with OctoPrint in Safe Mode.
When it's ok then, then it might be a plugin.


#11

Share your octoprint.log.


#12

I updated my firmware from 1.1.2 - 1.1.9 and did a dist OS upgrade on the raspberry pi and that seems to have solved the problem.