Over night bug: Invalid Kinematics [Solved]

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.

o_lampe

@dc42
but hitting the emergency button in DWC does?

jay_s_uk

@o_lampe thats a full system reset, so yes