Posts made by zlowred

That means G92 will set "homed" flag?
That should be exactly what I want, thanks!

I can always make it moving in full step increments during the printing (by simply keeping the layer height multiple of 0.01mm), but I'm concerned about the homing which may end up in arbitrary unstable microstep value which I will always keep the same by using multiples of 0.01mm.

The alternative solution to what I wanted above is maybe using full steps for homing and then somehow switching to 16x + I microstepping without losing the homed position. Is that possible?

Hi,

I have a Z axis with 100 full steps (1600 microsteps with 16x microstepping) per mm.
It looks like even a full step resolution is ok, and the stepper motors have better holding torque & better accuracy on the full step boundaries, so that should be a way to go for my setup for better accuracy and quality.
At the same time, I'd like to keep the stepper silent (which only works in 16x microstepping mode with interpolation).

So are there ways to keep the stepper working in 16x microstepping + interpolation mode, but always make it moving in full step increments?

Not sure where to report DWC issues, so posting it here. Dark theme is broken in the latest 1.20-RC1 - it is visible immediately upon switching (and applying) the Dark theme. Some backgrounds remain white.

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)

I didn't have any WiFi disconnects since installing the WiFi firmware 1.20beta10 so I hope it is fixed finally.

As a separate report, Watchdog resets that I'm started experiencing in DuetWiFiFirmware-1.20beta7 are still reproducible in DuetWiFiFirmware-1.20beta10

WiFi stopped working for me with DuetWiFiServer-1.20beta10
M552 S1 says:
Failed to initialise WiFi module, code -10

Reverting to DuetWiFiServer-1.20beta9 fixes the problem

I did the M997 S1 twice, and I tried installing Beta10 again after reverting to Beta9 with the same result.
Debug mode says:

Debugging enabled for modules: WiFi(14)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13)
WiFi: 
WiFi:  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
WiFi: 
WiFi: load 0x4010f000, len 1384, room 16 
WiFi: tail 8
WiFi: chksum 0x2d
WiFi: csum 0x2d
WiFi: v60000100
WiFi: ~ld
WiFi module started
Error: Failed to initialise WiFi module, code -10

The last line appears after ~30 seconds delay

I've replaced my Apple router with Google WiFi today, and it still disconnects, so I don't think it is related to particular router model.

I'm on Duet WiFi. Also, my printer is Delta, not CoreXY. The bug may be in Delta-specific code. Or something else specific to my configuration (sensors, heaters, motors…)

Moving report to the latest firmware version. As reported here https://www.duet3d.com/forum/thread.php?pid=30376#p30376, I'm experiencing random firmware resets, likely by the watchdog timer. I've tried several latest firmware versions, and now have high confidence that 1.20beta6 does not reset, while 3 versions afterwards (1.20beta7, 1.20beta8, 1.20beta8+1) all randomly reset. I also verified that reset behaviour is not affected by the WiFi module firmware, e.g. 1.20beta6 is still stable even with WiFi Firmware 1.20beta9

I had to revert to 1.20beta6 for now because starting from 1.20beta7 it resets every now and then and I have lots of failed prints because of that. I'm still running the latest 1.20beta9 WiFi firmware though.

I did additional M997 S1 and then reproduced disconnect once again, but it didn't result in any additional messages in the log.

Sure, will do. I wonder if there is anything of interest to you in the debug message showing when I do M552 S0 after such disconnect:

WiFi: state: 5 -> 0 (0)
WiFi: rm 0
WiFi: pm close 7
WiFi: tcp_pcb_purge: pcb->state == SYN_RCVD but tcp_listen_pcbs is NULL
Wifi module is idle
WiFi: tcp_pcb_purge: pcb->state == SYN_RCVD but tcp_listen_pcbs is NULL
WiFi: tcp_pcb_purge: pcb->state == SYN_RCVD but tcp_listen_pcbs is NULL
WiFi: del if0
WiFi: usl
WiFi: mode : null

Not sure if these pcb->state checks are ok

Hi David,

So I was able to reproduce few more times. Here are my observations:

• (obvious one) I didn't see any debug messages including p->buf==1 while DWC page is not opened
• these p->buf==1 messages always (or most of the time) come out in pairs
• there are no regular intervals between these messages, sometimes I see few per second, sometimes I don't any for 10-15 minutes
• they are not getting more often before the disconnect
• I feel that messages are coming much more often when printer is printing (compared to the idle) - suspect it may be related to some timings, e.g. CPU is busy with something and can't send some command or data to the WiFi module in time. Or maybe noise in power line due to heaters PWM. My power supply is able to provide enough current, so it's not under-voltage, but maybe some noise…

I'll post here if I get more data

I wonder if this is related to the WiFi disconnections. I've looked at the assertion that produces that p->ref==1 message. If that indicates any sort of memory corruption, the watchdog reset could happen irrespective to your recent changes in the code. It might be that because of totally unrelated changes the compiler optimised something slightly differently, and it started to cause side-effects that weren't there before.

Sure, I'll collect more data and post it here

In the meanwhile – I can build the firmware myself, so if you need me to build it with maybe some additional debug flags, or quickly test some changes without releasing the new beta version – feel free to ask.

Last version I'm pretty sure was stable is the one I built myself, immediately after I added the 3-wire PT100 support. I've spent maybe 20 hours printing on that version, and didn't see any resets. The next one (was that 1.20beta6?) also never reset, but I spent only couple of hours printing with it, so less confident.

First message is seconds after I connected. Others are at irregular intervals between few seconds and somewhere around a minute between each other.
In the meanwhile, I've replaced the wifi module with ESP-07S with external antenna, and it didn't change anything, e.g. behaviour is exactly the same.

The issue described in https://www.duet3d.com/forum/thread.php?pid=30376#p30376 still happens after the upgrade to 1.20beta8