Issues after prime

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.

Heartleander81

Oh in the M122 ist the board Version 1.01 but I habe 1.01A

Heartleander81

@dc42
I have no idea about programming or what RFF is capable of.
But I've read that you can write a debug file.
But that won't help either, otherwise they would have suggested it.

Should I make an M122 from the Toolborad?

dc42

@heartleander81 said in Issues after prime:

@dc42
I have no idea about programming or what RFF is capable of.
But I've read that you can write a debug file.
But that won't help either, otherwise they would have suggested it.

Should I make an M122 from the Toolborad?

I don't think that will show anything. The toolboard is working properly as far as I can tell.

Heartleander81

@dc42 ok

dc42

@heartleander81 I can see a jolt in the movement when the G1 E-0.6 line is kept as-is, but not if I change the E value to -0.5 or -0.8. This ties in with a report from another user.

I've just run the same file under the latest 3.4beta firmware, and the jolt is gone. So it's possible that the bug is already fixed. The scheduling code has change since release 3.3 but I need to check whether there has been a change that could fix this issue.

If you want to try the latest 3.4beta series firmware, you can find it at https://www.dropbox.com/sh/cq7q3g8coymo9s3/AABtPYEzV1_unETpKEMPInSia?dl=0. Use it with caution as I have only tested it briefly. It will work with the version 3.3 tool board firmware.

Heartleander81

@dc42

OK. I only need the .bin file? Will test it with caution.

dc42

@heartleander81 yes, just the .bin file for the MB6HC.

Heartleander81

@dc42 Unfortunately the bug is still there.

dc42

@heartleander81 thanks for testing it!

Heartleander81

@dc42 With pleasure. I like to help when I can

Heartleander81

@dc42 I think the board is not on Firmware 3.4 I must Look why

dc42

@heartleander81 said in Issues after prime:

@dc42 I think the board is not on Firmware 3.4 I must Look why

It may be that you need to upload the IAP file from the 3.3 release, to get a copy of it in the /firmware folder of the SD card, then run M997. https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/Duet3_SDiap32_MB6HC.bin

Heartleander81

@dc42
I hadn't uploaded the firmware to the board via upload, but only tried using drag & drop. That was not possible so he installed the 3.3 again. I have now loaded the 3.4 via upload and install it. But it's taking an unusually long time.