Here's my printable optical encoder wheel filament sensor!
-
Had a buddy come build one today and seemed to come out with different holediameters and depths. The depth might be a non issue as I think the screws we had on hand were M3x8 not the reccomended M3x6.
But the circled holes came out too tight for M3, but nothing a drill+tap didn't sort. Something you have changed since i downloaded it? Or just tiertime that decides to things their way, for
better orworse?
Still need to re-do the wheel to get some external flex, but looks good man - thanks for sharing!
-
@bearer said in Here's my printable optical encoder wheel filament sensor!:
So it's important that the filament monitor senses the direction of motion and passes it to the Duet along with the amount of motion,
Can't we just use the "direction pin" on the extruder driver to determine direction ?!
It is not possible for filament to change direction without motor doing so, it might move less than we want but it will never move more than we want and in oposite direction -
@arhi did you see this? https://forum.duet3d.com/topic/17111/rrf-3-1-1-m572-breaks-m591/
(missleading topic title i'd say, but maybe relevant)
beyond that I'd defer to big cheese dc42 as it was his quote (i just stripped the @ to keep the noise down)
-
@arhi said in Here's my printable optical encoder wheel filament sensor!:
Can't we just use the "direction pin" on the extruder driver to determine direction ?!
We could use a quadrature encoder, or a pulse+direction arrangement. however in both cases these need more pins. for some applications that is no problem, in others pins are limited. ATTiny microprocessors are inexpensive which is why we went with the option of carrying out the initial processing on the filament monitor and then passing that processed information back to the Duet in a form that just uses 1 pin and works on an endstop input.
It would be possible to either:
- Develop alternative code for the Duet main firmware that uses multiple pins to work with pulse+direction or quadrature.
- Develop alternative firmware for the Attiny or similar microprocessor that read your preferred sensor arrangement and converted it to the protocol the Duet uses.
That said at this point I don't see us (the core Duet3D team) having time to do either.
-
And -rereading your original question I now see that you mean for the firmware to stick with reading the pulses from the sensor, but use the commanded direction of the extruder driver to determine the direction that those pulses relate to.
That's a different question from the one one I answered above. there are certainly cases where with high enough pressure advance the extruder could be turning in the opposite direction from what would be expected looking at the gcode, but as you say the firmware knows that as its commanding the extruder to move in that direction....
So the question is can a pulse extruder be configured to work more accurately if the firmware takes into account the current commanded direction of the extruder and then assumes that any pulses relate to movement in the direction commanded. Definitely one for @dc42 !
-
ok, lemme reiterate
There is no way a filament will move in contra direction of the motor, the only thing that can happen is filament not moving, filament moving less than required or filament moving as required. It is not possible for filament to move in contra direction or more than expected.
So I do understand that current implementation does not know how to handle this and that firmware look at pulses as "forward only" (weird decision but ok) and that there is a non-working duet filament sensor that has a small MCU and can send additional data and and and.... but, the motor is rotated by the firmware. The point that there are few processes influencing motor behavior (acceleration, jerk, pressure advance, dynamic acceleration...) is irrelevant it just means that software needs to be improved not that there is a need to add direction data as there is direction data in the firmware already, it is just a question if you are using it or not.
I, of course, understand the limited nature of resources and I agree that there are more important features that should be finished/polished and / or implemented so I can agree that writing a bit of code on the attiny or pic12f or another puny few cent few pin mcu can solve the issue faster, allowing those "resources" to focus on more important features. I'm not familiarized with the duet codebase (I did manage to compile it and modify it a bit but am still missing the big picture) to be able to quickly figure out how this works now and what needs to be changed to make it work properly
-
@T3P3Tony said in Here's my printable optical encoder wheel filament sensor!:
converted it to the protocol the Duet uses
I assume the "the protocol the Duet uses" can be deducted from the attiny firmware for the duet laser sensor?
-
@T3P3Tony said in Here's my printable optical encoder wheel filament sensor!:
but as you say the firmware knows that as its commanding the extruder to move in that direction....
Yes, there's no "external system" that measures the pressure and reverses the motor direction without firmware knowing about it. The motor is directly controlled by the firmware hence firmware knows the direction motor is turning.
So the question is can a pulse extruder be configured to work more accurately if the firmware takes into account the current commanded direction of the extruder and then assumes that any pulses relate to movement in the direction commanded.
As I said it's virtually impossible for direction of filament to be different than direction of the motor. Also, I think I did ask when I first looked at the "e_stop" input if the firmware uses the motor direction to properly handle retractions as there is no direction pin, and I think dc42 replied that it does or there was no reply at all so I assumed it does, I don't remember and I can't find that post any more.
I always assumed that direction is fetched from the motor direction, and before PA it does look ok, seems that retractions are handled properly (even a rather long retraction), but looking at mentioned thread looks like PA messes it up, so it's possible that for retractions the direction is considered but for PA direction is not considered and just need to be "fixed" (the question is how quick that fix is, I don't feel comfortable assuming anything is easy/hard to fix till I get myself familiar with the code).... now, I do have some gaps in workflow these days that I can use for some development... doing a quick "read encoder, shoot data over spi/i2c/usart/1wire.." should be super simple if the protocol is described somewhere or example (existing sensor) is not too cryptic
-
looking at the
dc42
A1 means that extrusion will not be measured during retraction moves. it will still be measured during the whole of a move in which extrusion is commanded, even if pressure advance causes the end of that move to turn into retraction.so attm during retraction it just "ignore impulses"
how hard would it be to do the same when PA reverses the motor direction? if it works for retraction should work with PA ?I understand this is separate vs single move (PA changes direction during a single move and retraction is separate move) but again..
as is right now, looks like these sensors are useles with PA anabled
-
(and that is why I posted dc42's response from another thread , no point in building one if using PA with current firmware; if and how to "fix" it might be better discussed in a dedicated thread leaving the warning here for now?)
-
@bearer said in Here's my printable optical encoder wheel filament sensor!:
no point in building one if using PA with current firmware
well it depends, I did not notice PA reversing my extruder yet at the value I'm using it (0.042) .. higher values are more problematic...
anyhow, don't have enough experience, still did not have a single print done with "enabled" sensor, I'm running it disabled for now
-
@bearer awesome
well I made all holes 2.8mm diameter so to make a 3M screw "self-tap" itself in.Came out great out of my well tuned railcore but it might quickly get too tight with a little overextrusion; drilling should care for that.
Btw the clamping side of the enclosure is 3.5mm as to let the screw slide freely until set.
@arhi @T3P3Tony That just made me think; how about a mechanical freewheel physically stopping the encoder from spinning backwards; could be a ratchet or one-way bearing -although I don't know of any smaller than 608 size) or something else
-
@fractalengineer said in Here's my printable optical encoder wheel filament sensor!:
@arhi @T3P3Tony That just made me think; how about a mechanical freewheel physically stopping the encoder from spinning backwards; could be a ratchet or one-way bearing -although I don't know of any smaller than 608 size) or something else
can be done for new desings, will not work for existing ones + IMO that's a wrong approach to solving software issue
-
Just published the updated model using a $3 Schmitt trigger equipped arduino sensor;
Getting much more consistent reading
Check it out there
Railcore II ZL
-
@arhi said in Here's my printable optical encoder wheel filament sensor!:
There is no way a filament will move in contra direction of the motor
@fractalengineer thanks for warming up this thread.
I read it and the above quote made me think of murphy's law.
YES there is a way filament pressure builds up so hard ( eg. Bowden setups) that the stepper looses control and gets pushed backwards a few degree (visible and audible). That happens regardless of the DIR pin value.
I've seen that happen regularly with a Diamond mixing hotend and three 0.9° steppers. -
@o_lampe possible, dunno, I assume the motor can skip steps, it can even chew the filament so motor is spinning but filament is not moving, but never seen filament going backwards trough motor .. .but yes, with bowden everything is possible, I don't use bowden, ever, I always believed it is a terrible way to do things especially as I almost never use PLA and the "springy" filaments I use really hate bowden setups
-
@fractalengineer said in Here's my printable optical encoder wheel filament sensor!:
Schmitt trigger equipped arduino sensor
The endstop definition already has a threshold parameter. I was wondering, why that was not enough? Does the Schmitt-Trigger offer a bigger hysteresis or what's the difference?
-
@o_lampe Excellent question; it worked about fine for me with pretty high tolerance (ended up running 25-200%) but would still get occasional spikes at 400% triggering false positives
Then @JohnOCFII made this awesome in-depth investigation using a logic analyzer and found out that the signal was indeed noisy and implementing a schmitt trigger solved the issue; https://forum.duet3d.com/topic/19284/inconsistent-results-with-optical-encoder-wheel-filament-sensor
So I found an IR sensor that has a shmitt trigger integrated and modified the housing for it
-
This post is deleted! -
I remixed the design by Fractalengineer to use the Duet3D Laser Filament Monitor, and it seems to be working well.
https://www.thingiverse.com/thing:4796741
