@Phaedrux:
Thanks again - it works perfectly. I removed the second step however - this is handled by the gcode of the print itself:

M307 xxxxx ; PID values for quick heating
G10 P0 S180 ; set temp of tool to 180°C
M116 ; wait for temp
M307 yyyyy ; PID values for stable temps during print
; final temp is supplied by part gcode

@dc42:
sure, I played a lot with autotune but for some reason did not get any satisfying results with the Duet that combined a quick heat-up and a stable print temperature. I do not remember though if I changed D that much - I will try that.

Interestingly, the autotune of the old Printrboard had yielded a better result, which is why I fell back to setting the PID values with M301 for a while and simply used what the Printrboard autotune had told me on the Duet as well, but I had to resort to setting an M307 setting to define a maximum PWM since the duet does not seem to provide another way to set this - and then overwrite this setting partly with M301. (On the Printrboard I could define the max. PID drive in the firmware eeprom.)
This did not work perfectly though (unsure why - maybe due to different response times of Duet vs. Printrboard?). But for now and with Phaedrux' trick I finally have a setting I feel comfortable with.

By the way - thanks a lot for including the german translation I had sent you into the PanelDue firmware

Same here: I upgraded my Duet Wifi (v1.02) from 3.2.0 (my first v3 firmware) to 3.2.2 and the printer got stuck and required additional help to get WiFi running again. I had used the new update procedure for the PanelDue (5" v3.0) just before that, just to mention that in case it helps. SD card seems fine though, if I can trust Windows...

@dc42 While searching on how to do this, I found your wiki help section "Installing and Updating Firmware" seems a bit outdated. It is still talking about iape4e/iap4s.bin being needed. Thankfully the M997 command complained about the missing Duet2_SDiap... file instead of showing me obscure error codes as some other systems might do.

(thanks @T3P3Tony for getting my account running again btw, the Akismet spam tool drove me nuts... now I can at least post something again even if it still bugs me now and then...)

Just in case somebody stumbles over this thread and has the same problem:

In the meantime I got the second amplifier and included it in my bed sensors.

Dividing the three piezo bed sensors on two different amplifiers - both (digital) outputs being connected in parallel to the input of the Duet - worked perfectly for me. All problems I had with the bed sensors are gone and contact sensing works great even with the slow z axis of my printer.

Thus, I can recommend this method whenever there is a crosstalk problem with piezo sensors.

Hello together,

ever since I finally threw out the old Printrboard on my GRR Neo and replaced it with a Duet Wifi (which I should have done much sooner btw...), I have been fussing around with two things:

• getting the steppers' motion silent (GRR seems to have used some rather weird motors there...) and
• minimizing the oscillation of the temperature of the E3d lite6 hotend.

By now it seems I have finally solved both problems - the motor issue thanks to several hints here and thanks to the new firmware (in case someone needs it - "M569 ... T1:1:0.5:6 C65974" yields the best results so far), and the hotend oscillation after dozens of unsuccessful attempts by rather severely decreasing the max PWM value by using the M307 S... parameter, and this brings me to my question:

By reducing the max. PWM to 0.25, I managed to reduce the temperature swing from ±3...4°C (which was the best I could get out of both automatic as well as manual tweaking PID parameters) to ±0,7...1°C.

The drawback is that it takes now some 8...10 minutes for the Neo to heat up.

So here is my question: is it somehow possible to configure the Duet in such a way that you e.g. use a max. PWM of 0.5 for up to 180°C and then go on with a PWM of 0.25?

(I am aware that I somewhat contradict the idea behind the PID management of the hotend with this question, but as mentioned above I miserably failed getting it to work like that - regardless what I do, PID always either fires too hard when it recognizes a temperature drop or it reacts too slow when temperature is reached)

Best regards
Florian

@arhi I had already posted the setup I used
You can see it here: https://forum.duet3d.com/topic/14477/piezo-board-with-4-sensors/29

The bed screw holes of the original bed support (a shaped sheet metal plate) were drilled open to let the bed springs through, and I added additional screw holes to hold the added aluminium profiles in place and stiffen the original bed support.

The basic "mount" for each sensor is a more or less L-shaped aluminium profile I had lying around (a rest of the cable channel for our TV). You can replace it with any aluminium L profile that has at least the following dimensions: material thickness 1,2mm, long "leg" of L profile 24mm, short "leg" of L profile 8mm.

I cut fitting holes into the material as needed (two screws for the Andromeda, one larger for the bed spring, another screw hole for screwing the whole thing onto the original part and making the assembly stiffer than it was before and two M2 threaded holes for some sensor covers I printed from PETG) and used clinch nuts to get stable threads for mounting the Andromeda sensors. Since I mounted these aluminium plates on top of the original sheet metal bed support so save some millimeters (as noted in the other thread, there is not much available space in my printer), I used DIN 988 adjusting washers to even out the heights when I screwed on the sensors.

In order to catch the tolerances, I mounted everything loosely first, then added the bed and only then tightened all screws with a little bit of Loctite (be careful not to let that stuff get onto the epoxy material of the PCB, in some cases this causes trouble some years later).

That's it, basically... sadly nothing another user could use 1:1 I am afraid - but It's a concept. If I can help you (or anyone else) with details please feel free to ask or send me a message

Wow - that went fast. Thanks a lot, I'll try that!

@phaedrux In that case I sincerely hope I will never ever have to cope with whomever you label as "beginner"

@phaedrux Nice to hear you trust my programming capabilites more than I do

Well then, I downloaded the example and will try to find out what the heck that "Vue" language is. Let's see if I can get it running somehow (and hope nobody will ever look at the code) - the calculation itself is not a big deal indeed...

@phaedrux said in Mesh bed - substract offsets from varying trigger heights:

@neodue said in Mesh bed - substract offsets from varying trigger heights:

Might there be a possibility to automate step 4 and 5 of the following process within the Duet? Or is this already possible today?

Not currently. Though you could probably do something like this in Excel to the raw CSV files.

In future, a plugin could maybe be written that could do it within DWC or DSF on attached SBC.

Excel is exactly how I do it at the moment, but that's not really an ideal process, hence my question

Hm... a DWC plugin would be an idea. In that case, could you please move this request to the DWC wishlist and rename it accordingly? I took a look at the example plugin - but while I could easily contribute with the bit of HTML code needed, my programming capabilites for the rest are nothing I would dare offering to anyone for use...

Bed probes relying on a force feedback such as piezos depend on the stiffness of the bed, which varies depending on the printer design.

Might there be a possibility to automate step 4 and 5 of the following process within the Duet? Or is this already possible today?

1. measure the bed grid with a bed surface which is known as flat (such as a mirror glass glate often is). For this reference measurement, the user must verify that the reference is indeed flat and that the bed is correctly leveled (or he has to do manual work to correct the error)

2. take the heightmap and substract the value of e.g the highest point from all values

3. save this changed heightmap as a reference for the trigger height error

4. measure the bed grid with the surface to be printed on (grid size to be left unchanged relative to the reference height map)

5. substract the value previously saved in the reference height map from the measured value for each point and save the result as the current heightmap

By doing so, any repeatable measurement error of the bed level sensor(s) could be removed, regardless of its origin.

@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...

@phaedrux I am afraid no, at least as far as I can tell.

The underscore is the only thing I changed in my config.g during these tests (with a reboot afterwards each time), and this fault was repeatable on my machine (tried three times in total before I posted)... as soon as I removed the underscore, I did not get any calibration data with M591 D0 when I printed something. But as soon as I add it, I get calibration data for each print (same file printed in both cases time, tested with three different files so far).

I have however not tried yet if the sensor will work without the underscore being included in the name - even if he does not spit out calibration data.

Edit: files were printed from the SD card each time by the way.

@arhi I had already posted the setup I used
You can see it here: https://forum.duet3d.com/topic/14477/piezo-board-with-4-sensors/29

The bed screw holes of the original bed support (a shaped sheet metal plate) were drilled open to let the bed springs through, and I added additional screw holes to hold the added aluminium profiles in place and stiffen the original bed support.

The basic "mount" for each sensor is a more or less L-shaped aluminium profile I had lying around (a rest of the cable channel for our TV). You can replace it with any aluminium L profile that has at least the following dimensions: material thickness 1,2mm, long "leg" of L profile 24mm, short "leg" of L profile 8mm.

I cut fitting holes into the material as needed (two screws for the Andromeda, one larger for the bed spring, another screw hole for screwing the whole thing onto the original part and making the assembly stiffer than it was before and two M2 threaded holes for some sensor covers I printed from PETG) and used clinch nuts to get stable threads for mounting the Andromeda sensors. Since I mounted these aluminium plates on top of the original sheet metal bed support so save some millimeters (as noted in the other thread, there is not much available space in my printer), I used DIN 988 adjusting washers to even out the heights when I screwed on the sensors.

In order to catch the tolerances, I mounted everything loosely first, then added the bed and only then tightened all screws with a little bit of Loctite (be careful not to let that stuff get onto the epoxy material of the PCB, in some cases this causes trouble some years later).

That's it, basically... sadly nothing another user could use 1:1 I am afraid - but It's a concept. If I can help you (or anyone else) with details please feel free to ask or send me a message

Just in case somebody stumbles over this thread and has the same problem:

In the meantime I got the second amplifier and included it in my bed sensors.

Dividing the three piezo bed sensors on two different amplifiers - both (digital) outputs being connected in parallel to the input of the Duet - worked perfectly for me. All problems I had with the bed sensors are gone and contact sensing works great even with the slow z axis of my printer.

Thus, I can recommend this method whenever there is a crosstalk problem with piezo sensors.

@printernoodle you do not need the M574 command (which ought to result in some error anyway since M574 does not support the "E" parameter anymore since version 1.16 - which was quite some years ago).

The M591 command is enough.

The only problem that drove me crazy on my Duet Wifi running with firmware 3.2.2 was the pin name - for some reason M591 D0 P7 C"e0stop"... does not work, but M591 D0 P7 C"e0_stop"... does. Unsure if that is a bug in the Duet firmware or intended behaviour though.

I think that goes too much offtopic now - I'll send you a PM