... to all the Duet 3D programmers. I just updated the Duet and the PanelDue to 3.4.0 - and especially the latter part shows how far you have come with simplifying the task: upload, right-click, choose "install" and that's it.
This is light years away from the old process with Bossa. Congratulations for making this so effortless!
@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 
@dc42 Thanks a lot! Then this is really weird, because this does not fit for some reason.
My explanation above does not seem clear enough, so let me try to rephrase what happened:
All in all, using M221 does behave differently on my Duet Wifi than changing the extruder values directly in the gcode - the latter seems to have about a 10 times higher effect than the former if I use the same percentage value in both cases.
@fcwilt Is this explanation clearer?
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:
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
@fcwilt said in M221 with percentage value behaves strangely:
- What do you mean by "until the extrusion fit"?
I changed the M221 setting, printed that part (you might have noticed it is rather small - just 3x4mm, so printing is pretty fast), optically checked and measured it, changed it again etc. until the part turned out as it should.
- Have you verified the steps-per-mm setting for the extruder?
Yes, the extruder setting is fine. Maybe I should add I have had this printer in regular use for years and it prints perfectly well. This only happens if I use M221. Apart from that, the steps-per-mm setting of the extruder should not be affected whether I use M221 in my code or not
@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
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...)
Wow - that went fast. Thanks a lot, I'll try that!
... to all the Duet 3D programmers. I just updated the Duet and the PanelDue to 3.4.0 - and especially the latter part shows how far you have come with simplifying the task: upload, right-click, choose "install" and that's it.
This is light years away from the old process with Bossa. Congratulations for making this so effortless!
@dc42 This means for any files called with M98, M221 is not executed? Yes, that - mostly - explains it.
The only thing I wonder about then is that M221 still seems to have a minor effect from within my subprogram - as noted, adding M221 S42 seemed to reduce my extruder flow slightly - at least from what I could tell.
@phaedrux I guess the correct answer would be "both"... I have one file (code added below) that I start as a job from the SD card that initialises the printer (set temps, call my standard homing macro etc.). This file then sets the second coordinate system and calls the second file ("multipart.gcode" which then contains the gcode part of which I posted above) with M98.
M107 ; turn off fan in case it was manually turned on before
M190 S60 ; set bed temperature and wait for it to be reached
;TYPE:Custom
; prepare printer
G28 ; zero axes
M98 P"/sys/homezfein.g" ; heat hotend to 160°C and fine home z with piezo bed sensors
G10 P0 S215 ; final temp for first layer
M116 ; wait
M98 P"/sys/naseputzen.g" ; wipe nozzle and start printing
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G92 E0
; Filament gcode
; 1st part
G1 X68.5 Y43 F6000 ; go to new print centre
G10 L20 P2 X78.5 Y78 ; ... define 2nd coordinate system
G55 ; activate 2nd coordinate system
M98 P"0:/gcodes/multipart.gcode" ; call part gcode as subprogram
G54 ; reactivate main coordinate system
; 2nd part
G1 X68.5 Y78 F6000 ; go to new print centre
G10 L20 P2 X78.5 Y78 ; ... define 2nd coordinate systemn
G55 ; activate 2nd coordinate system
M98 P"0:/gcodes/multipart.gcode" ; call part gcode as subprogram
G54 ; reactivate main coordinate system
; 3rd part
G1 X68.5 Y113 F6000 ; go to new print centre
G10 L20 P2 X78.5 Y78 ; ... define 2nd coordinate system
G55 ; activate 2nd coordinate system
M98 P"0:/gcodes/multipart.gcode" ; call part gcode as subprogram
G54 ; reactivate main coordinate system
M107
;TYPE:Custom
; Filament-specific end gcode
;END gcode for filament
M98 P"/sys/cancel.g" ; call cancel macro to end printing
@fcwilt said in M221 with percentage value behaves strangely:
- What do you mean by "until the extrusion fit"?
I changed the M221 setting, printed that part (you might have noticed it is rather small - just 3x4mm, so printing is pretty fast), optically checked and measured it, changed it again etc. until the part turned out as it should.
- Have you verified the steps-per-mm setting for the extruder?
Yes, the extruder setting is fine. Maybe I should add I have had this printer in regular use for years and it prints perfectly well. This only happens if I use M221. Apart from that, the steps-per-mm setting of the extruder should not be affected whether I use M221 in my code or not
@dc42 Thanks a lot! Then this is really weird, because this does not fit for some reason.
My explanation above does not seem clear enough, so let me try to rephrase what happened:
All in all, using M221 does behave differently on my Duet Wifi than changing the extruder values directly in the gcode - the latter seems to have about a 10 times higher effect than the former if I use the same percentage value in both cases.
@fcwilt Is this explanation clearer?
Currently my printer is running firmware 3.2.2 (I do not remember noticing any difference with 3.3 though but I did not explicitly check this), and I have a problem with recalculating the extruder moves on a hand-optimised piece of code.
The existing code is called with M98 from another file after defining and activating a second coordinate system in order to be able to print several of these parts. Here is the relevant section:
[skirt and layer 0 code removed]
M221 S42 ; just 42% - what the heck??
;LAYER_CHANGE
;Z:0.35
;HEIGHT:0.15
;LAYER:1
G1 Z0.350 F6000.000
G1 X77.216 Y77.222 F6000.000
G1 F120.000
G1 X79.780 Y77.228 E0.05871
G1 X79.780 Y79.780 E0.05844
G1 X76.220 Y79.780 E0.08151
G1 X76.220 Y77.220 E0.05862
G1 X77.156 Y77.222 E0.02142
G1 X76.619 Y77.702 F6000.000
G1 F120.000
G1 X76.619 Y79.464 E0.05462
G1 X76.619 Y77.537 E0.05974
G1 X77.171 Y77.538 E0.01713
G1 X77.171 Y79.464 E0.05970
G1 X77.724 Y79.464 E0.01713
G1 X77.724 Y77.540 E0.05966
G1 X78.276 Y77.541 E0.01713
G1 X78.276 Y79.464 E0.05963
G1 X78.829 Y79.464 E0.01713
G1 X78.829 Y77.542 E0.05959
G1 X79.381 Y77.543 E0.01713
G1 X79.381 Y79.464 E0.05955
[several more similar layers follow]
where I want to remove the M221 code to make later maintenance easier.
From what I get from the gcode reference, I ought to be able to recalculate the E values in this case with "new E value = old E value * 0.42" since a value of 1...100 after M221 ought be a percentage value. This does however result in massive underextrusion.
After a lot of attempts, I can say now I only get a comparable result if I calculate as follows: "new E value = old E value * (1-0,042)" - which again does not seem to fit to the explanation of M221 as I understand it.
The printer runs perfectly fine otherwise - but my usual prints (some of them being of similar size) do not not include M221 at all - I used it here to find the "sweet spot" since the part has rather tight tolerances in this area. My extruder is defined with 256 microsteps (6640 microsteps per mm of material) and no interpolation.
Can anyone check/confirm this - or correct my misunderstanding of the gcode reference entry if there is one? If needed, I can upload the gcode file as well, but I guess this would not be of much use on another printer...
@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?
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)
take the heightmap and substract the value of e.g the highest point from all values
save this changed heightmap as a reference for the trigger height error
measure the bed grid with the surface to be printed on (grid size to be left unchanged relative to the reference height map)
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.