REQUEST: Integrate Signal from Optical Sensor to Track Filament Movement

[rf1k-mjh11]

FEATURE REQUEST:

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 from the extruder motor
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)

On bowden systems, provided the sensor were mounted close to the hot end, it could even compensate for the inherent play/hysteresis in a bowden system.

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 (even with a hobbed bolt!!). I think you will see slip rates between 0-8%, despite thinking the hobbed bolt acts like a gear (it's basically 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 Marlin people and 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

[repetier]

We are working an a similar system to see if extruder is clogged. Would also detect out of filament.

A feedback system is currently out of scope a sit is much more complicated and needs faster interrupts in parallel to normal printing to update for missed moves. We start fist with simple solutions and then see what is possible.

[kyrreaa]

Copy from post in wrong forum: This is what I have been working on for a bit. (And what I have been talking about on IRC.)

The hobbed bolts are good over a certain range but will deviate. I have done quite a lot of testing on different hobbed bolts and other feeders/extruders and also looked into the filament diameter as source to some discrepancys I found in my prints. In the end it turns out that 1.75mm filament atleast (which is all I ever use nowadays) are very good in dimensions (atleast from my suppliers) and there was very little room for improvement here. The feed however varied quite a lot, a factor 20 vs the filament diameter when it comes to total volume influence.

I've been testing multiple optical sensors and writing interface code to use a few of them. The plan is to add support in my branch of Repetier fw to test it on a live printer. I am having some issues with the communication though due to the way the entire software is structured and timed. It does not lend itself easily to such quick mods where you need to add extra communication on a new bus.

Anyway, in case others want to play I can share some fun info. First off, development the last years have made many of the optical sensors into a single chip solution. They don't just integrate the optical sensing elements and the correlator anymore. Some even have USB or wireless more or less integrated. The cheap chips we can easily get seem to end up as USB. This ofcource is a problem for our poor controllers but it turns out they still support PS/2 which is much easier and run over the D+/D- signals of the USB plug. I've been adding PS/2 code to allow these to be read. There are still chips out there that are SPI and I2C too, so we do have options.

SPI would ofcource be preferred due to speed and better noise immunity, but in Atmel chips this is still a poosly supported peripheral and will take time away from other tasks.

As for the actual sensors, yes they are mostly automatic and they do integrate motion all by themselves. The integrals reset every time you read them and there are overflow-flags to signal you if you are reading them too infrequently. A very cool feature of some of the sensors is ofcource that we can even read out the image array. This could theoretically be used to estimate filament width using some edge estimation techniques and taking advantage of the pixel depth available in the sensor to gain sub-pixel accuracy. This technique works great for LIDAR systems so should be ok for filament estimation too.

For me, this is just another thing I fiddle with in a sea of stuff I need to get done so I am ofcource pressed for time. So much cool stuff to do, so little time... I wouldn't expect my stuff to be ready anytime soon, but I do have around 20 more optical chips on the way for more experiments. I plan to make a sensorboard that will integrate easily and add to the bowden extruders in a easy way.

[kyrreaa]

Also, to use as feedback, you do not have to read it very often. No realtime is needed. As repetier sais, the system does not have the processing power to track this fast enough to react to the springyness in a bowden. That is way too ambitious. A simple feedback to register motion and to verify approx correct steps for a given feed rate is enough.

[Jmjcoke]

For Arduino based systems without the processing power could the step/direction signal be used to run a drive that uses the mouse or whatever device to create a closed loop between filament movement based on this sensor instead of an encoder, drives can usually produce analog and digital output that could then control things on the Arduino like temperature and speed like the siders in software based on missed steps.

I have switched to smoothieboards on all my printers so processing power is much higher, but I think all but the most powerful motion control systems let the drives handle all closed loop functions.

On Wed, Mar 4, 2015 at 11:09 AM, kyrreaa notifications@github.com wrote:

Also, to use as feedback, you do not have to read it very often. No realtime is needed. As repetier sais, the system does not have the processing power to track this fast enough to react to the springyness in a bowden. That is way too ambitious. A simple feedback to register motion and to verify approx correct steps for a given feed rate is enough.

— Reply to this email directly or view it on GitHub https://github.com/repetier/Repetier-Firmware/issues/370#issuecomment-77199968 .

Joshua Coke

815-323-2784

[rf1k-mjh11]

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.

Mike

[repetier]

You can not sense the current going through stepper drivers. At least not with the drivers used. And it will most probably also not work with divers which could do it. They have some conditions which all needs to be met for it to work. So even if someone manages to get system that can it will get so difficult that no normal user can handle it. I tried it with an other project and after sever PCB we switched to normal sensors.

BTW: Jam detection seems to work now, only there is currently no action when detected. And the used method is so simple that everyone can build a detector.

[kyrreaa]

I have 5 different optical sensors and have found a few that are twi (kind of 2 wire spi) which may be most usefull. PS2 is also very easy to use.

Right now however, I am tidying my hobbyroom, not coding. Based on the lack of free horizontal surfaces I will be at it for a few days at least.

[rf1k-mjh11]

Not being an electrician, nor to much at home with electronics, I can't refute your statement. But I can explain my thoughts: The stepper motor has multiple coils (generally 2). There is always a current on the coils, even when the motor is stationary. But I thought that this current either switches direction, or goes off completely, whenever the motor moves. And since this current tends to be fairly high (1 A or more), I thought you could sense this remotely, without having to be included in the circuit itself (like they do on high-tension lines). So, by sensing a current reversal or disappearance, I could infer that the motor should be turning. And since the motor rarely makes just one step, this reversing/pulsing of the current would go on as long as the motor is turning. Even with microstepping, you would get a current something like a sine wave, while the motor is running.

But I may not understand it all, or a current of only 1.5 amps isn't enough to be reliably sensed.

Mike

On 03/08/2015 16:28, repetier wrote:

You can not sense the current going through stepper drivers. At least not with the drivers used. And it will most probably also not work with divers which could do it. They have some conditions which all needs to be met for it to work. So even if someone manages to get system that can it will get so difficult that no normal user can handle it. I tried it with an other project and after sever PCB we switched to normal sensors.

BTW: Jam detection seems to work now, only there is currently no action when detected. And the used method is so simple that everyone can build a detector.

— Reply to this email directly or view it on GitHub https://github.com/repetier/Repetier-Firmware/issues/370#issuecomment-77755572.

[kyrreaa]

The stepper motors do not operate that way at all. A stepper motor operates by always applying a field to the motor.

For whole steps it is a matter of energizing either coil A or coil B in either forwards or reverse. This gives 4 options and thus you sequence 4 whole steps before repeating. These steps are all current controlled which means the controller will attempt to deliver the specified current all the time to the coil in question. Only during actual acceleration will a emf be generated that makes a higher voltage necessary to apply this current. Once motor has sped up or reached it's target step this goes away again. You can thus use this to estimate the inertia in the system but not detect much else without serious electronics tinkering and software coding.

For half steps this is the same, only now we add the intermediate positions where we energize both coils at once. There is thus 8 steps available per repetition of the sequence.

Microsteps go one further and subdivide the energizing intervals between the coils to hold the motor at intermediate positions between the stable states above. Here, torque on the shaft can skew the motors position forward or reverse in relation to the microsteps but in general it will sync up on the hole/halfsteps or you will get skipped motion.

In our situation we do not get skipped steps unless the current is way too low. What we do get is the teeth in the hobbed bolt engaging differently at different pressures, causing a varying advance of the filament. Idlers rolling on the filament or optical tracking seems to be the best candidates to track this.

[kereknjek]

Since repetier allredy has software writen to track filament movements by switching one pin on and off, what about taking optical mouse sensor, connect it to attiny and make attiny switch that pin?

[jamesarm97]

That is kind of how the one a lot of us on the 'sailfish / mightyboard' side do it. Here is a board someone came up with and sells it. Works really well. Detects jams and filament out and pauses the print. Has a configurable timeout and doesn't start until so much filament had passed.

http://www.toybuilderlabs.com/products/tunells-3d-printer-filament-monitor

James Armstrong

On Jun 11, 2015, at 4:12 PM, kereknjek notifications@github.com wrote:

Since repetier allredy has software writen to track filament movements by switching one pin on and off, what about taking optical mouse sensor, connect it to attiny and make attiny switch that pin?

— Reply to this email directly or view it on GitHub.

[kereknjek]

"If you have a god idea, it is very probable that someone had it before you."

I actualy wanted to point out optucal sensors. I've seen alot of mechanical solutions, but no single with optical mouse sensor. The point is that if you use mechanical sensor, it can also jam. Like any old ball mouse...

While I'm at it, can some one direct me how to program comunication on atmel and adns-xxxx using bascom avr or arduino? I kind of suck at serial comunications.