First of all, VERY COOL idea. I presently have FSRs on my bed. I'm following this thread with lots of interest.

One thought on redundancy, using your idea of back to back transducers… Maybe set it up such that both sensors are handled separately with signal conditioning, then the outputs are logically "AND"ed together. Then, if both don't trigger as expected (maybe after an RC time constant??), the ANDed output stays triggered (or is somehow latched triggered), which will signal an issue to the Duet's firmware.

Or similarly, have a second output from the signal conditioning board that would change states if the outputs don't behave as expected (i.e. last time, only one triggered). This signal could be monitored by the Duet firmware to identify a fault condition.

In either of these cases, you would probably have to match the gain and offset of the signal conditioning/comparator for each sensor such that they trigger at the same time. Or get really slick about it and let a tiny PIC automatically configure gain/offset for each side and also have it drive the triggered output with a buffered signal.

Hope that all makes sense. I don't know if what I suggest is feasible, but I thought I'd throw it out there.

@dc42:

Sorry I won't be able to look at this for several more days. I've already looked at the code changes in 1.15c and I didn't find anything to explain it.

If you wish, you could try connecting the fsr board to the Z probe connector instead of E0 and use probe type 5.

I tried this and it worked! The signal line from the FSR board (Green wire) moved to "Z_PROBE_IN". Black to GND and Red to +3.3V.

It must have had something to do with the E0 endstop being used as the probe signal input.

I also tried firmware 1.15c with 18 bed probe points and that worked as well. So the only things I changed were going from E0 STOP to Z_PROBE_IN for the FSR probe board signal connection. This required changing the M558 parameter from P4 to P5.

For clarification, the G0 vs. G1 conversation that happened in the recent posts… I don't believe it has anything to do with the FSR probes not working. That was something to do with the reported object height on the DWC interface.

@dc42:

Those of you who are having Z probe trouble going from 1.15b to 1.15c, what probe type do you have set in M558, and how do you have the probe connected?

Any more thoughts on this issue?
I know you are quite busy, and hopefully have a life outside 3D printing, so I understand any delay.

Mine is connected to the E0 endstop.
Jumper on JohnSL board is set for NC

M558 P4 X0 Y0 Z0
M574 X2 Y2 Z2 S0 // hall effect switches at the top of each delta tower
G31 X0 Y0 Z0 P500

Thanks DC

I just had the same problem with the FSR sensors (JohnSL board). With 1.15c when I try an auto bed calibration on my delta, it says the endstops are already triggered. No hardware change. Reverted back to 1.15b and it works again. I tried rebooting the duet wifi, but that didn't help.

I do have a 17 point bed.g file. 10 points on perimeter and 6 points halfway in and one in the center. Don't know if that matters.

I do have the jumper on the JohnSL board to make the board look like (I think) a normally closed switch. This didn't get changed between firmware.

Not sure why but it is something different in 1.15c.

Thanks for the info. Now that I have my printer mostly dialed in, I'm looking into slicers and slicing parameters. I was curious how you did it.
Cheers!

Very, very cool.

Out of curiosity, is this done with the "vase" spiral mode, or are there more than one perimeters per layer?

If it's not a spiral, how did you deal with the seams? Are they running up the back of his head?

And what slicer program did you use?

Makes perfect sense. I just noticed that "one of these things is not like the other".

Thanks for posting this. It might come in handy down the road.
I had a look through the schematics and noticed that Fan1 doesn't have the 10k pull-down between the gate and ground like the others have. It probably doesn't matter if the processor has internal pull downs.

Quick update…

Using the 1.15 rc3 firmware, I was able to tune my heated bed after increasing the dead time parameter. I did 4 tuning runs on the hot end and 2 runs on the bed. They gave very consistent results, which I averaged and put into the M307 lines in my config.g file.

I now have the hot end and bed calibrated and they seem to work really well! Overshoot on the both the bed and hot end is maybe 0.5 deg C max. Once stabilized, they stay very consistent.

I also updated to the latest release 1.15 and DWC and webserver files.

Good job dc42 and chrishamm!