Over night bug: Invalid Kinematics [Solved]
o_lampe last edited by o_lampe
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
; 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?
;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)
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...
@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.
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 last edited by
@dc42 thank you for explaining!
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
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 last edited by
@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.
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 last edited by 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.
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
@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.
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.
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?
@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" ?
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.
@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.
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.
@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.
but hitting the emergency button in DWC does?
jay_s_uk last edited by
@o_lampe thats a full system reset, so yes