Factory Filament Sensor, works on SD but not octoprint?

What is the problem?

Factory fitted filament sensor doesn't work with octoprint, but works ok when printing from SD card.

What did you already try to solve it?

Try SD card printing, it works ok

Have you tried running in safe mode?

no

Did running in safe mode solve the problem?

no

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

Printer: BIQU B1
Firmware: looxonline INSANE RES for BIQU B1
Raspberry Pi: 3 Model B+

I have done some research and seen the people connect there microswitch to the raspberry pi. That's fine, but why? Isn't there a way it can work whilst being plugged into the printer? And send the signal through the USB cable to the raspberry pi?

Hello @Joe_Morgans !

To give a more defined answer, there are missing some information here (printer, firmware etc).

All we can say now is this: Some printers do not support all important features that the firmware can provide.

The firmware in the printer needs to support sending "out of band" messages through the USB. If the firmware is Marlin-based, then HOST_ACTION_COMMANDS and HOST_PROMPT needs to be enabled in the firmware. See the following for more detail (or search this forum for either or both of the above).

1 Like

Thank you for your quick responses!

I have checked the firmware, HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT are both enabled already.

I tried sending a M412 to recieve a filament sensor reading (someone else done this in the mentioned thread), but this happens:
Send: M412
Recv: echo:Unknown command: "M412"
Recv: ok

What can I do? Is it octoprint settings?

First, enable the serial.log (click on link for details). Then start a print using OctoPrint and force a filament failure.

Upload a systeminfo bundle (click on link for details) which will include the serial log and we will take a look.

My guess is that even with the right firmware options, it is still up to the firmware to initiate the communications and your printer's firmware isn't doing it. Since the firmware is based on Marlin, the Marlin license says that the firmware sources must be made available. Ultimately, this issue will need to solved by examining the source. Alternatively, the configuration files of the current firmware and the current generic sources for Marlin can be used to create a version of firmware for your printer that should work.

@Joe How sure are you that the version of source you are looking at generated the object file used to flash your printer?

Using OctoPrint's Terminal Tab, send an M115 to the printer and post the results here.

Send: M115
Recv: FIRMWARE_NAME:Marlin bugfix-2.0.x (Jul 19 2021 19:40:44) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:BIQU B1 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:RUNOUT:0
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:1
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:1
Recv: Cap:PROMPT_SUPPORT:1
Recv: Cap:SDCARD:1
Recv: Cap:REPEAT:0
Recv: Cap:AUTOREPORT_SD_STATUS:1
Recv: Cap:LONG_FILENAME:1
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:ARCS:1
Recv: Cap:BABYSTEPPING:1
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: area:{full:{min:{x:-3.0000,y:-2.0000,z:0.0000},max:{x:235.0000,y:243.0000,z:270.0000}},work:{min:{x:-3.0000,y:-2.0000,z:0.0000},max:{x:235.0000,y:243.0000,z:270.0000}}}
Recv: ok
Send: M155 S2
Recv: ok
Send: M876 P1
Recv: ok

Sorry, I don't understand what you mean

Sorry I assumed that you were looking at the source .h files to see what options were enabled but from you're response I guess you were using M115.

BTW there was an issue with bug fix versions recently

Oh I see, I used looxonline INSANSE RES for BIQU B1 firmware, and made some minor changes in visual studio, then compiled it my self. Looking at the config files, HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT are uncommented.

octoprint-systeminfo-20210803184316.zip (71.1 KB)

Here you go.

When removing the filament, there was no effect on the printer, it continues to print.

The LED on the filament sensor it working correctly.

FYI, I accidently left octolapse running on this print.

Obviously the runout sensor is not activated in the firmware.

But op states "Factory fitted filament sensor doesn't work with octoprint, but works ok when printing from SD card."

Interesting that notes for M412 are
" Requires FILAMENT_RUNOUT_SENSOR .
Parameter D requires FILAMENT_RUNOUT_DISTANCE_MM .
Parameter H requires HOST_ACTION_COMMANDS ."

Just checked the configuration.h and found this...

Shall I enable:
//define FILAMENT_RUNOUT_SENSOR

1 Like

Who knows what wired stuff happens in the firmware...
Maybe there is a different runout routine

I have now enabled #define FILAMENT_RUNOUT_SENSOR in the firmware, and now octoprint comes up with a pop up saying: message from printer, no filament. (Even though there is). Triggering the switch doesn't have any effect at this point.

Ok, I think I know what the problem is. My filament sensor is plugged into my TFT screen on the printer, not the SKR 1.4 board.

I read this website: Adding filament sensor in SKR electronics (MINI E3, v1.3, v1.4 and v1.4 Turbo) - 3DWork
I unplugged the filament sensor from the TFT screen and plugged it into the E0DET port thinking this would fix it, but still no luck.

Now I think I either have it plugged into the wrong port on the SKR V1.4, or the pin configuration is not correct. This is all new to me and I am completely and utterly out of my depth! Please can someone suggest what to try next?

Seems like you are getting somewhere, but it is also interesting how the runout sensor was setup on the screen. I've not seen it like that before, but I guess the screen was just telling the printer to pause, but of course it was telling the wrong person since OctoPrint was in control.

That looks like the right pin (can see it in the Marlin source code), it's labelled right and it looks like they are both using the GND pin.

Are you able to test with M119 to see if maybe it is inverted? Take the filament in & out and test it to see if there's any change?