New beta firmware 1.20beta11

frafa

Hi David
OK for me on Scara
Thanks

zlowred

David,
I'm happy to report that I spent an hour dry-running the print (without the filament, just to test for the watchdog reset) and I wasn't able to reproduce any of the major problems I had before (watchdog reset and wifi disconnect).
I was usually getting resets within 10 minutes into the print.
M122 after the print is showing considerable number of step errors, not sure if I should be concerned:

M122
=== Diagnostics ===
Used output buffers: 3 of 32 (16 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20beta11 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4S8-6JTDD-3SJ6P-9MXBY
Static ram used: 15488
Dynamic ram used: 98168
Recycled dynamic ram: 1032
Stack ram used: 1368 current, 9264 maximum
Never used ram: 7120
Last reset 00:53:32 ago, cause: software
Last software reset reason: User, spinning module GCodes, available RAM 7072 bytes (slot 1)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 2
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 30.4, current 30.7, max 31.2
Supply voltage: min 23.9, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-11-29 00:15:11
Cache data hit count 4294967295
Slowest main loop (seconds): 0.117362; fastest: 0.000108
=== Move ===
MaxReps: 5, StepErrors: 1774, FreeDm: 240, MinFreeDm 120, MaxWait: 8ms, Underruns: 2, 1
Scheduled moves: 189136, completed moves: 189136
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.0
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) 12
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 state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20b10
WiFi MAC address xxx
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 26824
WiFi IP address xxx
WiFi signal strength -51dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

KeeganB

Updated to DuetWifiFirmware 1.20beta11 and DuetWifiServer 1.20beta10 and now I can't load DWC at all. I had to run M997 S1 a second time to get the server firmware loaded. M552 via Pronterface reports connected. Router client list shows the Duet. I can ping the Duet. I just can't get DWC to load.

I will continue to poke it.

EDIT: Got it. I had to remove the SD card. Delete the wifiserver.bin that was on it, put a fresh copy on it, then run M997 S1 again.

Successfully updated to all the latest betas.

deckingman

David,

It seems the changes to allow M201/203 etc to hidden axes in M584 doesn't work in this beta. I just tried adding the P3 parameter to my M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 at the start of the drive section and commenting out the line at the end of config.g that had P3 at the end, but when I tried to home, the axes were not moving together. Not sure what U and V were trying to do but it wasn't the same motion as X and Y and I had to hit emergency stop. Also, I had put M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3; at the end of my homing files instead of simply M584 X0:3 Y1:4. This has the effect of making U and V appear in DWC at the start of homing (due to this M584 X0 U3 Y1 V4) then disappear at the end of homing. This works a treat in bet10 but with beta11, I can home all successfully once but if I try it a second time, the upper axis tries to move differently to the lower one. It's almost as if M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3 deletes the M201/203 etc settings for U and V or that it causes U and V to revert to Cartesian or some other Kinematics. Very strange….....

lolorc

hi,

is it possible to free more RAM by disabling the network stack at compile time ?

KeeganB

No issues with print, step errors, or layer shifting for me. I do continue to have the disconnect issues. I ran a print overnight, and when I came back to the computer it looked like it was still connected, but when I went to preheat the hot end, it immediately gave an AJAX error and was locked out. I could still ping the Duet, it still shows connected in my router client list, and M552 still reports connected.

M122 from immediately following disconnect. 96 reconnects….

[c]SENDING:M122
=== Diagnostics ===
Used output buffers: 7 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20beta11 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4SD-6JTF0-3S86N-TLWZX
Static ram used: 15488
Dynamic ram used: 97952
Recycled dynamic ram: 1248
Stack ram used: 4328 current, 9276 maximum
Never used ram: 7108
Last reset 08:22:44 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 7296 bytes (slot 3)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0

Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 81.1ms
MCU temperature: min 25.8, current 28.5, max 36.0
Supply voltage: min 12.3, current 12.7, max 12.9, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-11-29 07:42:29
Cache data hit count 4294967295
Slowest main loop (seconds): 2.637146; fastest: 0.000040
=== Move ===
MaxReps: 5, StepErrors: 0, FreeDm: 240, MinFreeDm 120, MaxWait: 1261068800ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: -0.133 -0.108 -0.113 -0.150 -0.265
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.4
=== 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 ready with "M122" 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 state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20b10
WiFi MAC address 5c:cf:7f:ef:51:6f
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 28432
WiFi IP address 10.0.1.161
WiFi signal strength -39dBm, reconnections 96, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)[/c]

KeeganB

in addition to my previous post above….

After capturing the the M122 report, I sent an M552 S-1 followed by M552 S1 to restart the wifi. This nearly always works, but this time it took three times. The first two times It reconnected in DWC and IMMEDIATELY threw up the small (not ajax) disconnected error box. The 3rd time seems to have worked fine for now.

franzelka

Layer shifting has been resolved with this version!

dc42

@KeeganB:

in addition to my previous post above….

After capturing the the M122 report, I sent an M552 S-1 followed by M552 S1 to restart the wifi. This nearly always works, but this time it took three times. The first two times It reconnected in DWC and IMMEDIATELY threw up the small (not ajax) disconnected error box. The 3rd time seems to have worked fine for now.

Those 96 reconnections look abnormal. Please can you connect a PC to the Duet via USB, send M111 S1 P14 to enable wifi debugging, then run a print (or do anything else that provokes reconnections other than due to poor signal strength). After the print, post the debug output along with a M122 report.

KeeganB

David,

I will enable and test that this evening.

Forgvn77

Layer shifting and extruder issues are fixed here! I did have to take apart my diamond hot end to unclog two of the filament chambers due to extruder issues in the previous beta. But, hey, we're off and running again!

dc42

@KeeganB:

David,

I will enable and test that this evening.

I forgot to ask: are you now using DWS 1.20beta10?

dc42

@Forgvn77:

Layer shifting and extruder issues are fixed here! I did have to take apart my diamond hot end to unclog two of the filament chambers due to extruder issues in the previous beta. But, hey, we're off and running again!

Thanks for the feedback!

KeeganB

@dc42:

@KeeganB:

David,

I will enable and test that this evening.

I forgot to ask: are you now using DWS 1.20beta10?

Yes.

deckingman

Further to my earlier post, I can confirm that having an M584 with the P3 parameter anywhere after an M584 without the P3 parameter completely messes up the movement of the U and V axes. That includes having M584 with P3 in a homing file instead of, or as well as, at the end of config.g. To be clear, that is with this beta11 version - the beta10 was fine in that respect as long as I had an M584 without the P3 at the beginning of config.g then subsequent M584 commands with the P3 parameter would simply hide the axes in DWC but movement was unaffected.

Edit. Just tried a print and everything is fine as long as I keep all the axes visible at all times (no M584 with P3 anywhere) so it's not huge issue. Also, I tried a quick print with beta10 and a 3 colour mix but had huge layer shift issues but there is no sign of these problems with this beta11.

k3lag

I noticed on beta10 (although I thought I was crazy) and now on beta11 that the layer count is wrong. It is off by 2. For a print 50 layers high, it will finish on layer 52. Right now I am printing the first layer of a print and duet web control says it is on layer 3.

I'm pretty sure it wasn't like this before the last beta or two.

Larry

KeeganB

Ok, After running a print overnight I came back to a disconnected printer. It reconnected no problem with a single click of "Connect" in DWC.

Here is what was in Pronterface:
[c]WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(808) p->ref == 1
WiFi: lwip: ../src/src/core/ipv4/ip.c(652) p->ref == 1
[/c]

Here is the M122:
[c]SENDING:M122
=== Diagnostics ===
Used output buffers: 6 of 32 (15 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20beta11 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4SD-6JTF0-3S86N-TLWZX
Static ram used: 15488
Dynamic ram used: 97952
Recycled dynamiWiFi:
c ram: 1248
Stack ram used: 4328 current, 9276 maximum
Never used ram: 7108
Last reset 31:44:09 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 7296 bytes (slot 3)
Software reset code 0x0003, HFSR 0x00000000, CFWiFi: LINK
SR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed3WiFi: xmit: 0
8, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0

Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 72.3ms
MCU temperature: min 28.1, current 28.8, max 35.9
Supply voltaWiFi: recv: 0
ge: min 0.0, current 12.7, max 13.0, under voltage events: 1, over voltage eventWiFi: fw: 0
s: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-11-30 07:03:54
Cache data hit count 4294967295
SloWiFi: drop: 0
west main loop (seconds): 0.118605; fastest: 0.000034
=== Move ===
MaxReps: 5, StepErrors: 0, FreeDm: 240, MinFreeDmWiFi: chkerr: 0
120, MaxWait: 34853746ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: -0.018 -0WiFi: lenerr: 0
.050 0.010 0.026 -0.034
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.4
=== GCodes ==WiFi: memerr: 0

Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
WiFi: rterr: 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(sWiFi: proterr: 0
) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is runniWiFi: opterr: 0
ng
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20b10
WiFi MAC address 5c:cf:7f:ef:51:6f
WiFi Vcc 3.38, reset reason Turned on by main pWiFi: err: 0
rocessor
WiFi flash size 4194304, free heap 28704
WiFi: cachehit: 0
WiFi IP address 10.0.1.161
WiFi signal strength -40dBm, reconnections 135, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
WiFi:
WiFi: ETHARP
WiFi: xmit: 409
WiFi: recv: 8988
WiFi: fw: 0
WiFi: drop: 51083
WiFi: chkerr: 0
WiFi: lenerr: 0
WiFi: memerr: 0
WiFi: rterr: 0
WiFi: proterr: 51083
WiFi: opterr: 0
WiFi: err: 0
WiFi: cachehit: 43344
WiFi:
WiFi: IP
WiFi: xmit: 44098
WiFi: recv: 42967
WiFi: fw: 0
WiFi: drop: 0
WiFi: chkerr: 0
WiFi: lenerr: 0
WiFi: memerr: 0
WiFi: rterr: 0
WiFi: proterr: 0
WiFi: opterr: 0
WiFi: err: 0
WiFi: cachehit: 0
WiFi:
WiFi: IGMP
WiFi: xmit: 342
WiFi: recv: 1110
WiFi: drop: 0
WiFi: chkerr: 0
WiFi: lenerr: 0
WiFi: memerr: 0
WiFi: proterr: 0
WiFi: rx_v1: 0
WiFi: rx_group: 0it: 2228
WiFi: recv: 15760
WiFi: fw: 0
WiFi: drop: 0
WiFi: chkerr: 0
WiFi: lenerr: 0
WiFi: memerr: 0
WiFi: rterr: 0
WiFi: proterr: 0
WiFi: opterr: 0
WiFi: err: 0
WiFi: cachehit: 0[/c]

dc42

Thanks, that p->ref==1 does indicate an error, and it has been reported by other users too. I have it on my list to investigate.

dc42

@k3lag:

I noticed on beta10 (although I thought I was crazy) and now on beta11 that the layer count is wrong. It is off by 2. For a print 50 layers high, it will finish on layer 52. Right now I am printing the first layer of a print and duet web control says it is on layer 3.

I'm pretty sure it wasn't like this before the last beta or two.

Larry

Thanks for the report, I'll check it out.

k3lag

@dc42:

@k3lag:

I noticed on beta10 (although I thought I was crazy) and now on beta11 that the layer count is wrong. It is off by 2. For a print 50 layers high, it will finish on layer 52. Right now I am printing the first layer of a print and duet web control says it is on layer 3.

I'm pretty sure it wasn't like this before the last beta or two.

Larry

Thanks for the report, I'll check it out.

I figured out why it's doing it. I had a fair bit of baby stepping dialed in and it must be taking that into account when it determines what layer it's on. I reconfigured my probe height and turned off the baby stepping and it's back to normal.

I had made other changes to the printer the same time I upgraded the firmware and was too lazy to go in and update the probe height in config.g.

Larry