Firmware 2.0RC6 and 1.21.1RC6 released

dc42

Duet Web Control.

resam

@dc42 regarding the number of gcode files per folder and moving them into subfolders:

I think there is no g-code to move or rename a file on the SD card.
M30 deletes a file - but thats about it...

DWC has rr_move and rr_mkdir and rr_delete.
Would be nice to add this to the Firmware wishlist.

Looking through https://reprap.org/wiki/G-code, it seems no other firmware supports this either...
All the "good" numbers around M20-M30 that do things with the SD card are already taken.

Donpi

@dc42 Haha ok

Totaly powering of the Duet does nothing.
But maybe i have a cache problem.
I'll try tonight.

wilriker

Just finished a 3:45h print successfully with no issues apart from warping - but that is clearly not a problem of the Duet.

zerspaner_gerd

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

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

Unfortunately, I still have an unstable DWC connection.

It will show "pending" for a long time (about 2 seconds), then "failed" and from then on DWC will not be updated anymore.

Are you able to reconnect DWC after the error?

Yes, I can immediately press on Disconnect Connect.

Have you increased the AJAX retry count in DWC from the default of 1?

I have played with this attitude something (up to 2) without change.

I suspect there may have been a change in your WiFi environment - in which case, reverting to firmware 1.21 will show the same problem (if the change in the environment is still present).

It's enough if I downgrade to DWC 1.21

Current combination:

Firmware Version: 2.0 (RTOS) RC6 (2018-05-29b4)
WiFi server version: 1.21
Web Interface Version: 1.21

No noticeable delays. (over an hour) With 1.21.1 it was between 10 seconds and a maximum of 5 minutes.

The debug mode shows the same error, only the difference is, it just continues after the error.

0_1527717963254_DWC 1.21 Debug.png

So it seems to me that the cause of DWC is not RFF, right?

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

I can no more right click on Tool 0 to use the filament macro.

I can confirm that, that's exactly the case with me. I already wrote it at RC5.
https://forum.duet3d.com/topic/5394/new-firmware-2-0rc5-available/74

3dmntbighker

Installed rc6 in my coreXY and so far so good. I don't have many extra goodies yet to trip it up of course.

Danal

Installed on BFD (Big Fast Delta).

Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later
Firmware Version:	2.0(RTOS)RC6 (2018-05-29b4)
WiFi Server Version:	1.21
Web Interface Version:	1.21.1

Collected Data
Warm-Up Time	Current Layer Time	Last Layer Time		Print Duration
01m 36s		09s			58s			8h 44m 53s

Estimations
Based on	Filament Usage	File Progress	Layer Time
Time Left	16h 37m 49s	22h 27m 39s	24h 54m 39s

No issues.

SM3D

@dc42 you are right. I took the SD card and made subfolders to make sure there are less than 25 files in each folder. Now I see all the files in DWC.

I did a small 1 hour print and no issues so far.

Cheers,
Vasan

timcurtis67

Just ran a 8 hr print with no issues. Running IDEX ditto printing with both heads at the same time.

Works great so far.

SM3D

@dc42 I noticed one more issue. It happened twice after 2.0RC6 upgrade (past 2 days) - whenever I update the config.g file, DWC says it cannot be updated and loses connection. 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.

Cheers,
Vasan

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?