Integrate Signal from Optical Sensor to Track Filament Movement #1558

rf1k-mjh11 · 2015-03-04T15:37:08Z

I've started passing my idea around to Firmware & host software programmers.

The optical motion sensor in a generic mouse has a resolution of 800-1000dpi. It can pick up the movement of the filament forwards and backwards. (Better to track the movement of the idler bearing/pressure bearing to avoid filament color/transparency issues).
If the firmware were to compare the extruder feed commands with signals returned by the sensor, several error conditions could be acted upon in time:

Out of filament
Missed steps
Sudden, or imminent nozzle clogging
Failure of the hot end heater
Excess speed (resulting in excess pressure, resulting in increased slippage of the hobbed bolt, or missed steps)

If this idea were implemented in the firmware, the firmware would need to process the output signal (sent via USB) from the (mouse) sensor and compare it to the recently sent GCodes.
With sufficient resolution it may even be possible to use the signal as a feedback loop to regulate temperature during high speed printing - the higher the print speed, the higher the pressure in the hot end, and the higher the slip rate will be (despite the hobbed bolt!!). I think you will see slip rates between 0-8%, despite thinking the hobbed bolt acts like a gear (just like a car tire - as soon as there is some elasticity in the system, you will get slip). So if the firmware registers a higher slip rate, it could increase the temperature slightly to compensate.

I'm not a programmer or good with electronics. I'm just providing an idea. I've also plugged it to the Repetier-Host people, since it would also be possible to handle this through the host while printing.

If the idea is unclear and you'd like it in German, drop me a line & I'll do it in German - kein Problem.

mjh11

alexborro · 2015-03-04T15:42:17Z

Hi @rf1k-mjh11 (please, tell us your name, it is strange talking to nicks like alsdfjasldfm)

Don't mind your English, it is pretty good and your message is clear.

I'm thinking about this idea.. But I don't like to use scrap parts, I mean, parts from a broken mouse. First we need to know how to source the sensor.
Then using USB to do this is not acceptable - at least to me. We need to know what is the sensor native comm protocol.. And then try to implement it in Marlin.

Do you have more specs about the sensor?? A datasheet and a place to source one is welcome.

Cheers.

Alex.

JustAnother1 · 2015-03-04T22:16:07Z

The ADNS2610 / ADNS2620 was an option. Data sheet:
http://www.efo.ru/components/avago/catalog/files/pdf/5988-9774EN.pdf
Interface is SPI. But the chip is not available anymore.

boelle · 2015-03-05T16:20:01Z

hmm i like the idea too, but it can be more simple...

i picture the slotted wheel from a mouse with ball... attach such a wheel to a roller with a hobbed section... and then a pinch roller on the other side... almost like an extruder

then a simple opto unit that sends ir light from one side and ir sensitive transistor on the other side...

hope everyone gets the picture

rf1k-mjh11 · 2015-03-05T17:15:53Z

Bo,

There is a fellow in the /RF1000.de/ forum who has a similar approach
implemented. He doesn't use the hobbed bolt, but has a printed disk
attached to the idler bearing with several magnets embedded. Then he
has a Hall-effect sensor pick up the signal.
Unfortunately, his resolution is currently only 6.3mm (1/4"). His
system is self-contained, with its own electronics.

Your approach would also work off of the idler bearing. Just attach the
slotted disk to the bearing. The resolution would be around 1mm,
depending on how fine the slots are.

Mike

On 03/05/2015 17:20, Bo Herrmannsen wrote:

hmm i like the idea too, but it can be more simple...

i picture the slotted wheel from a mouse with ball... attach such a
wheel to a roller with a hobbed section... and then a pinch roller on
the other side... almost like an extruder

then a simple opto unit that sends ir light from one side and ir
sensitive transistor on the other side...

hope everyone gets the picture

—
Reply to this email directly or view it on GitHub
#1558 (comment).

rf1k-mjh11 · 2015-03-05T17:31:41Z

Alex,

Sorry about the nik, it's one nik I use for all my 3D printer-related
activities. It was created out of the nik I had for decades at my old
company (from before email & the web), plus my latest printer, the RF1000.
I try to keep my internet presence low - paranoia, I guess.

I've gotten some response from others (Repetier, etc.). And a Lars
Pötter found a chip (out of production?) that seems to be used in
optical mice.
http://www.efo.ru/components/avago/catalog/files/pdf/5988-9774EN.pdf

But again, I'm not an electronics guy, nor very good at programming (I
dabble a bit in VBA when working on Excel macros). Because of this,
even your statements about "native comm protocol" are just "gobbledy
gook" to me.
Admittedly, I was looking for a simple solution, and, while using a
broken mouse seemed like an option, since a mouse only costs €6
nowadays, buying a new one and cannibalizing it for its sensor seems
reasonable to me.

Maybe it would all boil down to a solution using a separate processing
setup, that ends up sending one simple signal to the
motherboard/firmware. Sort of like the LED screen you can buy to add to
your Printrboard, or Gen6. /A "Filament Watchdog" add-on/, complete with
sensor & electronics - all the firmware has to do is provide an
interface (which I think it already does).

Thanks for spending the time on the idea,

Mike

On 03/04/2015 16:42, alexborro wrote:

Hi @rf1k-mjh11 https://github.com/rf1k-mjh11 (please, tell us your
name, it is strange talking to nicks like alsdfjasldfm)

Don't mind your English, it is pretty good and your message is clear.

I'm thinking about this idea.. But I don't like to use scrap parts, I
mean, parts from a broken mouse. First we need to know how to source
the sensor.
Then using USB to do this is not acceptable - at least to me. We need
to know what is the sensor native comm protocol.. And then try to
implement it in Marlin.

Do you have more specs about the sensor?? A datasheet and a place to
source one is welcome.

Cheers.

Alex.

—
Reply to this email directly or view it on GitHub
#1558 (comment).

alexborro · 2015-03-05T20:46:53Z

I did a test here with my Microsoft Mouse and it could "sense" the filament
pretty well. even a transparent Tritan I have laying around.

But I don't like USB communication. I will try to source a cheap chinese
mouse, put it apart and figure out the communication protocol of the chip..

Cheers.

Alex.

2015-03-05 13:20 GMT-03:00 Bo Herrmannsen notifications@github.com:

hmm i like the idea too, but it can be more simple...

i picture the slotted wheel from a mouse with ball... attach such a wheel
to a roller with a hobbed section... and then a pinch roller on the other
side... almost like an extruder

then a simple opto unit that sends ir light from one side and ir sensitive
transistor on the other side...

hope everyone gets the picture

—
Reply to this email directly or view it on GitHub
#1558 (comment)
.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

whosawhatsis · 2015-03-05T23:06:53Z

@rf1k-mjh11 Are you aware of the filament monitors using encoders like this one? http://www.toybuilderlabs.com/products/tunells-3d-printer-filament-monitor-for-makerbots

rf1k-mjh11 · 2015-03-06T07:39:13Z

@whosawhatsis https://github.com/whosawhatsis,

This looks a lot like the solution a fellow is using at RF1000.de (Link
http://www.rf1000.de/index.php/kunena/erweiterungen/401-neues-andrucksystem-mit-integrierter-ueberwachung#3597
, sorry, it's in German) - but he uses a disc with magnets & hall effect
sensors. I think he only gets 6 or 8 pulses per revolution, translating
into a resolution of about 6.5mm. That is miles (kilometers) away from
the 800-1000dpi that the optical sensor from a mouse delivers - but his
solution is up & running.
My idea is currently looking like it needs its own dedicated
(complicated) circuit to be able to interface to the firmware/printer.
But I'm not giving up hope.
I think both systems, the one you quoted, and the one from RF1000.de,
use very simple logic to determine a jam, i.e. if no filament movement
at all occurs for longer than a preset time, let's say 3.5 seconds. I
don't think either of them actually react to the actual GCode commands.
So, if, for whatever reason, the printer were to pause for 4-5 seconds,
those systems would trigger a false alarm, due to no filament movement
occurring for more than 3.5 seconds. But, I'm not sure how they work,
so I could be wrong. Maybe all you need is to use the simple "timeout"
solution.
_
Or, is it possible to simply "eavesdrop" on the signals being sent to
the extruder stepper motor and then expect a signal from the optical
sensor (practically in real time)__?_ (<== New idea!) There would be no
need to pass through the GCodes and process them. This solution
probably couldn't differentiate between a retract motion and a normal
extrude, but would it matter? The sensing of the current being sent to
the extruder stepper could even be done indirectly (AFAIK, there is
always a current, but it pulses during movement?).

Since I'm not electronics savvy, nor a programming genius, but just a
mechanical engineer, I'm hoping someone in the scene can make use of the
idea. I posted it on multiple sites to prohibit anybody else from
patenting the idea and making money off of it.

Mike

On 03/06/2015 0:07, whosawhatsis wrote:

@rf1k-mjh11 https://github.com/rf1k-mjh11 Are you aware of the
filament monitors using encoders like this one?
http://www.toybuilderlabs.com/products/tunells-3d-printer-filament-monitor-for-makerbots

—
Reply to this email directly or view it on GitHub
#1558 (comment).

whosawhatsis · 2015-03-06T18:41:27Z

That one uses a self-contained encoder like this one: https://www.sparkfun.com/products/10982

I believe it has a small microcontroller that just watches for the filament to stop moving for X seconds, and pulls a digital pin high to alert the printer if that happens. No integration with the information of what the extruder's trying to do.

JustAnother1 · 2015-03-06T19:41:16Z

A simple implementation could be to count the Steps on E in a variable and subtract the increments reported by a sensor from that value. This way the variable should always have a value around 0. once the value increases above a certain limit we know that an error has occurred.

As configuration Items this would need the Limit for alarm and a Increment to Step ratio for calibration.

thinkyhead · 2015-03-07T00:15:05Z

A simple continuous potentiometer articulated by the extruder idler might be another cheap alternative, assuming it can be pretty frictionless.

rf1k-mjh11 · 2015-03-08T15:20:31Z

I realized some time ago, that there may not be a reason to actually process/read the gcodes passing through to the printer. Could one just simply sense the current going to the extruder stepper? When stationary, current is constant. When it is (or should be) moving, the current pulses.

One should be able to pick this pulsing up, without a direct electrical connection, and compare it to a signal from the optical sensor. That is, whenever there is a pulsed current on a stepper lead, a movement signal should be expected. I know you can pick up very strong currents, without actually being in the loop/circuit, just by sensing the field the current generates.
I am not sure if you could detect which DIRECTION the stepper is moving, But that is secondary. The main thing we want to track is that the filament moves when it should. (I sincerely think it's highly unlikely that we tell the stepper to retract filament, yet the filament decides to extrude, and the same vice a versa).

BTW, I came up with several single-piece chip solutions for the sensor. Only one that I found has a PS/2 protocol, the others USB. But I'm sure there are more around.
PAN3401 (PS/2)
The PAW range (PAW3504, PAW3512DK, PAW3515DB), and NST's M16175 (all USB).
The data sheets, with pinouts, etc. seem to be available on line, but it is incomprehensible to a non-electronics person like me.

I have the data sheets on the chips I listed, but don't know how to upload here.

Mike

rf1k-mjh11 · 2015-03-08T15:22:40Z

BTW, I bought a Fujitsu mouse for €4.99, took it apart and looked at the chip. That is how I 'discovered' the others on the web.

alexborro · 2015-03-08T15:30:45Z

Mike, stepper motors don't work like that.. You cannot use the current
information to sense the motor load like you do in a regular DC motor. It
is feasible, but not easy.. The added complexity (and additional chips) is
not worth it.

And I will look the datasheet of the chips you figure out.

Cheers

Alex.
Em 08/03/2015 12:22, "rf1k-mjh11" notifications@github.com escreveu:

BTW, I bought a Fujitsu mouse for €4.99, took it apart and looked at the
chip. That is how I 'discovered' the others on the web.

—
Reply to this email directly or view it on GitHub
#1558 (comment)
.

rf1k-mjh11 · 2015-03-08T16:09:17Z

Alex,

I know that the motor is always receiving current, even when it is
stationary. But whenever the stepper moves the current to one of its
coils either turns off or on, or changes polarity. That change in
current could be sensed remotely and used as proof that the extruder
should be moving filament.

Actually, I guess what I'm talking about now is, again, more of a
discrete electronic circuit, which would only contact the firmware via a
"high" or "low" signal. Then the firmware would perform some predefined
script. It probably wouldn't be possible to have a true feedback loop,
but I'm not competent enough for that.
Still, the system would be able to detect an out-of-filament condition,
jammed/clogged extruder (with or without a stalled stepper motor). It
probably would not be able to discern mere slippage, as long as it
detected movement.

Have a nice Sunday,

Mike
On 03/08/2015 16:31, alexborro wrote:

Mike, stepper motors don't work like that.. You cannot use the current
information to sense the motor load like you do in a regular DC motor. It
is feasible, but not easy.. The added complexity (and additional chips) is
not worth it.

And I will look the datasheet of the chips you figure out.

Cheers

Alex.
Em 08/03/2015 12:22, "rf1k-mjh11" notifications@github.com escreveu:

BTW, I bought a Fujitsu mouse for €4.99, took it apart and looked at the
chip. That is how I 'discovered' the others on the web.

—
Reply to this email directly or view it on GitHub

#1558 (comment)
.

—
Reply to this email directly or view it on GitHub
#1558 (comment).

rf1k-mjh11 · 2015-03-08T16:26:28Z

Scott,

Wouldn't a continuous potentiometer go from
high-resistance-to-low-resistance, then suddenly back-to-high-resistance
again, during a full revolution?
How would the software or circuit deal with that?

Mike
On 03/07/2015 1:15, Scott Lahteine wrote:

A simple continuous potentiometer articulated by the extruder idler
might be another cheap alternative, assuming it can be pretty
frictionless.

—
Reply to this email directly or view it on GitHub
#1558 (comment).

thinkyhead · 2015-03-09T04:27:26Z

@rf1k-mjh11 A very large change can be easily software-corrected. The software takes note of the highest resistance value read and uses it as a threshold. You also need to pick some value over which a move must be considered to be going the other way. The calculation works something like:

...
delta = new_pot_value - prev_pot_value;
adelta = abs(delta);
if (new_pot_value > pot_threshold) pot_threshold = new_pot_value;
if (adelta > pot_max_possible_move) delta += pot_threshold * (delta / adelta);
prev_pot_value = new_pot_value;
...

boelle · 2015-03-10T21:55:26Z

i think the rot. encoder mentioned by whosawhatsis would be the way to go... easy to get and loads of examples on how to use it... if it makes to much friction is of course important...

boelle · 2015-05-31T14:42:54Z

closing... we recently agreed that support from hardware should come from makers of the hardware and not us

hussainsail2002 · 2019-04-29T09:14:22Z

closing... we recently agreed that support from hardware should come from makers of the hardware and not us

Hi, I know this has been quite a while since this feature has been closed, but after seeing it on the new craftbot I figured it was quite a useful feature to have.

I found this link on thingiverse : https://www.thingiverse.com/thing:3071723
where the maker has designed the hardware, and got it running on marlin. He has also documented his work. Do you think this feature could be brought back as a feature request.

github-actions · 2020-07-11T14:04:30Z