@tristanryerparke said in Duet 3 3.2 Beta2 + SBC jerking motion:

I believe this is the same issue as the what the OP had.

Ah, sorry, I didn't notice that you weren't the OP.

Yes please create a new thread.

@Klaas-B Glad to hear that solved it! The SD card can be used either in the Duet or the Pi but if a Pi is attached no SD card must be present in the Duet.

@evomotors said in Duet3 resets mid print on RRF 3.2:

SD card (Pre imaged) that came with Duet3 board

Definitely try a fresh one.

@Phaedrux I think so.
This is the current M307 that's running on the printer now and seems to control the bed well.
M307 H0 R0.196 C734.056:734.056 D0.65 S1.00 V12.1 B0

This is config-override.g from a backup I made in June, 2020
M307 H0 A172.9 C784.9 D0.4 S1.00 V11.9 B0

At the fourth try the tune returned a result:
Warning: heater behaviour was not consistent during tuning
Auto tuning heater 0 completed after 3 idle and 25 tuning cycles in 3280 seconds. This heater needs the following M307 command:
M307 H0 R0.223 C738.8 D0.64 S1.00 V12.1

The values appear to not be very much different from the current M307.

I captured a portion of the temperature chart. The whole tune cycle looked like this portion. A gentle sawtooth moving between 65 and 70 degrees. I never saw anything that looked inconsistent.

d3492461-39d4-47c4-9ce4-053fe8e706c5-image.png

I have reverted to the files I attached in my post from "31 Dec 2020, 00:24".

I had double checked the version. I couldn't attach debug info because the post exceeded the allowed length.

=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DJM-956L2-G43S4-6JKDD-3SJ6L-TB62G Used output buffers: 1 of 40 (15 max) === RTOS === Static ram: 149788 Dynamic ram: 64700 of which 112 recycled Never used RAM 144232, free system stack 154 words Tasks: Linux(ready,71) HEAT(blocked,295) CanReceiv(blocked,801) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,53) MAIN(running,1120) IDLE(ready,19) Owned mutexes: HTTP(MAIN) === Platform === Last reset 01:36:39 ago, cause: software Last software reset at 2021-01-05 21:57, reason: User, none spinning, available RAM 144336, slot 1 Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 39.4, current 39.8, max 40.4 Supply voltage: min 31.9, current 31.9, max 32.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0 Driver 0: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Driver 1: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Driver 2: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Driver 3: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Driver 4: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Driver 5: position 0, standstill, reads 13972, writes 0 timeouts 0, SG min/max not available Date/time: 2021-01-05 23:34:00 Slowest loop: 93.48ms; fastest: 0.06ms === Storage === Free file entries: 10 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 === DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 3, completed moves 3, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by 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 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 18738, send timeouts 0, received 56197, lost 0, longest wait 1ms for reply type 6036, free buffers 48 === SBC interface === State: 4, failed transfers: 0 Last transfer: 1ms ago RX/TX seq numbers: 59729/59729 SPI underruns 0, overruns 0 Number of disconnects: 2, IAP RAM available 0x2c8a8 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 35.62 Maximum length of RX/TX data transfers: 3364/292 pi@qTC:~ $ sudo /opt/dsf/bin/DuetControlServer -l debug Duet Control Server v3.2.0 Written by Christian Hammacher for Duet3D Licensed under the terms of the GNU Public License Version 3

If you run this code you can run the code above yourself and see.

M950 J3 C"0.io3.in" ; Use the input pin on io3 on the main board as carriage coupling check. M581 P3 T4 S1 ; Use triggers as info.(Run Trigger4.g)

@dc42, that's right, there are M584 commands inside some tool change and various homing files.
I publish configuration file:
config.g
Unfortunately I cannot confirm the exact operation of tool change in an older version of rrf because I am finishing implementing it now.
Also I point out that when I restart filmware, warnings like this are displayed:

Warning: M307: Heater 2 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365C Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 672C Warning: M307: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 478C

I seem to remember that with RC1 it was fixed.

I've got a fix ready for this, it won't happen again in future versions.

Extruder won't turn unless tool is selected and up to temp, or you've allowed cold extrusion.

Otherwise need more details.

Printing from yesterday:
alt text
alt text

Workimg whitout any issues.
Updated everything - reprapfirmware, dwc, paneldue.

Great job guys! Like usually 😜

@Veti said in RRF3.2-RC2 "Failed to get file list":

for the 12864 displays thats were the config items go

Since I got currently no 12864, let´s consider this "solved"!

Thanks!

Edit: created the folder manually and now the error message is gone. Brings me to the thought if that could also be done by cdreating a "New file" that creates that folder and just delete the test file afterwards (but the folder is already created in the backround and not deleted by this)?

Solved

As a workaround, I use this in my toolchange script:

if heat.heaters[2].current > 190 G1 E10 F1000 ; extrude 10mm

@chrishamm Thank you!
Please also note that the log level of S1 and S2 are reversed to what is stated in Gcode documentation.

Thanks, I'll fix that in the next version.

I included a fix for this in RC2 so it should no longer be a problem.

So just to add some more data into this issue, I actually got some apparently real readings from my DHT22 (it's around 20ºC in this office) even if briefly.
I was doing a G32 Bed Levelling at the time.
Could not replicate with another G32.

6a60b311-c3cd-4486-8cd4-5a30c6ddf63a-image.png

And....while writing this I got another reading while the printer is idle:
a0aea57d-e7ac-46fe-918e-21a049588ad3-image.png

It was always my fault with my macros not beeing resiliant enough.

Thanks for the script but my point was a different one,
With the BLTouch we have a sensor that is able to detect and report a malfunction, which i think is a good feature.

IMHO it would be good if RRF could make use of this and be enabled to recognize when a malfunction is reported and to respond..

There is already specialised code for the BLTouch so this would "complete" the current implementation and close the feedback loop.

Okay, that worked, thanks!

No worries, appreciated - you can always rely on users to do the unexpected. I never realy thought about the override file, never used it, suppose I should have realised what M501 actually did. It's one of those things you do early on then forget about - until it bites you .....