RepRapFirmware 3.0 first official beta is out
-
I've had multiple days of completed prints, thought I was out of the woods, but then had another stop and report it's 100% only part way through the file. Checked the file's gcode, and it did upload all 100mm of the print, but it stopped at 41.6mm. No error or heater fault reported, both heaters shut off when it stopped.
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 v0.5 version 3.0beta10 running on Duet 3 prototype v0.5
Board ID: 08DGM-9T66A-G63SJ-6J1FJ-3SD6M-KS0BA
Used output buffers: 1 of 32 (6 max)
=== RTOS ===
Static ram: 67696
Dynamic ram: 133764 of which 60 recycled
Exception stack ram used: 592
Never used ram: 191104
Tasks: NETWORK(ready,2044) HEAT(blocked,1208) CanReceiv(suspended,3804) CanSender(suspended,1496) CanClock(blocked,1432) TMC(blocked,456) MAIN(running,2060) IDLE(ready,196)
Owned mutexes:
=== Platform ===
Last reset 01:05:56 ago, cause: power up
Last software reset at 2019-09-19 17:50, reason: Unknown, spinning module Platform, available RAM 191596 bytes (slot 2)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
MCU temperature: min 44.0, current 57.2, max 57.4
Supply voltage: min 22.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, reads 22271, writes 23 timeouts 0, SG min/max 0/1023
Driver 1: standstill, reads 22273, writes 23 timeouts 0, SG min/max 0/1023
Driver 2: standstill, reads 22270, writes 27 timeouts 0, SG min/max 0/184
Driver 3: standstill, reads 22271, writes 27 timeouts 0, SG min/max 0/1023
Driver 4: standstill, reads 22272, writes 27 timeouts 0, SG min/max 0/178
Driver 5: standstill, reads 22281, writes 19 timeouts 0, SG min/max 0/1000
Date/time: 2019-09-20 14:10:57
Slowest loop: 176.43ms; fastest: 0.19ms
=== Move ===
Hiccups: 94892, FreeDm: 375, MinFreeDm: 297, MaxWait: 177311ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 6, completed moves: 6, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file* is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon* is ready with "M122" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 16.40ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8- Ethernet -
State: 0
Socket states: 0 0 0 0 0 0 0 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 88ms ago
RX/TX seq numbers: 6056/6056
SPI underruns 0, overruns 0
Number of disconnects: 1
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.0.3.3
File:
Pending code: G1 X126.818 Y131.288 E0.04478
Pending code: G1 X126.235 Y131.602 E0.02226
Pending code: G1 X125.637 Y131.893 E0.02236
Pending code: G1 X125.026 Y132.161 E0.02243
Pending code: G1 X124.417 Y132.399 E0.02199
Pending code: G1 X123.431 Y132.722 E0.03487
Pending code: G1 X122.487 Y132.975 E0.03285
Pending code: G1 X121.843 Y133.113 E0.02213
Pending code: G1 X121.189 Y133.225 E0.02230
Pending code: G1 X120.536 Y133.307 E0.02213
Pending code: G1 X119.204 Y133.394 E0.04488
Pending code: G1 X118.802 Y133.387 E0.01352
Pending code: G1 X98.914 Y113.500 E0.94545
Pending code: G1 E-0.56250 F3300.00000
Pending code: G1 F9600
Buffered code: G1 F3793
Buffered code: G1 X115.759 Y101.174 E0.91349
Buffered code: G1 X114.852 Y101.362 E0.03114
Buffered code: G1 X114.289 Y101.516 E0.01964
Buffered code: G1 X113.138 Y101.895 E0.04072
Buffered code: G1 X112.018 Y102.359 E0.04074
Buffered code: G1 X111.501 Y102.608 E0.01929
Buffered code: G1 X110.442 Y103.191 E0.04066
Buffered code: G1 X109.428 Y103.848 E0.04062
Buffered code: G1 X108.961 Y104.191 E0.01946
Buffered code: G1 X108.029 Y104.957 E0.04056
Buffered code: G1 X107.601 Y105.350 E0.01955
Buffered code: G1 X106.745 Y106.225 E0.04114
Buffered code: G1 X106.503 Y106.503 E0.01238
Buffered code: G1 X129.437 Y129.437 E1.09030
Buffered code: G1 X128.490 Y130.200 E0.04089
Buffered code: G1 X127.949 Y130.584 E0.02231
=> 732 bytes
Code buffer space: 2048
Configured SPI speed: 1000000 Hz
Full transfers per second: 312.28
Processing print job /opt/dsf/sd/gcodes/joel-new-and-improved-without-additional-stuff-in-his-head2_0.16mm_PLA__2h14m.gcode
- Ethernet -
-
@CaLviNx caps were on due to working in gcodes with web control. its not that i dont have the inteligance, i just work all day, outside in the heat. am tired at the end of the day, no need to be rude.
-
@tdybare69 said in RepRapFirmware 3.0 first official beta is out:
@CaLviNx caps were on due to working in gcodes with web control. its not that i dont have the inteligance, i just work all day, outside in the heat. am tired at the end of the day, no need to be rude.
The word is intelligence, and trust me, for me I was being extremely nice.
-
@kraegar please try DSF 1.0.3.5 when you get a chance.
-
This post is deleted! -
Updated, then had the thought to check M122. Once again it's showing I'm running 1.0.3.3 even though the pi reflects 1.0.3.5.
apt list 2>/dev/null | grep duet | awk -F'[/ ]' '{print $1" "$3 }'
duetcontrolserver 1.0.3.5
duetruntime 1.0.3.5
duetsd 1.0.2
duetsoftwareframework 1.0.3.5
duettools 1.0.3.5
duetwebcontrol 2.0.0-4
duetwebserver 1.1.0.0=== Duet Control Server ===
Duet Control Server v1.0.3.3
Code buffer space: 2048
Configured SPI speed: 1000000 Hz
Full transfers per second: 220.03I'll force the full update.
-
@kraegar stupid question but you are stopping the service and then restarting it?
-
I did not stop the service manually when I updated. If that's in the instructions I apologize, I winged it since I recall you'd said you were adding stopping the services to the apt scripts.
-
For clarification, I'm doing an sudo apt-get update; sudo apt get upgrade
Perhaps something odd is happening that's preventing it from upgrading for me?
-
Just checked, doesn't look like that's in the instructions, so I didn't skip it
I can provide more info on my pi, but literally the only thing I've installed has been the duet software. I've left it completely "stock" other than that. It's a pi4 running the "lite" install of Buster.
-
@kraegar This should do it...
sudo systemctl restart duetcontrolserver sudo systemctl restart duetwebserver -
yes its not in the instructions - fair one.
-
@gtj0 Sure. But using apt-get that shouldn't be necessary. Upgrade scripts should stop services if required. I have no problem doing it manually, either.
-
Very strangely reprinting the same file today as failed yesterday, while it's running and looks like it will complete, has plummeted in print quality. The only change at all was to update the duetsoftware framework on the pi. Same spool of filament, etc.
I'll test some other slices, but that was unexpected.
-
Does it matter on RRF3 if I connect my Z Probe to Duet2Wifi or Duex5? I know on RRF2 there was a difference in the latency.
Is this still the same here?
-
No changes other than updating the duet software and restarting the printer. The one from 1.0.3.3 on the right (that failed part way through), 1.0.3.5 on the left. I was tuning a new slicer (PrusaSlicer), so the first had some cooling issues, but the new one is something else entirely. I don't use pressure advance or firmware retracts, nothing like that.
-
Seems there is a bug with the endstops on the duet2.
My Z probe (normal micro switch) is randomly not working.
On the one hand sometimes it is showing in DWC Z-Probe status 1000 even when then probe is not triggered. Without touching the printer I do a emergency stop than the probe status is 0.
On the other hand sometimes it is not detected if the probe is triggered and my printer is crashing.The microswitch is connected to my duex5.
Its defined with this code:
; Z-Probe M574 Z0 C"nil" ; no Z endstop switch, free up Z endstop input M558 P5 C"!duex.e2stop" H3 F180 T25000 ; Z probe connected to Z endstop input G31 X-14 Y0 Z0.00 P500 ; Set Z probe offset + naher ran - weiter weg M557 X0:300 Y0:190 S50:47.5 ; Define mesh gridUPDATE: seems like it make a huge difference if I take the pins directly on the duet instead of the duex5.
-
I also have another wire behavior with stall detection on my corexy machine with the duet2.
If I start homing the machine executes the homey.g (also happens for X axis) as it should. But the randomly I get the massage homing failed. But no crash or something else. Everything is as it should just the message homing failed and the axis is not marked es homes.
I tried so many stall parameters but I don't this it has something to do with this, because the stall is working fine and the home is done fine. Just the axis get not marked as home then I get homing failed.
Is there a way to debug?
-
The Homing Failed message means that the homing switch was not triggered before the move completed. If using stall detection, it means no stall was detected.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in RepRapFirmware 3.0 first official beta is out:
The Homing Failed message means that the homing switch was not triggered before the move completed. If using stall detection, it means no stall was detected.
But it is detected because it move to the end position and then it do the rest of the script (move a bit away from the end position end so on). Otherwise the printer should crash normally because it have to go another 400mm if the stall is not detected
