Upload, Upload and Print weird behavior

New to 3D printing in 2021, new to RPI and Octoprint too.

What is the problem?

So I have a weird behavior with the gcode file manager. When I upload to the RPI (not SD), my ArcWelder does its thing and then creates a new file. Both new files are greyed out at first. I tried the homing axes and it ungreys them if greyed out. The issue is when I tell it to load or load and print nothing changes in the GUI, file name doesn't show up STATE tab with either button. So if I delete the file and immediately reupload it automagically loads into the STATE TAB and is able to start printing.... Sometimes I have to reboot (not restart Octoprint) and then the trick works, never just works straight uploading and printing.

I've disabled and reenabled a bunch of mods and searched for it, found older tickets associated with some of the mods I had like gcode editor (which I uninstalled and no change), but nothing changes this behavior...

What did you already try to solve it?

WRITE HERE

Have you tried running in safe mode?

Yes

Did running in safe mode solve the problem?

I think so :stuck_out_tongue:

Complete Logs

octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)

WRITE HERE

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Running current Octoprint version 1.5.3 Python 3.7.3 OctoPi 0.18.0 and all plugins are updated and current. Using Smith3D 2.0.x.17 5x5HS on Ender 3 V2 with 4.2.2 and BLTouch. Using Google Chrome (running the octopi local in incognito mode).

WRITE HEREoctoprint.log (2.1 MB)

Tried in regular chrome (instead of incognito), no effect.

any other information I can provide to get some suggestions I will gladly follow. I know it's one of the plugins, I just can't figure it out.

If running in safe mode solved the problem, then its almost certainly one of the remaining plugins that is causing the problem. Use a binary search to determine which one.

If you aren't familiar with using a binary search it is really quite simple. Disable half of the remaining plugins and test. If the problem remains, the "bad" plugin is still enabled. Disable half of the remaining plugins and test. If the problem goes away, the bad plugin is in the half you just disabled. Enable half of the last group and test again.

Using this method should find the bad plugin in less than five tests (you have 40 plugins registered but quite a few of them are bundled).

1 Like