"Only show files stored on SD" doesn't show any files

Get Help
,
1

What is the problem?

In the file browser, when "Only show files stored on SD" is selected, it doesn't show any files from the SD card attached to the printer itself. Also, the "Upload to SD" button is disabled. However, "Enable SD support" is enabled in the Features menu, and I can see and start a print from the SD via the printer's own control panel.

The terminal does show this:

Recv: ok
Send: M155 S10
Recv: ok
Send: M20
Recv: Begin file list
Recv: PRUSA3~1.BBF
Recv: TFP-PL~1.BGC
Recv: End file list
Recv: ok

Have you tried running in safe mode?

Yes.

Did running in safe mode solve the problem?

No.

Systeminfo Bundle

octoprint-systeminfo-20241029111203.zip (32.4 KB)

FYI, attempting to generate the systeminfo bundle while in Safe Mode caused my Raspberry Pi to crash and I had to manually power-cycle it.

Additional information about your setup

OctoPrint 1.10.2
Python 3.9.2
OctoPi* 1.0.0cam (build 2023.07.20.144556)

Prusa MK3.5s

2

These files appear not to be usual gcode files.

3

TFP-PL~1.BGC is a bgcode file.

4

As I said: Not usual.

5

Why would Octoprint need to know whether a particular file is printable or not? Isn't it the job of the printer firmware to make that determination?

6

This is not how OctoPrint and usual marlin works.

Files are not transferred as a whole from OctoPrint to the printer. It is done line by line.
Therefore OctoPrint relies on readable gcode files so it can react on certain things during that procedure.

And don't blame OctoPrint for that: It is the way Marlin works when getting data from a host.

There have been discussions on support compressed gcode files:

7

This is not a bgcode issue. Octoprint is capable of monitoring the print when I start the print from the printer itself.

The problem is that Octoprint doesn't see any of the files on my SD card despite being told what they are.

8

That is a BINARY gcode file a standard gcode file ends with .gcode

9

It is a bgcode issue. OctoPrint doesn't recognize Binary gcode

10

I know that, but I don't see what your point is. When the printer prints a gcode or bgcode file from SD, Octoprint is already capable of monitoring the print. That's not my problem.

My problem is that the file viewer doesn't show any files, and so I can't start any prints from within Octoprint.

11

Ok - so you are saying, since the file manager doesn't 'see' the file, you can not start the file from OctoPrint. You can monitor the print (probably because of Host Action Prompts and other plugins.
To get you going, you can use the Terminal (if Prusa didn't mess that up with everything else)
Send an "M20" to get the list.
Send "M23 filename"
Send "M24" to start.
I heard about some changes to the file manager but don't remember what they are.

12

Isn't this something that I should be able to do via the Octoprint GUI?

It would be less work to walk to the printer and using the control panel.

13

Another MMTB.
Well, do that then. What ever is easier for you.

14

Because OctoPrint ONLY shows files with the extension .gcode
It will not show any file just because it's on the SD card

15

This seems like an odd thing to have hard-coded, because it's not Octoprint's job to decide what files the printer can or cannot print.

16

then put in a feature request. I didn't write the software

17

As a test, I put a traditional, text-only .gcode file on the SD card and inserted it into my printer.

Recv: ok
Send: M21
Recv: ok
Send: M155 S10
Recv: ok
Send: M20
Recv: Begin file list
Recv: STAR_0~1.GCO
Recv: End file list
Recv: ok

The files window still shows no files:

Screenshot from 2024-10-30 10-21-33
Screenshot from 2024-10-30 10-21-33619×569 53.2 KB

So once again, this has nothing to do with bgcode.

18

Dumb question: You've enabled the SD support in the OctoPrint settings?

grafik
grafik756×584 30.7 KB

19

Yes, it's enabled. It's the first thing I checked.

1 Like
20

FYI, gcode not being recognized as extension has been fixed for 1.11.0

And the file list not updating turned out to be a firmware bug - yet again: