This is just selecting the bit in the bitfield and assigning it to a flag called GCONF_INT_RSENSE. It's not setting the value to 1.

Do you see somewhere in the code this flag is used and setting the value to internal?

@dc42 Thanks for taking a look so quickly.

Since the shifts only happen after 12-24 hours it's been a bit slow to confirm, but in the end it looks like it was caused by a bad cable that otherwise passed a visual inspection of the crimps.

I hope the bug report has helped in other ways at least.

Well after spending most of the day playing around with no success, a can of compressed air over the board, around the sd card slot and ethernet slot and now it's functional.

I've tried to remove and reinsert the card a bunch of times, put a small amount of pressure on the card and reader, let it run to warm up a bit, and it still works.

Well after spending most of the day playing around with no success, a can of compressed air over the board, around the sd card slot and ethernet slot and now it's functional.

I've tried to remove and reinsert the card a bunch of times, put a small amount of pressure on the card and reader, let it run to warm up a bit, and it still works.

My Duet Maestro crashed when prepping a print this morning, now I have a diag light and fully unresponsive (including serial) when there is an sd card installed. If I remove the SD card everything works, I can even enter all the GCODE from on config.g over the serial line and it seems to be ok.

I've tried reflashing with BOSSA, replacing the SD card, using the new sd card contents, end result is always the same, diag light on and unresponsive when restarted with an sd card present.

5v and 3.3v lights are lit.

If I insert the SD card after restarting, I see this with M122

Error: SD card speed 30.00Mbytes/sec is unexpected

Again with any sd card.

Any other ideas?

You are absolutely right, R0 not R1! Sorry about that.

Thanks though for the quick response.

And, before I forget. Last released firmware here.

Firmware Name: RepRapFirmware for Duet 2 Maestro
Firmware Electronics: Duet Maestro 1.0
Firmware Version: 2.02(RTOS) (2018-12-24b1)
Web Interface Version: 1.22.6
Web Interface by Christian Hammacher
Licensed under the terms of the GPL v3

I had my first power failure today, and was able to get recovery working with a little bit of effort. I noticed that the generated ressurect.g has a small error in it where it didn't put quotations around the file name when calling M23, so on resume it failed to find the file until I renamed it. At least I think it is for this reason.

; File "Tube 1 (PLA).gcode" resume print after power failure at 2019-04-20 19:34
M140 P0 S60.0
G10 P0 S200 R200
T0 P0
G29 S1
G92 X146.044 Y181.025 Z140.000
M98 Presurrect-prologue.g
M106 P0 S0.00
M106 P2 S1.00
M106 S1.00
M116
M290 S0.080
G92 E0.00000
M83
M23 Tube 1 (PLA).gcode
M26 S11969350 P1.243
G0 F6000 Z142.000
G0 F6000 X146.044 Y181.025
G0 F6000 Z140.000
G1 F6000.0
M24

The result of this was that it tried to load "Tube 1 .gcode" dropping the filename at the '(' character.

Additionally the "M290 S0.080" had an additive effect (as it would normally), so upon re-running M916 after renaming the file it finally succeeded but left a bit of a gap at the first layer until I fixed the stepping, it might be better to use "M290 S0.080 R1" in this case.

This is just selecting the bit in the bitfield and assigning it to a flag called GCONF_INT_RSENSE. It's not setting the value to 1.

Do you see somewhere in the code this flag is used and setting the value to internal?

@gnydick Update to firmware 2.02, there was a bug fixed after RC7 which could explain this.

See here: https://forum.duet3d.com/topic/8250/hiccups-causing-layer-shifts/6

I think this is resolved by firmware 2.02, incorporating the timing fixes. I have not had hiccups or layer shifts in the last 2 days, but I'll keep checking for a couple more just in case.

@dc42 I looked at your commit and I agree that I think it will resolve the problem on the basis that it's similar to what I was going to try myself.

I've been running a couple of hours now with the change and all of the statistics, including custom debug code that I added which caused me to find the bug, all seem to be reporting correctly now.

I'll need to run longer to check if this resolve my other issues with layer shifting, I'll post in that thread if it works.

Thanks for your help.

@dc42 said in StepTimer::GetInterruptClocks isn't incrementing:

ease modify your debug to print start and end in hex, because that may make it easier to see if the problem occurs when the 16-bit timer wraps around.

Thanks! I'll grab the change and test this morning too.