Adding some information about possible problems with this sensor if anyone will dig out this thread (as I did).

In my case sensor had intermittent failure. Once a few or a dozen minutes of printing it reported no filament (== no "low" pulses were sent). Then after 1-2 days it died completely.

It turns out that when I mounted it using one of thingiverse mounts screw pressed a tiny bit on the side of connector causing it to rip ground path directly under connector. That caused no power on C145 chip (well, there was ~1.2V there).

The fault was only visible under microscope and even then it wasn't immediately obvious/visible because main pins were soldered fine. Only one pin on the side (the mounting one) was ripped (and was up over pcb a fraction of mm).

@knutselsmurf there is no easy fix, because you need two separate UARTs to drive the PanelDue and the Neopixel board, and the only user-accessible UART on Duet WiFi is the one connected to the PanelDue port.

@mafco77, et al

I have received a lot of messages regarding this, so I figured I would post an update here.

I have not gotten any further with the Stratadue project.

The limitation remains determining how to control the steppers and servo motors through the Attiny85. Perhaps the Attiny85 was a bad choice in chip as I am using literally all the pins for IO and that means reprogramming can only be done via a high voltage programmer. If I were to continue, I would need to swap to a device with more pins or an Attiny85 in a DIP socket.

I cannot remember, but I believe the device requires a Duet2 with custom firmware. Not sure if my changes for the multiple expansion chips was ever merged into the main code or not. It's unfortunate that Duet3 came out soon after I started working on this and it doesn't appear to be compatible either. Bad timing unfortunately!

I do have a few PCBs built, but without the Attiny85 code, and custom Duet firmware, I'm not sure it would be of much use. I still have ~10-12 uPrint printers sitting around gathering dust too! I would love to get them up and running but I believe technology has advanced so much that newer / cheaper printers are leaps and bounds better.

@jay_s_uk Thanks, I flashed in fresh firmware and moved them to the proper menu directory. I'm still not seeing anything on the LCD 😞

Screen Shot 2022-07-04 at 12.49.36 PM.png

EDIT: Flipped my cables one more time and now have it working, thanks so much!!!

@dc42 I purchased MLX90614 sensors for experimentation. Maybe you have a beta version of the RRF software to try to connect?

@leobg see https://docs.duet3d.com/User_manual/Connecting_hardware/Display_12864#connecting-bigtreetech-colour-displays

Ian

@topenga If you are in SBC mode (attached RPi), use apt update/upgrade. In standalone mode just upload the web interface ZIP file from here or here.

@zapta the example I linked to is for use where Z hasn't been homed.
and the docks typically have a little lip to stop the probe dropping out although its still a possibility if held upside down at the right angle.
STLs for the V2.4 can be found here

@creamofpantssoup It would be best to start a new thread and provide as much detail as possible including your config files and firmware versions and details of wiring.

@phaedrux
Thanks so much.

Your suggestions of course!, worked well.

Thanks Once again.

Graham Solomon

@jay_s_uk Thanks a lot

For serious, accurate closed-loop encoder feedback the encoder system either needs to be interrupt driven from the encoder signals directly with no software involvement prior to that (which means a very fast CPU), sampled, preferably in a timer interrupt, at a rate faster than any possible input change rate, or you need to use a device that has hardware encoder inputs.

Hardware encoder units are available in various MCUs, eg. dsPICFJxxxMC devices have two hardware quadrature channels & various other dsPICs have one or two, plus many other hardware interfaces.

The dsPIC33CK256MP508 has two encoder channels and built-in CAN-FD; likewise dsPIC33CH512MP508 but with two CPUs as well.

Those look particularly good for direct Duet CAN compatibility?

Also the Arduino Due has two encoder channels.

The Pi Nano is an interesting device, but by no means ideal for CNC drive type use; there are far more suitable and still low cost devices.

@phil333 this sounds similar to https://forum.duet3d.com/topic/25291/genuine-bltouch-v3-0-weirdness-with-rff-3-3?_=1635272591563 except that you are using a Duet WiFi instead of a Duet Maestro. I will take the fix that I implemented in RRF for the Maestro and port it to the Duet WiFi/Ethernet build.

@paulhew https://www.youtube.com/watch?v=NWookm1u_0E

@brewchester I’m have same problem after updating from RRF 2.2 to 3.3
Can’t hame z.

What solve your problem?

@cosmowave for the moment PETG...

Thx

@jay_s_uk thanking you! Will try that remotely next chance I get.

@paulhew Thanks dude and yeah, I've seen that link and have all those configured. I'll keep sussing around with it

@arhi I understand completely 👍

BTT quality is a nightmare, don't ask me how I know. I wish I had started with RepRap and Duet board two years ago when I picked up the hobby, but then again, I've gotten an extensive education on what doesn't work and a bigger appreciation for what does.

@jens55 on a whim I touched up the solder on the 5v and ground pins on the fan board. Have it running on another pi that's running 2 web cams + a small display and hasn't had an issue yet. I'll test for a couple days. Maybe it was just bad manufacturing.

@leadinglights Thanks for the remark with the Chladni plates! I never heard of these before (not common part of school physics when I was a pupil at least), but this fits perfectly to what I observed with my oscilloscope.

Since my Neo print head would need complete redesign to include a piezo up there, I stuck with reading out the sensors that got crosstalk separately and am quite happy with the result. I see some repeatable measurement errors due to the varying flexibility of the print bed, but that is fine for me for now.

Hm... now that I think of it, it might be worth a feature request to be able to substract a given height map from a newly measured one... by doing this you could remove such measurement errors...

@snt if the Duet3 has an heater3 on gpio, you can use:

M950 S1 C"exp.heater3" ; assign GPIO port 1 to heater3 on expansion connector, servo mode

@engikeneer You are right that could be a good opportunity. I'd have to check clearance really well but if people are interested it can be done 🙂