Firmware 2.0RC2 released

carlosspr

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
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 37.5, current 37.7, max 38.0
Supply voltage: min 23.9, current 24.0, max 24.2, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 1970-01-01 00:00:00
Slowest main loop (seconds): 0.010376; fastest: 0.000075
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== 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 idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2) Telnet(0)
HTTP sessions: 0 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
Failed to get WiFi status
Socket states: 2 0 0 0 0 0 0 0
=== Expansion ===

mperdue

OK, I've reloaded and gotten things moving again so I'm working on my homely.g file now. In the previous releases I've run I would start the home sequence by moving both the X and Y towards the origin simultaneously, then I would fine home each of them separately. I don't seem to be able to move them both at the same time anymore but I can live with that. A bigger issue is that I would also fast home the Z and then fine home it. I'd do this my moving the X and X to the center of the bed and then moving the Z at a reasonable speed toward the bed. Then I'd back off and do the actual probe.

The code I used

M401 ; Deploy probe
G1 Z-999 F1000 S1 ; Course home Z Only
G1 Z5 F1000 ; Back off home location
M401 ; Deploy the probe
G30 Z-300 S0 ; Probe Z

The G1 using the S1 no longer seems to work as it did so this script no longer works. The G30 works well but it is very slow so if the machine was shut down with the bed at Z 250 it will take a very long time to probe the Z. Is there something I'm doing wrong here?

On the plus side I no longer have to tell it to deploy the probe since the BLTouch now has a unique definition and is handled properly.

dc42

You should still be able to home X and Y concurrently initially, nothing has been changed in that respect.

Your method of Z homing is unusual. Normally you would use either a G1 S1 Z move and a homing switch, or a G30 Z probe, not both. But either of the following methods should still work if you want to do fast then slow Z homing:

Tell the firmware that the Z endstop (for the G1 S1 Z command) is the Z probe, by using M574 Z1 S2 in config.g.
Use G30 to do the fast Z homing instead of a G1 S1 Z move, but use an extra M558 command to temporarily increase the probing speed (F parameter in M558).

Cata

What is that? need a not-maestro explanation
0_1526080068620_12864 disp.JPG

okercho

Hi, I just installed the RC2 and from the interface I'm not able to shutdown the heater, it turned on automatically (at 0ºC for active and standby temp) and if I try to "control all, turn everything off" or to switch from active to standby (from the interface) it does nothing, but I can switch from active from standby in the paneldue though.

In the console I see this "G10 P0 R-273.15 S-273.15", but nothing changes.

I think nothing changed at heater config level between 1.21 and this RC, right? (at least, I didn't see it...)

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

Anyone else sees the same?

Regards

mperdue

@dc42

I've changed my Z homing code to work as in your second option and it works well. However, I've decided to disable the functionality for now using M564 H0. I'll revisit this after I get a few print jobs completed and I can give it my full attention.

JohnOCFII

@cata This is a 12864 display.

https://www.amazon.com/Sintron-Graphic-Display-Controller-Printer/dp/B06WP8BSBB

Cata

@johnocfii Yes, i know. But, can we have that on the duets?

JohnOCFII

@cata said in Firmware 2.0RC2 released:

@johnocfii Yes, i know. But, can we have that on the duets?

I looked into this a bit a year or so ago. My understanding is that it would require another board to supply the smarts that are in the PanelDue displays in between the Duet and the 12864. With that level of hassle and expense, it would be easier to just get the PanelDue if you wanted a display. At least -- that is what I remember. I decided not to pursue a display.

Cata

@johnocfii You are wrong, i see the full graphics display with a 2 usd wemos working in the duet. Total cost = 10 usd. I want to know how is working in the maestro.

dc42

On the Duet Maestro we included 2 more 10-pin ribbon cable sockets and and extra chip to gate and convert the SPI bus to 5V, so that we can support 12864 displays. We did that on the basis that someone buying a budget board would be more likely to want to use a budget display.

To do the same on the other Duets you would need an adapter that plugs into the daughter board connector and the CONN_SD connector, to provide the gating and level shifting.

dc42

@dc42 said in Firmware 2.0RC2 released:

On the Duet Maestro we included 2 more 10-pin ribbon cable sockets and and extra chip to gate and convert the SPI bus to 5V, so that we can support 12864 displays. We did that on the basis that someone buying a budget board would be more likely to want to use a budget display.

To do the same on the other Duets you would need an adapter that plugs into the daughter board connector and the CONN_SD connector, to provide the gating and level shifting.

Another type of budget display that works with all Duets is an old smartphone running DWC.

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.