Firmware 2.0RC2 released

wilriker

I upgraded to 2.0RC2 and currently my second print is running perfectly fine so far.

Only thing I realized was that after upgrading I did not reset the Duet (would that have been recommended anyway?) and when running a G29 (no Z probe, so manually adjusting via DWC buttons) movement commands where heavily delayed. So when clicking on a button to move Z up/down sometimes this was instantaneously and sometimes it would take up to several seconds for the printer to react. I have not reset the Duet afterwards and I have not yet tried this again (I will likely do it tonight or tomorrow as I have to move the printer again).

If you tell me that this is something that can be expected when upgrading firmware and not doing a reset then you can ignore this one.

mickey30m

@dc42 where stands dwc for. A Google search on dwc telephone dont give any good results

dragonn

@mickey30m Duet Web Control... just means open on the phone the Duet website :P.

Dougal1957

you can also use the findmyduet app on android works extremely well

dc42

@carlosspr said in Firmware 2.0RC2 released:

Same for me. At some point the Web Interface lost connection and the print stopped. I was able to access the board via Telnet and generate an M122, but several atpempts needed before gettign the log because the Telnet would close connection before dumping all information.

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC2 running on Duet WiFi 1.02 or later
Board ID: 08DDM-9FAM2-LW4S4-6J1D8-3SJ6M-TMVZY
Used output buffers: 2 of 20 (8 max)
=== RTOS ===
Static ram: 28564
Dynamic ram: 96048 of which 0 recycled
Exception stack ram used: 288
Never used ram: 6172
Task NETWORK ready, free stack 1408
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3804
=== Platform ===
Last reset 00:01:23 ago, cause: software
Last software reset time unknown, reason: Hard fault, spinning module Platform, available RAM 5864 bytes (slot 3)
Software reset code 0x4030 HFSR 0x40000000, CFSR 0x00000400, ICSR 0x0041f803, BFAR 0xe000ed38, SP 0x20005004
Stack: 0040b539 00433b84 01000200 f8000000 406e386f 3edb6db7 b7b4d800 3e178897 3e1cd04f 41700000 3e23e0ac 3e3a4c97 3e63a87e 3e9258c9 3cd1cfc0 3f317180 3f800000 60000000 40382d26 60000010 004448bb 20005070 200050b8 00000001

I move this post here from the thread on 2.0RC1.

I confirm that there is a problem with getting M122 reports via Telnet. I will try to fix this for the 2.0 release.

The software reset data indicates that it crashed while trying store data for Telnet to pick up, but the crash address doesn't make sense. Please confirm that you were running the firmware binary downloaded from the releases area on github, not one that you built yourself.

EDIT: I just spotted that the "impreciserr" bit is set in the CFSR, which would explain why the fault address doesn't make sense.

peirof

Hi,

I'd like try this release... but some questions?

It's sufficient stable for a print of 4/5h?
Can be instaled in Duet Wifi+Panel Due?
Need do some adjustements in config.g?

dc42

@peirof said in Firmware 2.0RC2 released:

Hi,

I'd like try this release... but some questions?

It's sufficient stable for a print of 4/5h?

Probably.

Can be instaled in Duet Wifi+Panel Due?

Yes.

Need do some adjustements in config.g?

If you are running 1.21 already then no changes are needed.

dc42

@carlosspr said in Firmware 2.0RC2 released:

Same for me. At some point the Web Interface lost connection and the print stopped. I was able to access the board via Telnet and generate an M122, but several atpempts needed before gettign the log because the Telnet would close connection before dumping all information.

I found the problem. Following the change to use RTOS, a mutex was needed to protect the Telnet reply buffer because it is accessed by multiple tasks.

I have updated the binaries in the release to 2.0-RC2a with this fixed. I also added binaries for Duet085/06 and RADDS.

okercho

My first print with the new firmware came out perfectly fine, but the heater was in "standby status" at 205ºC (the temperature of my print), so it didn't turn out when it finished...

My ending gcode is "G10 P0 R-273.15 S-273.15" (same as if I use "Turn Everything Off"), but it doesn't do the job. However, If I use "G10 P0 R0 S0" the status is still Active or Standby but the temp actually goes to 0 as the desired temp...

Regards

Dr_Ju_Ju

Updated successfully, but needed to do a power cycle, as with USB connected it reported an error (sorry didn't trap it). Tried the earlier release, but that kept throwing a heater prob, & stopped the extruder motor, but the other motors kept rolling along, as if doint the print...

One quick question regarding the web interface; while printing via USB from Simply3D the Machine elements (heaters\machine\fan status etc.) work as expected, but the Print Status screen is "blank" (graphics but no data) and the Pause print button is disabled. Is this how it should be ??

I also have to admit that I don't know if it was like this with the release version.

Cata

@dc42 i try panel due, phone, ipad and touch rpi raspbian. The last two works better but y want a display, non touch. Don't need see a movie in the printer, only temps and minimal info. This month I will try a esp solution and put in a post the results.

dc42

@dr_ju_ju said in Firmware 2.0RC2 released:

...
One quick question regarding the web interface; while printing via USB from Simply3D the Machine elements (heaters\machine\fan status etc.) work as expected, but the Print Status screen is "blank" (graphics but no data) and the Pause print button is disabled. Is this how it should be ??

That's expected. If you print over USB then the firmware knows nothing about the file you are printing - it doesn't even know you are printing a file. So your USB host program needs to handle pausing, print time estimation etc.

dc42

@okercho said in Firmware 2.0RC2 released:

My first print with the new firmware came out perfectly fine, but the heater was in "standby status" at 205ºC (the temperature of my print), so it didn't turn out when it finished...

My ending gcode is "G10 P0 R-273.15 S-273.15" (same as if I use "Turn Everything Off"), but it doesn't do the job. However, If I use "G10 P0 R0 S0" the status is still Active or Standby but the temp actually goes to 0 as the desired temp...

Thanks, I confirm this is a bug in 2.0RC2 and 2.0RC2a.

DaveA

Not sure if this is new in this release or not. First thing after power on I do a Home All from DWC that homes fine and then Delta Calibration from DWC. The first point probed during the calibration strikes the bed pretty hard and then proceeds to probe the remaining points normally. It returns a pretty bad value as a result. Just doing the calibration again with no other actions runs normally and I get a value of .025 or so.
This with a Duet ethernet and smart effector.

dc42

@davea said in Firmware 2.0RC2 released:

Not sure if this is new in this release or not. First thing after power on I do a Home All from DWC that homes fine and then Delta Calibration from DWC. The first point probed during the calibration strikes the bed pretty hard and then proceeds to probe the remaining points normally. It returns a pretty bad value as a result. Just doing the calibration again with no other actions runs normally and I get a value of .025 or so.
This with a Duet ethernet and smart effector.

Have you saved the results of calibration in config.g? It may be that your homed height (H parameter in M665) is set too high. If you are not sure, temporarily increase the M558 H parameter to start probing from a greater height.

ayudtee

@dc42 I installed the 1.21.1RC2 update on the 0.8.5 Duet and it noticeably slowed down my Ormerod 2 just like 1.21.1RC1 did. Prints still turn out ok and everything else seems to be working as expected.

dc42

@ayudtee said in Firmware 2.0RC2 released:

@dc42 I installed the 1.21.1RC2 update on the 0.8.5 Duet and it noticeably slowed down my Ormerod 2 just like 1.21.1RC1 did. Prints still turn out ok and everything else seems to be working as expected.

Do you mean that prints took longer, or something else?

Danal

Loaded:

Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later
Firmware Version:	2.0(RTOS)RC2a (2018-05-12b1)
WiFi Server Version:	1.21
Web Interface Version:	1.21.1-RC4

With no problems. It did take a power cycle to get WiFi to reconnect, but this is not totally unusual.

No Prints Yet.

ayudtee

@dc42 Sorry that I was not clear. Yes the prints take longer. The first indication of a difference is evident by the sounds made by the steppers when the skirt around the part is laid down. It was quite noticeable to me right away. I ran a test piece from the reprap whistle.stl file on 1.21.1RC1 and 1.12.1RC2 and each took 51 minutes. The same piece on 1.21.1 took 45 minutes.

DaveA

@dc42 Thanks for tip on the M558 parameter. I'm not sure what changed in the printer but changing M558 H from 10mm to 15mm fixed the issue. First time cal. after power up works fine now.