Issues after prime

Heartleander81

@dc42 Thank you very much for your effort and patience with me.

Phaedrux

@heartleander81 said in Issues after prime:

@dc42 Thank you very much for your effort and patience with me.

Thank you for testing!

Heartleander81

@phaedrux
very gladly. I work as a department service employee in a company. So I know how important troubleshooting and testing are.

dc42

@heartleander81 unfortunately I still can't reproduce the problem. I've run it with and without line 20 (the T0 command) commented out, and analysed the moves in both cases. The only difference between them is that with line 20 present, there is a slight pause at that point, because RRF will wait for all preceding moves to complete and then wait until a few moves are in the queue (or no more are forthcoming) before executing the next one.

The effect of changing line 14 to Z0.3 is that line 24, which was previously a null move, is now a move in Z. So the problem may just have moved to the Z axis.

If you have time, please can you revert to the file that you posted in this post https://forum.duet3d.com/post/246160 that did show the problem, then check that it still does. Then replace the T0 command in line 20 by M400 and check whether the problem persists.

Please also try the effect of commenting out line 24 (the null Z move) just in case it is having an effect.

Heartleander81

@dc42 I like to do

Heartleander81

@dc42 Using M400 instead of T0 is the same problem

dc42

@heartleander81 said in Issues after prime:

@dc42 Using M400 instead of T0 is the same problem

Thanks! so tool change is not part of the problem.

Does the problem still occur if you comment out the G1 Z0.200 F600 line 24 ?

Heartleander81

@dc42
Have it do, G1 Z0.2 F600 comment out problem is there

dc42

@heartleander81 thanks! So your file should look almost like this (I have commented out a few more commands that I don't think are relevant):

G90
M83
M302 P1 ;;dc
T-1 ;;dc
M106 S0
;;G4 S1 ;;dc
T0
M83
G1 X5 Y5 Z30 F6000.0 
G1 Y50 Z0.2 F3000 ;;after comment out this line looks out run without issuse
G1 Y90 E20 F300
G1 Y120 F1200
;;G92 E0.0
; process CR3D 0.4
; layer 1, Z = 0.200
M400 ;;dc was T0
G1 E-0.6000 F1200   ;SB
; feature skirt
; tool H0.200 W0.440
;; G1 Z0.200 F600
G1 X118.950 Y122.494 F12600
;G1 X19.489 Y53.567 F12600
;G1 E0.6000 F1200
;G1 X280.511 Y53.567 E8.9768 F1800
; layer end
;;T0

Please confirm that the problem is present using this file, and not present if you comment out the M400 at line 16.

Heartleander81

This post is deleted!

Heartleander81

@dc42 yes with the code and the line 16 M400 the error is there and if I comment out the line 16 M400 the error is gone

dc42

@heartleander81 thanks again. My current theory is that the problem occurs when a move sequence (after e.g. M400 or tool change) starts with a move that doesn't involve the main board. If that's the case, then inserting any axis move command (e.g. G1 Y120.1) after the M400 line and before the G1 E-0.6000 line should avoid the problem.

Heartleander81

@dc42 Yes that is correct after M400 the command G1 Y120.1 removes the problem.

dc42

@heartleander81 thanks. Now I know where in the code to look.

Heartleander81

@dc42
I'm glad that I was able to help.
So do I understand correctly that it is caused by the toolboard?
If you've found something, I'll be happy to test your change.

dc42

@heartleander81 said in Issues after prime:

@dc42
I'm glad that I was able to help.
So do I understand correctly that it is caused by the toolboard?
If you've found something, I'll be happy to test your change.

I think it's caused by he first movement after a break (such as M400 or tool change) using only CAN-connected expansion boards. My best guess is that the start of the following move is not being scheduled correctly, for example the move is started late so that it has a lot of steps to catch up.. Unfortunately I haven't yet made the problem happen here, even though I used your config.g and the same test file; but now at least I can look at that area of code to see how the start of the second move is scheduled.

Please can you do one more test. Run M122 to clear the statistics, then run that test file that provokes the problem. Then run M122 again and post the result here.

Heartleander81

@dc42 ok. The file with issuse?

dc42

@heartleander81 said in Issues after prime:

@dc42 ok. The file with issuse?

Yes, without the G1 Y120.1 command.

Heartleander81

@dc42

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3T8-6J1DA-3SD6P-KV4H9
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 62732 of which 180 recycled
Never used RAM 137520, free system stack 125 words
Tasks: SBC(ready,5.5%,298) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,250) CanReceiv(notifyWait,0.0%,774) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.9%,59) MAIN(running,86.5%,922) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:53:47 ago, cause: software
Last software reset at 2021-08-18 20:39, reason: User, none spinning, available RAM 137564, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 138
MCU temperature: min 45.1, current 45.3, max 45.5
Supply voltage: min 24.9, current 25.0, max 25.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/196/196, gc cycles 0
Driver 0: position 19412, standstill, reads 10928, writes 0 timeouts 0, SG min/max 0/142
Driver 1: position -285, standstill, reads 10926, writes 2 timeouts 0, SG min/max 0/321
Driver 2: position 160, standstill, reads 10926, writes 2 timeouts 0, SG min/max 0/327
Driver 3: position 0, standstill, reads 10928, writes 0 timeouts 0, SG min/max 0/152
Driver 4: position 0, standstill, reads 10929, writes 0 timeouts 0, SG min/max 0/157
Driver 5: position 0, standstill, reads 10928, writes 0 timeouts 0, SG min/max not available
Date/time: 2021-08-18 22:33:40
Slowest loop: 58.70ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 14072ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 6, completed moves 6, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 236, received 309, lost 0, longest wait 1ms for reply type 6013, peak Tx sync delay 7, free buffers 49 (min 47), ts 128/128/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
State: 4, failed transfers: 0, checksum errors: 0
Last transfer: 1ms ago
RX/TX seq numbers: 48223/48223
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 36.96, max wait times: 10.2ms/0.0ms
Codes per second: 2.33
Maximum length of RX/TX data transfers: 3004/1068

dc42

@heartleander81 thanks again! I was looking to see whether there were hiccups after the problem occurred, but there are none in your M122 report.