Posts made by TypQxQ

Hi!

Upgraded my Duet 2 WiFi from a older 3.4 beta to latest and greatest today.
After uploading a file, be it in DWC or trough PrusaSlicer, it doesn't show up in the job list and when refreshing I get the error:

Not sure if it's DWC or where this comes from. After waiting a while, refreshing works again.

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.2 (2024-06-11 17:13:43) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-956GU-DJMSN-6J1FJ-3SN6T-KTNHD
Used output buffers: 16 of 26 (26 max)
=== RTOS ===
Static ram: 23384
Dynamic ram: 74276 of which 0 recycled
Never used RAM 12364, free system stack 120 words
Tasks: NETWORK(2,nWait 6,14.3%,195) HEAT(3,nWait 5,0.1%,319) Move(4,nWait 5,0.3%,298) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,85.2%,717) IDLE(0,ready,0.1%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:11:20 ago, cause: software
Last software reset at 2024-08-26 16:49, reason: User, Gcodes spinning, available RAM 11684, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x14
MCU temperature: min 38.3, current 39.1, max 42.4
Supply voltage: min 23.9, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/96/96, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 153
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min 0
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min 185
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min 0
Driver 9: standstill, SG min 0
Driver 10: 
Driver 11: 
Date/time: 2024-08-26 19:00:51
Cache data hit count 4294967295
Slowest loop: 267.71ms; fastest: 0.17ms
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 12.2ms, write time 228.7ms, max retries 0
=== Move ===
DMs created 83, segments created 11, maxWait 842538ms, bed compensation in use: mesh, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 9696, completed 9696, 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.2
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 2921242 clear 26867682
Extruder 0 sensor: no filament
=== DueX ===
Read count 0, 0.00 reads/min
=== Network ===
Slowest loop: 247.23ms; fastest: 0.07ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address 5c:cf:7f:76:66:58
Module reset reason: Turned on by main processor, Vcc 3.40, flash size 4194304, free heap 39528
WiFi IP address 192.168.1.205
Signal strength -55dBm, channel 8, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Regards, Andrei

Hi!
I have a genuine but old Duet 2 Wi-Fi v1.03 that is not booting anymore.
I haven't used this printer in a while but decided to start using it again today.
When homing Z with the Precision Piezo Orion probe, the printer died. Before starting the print I tested the Z-probe, by taping on it and tested the heaters and steppers.

It restarted and I checked the logs but could not see anything more than that it had booted today and no errors, last boot before today was 9 months ago according to the log.

I tried to print again, and it died once more but doesn't boot up anymore.

The 3v led is not powering on. So, after some searching here, I disconnected all connectors, the DueX board and the SD card and tried powering by USB.

The u2 3v regulator gets hot but nothing else, not the SD, Wi-Fi or processor.

My electronics knowledge is close to none so my question is if it would be enough to change the regulator (have to find and pay someone) or if I should just "recycle" the board.

@dc42 Thank you! That did it!

In the object model there is a sensors.probes[n].offsets[2] that is set to -0.7 for both my P8 probes.
This is not the trigger height, that is 0.
I do setup my probe with G31 Z0.
Where does this offset come from and what is it?

Hello!

I run a toolchanger with only different colors of PLA right now.
For a small object the tool can be in action for just a couple of seconds for maybe a couple of layers and then change back to the other one and in between maybe not used for a 10 minutes.

Is there a way to delay putting the tool in Standby temperature for like 15 seconds from it being deactivated?

Using e3d Revo betas and heat up times are fast but so are the cooldown times.

I was thinking of using global variables and daemon.g but it might be overcomplicating things.

@t3p3tony Thank you! This looks much better!

@t3p3tony Forgot about it, have it in a macro:

M955 P0 C"0.spi.cs2+0.spi.cs3" I41

Hi!
I’m building a printer, CoreXY toolchanger, 500x500x600 build area.
When Irun the accelerometer on the carriage I get very hight response at very low frequency. Around 0.7 and 2Hz regardless of M201 setting, regardless of whether I tighten or loosen my belts.

Now using 3.4b6 but same problem since I got the accelerometer when this was first introduced.

My speed settings for XY:
M556 50
M203 33900 (reaching 500mm/s when collecting accelerometer data)
M201 5000
M204 5000

Collecting after 4s wait with:
M955 P0 C"0.spi.cs2+0.spi.cs3" I41
M956 P0 S1000 A0 G4 P10 G1 X100 F30000

!

I’ve been having this issue since the beginning and I now thaught that I’d ask for help.

This are some imaages of the printer if it helps:

Also, my config files are at: https://github.com/TypQxQ/DuetBackup/tree/main/qTC-backup

Thank you for looking at this.

@t3p3tony Thankyou, I missed that when checking the code for it....

[My fault, see below.]
I read that the b6 has a new toolchange behaviour: Important! After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned.

But my toolchanges have not changed, the new tool still goes back to where the old one was.
Am I missing something?

All my config files and logs are updated at: https://github.com/TypQxQ/DuetBackup

Using on Duet3 MB6HC +2xEXP3HC, tools and heaters being on one of the 3HCs.
Got a Heater Fault while printing but I can't see anything inside the log and nothing appeared in the console.
It was caused by slow heating when I printed fast, >30mm3/s and put the temp up by 10 degrees.
The heater stopped but the print did not.

@dc42 said in stop.g using conditional G code:

if state.currentTool >= 0
  if #tools[state.currentTool].heaters > 0 & heat.heaters[tools[state.currentTool].heaters[0]].current > heat.coldRetractTemperature
    G1 E-2 F300

Just for information if anyone else pulls his/hers hair out wondering why it doesn't work.
This will not work if the tool has 0 heaters because the whole second statemet is evaluated and an error is thrown.
This works instead:

if state.currentTool >= 0
 if #tools[state.currentTool].heaters > 0
   if heat.heaters[tools[state.currentTool].heaters[0]].current > heat.coldRetractTemperature
     G1 E-2 F300

Tested with RRF 3.4b6 on Duet3 6HC whithout SBC.

@dc42 Sorry but I have left on vaccation and won’t be able to test it until I get back.
Have a great summer!

@dc42 Thank you, I found and fixed it last week. It had no effect from what I can see.
This are the configuration files as of when I reported the problem.

@dc42 Here is a new link: https://www.dropbox.com/sh/yfjwidhzvlxk8k2/AAAQd95XneD8zUVNV8VnNO3ya?dl=0

@dc42 Made the above steps and I can't see any change. Here is the new logs event_rc3+1.txt . It's too long for the post limit.

@dc42 I haven't experienced any issues with the board reseting.
I use 3 ways of reseting the board:

1. Emergency Stop button in Web interface.
2. Emergency Stop button on mains power.
3. Emergency reset button and endstops mapped to Trigger file:

M25
M122 B0
M122 B1
M112

@engikeneer Not sure what would've happened if I'd get 24v on IO_IN.
I will definitely wire in a relay on PS_ON.

@o_lampe said in [3.3RC3] Missed stepps or overdue moves:

@typqxq said in [3.3-rc3] Missed stepps:

M584 X0.0:1.0 Y0.1:1.1

I don't know if it's helpful, but I'd put both X-motors on one controller and both Y-motor on the other.

I can confirm that this actually works much better and is usable now that the EndStop fixes are in place.

@phaedrux I know, that's the problem...
ZTATP needs the heatsink connected to ground for it to work. I now disconnect it when connecting the heater.
But there may be all-metal printers that could encounter such a problem. Or if in the middle of the print the heaterblock gets damaged.
I try to foolproof my machine as I am doomed to make all possible mistakes.