By the way, @Arthur_Wolf does Smoothie support filament sensors? Would be fairly simple to implement, i’d think.
Is Marlin’s ring buffer stored between sessions? Or will we have a whole Bowden tube of unknown volume every time we start the printer?
@Dale_Dunn good point. It’s stored in RAM, so once you power down your printer, the information will be lost and Marlin will assume the current diameter (in the sensor) until the buffer is filled (if i understand things correctly). EDIT: Marlin assumes the default diameter until the buffer is filled.
Though that shouldn’t be too much of an issue, since, hopefully, the filament isn’t that different in size one meter up or down the spool.
@Thomas_Sanladerer I’ve heard some people talking about implementing it, I think it’s coming ( could be in a separate branch already, but not merge back yet ).
Is there a reason for hall effect instead of optics? Also (and maybe I am way behind the curve on this one) I would like to put together a design where the filament is fully supported except at the sensor. Most of the “interesting” filaments I’m seen exhibit frequent changes in curvature that would likely make for bad readings if there’s any free space.
Hmm, time to knock something together.
Optical is more complicated, more expensive. The hall actually has better precision than a linear CCD. With the CCD you are limited by the number of pixels, and you will need to determine what point along the shadow transition you will consider to be the edge. The center of the filament will need to stay at a constant distance from the sensor so the shadow size isn’t affected by movement. The programming is more complex, with timing the clock pulses to control exposure and working with arrays to map out the shadow profile.
The other option is a $.50 magnet, $1 hall sensor, and analogRead.
I tried both optical (beam occlusion) approaches with a TLS1401 linear CCD and a simple photodiode (with the beam refocused). The linear CCD had severe resolution issues and even with interpolation and a boatload of smoothing and software-based guessing, i couldn’t get a stable reading out of it. The photodiode, obviously, is very sensitive to ambient light and, again, only has a fairly low overall resolution if you factor in the behavior at the operating point and ADC resolution. Both had advantages in other spots, but ultimately were not usable. The hall sensor can be positioned so that it is most sensitive at the operating point and generally delivers a very stable and repeatable reading, even if the rollers aren’t truly contactless (but low force nonetheless).
Gotcha. I was hoping the you could use the rollers and some mechanical advantage to move the reading point away from the filament itself, but it sounds instead as if the nonlinearity of the hall sensor is actually working for you.
Going back to the elliptical filament issue, you should be able to assume a relatively consistent cross section even in bad filament. And its presentation to the sensor(s) should also be relatively consistent, as well. How each person threads their filament may differ between users, but generally once it’s loaded it stays loaded in that orientation, and (at least in my experience) the orientation stays the same between different instances of use. The orientation may vary slightly, but I’d guess not all that much.
Then, even in the worst case scenario of being off by approximately 2%, you’ll be off by that much all the time… And a correction factor can be applied.
What I’m thinking is, the first time you use a filament you use a generic filament profile that assumes a round filament. You print a thin wall cube and make the normal measurements, then feed a correction factor based on that to your filament profile in your slicer to compensate for non-round filament errors (if they exist in your print). From that point, your filament calibration should be done, and the sensor handles all the work for you.
I guess the only questions are whether or not extrusion multipliers are ignored by Marlin when using diameter sensing, and whether or not my assumption of consistently wrong measuring is correct.
…but I’d be up for testing one to see.
This is another way to do optical, which wouldn’t be very useful for this application but I got it working pretty well for filament extrusion- https://www.dropbox.com/sc/auxolauudo4ld6r/AAAUlTBZM9Sa3h10ABPBmnT-a
This is inspired by laser micrometers which use a spinning mirror and lenses to sweep a beam across the measurement area, which gets focused back on to a point at the sensor. The measurement is determined by the length of time that the sensor is dark, so resolution is based on clock speed or sensor response rather than pixels. I can’t do the spinning mirror and lenses, so I used a stepper to sweep the light source and sensor (simple phototransistor) together. It’s the best way to get contact free measurement right at the nozzle, but adding a stepper, driver and laser didn’t provide enough benefit to compete with the stability and economy of a hall and a magnet.
@Ian_Johnson nice idea! I’ll look into it for my filament extruder to get a faster reading instead of having to wait until the filament is already past the water loop. If we used a small, geared DC motor (+ cheap encoder), we could actually build a micrometer-like apparatus for…
Hold on! Computer fans have an encoder built-in and run at relatively low RPM - use one of those with a mirror mounted on top?
@Thomas_Sanladerer
Back of the envelope suggests that even a slow fan might be marginal unless you tear it down. 1000 rpm is about 100 radians/sec, and your filament will occupy something like 1/10 radian, so about a millisecond of dark time, so you need a few microseconds of timing accuracy to get to 0.01 mm control. Which is doable, but a little baby gearmotor give you more comfortable numbers.
How would you produce an analog voltage from an ATtiny? PWM with capacitors to smooth it out? Just to go back into an ADC input with 5/1024mm resolution? I would stick with a digital signal. The UFID protocol has a provision for filament measurement devices built in. If you report a filament tolerance of zero, it means that the diameter measurement is coming from a filament measuring device and should be polled periodically. The current plan is to implement this on i2c.
@paul_wallich interrupts are your friend - and a millisecond actually is a lot of time when you’re clocking 16MHz.
@Whosa_whatsis yes, hardware PWM + voltage divider (improves resolution) + lowpass was what i planned on using for now, as that seems to be the only thing Marlin supports right now. I’d much prefer a digital interface, and if UFID already has something suitable spec’d out, i’ll gladly implement that as well. Any details as to what part of the protocol the sensor needs to handle?
Oh, yes, a millisecond is a very long time. But you have to measure that millisecond-long time to a few parts in a thousand. My experience is that accurately getting sub-10-microsecond intervals on a free-running tiny requires a bit of calibration. Doable, but not automatic.
@paul_wallich don’t laser micrometers typically have a many-sided mirror in there? But either way, with some intense oversampling (what’s the bandwidth of the filament diameter? 0.1Hz?) it should be doable. Or at the very least worth looking into, if only to have an alternative to the hall sensor setup, should that not work out for whatever reason.
@Thomas_Sanladerer
The spinning mirror isn’t the hardest part, it’s the expensive lenses needed to direct the beam. The beam sweeper I built moves it across the filament in an arc which isn’t ideal, it would be better for it to be screw-driven instead so it would move up and down in a straight line. A servo might work as well as a stepper. It is crucial that the speed be constant and consistent when passing the filament. Also the phototransistor needs to be connected to a hardware interrupt or the “dark time” will be a multiple of the amount of time it takes to execute the loop.
A screw would probably be too slow, what about a rack/pinion drive?
As @Thomas_Sanladerer points out, we’re not talking high bandwidth, so something that managed a cycle or a few cycles (two measurements) per second might do nicely. Hmm, how about a mirror on a cam-driven arm? Could be very light.
The good thing is that since the “micrometer” is measuring within a custom-designed enclosure it can be made at least partly self-calibrating. You know when the beam clears the sidewall just one side of the filament, and when it goes behind the sidewall just the other side of the filament. (And of course if you’re oversampling, the whole of astronomy has methods for extracting signals from ugly light curves.)