Issues after prime

Heartleander81

@dc42
After I comment out Line 20 its all good

dc42

@heartleander81 thanks again!

Heartleander81

I was able to issolate / fix the error by going to Z0.3 in line 14 with the long code.

I also tested things at the same time. Maybe that will help you

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?