The G31 P value is intended to set the threshold for analog sensors. The fact that it can be used to debounce noisy digital Z probe inputs is a by-product of the filtering that is applied. A Z probe reading is taken every 2ms and that is passed into an averaging filter. The filer takes the average of the last 8 readings. For an analog Z probe, the reading is whatever the probe returns. For a digital Z probe, it is 1000 when the probe output is active and 0 when it isn't.
The upshot of this is:
Events shorter than 2ms in duration may not be seen
If you use a digital sensor and you set the G31 P parameter to 125 or less, then a single active reading from the probe is sufficient to cause a trigger
If you set the threshold between 126 and 250 then you need two readings out of the last 8 to be active to cause a trigger
The 2ms interval between readings is a hangover from the old code that used the Arduino core, and I'll probably change it to 1ms before the 1.18 release.
Yeah… How do I make an embarrassed face lol.
I figured the 104 thing out last night. Once you choose proper values (I ended up using a 1 nF capacitor), such a simple circuit is quite effective at filtering the high frequency noise with almost no impact on the signal.
There is a 12V regulator on the DueX5 but not on the Duet. You can wire the fans as you say; or if all your fans are 12V, you can remove the fan voltage select jumper on the Duet and feed +12V to the centre pin of the jumper block instead.
Schematics are at https://github.com/T3P3.
I'm leaning towards the idea that in my case, with the PC close by, the PanelDue isn't going to give me anything apart from being a backup if I can't use my PC for any reason…............. But then that might be a useful backup facility to have......... And then again, I hadn't considered that if the Printer had a PanelDue attached, I could relocate it............hmmm...........
Thanks for the feedback guys
I can't imagine the processing required to do any type of z probing is taxing the duet controller if it can generate step pulses at 350Khz. Whether you want to integrate this type of thing is another issue. If you fit an accelerometer it processes it doesn't require the controller to process its raw data that's happening on board, its outputting the results.
I think I just found my answer,
If using JohnSL's trinket board: Connect its Vcc, Output and Ground pins to 3V3, STP and GND respectively on the E0 endstop connector, and select mode 4. Alternatively, connect them to 3.3V, IN and GND on the Z-probe connector and select mode 5.
Cable is just 4 strands of 7/02 - not screened but with nylon braid outer. The wiring for the hot end PT100 on the second channel is the same but runs inside a flexible conduit alongside the cables for all three extruders for about 1 metre, so a much worse case but that one is fine.
Can't find any intermittent connections when I wiggle the wires around. As I said, I can flex the wires and the connections as well as the cable chain that they run in between the moveable bed and the frame, all day long but never make it happen.
The only time I can make it happen is by doing a largish Z move and it's regardless of whether the bed heater is running or not. Never seen it during a normal print. So the only time it happens is when the Z motor is running continuously for a few seconds or more. Which would indicate that it's noise from the Z motor wiring being picked up by the PT100 wiring? I wouldn't have thought it's the Z motor itself because that's at the bottom of the frame, normally about 750 mm below the bed. The PT100 itself is embedded in the aluminium build plate, miles away from anything else (well a couple of hundred mm at least). The closest the PT100 wiring gets to the Z motor wiring is about 40mm where they both run up one of the 2040 legs but at opposite sides. Where the cables enter my Duet enclosure, the PT100 comes in at the top but the Z motor cable comes in at the bottom.
The odd thing is that it's only recently started happening and if it was interference due to cable type or routing, I'd expect to see much worse on the hot end PT100 with it's long parallel runs with the 3 extruder motor cables. Having said that, the extruders don't work as hard as the Z motor when it's lifting my 7kg bed,
I guess I'll try swapping the PT100s on the daughter board as Tony suggested and see if it stays with the sensor or with the channel on the board.
hm… I just saw that my console dont stops writing:
"Attempt to move the head of a delta printer before homing the towers"
What could be the problem ?
What it says. You tried to print before you homed the printer. Or you turned the motors off at the end of the previous print, so the firmware can't be sure of the head position any more and you need to home it again before you do another print.
Some people use G28 in their slicer start gcode to make sure the printer is homed before printing.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.