ptegler

they will work, calibrated to that bed/mass. I've now had to give up on this variation, as every time I change a print bed surface, i have to re-cal Z...

regarding 'dirty'...just indicates untracked files in the master..... 'dirty' is not an issue [https://discord.com/channels/582187371529764864/1133080505005395988/1133080505005395988](https://discord.com/channels/582187371529764864/1133080505005395988/1133080505005395988)

...have had my BDSensor now for well over a year..... bummed I've never bothered to even pull it out of the box a second time, after I found the I2C...

Is this with the oem control board on your TLM? My board never made it through the initial power up... display was trashed (lines) so everything was built the first...

My TLM verts are linear rails. Fully enclosed.. Magball 640mm arms, Smart Effector, Oribiter extruder on custom flying mount. SE works perfectly with the RepRap firmware. Marlin is my Flashforge....

already discussed.... [https://github.com/markniu/Bed_Distance_sensor/issues/1#issuecomment-1302657762](https://github.com/markniu/Bed_Distance_sensor/issues/1#issuecomment-1302657762)

'dirty' simply signifies those apps contain code NOT in the main branch. It has ZERO effect on ops of Klipper/Klipper Screen/etc ALL of the RatOS users se this with no...

...if you dig back here (way back) you'll note a conversation very early on why this sensor will never be supported directly in the main branch, as the I2C protocol...

noticed this too after updates...back on 7/29 was last successful render. all frames (no sequence number skipped) were written to /tmp/timelapse, but all frames have zero data (less than 4K...

yes, realized an error for the webcam selected.... webrtc recent updates (crowsnest v4 updates) url snapshot script was wrong. Have not tested (run a print) but a browser url test...