Another test before I swap encoder wheels. Very consistent results. This was a 3D Benchy.
Pulse-type filament monitor on pin !e1stop, disabled, sensitivity 4.000mm/pulse, allowed movement 30% to 1500%, check every 5.0mm, measured sensitivity 4.034mm/pulse, measured minimum 91%, maximum 109% over 871.3mm
I finally finished and published my RepPanel case. I used this as a good time to learn a bit about FreeCAD. The FreeCAD design file is included in the Thing.
https://www.thingiverse.com/thing:4822626
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
I figured out my issue with non-movement related false alarms
Gravity sucks!
Indeed!
I'ts been a really fun ride watching you build/diagnose/deal-with-it and then show success with this project.
Happy to share. I figure someone out there might benefit, so why not share?
Thanks for sharing your journey with us housebound folks.
I'd be nowhere without you and @arhi and of course, the great design from @fractalengineer!
Today I swapped in the encoder wheel with more narrower "spokes."
First run (fairly short) looked pretty good:
Pulse-type filament monitor on pin e1stop, disabled, sensitivity 2.400mm/pulse, allowed movement 30% to 900%, check every 10.0mm, measured sensitivity 1.720mm/pulse, measured minimum 132%, maximum 143% over 282.0mm
I realized the pulse wasn't every 2.4mm, so I reset for closer to the 1.72 I was seeing here, and got these consistent results across a number of prints:
Pulse-type filament monitor on pin e1stop, disabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.713mm/pulse, measured minimum 82%, maximum 118% over 2541.8mm
I also modified the check to be every 6.0mm which should allow 3 pulses. The percentage "window" seems a bit larger, but I assume that is because the actual distance is allowed is shorter due to the narrow spokes and the 6mm distance.
Either way, this continues to be very repeatable!
Next tests (maybe tomorrow, but sadly my vacation is over) will be to cut the filament and see how it responds.
@seeul8er I use the RepPanel regularly. I think my only issues are related to the potential memory issues -- things get flaky occasionally -- sometimes screen presses are not recognized, and I'll have to touch an area repeatedly. Sometimes it works first time in the same area.
I figured out my issue with non-movement related false alarms: 
(The PTFE fell out in my repeated replacement of filament...)
@snowcrash DId you set up the new notifications in the new software? That is something that did not transition from the old forum software, and has to be set up separately. I find the new notifications (with the new forum software) much more reliable than with the old.
FYI -- still loving the results!
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.727mm/pulse, measured minimum 87%, maximum 111% over 3654.4mm
@fractalengineer has received his new optical sensor with ST. Mine are still enroute.
As @autsch suggested, reverting from 1.21.2-b1 to 1.21.1 for the web interface fixed my issue.
I really appreciate that help. I did not think the DWC would have caused an issue like that!
@fcwilt Thanks for the example of posting that way. I use that for small segments of code, but hadn't realized it was a good way to post complete files.
As far as a Z-endstop -- I suppose it is possible. I haven't seen the need. As I mentioned above, the printer is working fine, just seem to be getting a message that does not correspond to the printer's behavior.
As far as the probe, you can read all the details on the Github page: https://github.com/nionio6915/Euclid_Probe/blob/main/README.md#probe-calibration
But in summary, a simple switch is magnetically attached to the carriage. The deploy and retract files handle the logic to determine if the probe is attached or not. The deploy macro will travel to the dock and "pick up" the probe. The retract macro will return the probe to the dock.
John
The Logic Analyzer arrived! Here's some data.
Speaking of duplication.. TL;DR.. The native Duet web interface is very good, compared to Octoprint it provides a lot more info about the printer itself, real-time axes positions, direct access to the machines configuration files, upgrade wizards, heightmap display etc. I use the webcontrol all the time when I'm (re)configuring my system at home.
But I do not use it to print; I print via Octoprint and streaming the gcodes over USB the old-fashioned way; Octoprint is a great interface for organizing/printing from, file management is good, webcam/timelapse integration seamless, The gcode viewer is handy, the plugin system is a bit patchy but contains some good stuff like the heater timeout plugin.
Fascinating idea. I hadn't considered feeding the DuetWifi via USB and continuing to use OctoPrint as I do on my MK2.
Architecturally, I'm conflicted. I love OctoPrint, and the plug-in environment. I wish I had all those features in DWC, or something similar. But – I also appreciate that Duet prints from the on-board SD card. I guess the ideal situation would be for OctoPrint to communicate with Duet via WiFi, and treat it similarly to the way OctoPrint treats printing from the printer's own SD card -- just communicating via WiFi instead of over USB.
The other approach is to load up the Duet and DWC or similar will more software features similar to OctoPrint, but as you pointed out, I think the hardware is more limited, and it doesn't make sense to take resources away from the main focus -- printing.
John
@qdeathstar said in Duet hardware actually makes it into Thomas Salanderer's videos:
what are the maestro specs? It almost looks just like the regular duet ethernet, what’s th difference?
Some specs are discussed in the video, or you can wait until next week.
@BoA said in Prusa Slicer 2.3alpha2 adds new G CODE flavor for RRF:
Finally G10 support?
I wonder what are the actual changes in this new g code flavor.
Details here: https://github.com/prusa3d/PrusaSlicer/pull/4553
A "normal" print with varying movement types and speeds up to 120 mm/sec. Results were pretty stable. Very similar to the vase mode print.
Pulse-type filament monitor on pin !e1stop, disabled, sensitivity 4.000mm/pulse, allowed movement 30% to 1500%, check every 5.0mm, measured sensitivity 4.016mm/pulse, measured minimum 91%, maximum 109% over 851.3mm
That's enough for today.
@3mm Thankfully, there are a number of different "skins" you can choose. The one I'm using now has white text on a gray or black background.
You can access this via the Profile menu in the upper right of the window. Under that, choose settings. in the upper left is the "Select a Skin" setting. The one I'm using now is called "slate." There are many others too.
John
I'd guess that running DWC on two other devices in addition to DuetLapse might have had the Duet2 board confused...
Today, after a fresh start on the printer and after quitting DWC after the first layer completed, I didn't see any disconnect errors.
Here's a nice example DuetLapse3 timelapse. This was a 3 hour 20 minute print in a 53 second timelapse.
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
The Saleae trace you posted shows the Schmitt trigger working PERFECTLY!!!
That is fantastic to hear!
I went ahead and passed the signal through the adjacent inverter. I don't know why, but it makes me smile.
@dc42 @Foosel suggests the format should be:
Recv: ok T:195.0 /195.0 T1:188.6 /190.0 B:60.0 /60.0
