Over night bug: Invalid Kinematics [Solved]

o_lampe

Hi Guys,
yesterday I had success with implementing the hitchhiker kinematics (CoreXYV) and made a testrun with several toolchanges. Only bothered by a U-axis showing up in DWC, although not declared.

Today, I switched the printer on, trying to add a tool copy mode, but some Gizmo has planted a bug in my config:

The U-axis disappeared
running M98 P"config.g" spit out three!! warnings of invalid kinematics.

m98 p"config.g"
Error: Invalid kinematics matrix
HTTP is enabled on port 80
FTP is disabled
TELNET is disabled
Warning: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 591C
Error: Invalid kinematics matrix
Error: Invalid kinematics matrix

Here's config.g

; Configuration file for Duet WiFi (firmware version 3)

; generated by RepRapFirmware Configuration Tool v3.2.2 on Thu Jan 21 2021 12:12:55 GMT-0600 (Central Standard Time)

; General preferences

G90                                                ; send absolute coordinates...
M83                                                ; ...but relative extruder moves
M550 P"Hitchhiker_XYV"                             ; set printer name

;CoreXY with extra Markforge U axis (see https://forum.duet3d.com/post/136554 )
M669 K1 X1:1:0:0:0 Y1:-1:0:0:-1 Z0:0:1:0:0 V0:0:0:0:1    ; adapted to CoreXYV

; Network

M552 S1                                            ; enable network
M586 P0 S1                                         ; enable HTTP
M586 P1 S0                                         ; disable FTP
M586 P2 S0                                         ; disable Telnet 

; Drives

M569 P0 S1                                         ; physical drive 0 goes forwards
M569 P1 S0                                         ; physical drive 1 goes backwards
M569 P2 S1                                         ; physical drive 2 goes forwards
M569 P3 S0                                         ; physical drive 3 goes backwards
M569 P4 S0										; extra hitchhiker motor
M584 X0 Y1 Z2 E3 V4                               ; set drive mapping

M350 X16 Y16 V8 E16 I1	    		               ; configure microstepping with interpolation
M92 X200.00 Y200.00 V234.375 E410.00               ; set steps per mm (400 for titan 1.8)
M350 Z16 I1
M92 Z2500
M566 X1200.00 Y1200.00 V1200 Z60.00 E600.00
M203 X12000.00 Y12000.00 V12000 Z1200.00 E3600.00         ; set maximum speeds (mm/min) was 15000
M201 X2000.00 Y2000.00 V2000 Z1000.00 E1000.00           ; set accelerations (mm/s^2)was 1000
M906 X2000 Y2000 Z1500 V400 E1500 I30                    ; set motor currents (mA) and motor idle factor in per cent was 1500
M84 S10                                            ; Set idle timeout 

; Axis Limits

M208 X0 Y50 V0 Z-2 S1                                ; set axis minima
M208 X260 Y170 V120 Z250 S0                          ; set axis maxima 

; Endstops
M574 X1 S1 P"xstop"                               ; configure switch endstop for low end on X
M574 Y2 S1 P"ystop"                               ; configure switch endstop for HIGH end on Y
M574 V1 S1 P"zstop"
M574 Z1 S2                                        ; configure Z-probe endstop for low end on Z

; Z-Probe
M558 P5 C"!^e0stop" H5 R0.1 A3 F500 S0.05 T18000   ; set Z probe type to switch and the dive height + speeds // variation max is 0.05
G31 P800 X-45 Y0 Z0.83	                           ; set Z probe trigger value, offset and trigger height
M557 X10:260 Y10:170 S40                           ; define mesh grid 

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138     ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                              ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B1 S1.00                                   ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0                                            ; map heated bed to heater 0
M143 H0 S120                                       ; set temperature limit for heater 0 to 120C

M308 S1 P"e0temp" Y"thermistor" T100000 B4138      ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                               ; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 B0 S1.00                                   ; disable bang-bang mode for heater  and set PWM limit
M143 H1 S280                                       ; set temperature limit for heater 1 to 280C 

; Fans
M950 F0 C"fan0" Q500                               ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1                                     ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"fan1" Q500                               ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1.0 H1 T75	                               ; set fan 1 value. Thermostatic control is turned on 

;M950 F2 C"fan2" Q500                               ; create fan 1 on pin fan1 and set its frequency
;M106 P2 S1.0 H2 T75	                               ; set fan 1 value. Thermostatic control is turned on 


; Tools
M563 P0 D0 H1 S"Tool_Y" F0 Y1                                  ; define tool 0
G10 P0 X0 Y0 Z0                                    ; set tool 0 axis offsets
G10 P0 R160 S0                                       ; set initial tool 0 active and standby temperatures to 0C 

M563 P1 D0 H1 S"Tool_V" F0 Y4                                   ; define tool 1
G10 P1 X0 V0 Z0                                  ; set tool 1 axis offsets
G10 P1 R160 S0                                       ; set initial tool 0 active and standby temperatures to 0C 

M563 P2 D0 H1 S"Copy_YV" F0 Y1:4                                  ; define tool 0
G10 P2 X0 Y-30 V30 Z0                                    ; set tool 0 axis offsets
G10 P2 R160 S0                                       ; set initial tool 0 active and standby temperatures to 0C 


;	Retraction
M207 P0 S1.8 R0.0 F3600 T3600 Z0.0					;	retraction settings for volcano 0.4 nozzle on titan direct drive extruder
M572 D0 S0.05										;	pressure advance

; Custom settings are not defined 

; Miscellaneous

M501                                               ; load saved parameters from non-volatile memory
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss
G92 x0 y170 v0 z0
T0

It's RRF3.2 btw.
What happened to my config overnight? Why did the U-axis disappear in DWC?

JoergS5

@o_lampe said in Over night bug: Invalid Kinematics:

;CoreXY with extra Markforge U axis (see https://forum.duet3d.com/post/136554 )
M669 K1 X1:1:0:0:0 Y10:0:-1 Z0:0:1:0:0 V0:0:0:0:1 ; adapted to CoreXYV

in the link https://forum.duet3d.com/post/136554 is always used U, but you use V in your config everywhere. Is this by intention?

I mean, if you use V, you'll probably need to define U also. U is not defined, so invalid kinematics. (my interpretation of the error message)

o_lampe

@joergs5
Yes, my Corexy is different because I have two tools on the Y-axis.
I tried it with defining U-axis first and T0 worked OK, but after switching to T1, it behaved weird.
So I thought X matches U and Y matches V and defined a fifth V-axis. All five axes showed up in DWC and I could switch between T0 and T1 vice versa and it worked...until this morning.
I'm currently rewriting the whole config, switching X and Y axis, bed orientation etc...to have two tools on X-axis.
Hope that helps...

JoergS5

@o_lampe in the firmware, drives and extruders are handled in arrays to pass them as parameters. I can think of problematic to have "holes" like a not defined U. M669 may create an array for XYZV, but the fourth array element will be handled later like an U somewhere in the code.

dc42

Having "holes" in the axis names is allowed. So you can use V without U. In that case, the 4th entry in the matrix will be V (not U) so you should use this matrix:

M669 K1 X1:1:0:0 Y1:-1:0:-1 Z0:0:1:0 V0:0:0:1 ; adapted to CoreXYV

I removed the 0 values in the 4th position of each parameter. Those zeros are also why you were getting the "invalid matrix" error, because you had an axis that could not be moved by any motors.

Note, if you do call the first new axis V then older versions of DWC and PanelDueFirmware may display it as U. Newer versions get the correct axis names from the object model.

JoergS5

@dc42 thank you for explaining!

o_lampe

@dc42
That's what I had initially, but with "U". Did work for T0, but not for T1.
Is it correct, that I can not match Y-U and have to use Y-V? Because that's the only explanation IMHO

Have a nice Sunday
Olaf
BTW: I was on my other PC (Win10, latest firefox) and coudn't reply to you. At least I could login...
Now I'm on Win7, latest Firefox and I was automatically logged in.
Weird things happen

JoergS5

@o_lampe there is an issue: https://forum.duet3d.com/topic/22420/issue-with-forum-login

I had problems too, was logged out with Win10 + Chrome and had no edit... menu an hour ago.

o_lampe

@dc42
Sorry to say, but it doesn't work with "V" either.
I tested IDEX on my Cartesian Prusa first and
when T0 was selected, I couldn't jog "V" .
When T1 was selected I could jog "Y" and "V"moved.

On the Corexy, I can
move "V" no matter which tool is selected, but it
doesn't move when I jog "Y" while T1 is selected.

It seems like the Tool-definition (M563) doesn't work.

; Tools
M563 P0 D0 H1 S"Tool_Y" F0 Y1                                  ; define tool 0
G10 P0 X0 Y0 Z0                                    ; set tool 0 axis offsets
G10 P0 R160 S0                                       ; set initial tool 0 active and standby temperatures to 0C  

M563 P1 D0 H1 S"Tool_V" F0 Y4                                   ; define tool 1
G10 P1 X0 V0 Z0                                  ; set tool 1 axis offsets
G10 P1 R160 S0                                       ; set initial tool 0 active and standby temperatures to 0C

Do I have to use
M563 P1 D0 H1 S"Tool_V" F0 Y5 instead, because 'V' is the fifth in XYZUV..WABC?

o_lampe

I think I found one reason for this and I blame the configurator tool:

M584 must come earlier in config.g than any M350 and M906 commands. If it creates new axes, it must also be earlier than any M92, M201, M203, M208, M350, M566, M574, M667 and M669 commands.

I took the configurator generated file as base to alter it to CoreXYU.
The configurator puts M584 in line 28, which is OK as long as you have a standard kinematic matrix.
It would be wiser to put it before M669 right away.

It's still unclear why I had it working until I shutdown the printer?
I have the feeling that some changes in config.g take two restarts or a full_coldstart (including browser) to chase away any Gremlins in all caches.

o_lampe

It's done, finally?
I had to place M584 before M669
I had to use E0 port (drive 3) for the V-axis. (E1 is now extruder) Maybe that's an Duet2WiFi thing to must have all motion axes in consecutive order?

I won't change it soon, maybe add another driver for extruder#2

JoergS5

@o_lampe nice that you found the solution. I thought about a little program to check those conditions of orders of the g-code commands. But they are only very few rules, so this may be overkill.

o_lampe

@joergs5 said in Over night bug: Invalid Kinematics [Solved]:

I thought about a little program to check those conditions

IMHO there is one order of commands that always works, even when adding tools and axes. Why not rewrite the configurator tool to apply this order?

dc42

@o_lampe said in Over night bug: Invalid Kinematics [Solved]:

@joergs5 said in Over night bug: Invalid Kinematics [Solved]:

I thought about a little program to check those conditions

IMHO there is one order of commands that always works, even when adding tools and axes. Why not rewrite the configurator tool to apply this order?

I already logged this to be fixed.

o_lampe

@dc42
Thank you!
I'm still unsure why I had it running the first time? Is there a chance that the drive mapping was in the memory even after I rerun config.g and that's why it accidently worked?

dc42

@o_lampe, had you perhaps sent M669 from the console when you had it working the first time? Or perhaps you had run M98 P"config.g" ?

o_lampe

@dc42
Yes, I run M98... often for debugging. I don't remember, if I wrote a full M669 via console, I can check the cache. But I'm sure I only have a naked M669 there to check the matrix.

dc42

@o_lampe, if you ran M98 P"config.g" that would have run the M669 command again, with the correct M584 drive assignments already set up from when config.g was run at boot time. So that's probably why it worked.

o_lampe

@dc42
In my case it would've been luck, but in other cases it would be better to erase eeprom every time. (Marlin insider)
As I said, I often restart/reset the printer and browser because of those funny accidents.

dc42

@o_lampe, if you want to run config.g and have RRF forget the previous values as far as possible, you should run M502 instead of M98 P"config.g". However, even running M502 doesn't destroy things you have already created, such as new axes, heaters, fans etc.