Firmware 2.0RC6 and 1.21.1RC6 released

[Donpi]

Today I tried to print with two extruder and get a strange behaviour.

I'm printing the Kisslicer Wizzard box with extruder 1 to the raft and extruder 0 to the main object.

And when the printer change from tools 1 to tool 0, the Duet switches to full steps. The print becom impossible as everthing goes 256 x faster and is 256 x bigger.

That worked at lest once with firmware 1.21.

May that help

PS : I checked the gcode after M92, M350 and M569 but fond none of them.

[resam]

@sm3d said in Firmware 2.0RC6 and 1.21.1RC6 released:

It shows under system editor only config.g.bak but no config.g files.
When I shut down the printer and restart again, it cannot connect or show my tools because config.g is not present. I have to take the SD card out and rename config.g.bak to config.g to make things work again. This never happened to me in previous upgrades.

I had the same thing happen to my printer once, maybe 2-3 months ago. Don't remember which FW I had back then, maybe 1.20?
So, I don't think this is a new thing.

[daveidmx]

After reorganizing my /sys files into subfolders (to get down below the limit so they call appear in DWC) I noticed that subfolders of /sys don't appear on DWC either. Would that be a DWC feature request, or is there firmware-side support needed too?

Is there a different way I should be doing this to maintain DWC editability of all my config files? (I can move some of them to /macros, but it wouldn't make sense for them ever to show up on the UI to be called individually. Is that what's expected, though?)

[3dmntbighker]

I printed two test cubes last night on my coreXY on RC6 and i notice each is actually a slight offset parallelogram. So it would be a slight shift in X. Any ideas? The cubes are only an inch square. I don't recall this behavior before.

edit: Apparently this is a common coreXY issue, but so far I can't see any obvious mechanical cause for the distortion. Presumably though there must be one somewhere

[Danal]

Just completed a 37 hour print, including running out of filament that I didn't catch for an hour, editing G-Code file, restarting, etc, etc, etc.

All on RC6 on a large-ish delta. No issues.

[timcurtis67]

Been running since last Thurday evening on prints that range from 2 hrs to 10 hrs without any issues. Using both print heads (changing tool and ditto printing).

The only thing I have found so far is the DWC time is way ahead of the paneldue time. I'm pretty sure this is a known issue and due to using Z hop (which I am using).

Otherwise it's working perfect.

[dc42]

@daveidmx said in Firmware 2.0RC6 and 1.21.1RC6 released:

After reorganizing my /sys files into subfolders (to get down below the limit so they call appear in DWC) I noticed that subfolders of /sys don't appear on DWC either. Would that be a DWC feature request, or is there firmware-side support needed too?

Is there a different way I should be doing this to maintain DWC editability of all my config files? (I can move some of them to /macros, but it wouldn't make sense for them ever to show up on the UI to be called individually. Is that what's expected, though?)

How many files do you have in in /sys? The number of files in /sys ought to be small enough that displaying all of them isn't a problem. It's the /gcodes folder that causes a problem when the number of files is large.

[3dmntbighker]

After a lot of tweaking to control blobbing I started a 12 hour PETG vase print last night running RC5. I still can't do a filament load, but the print was looking very good as far as layer quality. This morning I found the printer stopped dead in mid-print. All of the normal lights were lit on the board except the wifi light was off. I hit reset and it came up normally. I don't have any way to determine what may have happened with about a third of the vase left to print. And yesterday during the tweaking phase I seem to have caused a low temp failure by pausing a print. The screen dialog indicated I could have resumed the print after resetting the printer, but it wasn't clear how. Is this a development feature that isn't actually implemented yet?

edit: Oops, looks like I had a power dropout that caused the printer to stop dead. So that mystery is solved at least.

[BMMal]

I was several hours into a long print when the machine appears to have missed a portion of a travel move mid-layer. The move was mostly in Y but also had an X component. It does not appear that any steps were missed in the X direction but about 18.5-19mm worth of steps were missed in Y. It might be coincidental but my Y offset for the tool active when this happened is -18.5.

It's likely some mechanical problem but at this point but I'm not sure if there is anything meaningful in the diagnostics below.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC6 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 20 (12 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 96516 of which 0 recycled
Exception stack ram used: 420
Never used ram: 5756
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1200
Task MAIN running, free stack 3560
=== Platform ===
Last reset 05:57:03 ago, cause: software
Last software reset at 2018-06-04 10:05, reason: User, spinning module GCodes, available RAM 5672 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 24
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 762.6ms
MCU temperature: min 24.6, current 26.9, max 27.9
Supply voltage: min 24.0, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/1023
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-06-04 16:02:25
Slowest loop: 821.33ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 150, MaxWait: 4058580675ms, Underruns: 0, 0
Scheduled moves: 12, completed moves: 12
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 0 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 4 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 ===
Slowest loop: 821.33ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Filament sensors ===
Extruder 0 sensor: ok
=== Expansion ===
DueX I2C errors 0

[daveidmx]

@dc42 There were ~70. Half of those are test macros and related subroutines that maybe shouldn't be in there. (The entry-point macros are in /macros but I didn't want the subroutines to show up on the "macros" DWC UI menu.) The other half are config.g, but factored apart such that reusable parameters were in one place.

https://github.com/daveidmx/VORON/tree/feature/config/Firmware/DuetWifi/V2/daveidmx

For example, here are my homex.g and homeall.g, written such that the actual Z-hop moves and X/Y/Z probe moves are in their own files. They are re-usable and only need to be changed in one place.

; homex.g
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_zhop_down.g"

; homeall.g is a slightly optimized XYZ homing script that probes X, Y, and Z together without an intervening Z-hop between each axis
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_probe_y.g"
M98 P"homing_probe_z.g"
M98 P"moveto_center_xyz.g"

Maybe these should be shipped off to /macros?

[cgcafer]

Hi All,
There was a problem when i use RC6 without any problem. When it printing i changed M566 value from paneldue then error message appeared and printing stopped.
Old value was M566 X800 Y800
New value was M566 X1200 Y1200

and M122 result,
12:17:52
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC6 running on Duet WiFi 1.02 or later + DueX2
Board ID: 08DDM-9FAM2-LW4S8-6JTDG-3SJ6P-1MXBY
Used output buffers: 1 of 20 (13 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 96516 of which 0 recycled
Exception stack ram used: 420
Never used ram: 5756
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3560
=== Platform ===
Last reset 00:39:03 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 5816 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 8
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 32.2ms
MCU temperature: min 23.5, current 25.6, max 26.3
Supply voltage: min 0.9, current 24.0, max 24.2, under voltage events: 1, over voltage events: 0
Driver 0: standstill, SG min/max 365/683
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/616
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Expansion motor(s) stall indication: no
Date/time: 2018-06-05 12:17:51
Slowest loop: 53.39ms; fastest: 0.06ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 121, MaxWait: 141786ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 29
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.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 idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 38.73ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

• WiFi -
  Network state is running
  WiFi module is connected to access point
  Failed messages: pending 0, notready 0, noresp 0
  WiFi firmware version 1.21
  WiFi MAC address 5c:cf:7f:a4:04:fe
  WiFi Vcc 3.36, reset reason Turned on by main processor
  WiFi flash size 4194304, free heap 15528
  WiFi IP address 10.0.0.25
  WiFi signal strength -58dBm, reconnections 0, sleep mode modem
  Socket states: 0 0 0 0 0 0 0 0
  === Expansion ===
  DueX I2C errors 0

[dc42]

@daveidmx said in Firmware 2.0RC6 and 1.21.1RC6 released:

@dc42 There were ~70. Half of those are test macros and related subroutines that maybe shouldn't be in there. (The entry-point macros are in /macros but I didn't want the subroutines to show up on the "macros" DWC UI menu.) The other half are config.g, but factored apart such that reusable parameters were in one place.

https://github.com/daveidmx/VORON/tree/feature/config/Firmware/DuetWifi/V2/daveidmx

For example, here are my homex.g and homeall.g, written such that the actual Z-hop moves and X/Y/Z probe moves are in their own files. They are re-usable and only need to be changed in one place.

; homex.g
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_zhop_down.g"

; homeall.g is a slightly optimized XYZ homing script that probes X, Y, and Z together without an intervening Z-hop between each axis
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_probe_y.g"
M98 P"homing_probe_z.g"
M98 P"moveto_center_xyz.g"

Maybe these should be shipped off to /macros?

Thanks. I'm hoping to get a fix for the file limit soon, but if not then I'll suggest to Chrishamm that he adds support for subfolders of /sys in DWC, that way you won't have them showing up in subfolders of /macros.

[dc42]

@cgcafer said in Firmware 2.0RC6 and 1.21.1RC6 released:

Error status: 8

Thanks for your report. I suspect that it was random that the problem occurred when you sent the M566 command, however if you find that you can reproduce this fault then please let me know.

What's happened is that accesses to the SD card failed. In older firmware versions, this usually caused the print to stop where it is with the heaters left on. We have one OEM customer who is a very heavy user and has seen this happen occasionally, going back to firmware 1.21 and earlier. In 2.0RC6 the handling of SD card errors has been rewritten so that the print is terminated properly, error messages are sent and the heaters are turned off.

At this state I am not sure what causes these errors. Perhaps it is just a temporary hardware glitch or an ESD discharge between a stepper motor body and ground. I am considering adding a mechanism to re-initialise the SD card interface and retry the transaction when a SD card read or write error occurs, as long as the card detect switch indicates that the card hasn't been removed.

Were you able to access the SD card via DWC or PanelDue after the error occurred, without either resetting the Duet or sending M21?

The error status 8 indicates that output stack overflow occurred at some point. This is not uncommon, especially when using multiple DWC clients.

[dc42]

@bmmal said in Firmware 2.0RC6 and 1.21.1RC6 released:

Error status: 24
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 762.6ms
...
Slowest loop: 821.33ms; fastest: 0.08ms

Thanks for your report. I think there was an SD card read error, but for some reason it didn't cause the print to terminate. The Error status 24 indicates that you had output stack overflow (which is not uncommon) and that an SD card transaction took much longer than expected. The SD card longest block write time is also much higher than expected. The Slowest loop time is probably related to that.

[wackyfrog]

PanelDue v3.0a 5" FW 1.20(b15) can't connect after update DuetWifi to FW 2.0(RTOS)RC6 (2018-05-29b4), works well until now. PanelDue displays "Connecting...", tried to reset setting. Connected via 4 pin cable.

[dc42]

@adegtiar said in Firmware 2.0RC6 and 1.21.1RC6 released:

PanelDue v3.0a 5" FW 1.20(b15) can't connect after update DuetWifi to FW 2.0(RTOS)RC6 (2018-05-29b4), works well until now. PanelDue displays "Connecting...", tried to reset setting. Connected via 4 pin cable.

If you are powering the Duet with 5V power only, that's normal for now. There will be a new PanelDue firmware release in the next few days that supports the new Standby status returned by RRF 2.0.

[wackyfrog]

If you are powering the Duet with 5V power only, that's normal for now. There will be a new PanelDue firmware release in the next few days that supports the new Standby status returned by RRF 2.0.

Yes, using only with 5v.

One more thing: when jogging not homed axis I see errors in g-code console:

M120
G91
G1 X-0.1 F3600
M121
Error: G0/G1: insufficient axes homed
Error: Pop(): stack underflow!

[wackyfrog]

This post is deleted!

[cgcafer]

@dc42 said in Firmware 2.0RC6 and 1.21.1RC6 released:

Were you able to access the SD card via DWC or PanelDue after the error occurred, without either resetting the Duet or sending M21?

I sent M122 from DWC after that shutdown all system so i didn't test it.