[3.3RC3] Missed stepps or overdue moves

[TypQxQ]

Update, I followed a print on RC1. Pulled diagnostics while printing and the maxOverdue was 0 until I heard the steppers getting the jitters at about 35%. Pulled the diagnostics and there the high maxOverdue value was:

2021-05-29 14:49:05 [debug] Moves scheduled 78776, completed 78773, in progress 1, hiccups 0, step errors 0, maxPrep 53, maxOverdue 11483, maxInc 7925, mcErrs 0, gcmErrs 0
Peak sync jitter 13, peak Rx sync delay 182, resyncs 0, next step interrupt due in 547 ticks, enabled

It then stayed at 0 throughout the print so I assume that some moves are worse than others?

Here are the complete logs while printing the file: event_rc1.txt

The print turned out fine without layer shifts.

[TypQxQ]

Update: Printing the same file in 3.3b2 gave almost no errors:

2021-05-30 10:51:33 [debug] Moves scheduled 210365, completed 210365, in progress 0, hiccups 0, step errors 0, maxPrep 231, maxOverdue 4, maxInc 1, mcErrs 0, gcmErrs 0
Peak sync jitter 11, peak Rx sync delay 215, resyncs 10, no step interrupt scheduled

Here is the complete eventlog troughout the print: event_b2.txt

[TypQxQ]

Update: Running at 400% speed factor from layer 2 on 3.3b2 with this file: https://we.tl/t-37EugjkZzi worked well, same 4 maxOverdue:

2021-05-30 11:55:59 [debug] Moves scheduled 420730, completed 420730, in progress 0, hiccups 0, step errors 0, maxPrep 253, maxOverdue 4, maxInc 1, mcErrs 0, gcmErrs 0
Peak sync jitter 10, peak Rx sync delay 207, resyncs 8, no step interrupt scheduled

Here are the full logs: event_b2x400.txt

[TypQxQ]

Update: Something changed between Beta2 and Beta3 that got much worse in RC3.

I can run the fast x400 file https://we.tl/t-37EugjkZz without problems in Beta2 but later builds give me stuttering steppers and high maxOverdue counter, if that matters at all.

Beta3:
Event log for the standard file: event_b3.txt
Event log for the x400 file: event_b3x400.txt
I tried changing the Grace period for the movement queue length from 10 to 0, as in Beta 2 but nothing changed as seen in this event_b3x400_GP0.txt logs.

All logs include a M122 for each card after homing and after successful or paused print.

[TypQxQ]

@o_lampe said in [3.3RC3] Missed stepps or overdue moves:

@typqxq said in [3.3-rc3] Missed stepps:

M584 X0.0:1.0 Y0.1:1.1

I don't know if it's helpful, but I'd put both X-motors on one controller and both Y-motor on the other.

I can confirm that this actually works much better and is usable now that the EndStop fixes are in place.

[o_lampe]

@typqxq
It's good to hear, but also put's the whole idea of toolboards in question. They were designed to reduce wiring, but practice tells a different story (for now).

[dc42]

@typqxq said in [3.3RC3] Missed stepps or overdue moves:

Last reset 00:07:24 ago, cause: software 2021-05-29 12:03:19 [debug] Last software reset time unknown, reason: AssertionFailed, available RAM 159320, slot 1

I am more concerned by that line. Please try installing the firmware binaries from https://www.dropbox.com/sh/nmpsl9a3jfsumm5/AAA6adSjEcd1AM_j5_tVberGa?dl=0 and try again.

[TypQxQ]

@dc42 I haven't experienced any issues with the board reseting.
I use 3 ways of reseting the board:

1. Emergency Stop button in Web interface.
2. Emergency Stop button on mains power.
3. Emergency reset button and endstops mapped to Trigger file:

M25
M122 B0
M122 B1
M112

[dc42]

@typqxq those lines in the M122 B1 report indicate that the expansion board reset at some point. We need to establish whether that happened during the print, or a long time ago. If it did occur during the print, that would account for the maxOverdue value being so high.

Please do the following:

1. Upgrade the main board and expansion board firmwares to the versions at https://www.dropbox.com/sh/nmpsl9a3jfsumm5/AAA6adSjEcd1AM_j5_tVberGa?dl=0. Ignore the .map files.
2. Send M122 B1 P1004.
3. Run M122 B1 and check that the M122 report shows the software reset reason as "deliberate HardFault zeroDiv".
4. Reset the main board.
5. Try a print.

[TypQxQ]

@dc42 Made the above steps and I can't see any change. Here is the new logs event_rc3+1.txt . It's too long for the post limit.

[dc42]

@typqxq thanks, I will try to replicate your setup today.

[dc42]

@typqxq said in [3.3RC3] Missed stepps or overdue moves:

Here is a link to the configuration and a test gcode file https://we.tl/t-DQueVGrH61

Unfortunately that .link has expired. Please provide a new link to your files.

[TypQxQ]

@dc42 Here is a new link: https://www.dropbox.com/sh/yfjwidhzvlxk8k2/AAAQd95XneD8zUVNV8VnNO3ya?dl=0

[dc42]

@typqxq thanks.

I have spotted an error in your configuration, in file custom/tool_1.g:

; Create Heater
	M308 S2 P"2.temp1" Y"thermistor" T100000 B4725 C0.0000000706 A"T1 Heater"	; configure sensor 2 as thermistor on pin temp1
	M950 H2 C"2.out1" T2											; create nozzle heater output on out1 and map it to sensor 2
	M143 H2 S300													; set temperature limit for heater 1 to 300C (e3d v6 all metal)
	M307 H2 B0 S1.00												; disable bang-bang mode for heater  and set PWM limit

; Create Part Fan
	M950 F3 C"2.out4"	                            ; Define Part Cooling fan on out4 (4pin)
	M106 P3 C"Part Cooling T1"						; Setup Part Cooling Fan as Part Cooling T1

; Create Hotend Fan
	M950 F4 C"1.out7"	                            ; Define Hotend Fan on out7 (2pin)
	M106 P4 S255 T45 H2                             ; Setup Hotend Fan for thermal control, full on when H2 reaches 45C

You create the sensor and heater on board 2, but the fan on board 1. RRF has the following documented limitation:

A thermostatically-controlled fan on an expansion board can only be controlled by a temperature sensor on the same expansion board.

Did you perhaps mean to use port 2.out7 for the fan?

I don't know whether this is relevant to the problem of maxOverdue being much too large and the associated print issues. I will change the config to use port 2.out7 and try running your print.

[dc42]

@typqxq I have reproduced the problem on my bench system so I am now able to investigate it.

For future reference, it would be easier for me to use your configuration files if instead of using M98 P"/sys/custom/xxx" in many places, you used M98 P"custom/xxx". This is because I have your configuration in a subfolder of /sys.

[TypQxQ]

@dc42 Thank you, I found and fixed it last week. It had no effect from what I can see.
This are the configuration files as of when I reported the problem.

[dc42]

@typqxq please try the new firmware binaries at https://www.dropbox.com/sh/xfsvscbaab0dtzl/AACCcSeiTNINZL-xbs6IhC4Ja?dl=0. Ignore the .map files.

[dc42]

@TypQxQ have you had a chance to try the new firmware? We're waiting to release 3.3 stable but I would like to know whether this issue is resolved first.

[TypQxQ]

@dc42 Sorry but I have left on vaccation and won’t be able to test it until I get back.
Have a great summer!

[MaxGyver]

@dc42 I had the same problems described by @TypQxQ after upgrading from RC3.2 to RC3.3.
The new binaries fixed the issue.

Cheers
Max