Welcome! Log In Create A New Profile


Jam detection

Posted by scuba 
Jam detection
March 16, 2015 06:24AM
I've noticed shortly that repetier fw is going to get a new "jam detection" option in version 0.92.3. You can find the code in the repetiers dev. branch.
First at all: Great idea! Thank you very much for this Roland!!

Has anybody already played around with it or does anybody know about popular hardware designs for the filament sensor?

As far as I can see the filament should turn a wheel/axis which triggers a switch/light barrier each revolution while running trough the "filament sensor". The sensor might be connected to any free digital pin (i.e free endstop connector) so repetier fw can count the revolutions of the sensor axis and compare it with the amount of steps the extruder should have moved. When the difference is too big an action is triggered. Repetier also slows down your printing speed

Sounds quite simple but there are still some questions:
- What's about retractions ? Are they calcualted too?
- What's about multi extruder setups? It's possible to configure JAM_Pins for EXT0 and EXT1 but the other "jam parameters" seems to be common for both extruders. At Least "JAM_STEPS" should be configurable individually.

There's is a similar project with a little bit different approach.
A seperate pcb based on an atmega168 messures the turns of an mechanical 24PPR wheel encoder and sets its output pin high in case of an failure. So the firmware has to handle the particular action if this pin his high. (they offer a patch for marlin).

In summary I would prefere repediers solution cause it's much simpler and cost efficient on the hardware site and offers more options cause the fw knows about the state of the sensor and not only if there was an failure or not.

Although this a quite new and fresh feature it would be great if Roland could shade some light on this or if you all could share your experiences with this.
Re: Jam detection
March 16, 2015 08:41AM
Good summary.

Retraction: Firmware knows direction so it knows if switched signal came from up/down movement. So it also takes retractions into account.

You can have a jam detector on every extruder, which is why you have pin settings in extruder definition. But we assume similar extruders so that all other values must be the same for all extruders. That should be no problem since you should always some error margin (30% or more) so that small difference will not trigger a signal. A real jam will hit any step marker you set even 200%.

I would not make the wheel to fine. Even one signal every turn will work. 8-16 Signals per turn is a good compromise between precision and trigger time. Remember if you signal switches every 10 extruder steps 10% is only one step! And there will be always a difference.

Also you need to think about position. Since it counts against the extruder, it should be placed near the extruder. At the end of a bowden it makes no sense and would require VERY high error margins.

For reference from the firmware installation guide:

Jam and out of filament detection

From 0.92.3 onwards the firmware supports jam and out of filament sensors. These sensors work quite simple. Filament goes through
the sensor and turns a wheel. The turning wheel turns a switch on/off. This might be a mechanical switch, but contact less switches
like light barrier or hal sensor are better. One on/off cycle should always need nearly the same amount of extruder steps (JAM_STEPS).
Between changes the sensor might flip back to old signal, so we require JAM_MIN_STEPS since the last change before we assume the signal as
changed again completing the cycle.
If the extruder starts
to slip it will take more and more steps for a full cycle. Based on the steps we can follow, that we have a problem. If we have only a mild increase (> JAM_SLOWDOWN_STEPS)
extrusion gets heavier due to partial clogging or reduced grip. In that case we reduce speed by setting speed multiplier to JAM_SLOWDOWN_TO.

If we need more then JAM_ERROR_STEPS steps, we assume a more serious problem that even reduced speed could not solve and take the action defined with JAM_ACTION, preferably something that pauses the running print.

Action 0 does simply print a warning on the LCD and lets the printer beep. Action 1 is my preferred solution, but requires a LCD screen. It will block
any host communication preventing further print, moves extruder to filament change position and disables temperature and all motors, which would home
after filament change. Then it waits for the user to react. First click on LCD will reheat extruders. Then you have to wait until all extruders are back on
temperature. After that you can move extruder with your click encoder to remove filament, test if extrusion works, etc. During this period jam detection is disabled! Action 2 will request a pause from the host or pause a sd print.

To handle the new feature, there are some new commands:

M513 resets the jam signal, so the printer stops complaining about jam and also disables the beeper.
M601 S1 pauses extruder temperatures while M601 S0 restores the temperatures before the pause.
M602 S<1/0> P<1/0> is for debugging jam (S value) or disabling jam control (P value). If you enable jam debug, the firmware will not execute jam
actions. Instead it will write the signal switch steps and percent values into the host log. That way you can calibrate your 100% value.
This is also useful to find out at which extrusion speed the forces get too high, so that extruder starts to slip.

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!
Re: Jam detection
March 16, 2015 10:30AM
Thanks for your quick and detailed answer repetier!

Great to hear that retraction is no problem but too bad for the multiple extruder part. One of my old printers uses a comibination of bowden and geared wade extruder where it would be useful to have different configuration options.

Placing the sensor near the extruder is one thing I haven't thought of... but it sounds reasonable. I don't see any problem with bowden setups where size and weight of the sonsor doesn't matter, but for axis mounted extruders you would have to look for a small and light designe. The other project i've posted befor might be way to large for this kind of setup.
Re: Jam detection
March 16, 2015 10:40AM
Just for your information - my testing sensor weights about 25gramm. That is not very much and should not be a problem for a direct extruder. With some better planning that might even go down.

As I said, with different extruders use the one with the most steps per mm as reference and both will work, just one will signal a bit later. If you print discs for light make one with more gaps to compensate.

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!
Re: Jam detection
March 16, 2015 10:46AM
Yeah... found a great sensor solution for a standard wade or even a bowden Extruder
Re: Jam detection
March 16, 2015 10:56AM
Yes, that is a nice idea. You only need in addition some way to increase grip on the idler or it might not rotate 100%. Steep is very slippery. Maybe a very small rubber band is all we need here to put over the bearing.

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!
Re: Jam detection
March 16, 2015 11:58AM
True... or try to rough the bearings surface with a file...
Re: Jam detection
February 10, 2016 09:35AM
If I could ask a few dumb questions since I read over this and thought about it for some time. I have a filament out detector and would like to use the mechanics of it (the encoder wheel) with repetier so I can get the slowdown feature instead of using its output which just sets a jam error. I was trying to understand how everything works but for some reason could not get my head around the math. Here is what I have:

Encoder that outputs 24 steps per 360 degrees. I calculated about 47mm of filament in makes one revolution.
What I am not sure about is how I tie this to the extruder steps. If my extruder is lets say at 3200 steps per revolution and is at 98 steps per mm, do I do that math and figure out the breakdown of how many steps (98 * 47) it takes to move the encoder full circle then divide by 24 (steps per rotation)?
The other thing I could not understand just from the examples is the thresholds. Is JAM_STEPS the number of extruder steps it takes per step of the encoder output? How do you determine the SLOWDOWN steps and ERROR steps? A percentage of steps or what?

So if it takes 98Esteps*47mm to get 24 encoder outputs then that would be ~192 JAM_STEPS (or how many eSteps it takes for one step of the encoder)? If this is true, how do I calculate the other values or am I completely off base? I could just use the native output of the filament detector (Tunell) but like I mentioned, I would like to have the slowdown / slip detector also so I just wired across the encoder A and Common to an unused endstop pin.

Re: Jam detection
February 10, 2016 09:52AM
24 switches per revolution = 12 cycles? Anyhow I assume this. So one cycle is 47/12 = 3,92 mm => 3,92 * 98 steps per mm = 383 steps per cycle = 100% on ideal condition.

Now you could set 70% for slip detection so once it reaches 383/0.7 = 547 you will slow down to 70%

Take 766 for jam detection and let the print stop.

Best is of course to check in log how many steps per cycle are normal and how good distribution really is. You never get perfect match depending on friction/encoder quality etc. From this you could do the same adjustment I did for theoretical values.

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!
Re: Jam detection
October 06, 2016 01:45PM
I'm new here and I would like to understand better the idea of steps as something in my head does not connect in a good way smiling smiley
I've printed two encoder wheels. See attached picture. On this one with less gaps (24) to have ~100% value during debug I had to set JAM_STEPS was 85. Comparing to default value it was to small so I printed new wheel with 55 gaps and suprisingly I had to lower down JAM_STEPS value to get ~100% in debug.
Also I do not understand meaning of the value JAM_ERROR_STEPS. In my mind problem should be reported when filament does not move so number of steps is lower then some value. Or...
Writing this I started to think that maybe I look at the problem on encoder side not extruder motor. And looking from extruder motor side it would be: (default) number of steps 500 and no change signal on encoder side = we have problem?
And from your point of view which encoder wheel should be better? The one with big number of gaps can be too sensitive, am I right?

Edited 1 time(s). Last edit at 10/06/2016 01:46PM by samezrp.
open | download - 20161006_194042.jpg (125.1 KB)
Re: Jam detection
October 13, 2016 11:32AM
I am not sure if I understand all that has been said above.
I am more interested in filament out than in jam.

My plan is/was to guide the filament through a micro switch that closes a circuit to give an alarm through all of my house :-)
With my switch positioned far away from the extruder, there is enough time to run to the garage, hit the repetier-host pause button and replace the spool.

Am I correct that I can feed the switch output to a RAMPS pin in a way that repetier-host will go into pause and stop all heaters ?
So I can come later , replace the spool, reheat the stuff and hit resume ?

If so.. where can i find the pin configuration for RAMPS ?



Orca V4.4 rebuild to Ramps with Mk8 and E3D, as well as a Rostock Delta Mini and an OLO in backorder :-)
Sorry, only registered users may post in this forum.

Click here to login