Issue when switching from corexy (with custom motor setup) to hybrid
Discussing this issue: https://github.com/Rat-OS/RatOS/issues/160
GitHub
"Motor slot conflicts detected" when switching from CoreXY to Hybri...
What happened I have hybrid hardware, and it was initially enabled, but due to doing some debugging I set it to CoreXY mode. Rather than changing my wiring, instead when I changed to corexy, I sele...
179 Replies
So to clarify:
When I first installed my printer, I selected Hybrid
I then decided for reasons to switch back to corexy mode.
However, rather than unplugging the motors, what I instead did was:
When switching from hybrid to corexy in the configurator, I selected custom motor setup
I then set the X and Y motors to use the same ports that hybrid uses for these motors
please provide detailed step by step documentation how this happens
All went well
Then, later, I decided to switch back to hybrid
So I went into the configurator, selected hybrid, and was presented with this screen:
try to resize your browser window when this happens
just to make sure its not a stupid resize issue
also ashare the browser type you are using, also add the debug.zip here
you can create it in the navigation on the left side
I don't really wanna try and repro it now, my printer is currently fucked up in another way, I need to work through that
But once I have my shit sorted, I am happy to try and repro for you
Whatever, would that not just be a rendering issue?
as in, the motors may not show, but they should be set to the correct defaults?
Cos that is not the end of the story
Cos every time I would start up, I would have a "Motor slot conflicts detected" error
I fixed this by restoring my RatOS.cfg from a backup I had made while I was previously in hybrid mode
Which worked, and I was able to print etc
However, every time I power cycled the machine, it would happen again
you are not supposed to touch the ratos.cfg file, this file will be atumatically regenerated
the solutino is to select and configure your correct printer type and then do nto touch the configurator again
But I could not fix it from the configurator
Because it did not show the motors in the UI
by changing the ratos.cfg file you dont not change whats displayed in the configurator
you jsut change temporarily the ratos.cfg file, until it gets overwritten autmatically again
so please try this first
https://discord.com/channels/582187371529764864/1300755390828384276/1300756372866076693
also again, please provide detailed step by step information on how to reprocude this error
and the debug.zip file
OK, so I was under the impression that if you had a good config, and then backed up printer.cfg and ratos.cfg - if, at a later date, I restored those files, it should put the printer back in that state?
This is not the case?
no, you can make backups of course, but the ratos.cfg file gets overwritten automatically from time to time
Not understanding what the point of making a backup then if restoring it won't persist?
bc the file tells you how you have it configured before
it tells you for example the motor slots
in case you have forgot them
So there is no way to "Save" and "Load" as it were?
no
Ah
its also not needed if you dont change all the time the printer type in the configurator
once configured it remembers everything
until you select another printer
Right, but that's my point - when I did that, it did not fix the issue
In the end, the only thing that fixed the issue was deleting all copies (inc backups) of both config files, and then, without rebooting, running the configurator
if you really have a rendering or resizin issue then its not related to the actual config
the actual config will be rememrbed
Only then did it actually start afresh
Just going into the configurator and selecting another printer (Even selecting "Start Afresh") did not solve the problem.
Now I am scared of trying to repro it, cos I have no way of restoring from a backup, should I succeed...
I guess take an image of the SD card?
you can try to clear your browaer cahce and the reconfigure it
once configured you dont need to touch it again
What I mean is - I need to try and fix the other problem I am having - once I do that, I would be up for trying to repro this issue. However I don't want to lose that config and be back to square one again. This build has taken weeks already
you dont need to square anything
you jsut rredo the config
Yes, but as I said, last time I got into this issue, the configurator could not get me out of it (Or at least I could not seem to get out of it)
Now that you have given me some do's and don'ts, and some things to try (eg resize browser) then maybe it will be OK
It's just, honestly, I am at my wits end with this printer. It's one step forwards, two steps back
Sunk probably 100 hours into this build so far
@Helge Keck @miklschmidt
I think this is what I did. I have a funny feeling that at this point I thought "Oh fuck, I am not sure which motor is meant to be which port", and just hit back to mainsail and restored my ratos.cfg and printer.cfg
Part of the problem wrt that is that the docs use different names for the motors, so it's really confusing
The docs say name them L, R, Y1, Y2, whereas RatOS names them X, X1, Y, Y1 in Hybrid and X, Y in corexy
docs L = X in hybrid + corexy?
docs R = X1 in hybrid, Y in corexy?
docs Y1 = Y in hybrid?
docs Y2 = Y1 in hybrid?
So confusing, it took me like 5 mins to write that
TLDR at this point:
I should change Stepper Y to motor 1?
Ah, just realized, ofc I have the screen recording to refer to
OK so it's all happy if I do that
So I guess yeah, i must have exited in a panic or something thinking it would not save the changes and it did? Or I restored a RatOS.cfg and that screwed everything up?
In case it matters, but this was at the point after I selected the correct motor so it maybe does not tell you much.
So apart from my gripe with the naming - why does it not automatically select the correct config for hybrid? Could it be made to?
that is due to how klipper names them and we can't change that
Change the docs to match maybe?
This is expected behavior
expected as in not ideal but unavoidable, or expected as in how you want it to work?
See the descriptions of the motors
expected as in it's doing exactly what you're asking it to, you're asking it to assign your previous configuration to the new one, so Motor Y keeps the same slot
If you don't want to carry over your settings, pick "Start fresh"
Would it be any different if, when switching back to CoreXY, I selected "Start Fresh"?
yes
it would be different in both directions if you pick "Start fresh", that clears your client side configuration (this is saved in moonraker's database)
OK, I did that cos I had other stuff in the printer.cfg that I wanted to keep - specifically the re-assignment of the fan to use the heater -ve (Fan spins at 100% on boot fix)
printer.cfg will receive changes regardless and it can't port custom additions/changes (merge conflicts are a pain in the ass)
You'll have to manually copy the stuff you want changed or ignore the changes and fix it manually
I have a ticket open about it not remembering that...
Is that quirk documented somewhere?
in the top of printer.cfg in the diff view
it's in your video
Hmm, I did not notice that. Should be reading more carefully I suppose
when every "helper parameter" currently rendered to printer.cfg has been automated / recieved UI, this problem will be gone, but it's a lot of work, and there's so much other stuff to deal with so it'll take a long time before we get there.
Again, please don't take these comments as dispariging of your work, I am just trying to think of what we can do to protect users from our own fuck-wittery
Don't worry, I don't, it's good feedback regardless if the behavior is intended or not
no worries, please apologize my troll comment from earlier, was not appropiate
It's cool, shit happens. Used to that dev-qa type relationship where sometimes things get a bit heated
I wonder if maybe one remedy might be to make the default corexy config use the same ports as hybrid?
Hahaha oh yes, it can get a little wild sometimes. Humans and their capacity for marrying their ideas 😅
Is there any down-side to doing that? Apart of course from having to update docs
and all the wiring diagrams 😂
I take it that is handled by RR employees?
There are some stepper naming issues in klipper that makes it hard.
No, RatOS supports almost 50 boards, they're all done by me and some have been done by the community
All 50 would need to change
How are the images done?
its mikls favorite work
draw.io 😄
Is it just you two doing this?
Helge is Mr. Macro man!
where is my new AI image for that?
And then there's me
I could maybe pitch in
And @MDFPereira has been super helpful with wiring diagrams and pin assigments.
Coming right up
But as I mentioned before, I am about at the point of trying to sort beacon out, but the docs scares the shit outta me
I already killed a buildtak plate when I first tried it
How so?
The idea is you just run
BEACON_RATOS_CALIBRATE with a clean nozzle and empty hotend and then that's it.😂😂😂
I don't know why you're in perfect poop position
Brand fucking new 😦
How did it happen?
Big ole dent
Looks like the nozzle was too low?
Started a print without fully realizing how it all worked
I guess it did not account for the change in surface from the stock plate?
I'm still trying to get to grips with how it all works. When the printer starts a job I see it touch the bed, so I thought it would do so, gently, and adjust accordingly
This needs to be done per print surface?
No
Contact is used to ensure z=0 is where the nozzle makes contact.
You can swap build plates at will. The only case where you'd need to redo anything per print plate is if you use a scan compensation mesh.
I assumed what it did was scan using eddy to get the level-ness, then do a gentle probe to determine thickness of the surface on top of the spring steel, and adjust Z offset accordingly
That's essentially what's happening except it's not determining the thickness, it's adjusting your z_offset so that z=0 (what it's really doing is rehoming with contact, there's no z_offset) is where the nozzle makes contact.
IDK, I have been fucking around with config and stuff so much, maybe I had reverted back to a point before I did BEACON_RATOS_CALIBRATE
I remember following the instructions to do the initial test layer, then baby stepping it to good height, then doing save config
But as I said, I may have reverted out that change without realizing
Indeed. The process for that, when using "SAVE_Z_OFFSET" is that it modifies how much of the "hotend expansion compensation" is applied before printing. The hotend expansion compensation can only ever result in a bigger distance from the bed to the nozzle though. The higher the multipler, the further from the bed the nozzle will be.
I also seem to remember seeing something recently that said not to click the save config button, but to type it?
That makes no difference. You don't need SAVE_CONFIG at all.
unless you reduced your thermal expansion compensation so much that your new z-offset would make the multiplier negative, then it reverts to saving a z_offset to your beacon model, in which case you do need to run SAVE_CONFIG afterwards.
That whole thing is confusing af
exactly. SAVE_Z_OFFSET != SAVE_CONFIG
Two very different commands that do two completely different things.
ah right, yes. not the same thing
SAVE_CONFIG doesn't have anything to do with z_offset.
Sorry. as you say, so confusing, so much to take in
SAVE_CONFIG saves any runtime modifications to klipper internal state to the klipper maintained config section at the bottom of printer.cfg (the one that is commented out)
Yes, we want to reduce that, just gotta figure out how and not make it worse.
The more code we write to "help you" the harder it is to figure out wtf is happening when things go wrong.
But yeah, was looking to maybe work my way through this next: https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/configuration/beacon_contact.md
But as I said, there's so many terms being thrown around that I don't understand
GitHub
RatOS/site/docs/configuration/beacon_contact.md at documentation_v2...
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
Would be nice if you could list those terms so we can make a glossary or something
tbf, this is a pretty advanced DIY printer and software.its just impossible to use the documentation to help everyone to get from zero to hero. there is a learning curve you have to go through
That will always be the case indeed. We just gotta find a middle road.
It's always fun when mixing software and user assembled hardware and the error could be everywhere 😄
imagine setting this printer up withotu ratos and its configurator
Not even possible at the moment lol.
I still don't understand what a "beacon model" is
its the data the beacon collects during the calibration
So it describes the steel sheet?
Essentially a mesh, but describing the sub-surface rather than the surface?
no
in the model there is no mesh data
there are temperature data, z offset and simialr things
is it a model of one sheet? or applicable to all?
Because of contact it's applicable to all
You can read about beacon models in the official beacon docs
It's a calibration model containing measurements of how the device behaves in your particular environment.
May I suggest just removing that from the contact docs then?
i think its very important to stick to the official naming
Was about to say that
@evilC https://docs.beacon3d.com/models/
Oh sorry, I read that as "not applicable at all"
i know its a lot to read, but there is jsut no way to make this much easier
its part of the learning curve
OK so the link here jumps you to a point after models
because you don't need to worry about models, it's handled for you, as it says in the intro
😄
the link points to the top of the introduction, i believe its the best starting point 🙂
we use the contact feature by default, thats why it points there
That's part of what RatOS does
This is so fucking confusing and badly written
It explains why you would want to use multiple of them before it explains what one does
And the example it gives is of multiple build surfaces
Yet then later on:
it gives
default and cold??? Wy the fuck use temperature as an example of a variation?
That's why we don't link to it. Contact can calibrate these automatically (which RatOS does each print).
Wy the fuck use temperature as an example of a variation?Because temperature has a huge impact. That's why we calibrate the beacon with a hot bed (part of BEACON_RATOS_CALIBRATE).
Right, so you like to the contact docs, but it quickly starts talking about models, so then you are wondering wtf models are, so you look that up and it confuses you even more
If you want to reduce confusion you'd need to read the entire thing
including contact docs and the RatOS calibration code
It's a lot of stuff to take in that's not really useful for you
I'm really bad at taking something in without understanding it 😦
That whole "were gonna give you a shit-ton of information, but it won't make sense until you heard all of it"
There's not really any way around it. It's a pretty advanced device.
If you want to know how it works, there's a lot of stuff to learn
If you just want to use it, ignore it
its like trying to understand quantum mechanics without reading anything
:kekw:
Something something poison... Something cat
does this work with a dog as well?
Depends on the poison!
lmao
so each model has exactly one z-offset? ie difference between eddy distance and contact distance?
cos I am guessing it does one contact probe and assumes that diff is constant?
so each model has exactly one z-offsetYes and it's zero when using contact / true zero. Should never need to be modified.
ie difference between eddy distance and contact distance?eddy current is measured and the calibration model is used to translate that into a distance. Contact recalibrates the model so that the eddy current measured when the nozzle contacts the surface is interpreted as distance=0. We use contact multiple times during START_PRINT and BEACON_RATOS_CALIBRATE
so it's taking the z-per-coordinate value for lots of coordinates in an eddy mesh, and applying one z offset difference for the topper, based upon one contact probe?
the one that matters is the last one that's done before heating the hotend to print temp. We do that at 150C, then we apply the precalibrated hotend thermal compensation (
(print temperature - 150C) * measured thermal expansion coefficient) multiplied by your saved multiplier (saved with SAVE_Z_OFFSET) as a runtime g-code offset.I notice with my printer it probes the front edge on the left of the bed and moves slowly, and also seems to do a similar thing on the front of the right edge
No
You're going into how bed_meshes are implemented in klipper now
the right one looks like its probing the prime blob area
not sure what the front left one is for
bed_mesh is a gcode transform that happens internally. When you request a position, klipper interpolates the mesh at those x/y coordinates and modifies the requested Z coordinate.
using contact for prime probing is enabled by default, yes.
the final contact point should be in the middle of the bed (or wherever you have your safe_z_home, default is center).
Not quite getting what TrueZero is
if it's low force, then why are only hard surfaces able to withstand it?
TrueZero = contact with hotend at print temp.
Z=0 equals nozzle contact with the bed.
it says that:
OK, so why don't they say that? It's like they are deliberately trying to make it more complex
They do say that 😄
you mean "temperature insensitive thresholding"?
It's right in your screenshot
That's what "true zero" is. Auto calibration via contact at printing temperature.
It does not scream that's what defines true zero, it implies that they can do zero baby setting and the true zero offset calibration can be automatic (implying true zero could be done manually)
Plus it's self-referential
I didn't write the beacon docs, but i'm sure they are open to more understandable formulations over at beacon3d
Sorry, all that I am getting at is that I think we can maybe write some primer which helps de-mistify some of this
Maybe!
This says what TZ is in purely laymans terms. It should lead with that
That would be misleading... maybe our use of the term is misleading. We don't do contact at print temp. We do it at 150C and apply an expansion coefficient to arrive at the same value that contact at print temp would (or that was the idea).
Contact at print temp is hard because of oozing.
So we don't use TZ?
We're using something in between.
as in 150c?
150C + hotend thermal expansion compensation, yes
those 150C are modifiable via variables btw, so you could change it if you wanted to, but 150c is the default
OK so my ToDo #1: Have a preamble which maybe explains this before the link to the docs
Give your laymans terms for it, but then add we don't quite do that
Maybe a brief laymans explanation of Models ?before that?
Sure we can do all that
I am happy to try and get my head around it, submit a PR and we can tweak from there
tbf we dont use the term true zero at all in our docs
We've been more concerned with the "how" than the "what" and "why" because the vast majority of the docs are still incomplete.
yes but our link says to go to those docs and understand it
we do in the variables (that was my dumb idea 😂)
your fault
and it's confusing yet somewhat irrelevant
but noone reads the variable names
:kekw:
or the docs 😂
true
you guys maybe need to understand it, but we should probably try to shield people from information overload where it brings them no value
that's the point yes
we do shield people aöready from this overload, our doc doesnt explain at all how the beacon works internally
the doc could be 10 times longer and still uncomplete
most people don't care, they just want to click a button and watch a print go down without problems
I'm also mindful of this long wall-o-text in this issue - do you guys maybe want to start a channel or thread for this?
The more text we add in front of that the more they're gonna not read it.
Exactly
Yeah prolly a good idea, start a thread in #ratos-development maybe?
i think the our beacon doc is rpetty compact without any bs noone else need
yeah they are. But they may be too compact for some, and make references to something that makes people go "wait, wtf is that". In this case: beacon model.
Docs are hard
but i was already so generous and added a single link to the complete beacon doc, what do you want more
:kekw:
Sorry for all the pings and renames of threads, not really worked with threads before
I guess close this one?
I think it's maybe concise and lacks BS, but I did not understand some of the terms and the beacon docs didn't really help