Posts made by Notepad

@dc42

I have results so far!

For firmware updates with no gcode changes
Beta 2+1 behaves as expected
Beta 2+3 Produces the artefact (does not move in a diagonal at first move command)
Beta 2+4 Produces the artefact

Using Beta 2+4 the Quick Home XL macro has been edited with debug steps
Quick Home XL.txt

Which has produced the following

Whilst the order of the debug outputs are out of sync with the requests. once the values have been shifted around, the requested changes do appear to be happening.
This does not rule out if the printer is processing command moves with incorrect values, but it is more likely that the print to DWC service might have a delay.
Both behaviours however do not explain the sudden rise in the Z accelerations.

---

Replacing M201 in the macro with M201.1 in the config.g

Important to note the M201 in the macro only commands the X & Y motors, the Z acceleration is commanded in the config.g already (set to z500).

the Config.g was updated to include M201.1 Z300

This did no change to the behaviour

---

M906 was removed from the macro, which did noticeably increase the distance the bed could move before stalling. This definitely highlighted that the bed was accelerating very aggressively.

---

To guarantee that this behaviour is repeatable, I have tested this on a separate machine. This machine does not have a roto toolboard, and is instead using a D3-mini WITHOUT sbc.
The firmware version is 3.6.0.beta2+4
config.g Quick Home XL.txt

The behaviour of the motor stalling from excessive accelerations is also present on this machine.

---

This currently concludes my available testing. It appears that the use of M201, M201.1 M906 do not affect the behaviour of the printers, and the z motion on consecutive homing moves appears to stay broken.

Homing the printer through the homeall button does appear to be working, The first use after using the macro does produce the same error, but subsequent uses of the homeall.g appears to be working normally.
The single error appeared when a G30 line was used in the middle of the homing sequence

What is very interesting is after using a mixture of homeall.g and quickhome.g the printer does not seem to be doing the incorrect behaviour any more. What did show up a single time before this behaviour change (but after the machine has been moving multiple times) is the print head on a homeY.g move, moved backwards in a 15 degree angle. After this the z movement stayed consistantly working normally.

My current gut feeling is the issue may be directly linked to the diagonal moving identified in Beta2+3

---

I hope this is helpful @dc42, if there is any way to gather more advanced debug logs that would be helpful. feel free to use me in any way needed,

@dc42 Is it possible to get a binary made for the duet 2. last thing I need to test is if its hardware specific.

@dc42 Thats good to know. is there any additional testing you would like me to undertake with this new identified behaviour?

@dc42 Just to keep you updated. I will have the testing results tomorrow

@MrAwesome987 Unfortunately I havent seen any mount to go direct from E3D PZ coldside kit to Roto. For me Im using the PZ disk on its own and then making my own adaptor mount

@MrAwesome987
The advantage of having 3 sensors is you can have a redundant setup. if you set the sensitivity too low, then the sensor might not activate. by having multiple, you only need a single one to activate to tell the printer that the bed/nozzle has homed.

The downside of the sensors is they can be a bit of a hassle to set up, as if you set them to be too sensitive, they could also pick up vibrations from other sources (like someone dropping a heavy object on a suspended floor)

@MrAwesome987 said in Z Probe Options:

You mention putting the piezo under the bed... (Really showing my ignorance here...) How would that work? Do I need more than one?

You would only need one, but if money was no option, having one under each mount point could give a level of redundancy.

The way piezo disks work is they translate crushing force into a analog voltage output, so as long as when the nozzle taps the bed, the force can be pushed through the peizo disk, then it should sense.

I had a version that used it but unfortunately my bed mounting was too dampened with silicone spacers so it didn't have enough impulse to reliable sense the force.
For reference, Bambulabs P1 series has a peizo (its actually a load cell so technically different but works similarly) for their nozzle probing.

@MrAwesome987 If you have access to a CNC lathe, I would recommend making an adaptor to go from roto/hemera heartbreak to Voron mounting plate.
That way you can use the E3D probe on any voron style heat block

Alternatively you could look at putting Piezo disks under the bed, or having some form of tap/rtap plate

I personally would stick away from inductive probes and BLtouches nowadays as alternative solutions give perfect nozzle probing. otherwise a good M12 sized inductive probe is a fool proof solution.

@dc42
Will do. I had to step out the factory for today so I will get these tested tomorrow.

@dc42

please log a feature request for these on Github Issues.

Understood! Ill get on that later today.

I'm mostly using the tacho output as a method of error checking and its going to be the start of a process of per print documentation for part validation. It is quite nice to see the tacho output in the DWC and great at determining overall airflow from its output, but, its not actually that important for end customers to see, other than it looking quite cool.

The main reason for the 4 wire 12032 fans is actually for the quality of the fans outshines that of the standard 2 wire fans. The ones I have on hand even have stall detection and speed/load control which are noticeably quieter and start up smother with less of an amperage spike from a partially stalled stator when the initial power up cycle begins.

@darylprice Hi Larry, My name is Jacob, and I have quite a bit of experience with the Duet ecosystem and use them as my preferred motherboard/control board supplier.
I have used them for various machines ranging from tiny sub 100x100x100mm print volumes all the way up to 650x650x800mm Nema23 powered machines. My go to machines are all Duet powered, and have a build volume of 330x390x440, with print speeds of 600mm/s and accelerations of >6,000mm/s^2

The Duet ecosystem is more than capable of extreme high end printing and is fully user configurable. And yes, it can support multiple heat zones!

I would recommend looking at the Duet36HC. As for the nozzle, you will almost definitely want something with a very high flow for a large print volume. I would look at the Vez3D Goliath, and replacing its standard nozzle with a CHT nozzle for extra flow rate.

Im trying to set up a bank of auxiliary part cooling fans to be controllable via slicer output.
Most slicers appear to only have a single M106 command dedicated to Aux part cooling.

For Orca slicer in particular it is M106 P2 for Auxiliary fans and M106 P3 for chamber exhaust fans.

I currently have 4x Tacho enabled 4 wire aux fans

;Chamber Fans
M950 F4 C"!out4+out4.tach"                                              ;Chamber 12032 fans connected to 4 wire on mainboard
M950 F5 C"!out5+out5.tach"
M950 F6 C"!out6+out6.tach"
M950 F7 C"!out7+io7.in"                                                 ;Chamber 12032 fans connected to 2 wire output and io7 as input for tach on mainboard

Any ideas if this is possible?

---

From what I currently can see with the M106 inputs, a single Pnnn is used relating to the fan of the same number.
It would be nice to have a new optional input say Fnn:nn:nn where if the "F" is present, then it maps thsoe fans to a single fan tool.
This would also have the added affect of getting rid of lots of individual fan controls on DWC and instead having a single control for those grouped fans.

If this was done, then it could look something like this
M106 P2 F4:5:6:7 S0 B0.5 C"Auxiliary Fans"

@Argo

Beta2+1 https://www.dropbox.com/scl/fo/kaxbpbsyq2lxbae4tmzpk/AAPVUAh6CO_FMO-cG9ttX6U?rlkey=f0aesppc8d2p7bzwwi2s1jayo&dl=0.
(newest) Beta2+4 https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0.

You may want to try beta2+4's homing behaviour, For me something broke, On +1 it was fine.
Most of the step timing errors have been fixed in beta2

@dc42 THe last version I was running was Beta2+1
At the time I wasnt aware of a +2 +3 or available. If you have the Drop box link, I can load each one up and see which version started the behaviour

@scottcowen
The easiest way to do this will be to copy all the system files to your desktop/laptop. then recreate them on the 6HC as needed.
Because some of the ports will be different, you will have to edit some of the config.g to make this transition, but its not very painful, just a bit tedious. This will most likely be Pin names of the fans, heaters, etc.

Honestly I would recommend starting with the generic welcome tutorial on the docs.duet3d.com and update all the Gcode necessary

It looks like something related to probing speeds might have broken in Beta2+4

The first homing process from a fresh restart works completely normally. but subsequent homing procedures appear to either have the wrong accelerations or max speed applied.
Sending G30 on its own seems to be completely fine and doesn't replicate the issue.

I have made a YouTube Video showing the behaviour by pressing the Quick Home macro x3 times from a cold boot
https://www.youtube.com/shorts/KTWl_apopfc

config.g
Quick Home XL.g

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-beta.2+4 (2024-12-01 18:12:13) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD2M-9P9DA-F0PSD-6JKDD-3S06M-9PSH2
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 136756
Dynamic ram: 98216 of which 2936 recycled
Never used RAM 90068, free system stack 117 words
Tasks: LASER(5,nWait 7,0.0%,223) SBC(2,ready,0.9%,825) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,236) TMC(4,nWait 6,3.1%,345) CanReceiv(6,nWait 1,0.0%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,352) MAIN(2,running,95.5%,101) IDLE(0,ready,0.4%,29) USBD(3,blocked,0.0%,144), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:04:38 ago, cause: software
Last software reset at 2024-12-01 21:14, reason: User, Platform spinning, available RAM 90044, slot 1
Software reset code 0x2000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 39.4, current 39.8, max 40.0
Supply voltage: min 25.0, current 25.1, max 25.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/10, heap memory allocated/used/recyclable 2048/164/24, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-12-01 21:19:15
Slowest loop: 55.75ms; fastest: 0.05ms
USB interrupts 3
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 30, maxWait 94377ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 62400.00/62400/0.00 -11200.00/-11200/0.00 28000.00/28000/0.00
no step interrupt scheduled
Driver 0: standstill, SG min 0, mspos 392, reads 32681, writes 34 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 32704, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 392, reads 32681, writes 34 timeouts 0
Driver 3: standstill, SG min 0, mspos 756, reads 32668, writes 47 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 32704, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 1012, reads 32668, writes 47 timeouts 0
Phase step loop runtime (us): min=0, max=28, frequency (Hz): min=1677, max=2459
=== DDARing 0 ===
Scheduled moves 33, completed 33, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 2 -1 -1 -1 -1 -1 -1 -1, ordering errHeater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle 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
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2512, received 5581, lost 0, ignored 0, errs 136, boc 0
Longest wait 1ms for reply type 6043, peak Tx sync delay 21742, free buffers 50 (min 49), ts 1394/1393/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 10792/10792
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x27d20
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.6.0-beta.2 (2024-11-14 11:02:38, 64-bit)
HTTP+Executed:
> Executing M122
Daemon:
>> Doing macro daemon.g, started by system
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.52, max time between full transfers: 53.8ms, max pin wait times: 52.8ms/2.3ms
Codes per second: 6.30
Maximum length of RX/TX data transfers: 4361/960

@stuartofmt I GOT IT WORKING, and your "grubby" fix did the job perfectly

I kid you not, the thing that was holding it back was this:
What not to click:

Instead click on the additional options
And manually select ZIP again, and then it works..... Yup. 7Zip didnt work even if you select ZIP compression, Same with Win11's default. but additional options somehow works

@gloomyandy Not to worry, most of our farm is still using the stable 3.5.x.
I do however have about 5 machines dedicated to testing Alpha/Beta + quick fixes/interim builds for the sole use of trying to find what breaks in the firmware so we can provide diag logs to help with the firmware development process.

Plus you never know if a small change has broken something elsewhere, that may only crop up if a machine has been running for X hours before it can manifest

@gloomyandy
That makes sense. I was mostly in the mindset that testing each +X version might identify unexpected behaviours by the small fixes of each unofficial version

Do we know what was changed between 3.6.0-beta.2+2 and 3.6.0-beta.2+3?

Unfortunately I cant find any posts when I use the search with "3.6.0-beta.2+3" even though I can physically see a post with that string in the title https://forum.duet3d.com/topic/37032/rrf-3-6-0-beta2-3-corexy-kinematics-seem-to-be-broken

It might be a good practice to post each Alpha/Beta+X version to the pinned thread as I almost missed B2+3 and the search doesn't seem to be able to find it for some reason.