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!
Late to the thread, but very sorry to hear. His work (and the time spent documenting his work) was greatly appreciated.
@stuartofmt Glad to see work continue on this very useful tool!
@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.
@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
@sinned6915 Greetings -
I added your if statement to my homez.g file but it seems that current RRF 3.3 already checks for an attempt to home Z before homing X and Y, and responds with this message in the console: Error: Must home axes [XY] before homing [Z]
I added a final M64 S1 H1 to homez.g without change to the spurious message. I've since removed that line to continue troubleshooting.
I've moved the M564 to be before all G1 movements in both deployprobe.g and retractprobe.g as suggested, with the M564 H1 S1 after the G1 movements in each file.
Not sure about item 4.
I've checked my latest files for tabs. I use VSCode which switches tabs to spaces be default, but perhaps if I edited via DWC for changes, some were introduced there. No change in bahavior.
I did notice one interesting thing. After I complete homing X, Y, and Z, and get the error message, if I home Z a second time, I don't receive the "Error: G0/G1: insufficient axes homed" message" after the second execution of Home Z.
@fcwilt I'm uploading files using the icon for "Upload files." If there is a better or different way to do that, please point me at those instructions. I've added the remaining homing files, as well as the updated files after the changes discussed above.
Thanks,
John
homex.g homey.g homeall.g config.g homez.g deployprobe.g retractprobe.g
I'm running RRF 3.3 on Duet2Ethernet with Duex5. Printer is a Railcore 300ZL. I'm commissioning a Euclid dockable switch probe to replace a BLTouch. I've got my homez.g and my deployprobe.g and my retractprobe.g working well (other than fine tuning speeds).
After the homing completes, the console displays the message: Error: G0/G1: insufficient axes homed but DWC reports all 3 axes are homed, and I can use DWC to move each axis normally.
Is this just a bogus message, or am I doing something wrong?
I've attached my config.g, homez.g, deployprobe.g and retractprobe.g files (please ignore extraneous echo lines).
Thanks for any input!
John
@war4peace The file startDuetLapse3.py can be found along with the rest of the DuetLapse files here: https://github.com/stuartofmt/DuetLapse3
It is fairly straightforward to replicate if needed.
John
@stuartofmt said in DuetLapse3:
What version of DuetLapse3 are you on ? Sorry that you had to rebuild ffmpeg.
I'm running 3.4.2. I was on 3.4.1 before that.
John