Hello,
M291 works in RC1 but stop working in RC2.
The babystepping buttons in M291 permanently greyed out.
It is implemented in the custom macro.
M291 P"Please move the nozzle down to 0.10mm above the bed (use thickness gauge), then press OK to perform calibration." R"Nozzle Distance Calibration" S3 Z1 ; display message to jog nozzle down
M292 P0 ; continue operation
@oliof @dc42
Thank you very much for both of your responses. I'm just personally doubting about the quality and the test coverage of the more recently software releases. I know that a whole team of devs/testers is needed with enough funds to feed into the development process. I'm not blaming anyone here and also not trying to say who is not competent enough to develop good software.
V3.4 is still under development cycle and a release candidate was just recently released. Release candidate is from my point of view, should be the most recent stable version with zero new features allowed to be introduced to the software cycle. Only intensive testing and bug fixing should be focused at the current state onwards. Maybe you guys have already done enough testing that wasn't documented on Github. I don't mind If the current development process already fits your team workflow. It's really hard for a small team to develop really stable software, It's also hard for one man to keep track bugs that was reported, while also bringing new features to the software at the same time.
Dev hates testers for how annoying and picky they can be.
Testers also hate it when dev made errors on a simple task. No human is perfect even though you thought so.
If the dev has to test his own software, maybe they will find a few bugs here and there, but not much when a 2nd/3rd person looking at it against the written requirements.
Automotive ECUs are fairly flexible as well, with homologation laws and multiple variants of car configuration possible. The same ECU will also go into several car brands and models in its parent group. Some control units from Audi will also land in VW, Porsche, Lamborghini, Bentley, Skoda, etc. Very flexible indeed. They were still able to ensure great software quality in their system as well.
System test are very costly and time consuming to implement and run. But skipping the earlier tests in the V-chain is not gonna help uncover the bug in an isolated environment. At least some tests are better than no tests at all.
I like Duet ecosystem a lot and own genuine board. All the printers that I've built were designed to run Duet from the very start. Never plan to made a switch to Klipper or anything else similar in the near future. I'm glad to hear that further testing are planned in the near future. 
Hi, I've experienced in software testing in the Automotive Industries before.
Upon looking at the source code on Github, I've not seen any information or anything related about testing on Duet firmware.
Recently (v3.4+), I've experienced somewhat huge amount of software issues that weren't there in the previous betas, but surprisingly introduced in the newer beta/RC versions. That is why I'm starting to question about the quality of the firmware itself with regards to the implementation of the new features.
Duet firmware is to me seems like a reasonably sized project with demand in perfectly executed software features and execution order. Imagine people use this software on their CNC mill, or plasma cutter and suddenly the software behave unexpectedly and led to a crash on CNC or fire hazard on the plasma cutter. However I've seen none of the basic set of software tests perform on the project itself.
I'm just trying to hint out that the longer this thing released untested with increasing number of new features, the more messy and problematic and unreliable it will become in the future. Do not count on real world user to test software and report bug to you. People will tend to move on and find alternative that ensure the expected quality.
From what I've observed on the Github commit activities, the firmware is mostly a one man show who does almost all the implementations (1 man for firmware, 1 man for DWC, 1 man for PanelDue, 1 man for DSF, etc. From my experience, this has led to several project downfall and abandonware in the Automotive industries. OEM that experienced this kind of problem will mostly find a suppliers/subcontractors to overtake this deep pile of shit from them, and let the cheaper labor ensure the software quality for them instead. Recall is very costly in the industry, and I've seen a recall from a software module that was tested once and everybody thinks that retest in unnecessary because the module was untouched between software releases. Bugs begin to show once this module in integrated with another module in the system.
Each software feature/functionality deserves, at least, its own unit tests, that must be executed prior to release. I've not even move up to the Integration tests or even System tests that in usually perform sequentially to ensure quality in the proper software release cycle.
You have written up well enough System/Architecture requirements in Dozuki, but lack of traceability and the verification step to ensure the requirements are fully met. I think starting with well written requirements and a test project on Github that could be linked to the intended requirements will be a great starting point.
@dc42 Hi, It's hard for me to make the issue reproducible as well.
What you could try is to set the M203 extruder max speed to some really high value (50,000mm/min) or some value that the extruder will definitely stalled upon rapid movement. Also up the jerk/acceleration values to allow the extruder to stall on unwanted rapid movement as well.
Make the retraction length really long (10-20mm) but only set M207 retract at normal speed (35-60mm/s).
Slice and run the retraction tower or anything similar that will perform G10/G11 a number of times. The problem is that the issue is inconsistent, with the same Gcode file, extruders will sometime randomly do rapid extrusions/retractions. The behavior sometime happen with just a manual G1 E** input in the console as well.
** I ended up rolled back to v3.3 to get the normal behavior back.
@diamondback The issue is still there, but I have to find the way to make the machine work reliable again around this issue. With the rapid retracts/extrusions, sometime I get extruder jam on softer filaments (HIPS/ABS/Some PLA variants).
@diamondback Hi, do you mind sharing your jerk/acceleration/max speed for extruder here as well?
The problem seems to go away when I reduced the value of jerk/acceleration of extruder. I would like to know how your machine is setup for these values.
The problem is definitely there, I'm just setup the config to avoid this specific firmware issue.
@dc42 I was be able to make the problem go away by changing acceleration/jerk/max. speed of the extruder. The same print file running with old config.g and new config.g show no sign of unwanted rapid extrusion.
The test ran using 3.4b7+7. This might help narrow down the issue.
The jerk was reduced from 1000 to 300mm/min (5mm/s)
Max speed was reduced from 9000 to 3600mm/min (60mm/s)
Acceleration was reduced from 10000 to 5000 mm/s2
Since the above parameter was reduced, I've reduced the extruder motor current from 800mA to 600mA as well.
@dc42 Unfortunately, the issue is still persist with the 3.4b7+3 firmware.
@dc42 I'll test with the attached firmware and let you know how it is
@dc42 I have found something interesting. Since the firmware retraction behave unexpectedly, I've switch to slicer retraction and ran some test prints. The retract/unretract or let say any commands that involve extruder movement. Sometime the extruder move at a very high speed as well (Command that involve pure extruder move e.g. G1 E5).
This show that the issue is not purely related to retractions.
I think it will be easier to debug the issue by simply setup a gcode with a bunch of G1 E** commands and observe the extruder speed.
Hope it help for further investigation.
@dc42 Hi sorry that it took too long on my part.
I've attached the zip containing the files from SD card.
config, gcode, filament and macros that are used in startup/ending sequences.
The forum doesn't allow me to upload zip file, so please rename the file extension to ".zip" afterwards
repo.txt
The attached gcode file is just a bunch of 5x0.2mm hollowed cylinders. The machine and gcode is setup to do firmware retraction.
@dc42 Hi, I will setup some print files and all the associated settings and send it to you in couple of hours.
@argo I have not had my PA activated for this issue to happen. I believe this issue neither related to Pressure Advance nor Input Shaping.
@rks7204 looks like a similar issue here.
https://forum.duet3d.com/topic/26261/3-4-0beta6-home-limit-switch-bug
It happened to me on the new 3.4 firmware as well. But only if I set acceleration to a high value (>8000-10000mm/min)
Funny is, this number works on 3.3 without Phase disconnected warning.
@dc42 Hi, I haven't enable Pressure Advance on this firmware as seen in the attached filament config file.
I've had issue with pressure advance grinding the filament in the extruder on long bowden setup. Probably due to my pressure advance, extruder jerk/acceleration settings so it has been disabled on this machine.
@diamondback Have you had any issue with firmware retraction as well?
Try printing the retraction calibration tower at around 30mm/s retraction speed and something the extruder retract/unretract faster than Formula 1.
@dc42 I've attached a video of the issue.
The firmware retraction is set to
M207 S10 R0.0 F2400 Z0.2
No extra T parameter to specify the unretract speed.
The extruder is sometime retracting/unretracting at the speed way above the M207 definition.
Below is the M122 during this printing session.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta7 (2021-12-16 12:22:11) running on Duet WiFi 1.02 or later + DueX5
Board ID: 0JD0M-9P6M2-NWNS0-7JTD2-3SN6Q-TV0RK
Used output buffers: 3 of 24 (23 max)
=== RTOS ===
Static ram: 23804
Dynamic ram: 75784 of which 12 recycled
Never used RAM 8808, free system stack 102 words
Tasks: NETWORK(ready,14.0%,237) HEAT(notifyWait,0.1%,311) Move(notifyWait,1.4%,285) DUEX(notifyWait,0.0%,24) MAIN(running,84.4%,440) IDLE(ready,0.1%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:26:10 ago, cause: software
Last software reset at 2021-12-23 10:51, reason: User, GCodes spinning, available RAM 9952, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 37.6, current 42.0, max 43.1
Supply voltage: min 23.9, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/6, heap memory allocated/used/recyclable 2048/708/510, gc cycles 0
Events: 3 queued, 3 completed
Driver 0: pos 38686, standstill, SG min 0
Driver 1: pos -867, standstill, SG min 0
Driver 2: pos 1425, standstill, SG min n/a
Driver 3: pos 0, standstill, SG min n/a
Driver 4: pos 0, standstill, SG min n/a
Driver 5: pos 0, standstill, SG min 0
Driver 6: pos 0, standstill, SG min 0
Driver 7: pos 0, ok, SG min 0
Driver 8: pos 0, standstill, SG min n/a
Driver 9: pos 0, standstill, SG min n/a
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2021-12-23 11:17:32
Cache data hit count 4294967295
Slowest loop: 134.83ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 2.0ms, write time 116.3ms, max retries 0
=== Move ===
DMs created 83, segments created 34, maxWait 342508ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 10138, completed 10113, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X216.088 Y249.907 F30000" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== DueX ===
Read count 1, 0.04 reads/min
=== Network ===
Slowest loop: 134.14ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 2 of 8
- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address f4:cf:a2:ea:89:e6
WiFi Vcc 3.38, reset reason Power up
WiFi flash size 4194304, free heap 25776
WiFi IP address 192.168.1.49
WiFi signal strength -39dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
@dc42 I've flashed back and forth between 3.3 and 3.4 before, and could confirm from the same print gcode that the retraction behavior differs in these two versions. I've also tried with Input Shaping/Pressure Advance turned off.
@dc42 Hi, my printer has relatively long bowden tube. The retraction is set at around 8-12mm depending on the filament used. The retract/unretract speed is set to be around 6000mm/min. The wheezing sound of the bowden extruder driving the filament forward/reverse is pretty much in memory for the 3D printer I used. The sound of the retraction speed on v3.3 is consistent. On v3.4, it sometime retract at the set speed and unretract extremely fast (the motor sound higher due to faster speed). And this happened randomly between retract or unretract moves.
I've attached the filament config.g and the Duet config.g in case it help with debugging the behavior.