Over night bug: Invalid Kinematics [Solved]

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