RepRapFirmware 3.01-RC6 released
-
Sorry but I was wrong to do something, after turning off and on now point 3 works correctly
-
Updating only DWC to 2.1.0 on a duet3 (SD) with RRF-RC3 results in an inability to use DWC whatsoever. It appears that the DWC page keeps trying to refresh over and over, and the following shows up in the lower-right corner repeatedly:
-
Bug
On a duet 2 running RRF3.01-RC6 and DWC 2.1.0 I am unable to retract or extrude filament manually using the buttons.
Even sending M302 P1 does not allow me to manually retract or extrude the filament.T0 is active and up to temperature
-
@garyd9 said in RepRapFirmware 3.01-RC6 released:
@dc42 said in RepRapFirmware 3.01-RC6 released:
The release notes are at https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.
... If you were using M308 H or L parameters for thermistors attached to a Duet 3 main board, you will need to adjust those values
... The M308 thermistor H and L parameters on Duet 3 main boards have been re-scaled to match the scaling used on Duet 3 expansion and tool boards.Can you please publish the old scaling in the release notes to make it easier to adjust M308 L/H values? Even better would be a simple equation that people can just plug their old values into to get the new values.
For example, I have the following M308 (with L/H values carried since using a duet2 on RRF 1.19):
M308 S0 P"temp0" Y"thermistor" A"Bed" T100000 B3950 R4700 L54 H-97
Thank you
GaryFor Duet 3 main board, dividing your old correction by 8 should give the new value.
-
@jay_s_uk +1
-
@jay_s_uk said in RepRapFirmware 3.01-RC6 released:
Bug
On a duet 2 running RRF3.01-RC6 and DWC 2.1.0 I am unable to retract or extrude filament manually using the buttons.
Even sending M302 P1 does not allow me to manually retract or extrude the filament.T0 is active and up to temperature
I confirm this is a bug. Try reverting to DWC 2.0.7.
-
@garyd9 RC3 is likely incompatibe, upgrade to RC6. If you have no way to exchange DWC2, enter
forceLegacyConnect = true
into your JS console (open via F12) and it should connect using the old rr_status requests.I'll look into the other reports.
-
@dc42 said in RepRapFirmware 3.01-RC6 released:
... If you were using M308 H or L parameters for thermistors attached to a Duet 3 main board, you will need to adjust those values
For Duet 3 main board, dividing your old correction by 8 should give the new value.
Thank you.
@chrishamm said in RepRapFirmware 3.01-RC6 released:
@garyd9 RC3 is likely incompatibe, upgrade to RC6. If you have no way to exchange DWC2, enter
forceLegacyConnect = true
into your JS console (open via F12) and it should connect using the old rr_status requests.I had already pulled the sdcard and copied DWC 2.0.7 when I posted. I wanted to upgrade DWC first to see if the issue with it not prompting for a firmware upgrade on duet3 board was fixed. (Which, by the way, I can confirm as being fixed.)
-
@chas2706 said in RepRapFirmware 3.01-RC6 released:
I will try to re-install but not to worry if it fails because I have backup copies.
Upgrade failed.
Still get message "drive is unmounted so I gave up.Managed to re-install rrf3.01.RC3 but DWC is wrong version for this build. how do I obtain DWC version 2.0.7?
-
I come from working RC5 on 6HC. After the update works nothing!
(
-
Running a Duet3 with an RPi4 as an SBC. Updated using apt and have ended up with loads of issues. The first was the "drive is unmounted" error everywhere and a screen the same as teh one in the post above which I could only get rid of by power cycling.
The web interface now loads but while the extruder is listed under tools, the bed isn't. The status also continually says "Busy" in a yellow box. Pressing emergency stop / M112 results in the Duet crashing and not starting up again (the thermostatic fan runs constantly) until the power is cycled.
Allowing a restart after editing config.g results in no tools being shown at all.
M122 Dump:
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.01-RC6 running on Duet 3 MB6HC v0.6 or 1.0 Board ID: 08DJM-956L2-G43S8-6J1FJ-3SD6M-9S3GF Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 154084 Dynamic ram: 161268 of which 24 recycled Exception stack ram used: 320 Never used ram: 77520 Tasks: NETWORK(ready,2076) HEAT(blocked,1196) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,216) MAIN(running,4920) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:06:48 ago, cause: power up Last software reset at 2020-04-03 21:25, reason: User, spinning module LinuxInterface, available RAM 77760 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 43.4, current 46.9, max 47.0 Supply voltage: min 11.9, current 12.0, max 12.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 11.2, current 11.2, max 11.5, under voltage events: 0 Driver 0: standstill, reads 54044, writes 14 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 54044, writes 14 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 54045, writes 14 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 54046, writes 13 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 54047, writes 12 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 54048, writes 12 timeouts 0, SG min/max 0/0 Date/time: 2020-04-03 21:40:44 Slowest loop: 3.62ms; fastest: 0.21ms === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 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 ready with "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 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.66ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === Filament sensors === Extruder 0: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === CAN === Messages sent 1544, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 18ms ago RX/TX seq numbers: 12011/12012 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v1.3.0.0 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 22.67
-
@ChrisP said in RepRapFirmware 3.01-RC6 released:
Running a Duet3 with an RPi4 as an SBC. Updated using apt and have ended up with loads of issues. The first was the "drive is unmounted" error everywhere and a screen the same as teh one in the post above which I could only get rid of by power cycling.
Glad to hear i'm not alone.
I don't know what the issue is. I did a back up of the pi sd a while ago and even when I revert to that and then update It has the same issues. Nothing works because the DWC says "drive is unmounted". -
@chas2706 Did power cycling fix that issue for you? It did for me. MInd you, even when that works, the printer is still unusable.
A colleague of mine is just upgrading an E3D toolchanger to the same Duet3 + SBC setup, has just updated before we saw all this and is now in the same situation. (edit: post below)
-
@tobias_munich I got the same behaviour after updating.
-
@ChrisP said in RepRapFirmware 3.01-RC6 released:
drive is unmounted
by the sound of it its unable to load the config.g so that could explain why nothing else works.
could you also try doing
ls -l /opt/dsf/sd
andls -l /opt/dsf/sd/sys
in an ssh shell to see what permissions you have?edit: or did the power cycle solve it?
-
@elliott-griffiths it’s frustrating.
After setting it up from scratch.
Means... downloading the current image, and setup a new sd...
still issues.
Stand-alone with SD, no problem.But the SBC version.
After starting with the new image the sbc connects to the duet. So far so good.
DWC is able to acces the virtual SD with all folders.
But after uploading the config.g to the sys folder and rebooting,
the system has problems to access to the virtual SD with a lot of error messages .
It’s not able to read and access any folder of the virtual SDIt’s so frustrating
-
@bearer said in RepRapFirmware 3.01-RC6 released:
@ChrisP said in RepRapFirmware 3.01-RC6 released:
drive is unmounted
by the sound of it its unable to load the config.g so that could explain why nothing else works.
could you also try doing
ls -l /opt/dsf/sd
andls -l /opt/dsf/sd/sys
in an ssh shell to see what permissions you have?Thanks for picking this up, but that is not the porblem at this point. I've only seen that error once immediately after update and after power cycle, that hasn't happened again.
Everything now seems to load and I can see all the files on the interface, however, it's still not booting properly. After a reinstall, I'm still getting a persistant "busy" state and no the tools show the bed, but not the extruder, temperature chart still sows both. Pressing emergency stop now seems to work, but then nothing is listed in the tools and it still sits being "Busy" - see image.
-
@tobias_munich said in RepRapFirmware 3.01-RC6 released:
But after uploading the config.g to the sys folder and rebooting,
care to share the file and/or try a empty file?
-
@bearer I tried a lot of ways ....
And after all the tests I made it seems it’s a problem with the virtual SD. -
But after uploading the config.g to the sys folder and rebooting,
the system has problems to access to the virtual SDAnd after all the tests I made it seems it’s a problem with the virtual SD.
no doubt about it, just curious if its the content or presence of the config.g file that makes a difference; as it seemed it did make a difference from your earlier post.