Hi,
The firmware is working well overall except that it won’t print with the runout sensor enabled. I see in a previous post here about the same problem it was suggested that m119 would be a way to get an idea of what’s going on. Via Pronterface I sent the command twice, once with runout sensor on, and once with it off. The result is the same as you can see:
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: TRIGGERED
filament: TRIGGERED
ok P15 B3
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: TRIGGERED
filament: TRIGGERED
ok P15 B3
Not sure how to resolve this. Definitely must have a working runout sensor.
Thanks,
David
This is interesting - if the sensor is a ON / OFF type - and not a motion based one - this may well indicate either a faulty sensor, or the level setup is incorrect in the configuration.
Normally, the problem we see for wiring etc is that the signal is reversed - but if both with and without filament produce TRIGGERED as a status, then there is no way we can detect what’s going on.
Is it possible that the sensor is a rotary encoder type sensor which sends a pulse as the filament moves?
Hi!
Thanks for getting back to me.
It is the stock runout sensor supplied with the CR-10 S5. I’ve taken a couple photos of it, one with it opened up and you can see that it has a little pressure triggered switch just like an endstop switch, so it seems that if there’s no filament then the switch opens.
I have tried this firmware on two machines and both have the same issue with the runout sensor, so I don’t think the part is faulty.
Here are a couple of photos:
I might have replied to this earlier but I’ve been under the weather, and just getting back to work now.
Thanks,
David
I just tested it again, and, as before the results are the same regardless of the state:
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: open
z_min: TRIGGERED
filament: TRIGGERED
ok P15 B3
>>> m119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: open
z_min: TRIGGERED
filament: TRIGGERED
ok P15 B3
However, you’ll note that the result itself is different in so much as it now shows “x_min: TRIGGERED”, whereas previously that value was “open”.
This is interesting - the fact that you never see open as a status means that there’s no way that the firmware can tell if the switch itself is triggered…
The config used for the filament sensor on that particular printer is:
#define FILAMENT_RUNOUT_SENSOR
#if ENABLED(FILAMENT_RUNOUT_SENSOR)
#define FIL_RUNOUT_ENABLED_DEFAULT true // Enable the sensor on startup. Override with M412 followed by M500.
#define NUM_RUNOUT_SENSORS 1 // Number of sensors, up to one per extruder. Define a FIL_RUNOUT#_PIN for each.
#define FIL_RUNOUT_PIN 2 // Creality CR-10 S5 stock sensor
#define FIL_RUNOUT_STATE HIGH // Pin state indicating that filament is NOT present.
#define FIL_RUNOUT_PULLUP // Use internal pullup for filament runout pins.
#endif
So this could be a couple of things:
- The pin is wrong
- The Runout State is wrong - however in that case, we’d still expect to see a transition from
TRIGGERED to open - just in the reverse order
- The PULLUP state should be PULLDOWN instead… I don’t recall off hand how this bit works - so I’d have to take some time to dig into if that would show what you’re seeing or not…
I’ve raised this on the Marlin discord - but not having any of this hardware, it becomes difficult to experiment with the cause of the problem by trial and error…
Maybe someone has one that they can experiment on - or is in a bit better of a place where they can mentally debug the issue…
In fact, just as a second thought - just to make sure we’re not chasing our tails - when you have the sensor disassembled, does M119 show anything different when you manually press the microswitch to trigger it?
EDIT: Thinking further again - are you able to plug in your X or Y endstop into the filament sensor port and repeat the same test with manually pressing the endstop switch to see if that changes between TRIGGERED and open - that might rule out a hardware / switch issue completely…
In fact, digging deeper into this - if you were using the Firmware Builder to build for your printer, it looks like there might have been an interaction with set options that FORCED the sensor to be set up as a motion sensor - even if you told the builder that it wasn’t a motion sensor.
I’ve made a slight change to that logic now - are you able to build a firmware again and see if that resolves the issue?
I just swapped the runout sensor just to rule out that it’s not a defective unit, but the result was the same error as before, so I’m pretty sure the problem is not due to faulty equipment.
I can do a new build and flash of firmware with the changes you just made, or I can do the experiments you suggested, or both. I have (2) CR-10 S5 machines set up currently.
Just now I noticed that one machine’s firmware does not have runout sensor option in the menu. In getting these machines together I’ve done several iterations with the firmware builder and it seems the two machines are running slightly different versions after all. However, the one configured for runout sensor is most certainly having problems.
In the Firmware Builder runout sensor options I see:
Use HIGH signal for out of filament
and
Use LOW signal for out of filament
Which of these options should I choose? What signal is being referred to?
Leave the options as default for your printer - as that should work if its the stock configuration of items.
Given the bug I just fixed in the firmware builder, it may well just need a new compile with the default options…
If you’ve changed them in a profile, create your profile again just to make sure its set up correctly.
So that means don’t check either one of those options? Leave them off?
The default options should be as follows:
That’s with no profile and loading the default configuration into the builder.
Okay, but now the build is failing . . .
Oh Jeez - in an embarrassing and unrelated problem, the build server ran out of disk space hahahaha
That’s fixed and it should compile ok now…
Okay! Thanks!! I’ll try again now.
1 Like
I’ve just updated the firmware, and now I’ll set up the machine again and then test the filament sensor. I’ll let you know how it goes. Thanks!!
Well . . . Sorry to report it’s still doing the same thing!
Just to be a pain, can you start again with a new build (ie not load a profile) and see how that goes?
Loading from a profile may well bring in the wrong settings that you won’t be able to see…
I believe I did start that last one from scratch, and not from a profile. I was about to try again and set it for LOW instead of high and see if that makes a difference.
Anyway, I’ll make a fresh build with default settings and try it again momentarily.
The HIGH / LOW shouldn’t matter at this point - this would only make a difference if the settings were reversed - ie it detected a filament out when there was filament inserted, and also thought things were fine when the printer had no filament inserted.
They key part again will be testing with M119 with filament in the sensor, removing the filament from the sensor, and running M119 again. Hopefully - one should show open, the other one should show TRIGGERED. As long as there’s a difference, we can fix that bit easily.
If there is no difference between the two states, then we have a different problem that we haven’t quite figured out yet…
