RatOs 2.1 help in setting up (renamed post)
I just reflashed my CM4 with Ratos 2.1 (VERY nice configurator, gents,...!!!) After entering all my hardware (Manta M8Pv1.0, EBB42v1.2, physical endstops, perfomance mode) , press next, save, goto mainsail and get an error on pins (see picture). Ratos.cfg shows me that the UART pin is wrong. this should be z1_uart_pin=PD13. Strange, as the RatOS/boards/btt-manta-m8p/config.cfg shows the correct value (second picture). Also, the Stepper-z1 enable_pin: now has an exclamation mark. not sure if that is correct? Similar thing for z2 motor. Error on PD10 which is z2_step_pin but also uart_pin. Corrected this to PC7 and then the thing goes into a loop (not connecting)...
Must be doing something wrong, but am not seeing it...
Solution:Jump to solution
At least I am back in business, It's purring away quite nicely on the first print after the upgrade (steep learning curve again) Thanks @Helge Keck and @miklschmidt
113 Replies
Make sure you've updated everything
There were quite a few pin bugs in the initial RC1 release
As usual, update RatOS first, then the rest 🙂
Just rebooted and saw update manager waking up,... accidentilly started with klipper updating,... (stupid, I know better). I'll see how I fare,... Thanx Mikl (ps: do you ever sleep? 😉 )
FYI: Updated everything, next error is ADC out of range,... in [extruder] it had sensor_type: PT1000. I used to run max31865. corrected this and now pullup_resistor is not valid. Commented this out (my toolboard btt EBB42 has a max31865 chip and I have the rapido plus connected to this)
Now I am stuck with a pin error PD13 for spi2 (but also Uart pin for Z1)
My apologies for all the hard work that has gone in, but I am not having a good time with the upgrade... I am going back to 2.0 I think... too many custom things that I can't get to work and if I reboot, the Ratos.cfg reverts back to default (probably by design) and I do not know how to change the Max31865 and delete the pull_up sensor from this file... Also, all my fans are screwed up (part cooling didn't work connected to EBB42, CM4 fan is not working properly, Toolhead_fan goes on at100% and doesn't go off (below 50degr)....
I'll try again in a few months.
This will break
@Arthur_C see https://discord.com/channels/582187371529764864/859890291591217162/1249842989417631784
I don't recommend running the MAX31865, but if you want to use it, just pick a different thermistor (only PT1000 forces the alternative pullup).
This happens if you use hardware spi on the same bus that runs the adxl or steppers, RatOS resorts to software spi as hardware spi is very broken with multiple devices. Use the software_spi pins instead of
spi_bus for your MAX31865..
These weren't bugs, they were caused by custom configuration, it'll be the same in a few months 🙂
The PT1000 one was even mentioned here once before (the only other user using the MAX31865 😂)just reset klipper as per your suggestion (although it is not yet clear to me what that solves, but I trust it is the right thing to do...)
There are severe probe problems with the newest klipper code
Would you then connect the rapido plus thermistor to the ebb42 like it was at pt100?
RatOS pinned klipper to the commit you just checked out, but since you updated klipper before RatOS you got the new code.
PT100 won't work as a thermistor, those require an amplifier (and pretty much nobody uses them). PT1000's work just fine and plenty accurately as a thermistor yes. If you use a toolboard such as the BTT EBB series with an alternative pullup_resistor option for using PT1000 on thermistor (makes them a bit more accurate), RatOS requires you to put in the PT1000 jumper on the board.
It even shows you a warning about this in the hardware configurator
Yes, I saw the warning,.. even read the manual (and who does that...) As I have the rapido plus AND ebb42 with max31865, it was not clear how to connect it. The manual gives an option in case you'ld have the NON Max version so I think i should use that: connect the 2 wires (from rapido plus to TH0, jump the 2 pins and ignore the max31865 chip. Configure it as per picture
it was not clear how to connect itThe RatOS wiring diagrams shows you how to connect it 🙂
onnect the 2 wires (from rapido plus to TH0, jump the 2 pins and ignore the max31865 chip. Configure it as per pictureThat's it, yes.
When you guys start taling about these SPI-things I am fully lost :-). I am barely hanging on in terminology but this was a bit much for an old Civil Engineer,...
It's pretty confusing, i don't blame you. It's also one of those nice undocumented klipper quirks you have to discover through trial and error lol. There's a lot of weirdness in klipper that RatOS handles for you, one of them is not using MAX31865 because it's a PITA to deal with.
And the benefits are very very small with a PT1000 in the first place. If you had a 4-wire PT100 the MAX chip makes sense.
With 2 wire thermocouples you introduce extra resistance from the wiring, and it trips up almost everyone.
Appreciate all the support, Mikl! Thanks (if you ever need advise on how to build an offshore windfarm, give me a call so I can return the favour!!!)
I hear there's decent money in those 😂
Worth considering lol
Not as much fun as 3D-printing, though,...
FYI, I did the "revert Klipper to previous commit"-thing, yesterday. Today I put the Rapido thermistor on TH0 (as per above). Stuff is starting to behave now. Had to revert the pin for all three Z motors, and X and Y and toolhead_cooling_fan pin, did the calibration of the beacon model... looks good now... next step : Bed_mesh_calibrate and Z_OFFSET_APPLY_PROBE. After that, webam and start printing? Any idea of the status of the documation? Maybe somewhere where I can help reading/drafting etc?
Had to revert the pin for all three Z motors, and X and YThis is normal, pin direction depends on motor, cable and board. So they're always configured for the default hardware.
toolhead_cooling_fan pinThis is not necessary, you just picked the wrong fan in the configurator. People seem to struggle a lot with this I'm not sure what to do about it
Any idea of the status of the documation? Maybe somewhere where I can help reading/drafting etc?Helge has been writing a whole bunch and i've been working on incorporating the wiring diagrams into the wizard. See helge's work here: https://github.com/HelgeKeck/RatOS/tree/documentation_v2.1/site/docs/configuration
GitHub
RatOS/site/docs/configuration at documentation_v2.1 · HelgeKeck/RatOS
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
Not realy sure if I agree... In the wizard, I get one choice for a fan and that is the controler_fan, cooling the MantaM8P. I choose a 4pin and that works as designed. I do not see (kindly correct me if I am overlooking this) any place where I can choose the fan and pin that control the toolhead. In the generated ratos.cfg, there is an exclamation mark at the pin, which caused my fan to run at boot and switch off when extruder is on and/or above 50deg C. I had to remove the exclamation mark to get it to work (and also add a tach as I run Ellis' extruder-fan-monitoring macro,... if I can get that to work....)
In the wizard, I get one choice for a fan and that is the controler_fan, cooling the MantaM8PConfigurator screenshot is controller fan, config screenshots are part fan and hotend fan. There are separate dropdowns for those in the the toolhead box.
Ah,... Got it,... must have overlooked it only 10 times or so,... (apologies)
Next "issue": filament unload is very much changed compare dot 2.0. I see a lot of variables added (or at least in default [gcode_macro T0]). I trust all these lengthes are already tuned to my setup. When I press the button to unload filament on the orbiter 2.0 filament sensor, a little dance starts with the filament going up and downd, faster and faster (no problems here, I think I understand what is going on). at what I assume to be the last step (actuall unloading the filament) my extruder makes a high pitch noise but doesn't do anything. I think the unload speed is to high but I can't find a variable to change that fixes this (see the last 4 variables.). Also, the default of 60 should be no problem with an orbiter, right? Again, a little nudge in the right direction would be appreciated
GitHub
RatOS/site/docs/configuration/macros.md at documentation_v2.1 · Hel...
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
it's relatively slow by default and shouldn't cause issues, so i'm not sure what's going on there.
Did you configure the filament sensor like described in https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/configuration/filament_sensors.md#toolhead-filament-sensor ?
GitHub
RatOS/site/docs/configuration/filamentsensors.md at documentation...
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
Oh...Crap,... I just used the old UNLOAD_filament macros'.... Let me try again with the correct config... (the "pause_on_runout: False" surpises me a bit but I assume the macro will handle pause.)
Ha,... funny (not).... extruder motor was still reversed,...
The macro's handle pausing
Well 😅
Working quite nicely I must say,....:chefkiss:
Now to sort out some custom gremlins (Ellis' Hotend Fan RPM monitoring,... worked like a charm this morning,... not anymore now....).
Ok, Sorted the " Hotend Fan RPM monitoring" issue. Back to following the config guides. Did the Beacon calibrate, did the latency check / poke test (it is between 0 an 1, so that is good). At probing it give me an error (Probe samples exceed sample_tolerance), but eventually (after a firmware restart) it succeeded. When I started the BEACON_CALIBRATE_NOZZLE_TEMP_OFFSET, it gives the same errors and the test fails (extruder at 0 succeeded, 150degr succeeded, 250 succeeded, 150 degr failed. Rebooted, and test failed at the beginning). Is this something we could look at here or should I go the the Beacon discord?
(it is between 0 an 1, so that is goodGood? That's incredible 😮
Probe samples exceed sample_toleranceEither loose motor couplers or nozzle isn't clean / meltzone not empty Can also be a loose nozzle or loose hotend It's not a beacon bug 😉 It's very good at revealing all the problems with your machine that were otherwise ignored and caused bad first layers
I got the extruder up to 280, brushed the nozzle (it was already tight) and with some minor misprobes, it succeded in the calibration!
Which brings me to step 5. it says:
Override the beacon_contact_expansion_multiplier from here to fine tune your first layer squish. Higher value means less squish and lower value means more squish. 1.1 = a bit less squish, 0.9 = a bit more squish, ....
but it is unclear HOW I should override this. What I now did for my first print is baby step until I had a good first layer and then saved the new offset in the beacon model. somehow, that doesn't appear to be what I SHOULD have done,....
One general comment/question I have now: If I do a first print, there is a lot going on:
-home xyz
-calibrate beacon/contact (I think)
-tilt correction
-bed meshing
-another contact probe in the centre
-a contact probe at the primeblob location
-primeblobbing
There seems to be no such thing as making a quick print anymore? Is it going to do all these things every print?
like all other RatOS variables:
in printerc.fg:
but it is unclear HOW I should override this. What I now did for my first print is baby step until I had a good first layer and then saved the new offset in the beacon model. somehow, that doesn't appear to be what I SHOULD have doneCorrect, contact should be perfect after autocalibration But it's fine with the model you calibrated, should still work
sure, but finding the right multiplier, is that then trial and error, or is there another spiffy macro how to solve that?
There seems to be no such thing as making a quick print anymore? Is it going to do all these things every print?Yes. Because that means perfect layers every time (including if you swap plates or nozzles).
sure, but finding the right multiplier, is that then trial and error, or is there another spiffy micro how to solve that?You could do something like the following: - Start a print - Baby step to perfect Z. - new expansion coefficient =
old_expansion_multiplier - (expansion_coefficient * (print_temp - 150) / runtime z offset adjustment) / 100) . ie 1 - (0.0073423 * (250 - 150) / 0.01) / 100
Generally for beacon contact ask in #beacon-contact
@Helge Keck does this makes sense IRL like it does in my head? 😂there is no live method atm to tune that multiplier. i can think about it how to implement one. the reason why we are using a multiplier instead of a real z-offset is that a z-offset is temperature related, the multiplier not, means one time set it works acorss all printing temperatures
i coul dthink of a easy test where you print like 9 squares at once with exlude object and set a multiplier for each object, i can make a script for that
similar to the ellis em tuning test
maye @miklschmidt has a better idea for doing it
but honestly, tuning that multiplier isnt that hard imo. you print your first test layer and then you see if you want more or less squish, then you print asecond and maybe a third
the good thing is this is a one time tuning and then hit and forget
If my math is right, you could just baby step and calculate the multiplier by calculating
1-(expansion_coefficient * (print_temp - 150)/ amount of manual z offset adjustment) / 100I highly Appreciate you (both) responding to all my questions! I now set the z-offset back to 0 and used a multiplier of 1.1. seems a bit to high (z-offset was only 0.03 so almost negligable)
oh, we could make a simple macro that spits the multiplier out based on the current z-offset
yes!
gotta go
if its a bit too high just reduce the multiplier a bit, try 0.95 for example, this mreans 5% less
I increased the z-offset to 0.03 (+) so Mikl's calculation shows....euhm,... wait for it,.... 1 - (0.06969*(250-150)/0.03)/100
= 1 - expansion_coefficient = 0,930313
Ah,... [exclude_object] was not in the printer.cfg,.... That's why the printer keeps shouting at me:
Unknown command:"TIMELAPSE_TAKE_FRAME"
Unknown command:"EXCLUDE_OBJECT_START"
yeah, by default not activated bc some slicer are too stupid to proper implement it
Solution
At least I am back in business, It's purring away quite nicely on the first print after the upgrade (steep learning curve again) Thanks @Helge Keck and @miklschmidt
ah if it was with 1.1 it would be
1.1 - (0.06969*(250-150)/0.03)/100 = 1.03031Ah! Got it! Try that in the morning.
its this here
(expansion_coefficient + baby_step) / expansion_coefficient = new multiplierisn't it relevant to convert the baby_stepping to a "change per 1 degree" unit, like the expansion coefficient?
hmmm
i think you are right
ie "i need 0.03mm per 100 degrees"
I'm pretty sure
old_expansion_multiplier - (expansion_coefficient * (print_temp - 150) / runtime z offset adjustment) / 100) encapsulates all of it
it's converting the expansion_coefficient to a "change per x degrees" that matches the runtime z adjustment instead, but same thing.
150 should be replaced by whatever temp the beacon contact is done atright
dude, just reprint another square
:kekw:
😂
While we are fumbling with numbers,... is there a sketch or a drawing of some kind on how these variables measure out?
I would like to get into your brain to see if I understand it but a drawing would be more practicle.
no this doesnt exist
😢
Found it:
thats actually not correct
this is a completely different setup
it doesnt represent the rapido, orbiter and a sensor on top of the extruder
the vc4 doesnt have the sensors insode the hotend
Well it is actually the model of the rapido UHF with the orbiter 2 and sensor that i run on my Vcore 3.1... crossections are (mostly derived from the existing cad model,... not sure why you say this is not correct,..
its still wrong
extruder gear to toolhead sensor cant be inside the hotend like in the image you share
thats definitly wrong
the sensor sits on top of the extruder and not between extruder and hotend
The measurements I put in to see if I can correlate wht the macro's and defaults are doing
i dont know who made this images, but they are definityl not correct
the values ni ratos are for orboiter, rapido and the sensor, you dont need to change them
labels are not correct (yet). the guy who drew this has an off day,... I'll have a chat with him in a minute
normaly you dont need to change these values
and still, I do not get fillament out of the nozzle when I load new filament. I am trying to understand what you guys have put in here and see how this all works.
this has nothing to do with these values
when loading new filament it is not supposed that filament comes out of the nozzle
if you want to purge filament out of the nozzle after loading it just change the purge_after load value
i do njot recommend to change the values you just shared
these values are correct and should not be changed
why dont you tell me exactly what issue you are having
instead of asking for graphs
then i can probably help you
Appreciated and noted to above. Deleted it from my printer.cfg. I allready (earlier) changed variable_purge_after_load: 60 and still have not filament coming out the nozzle. So question then is: If variable_purge_after_load: 0 is the print not going to underextrude for the first part of the print? In 2.0 I believe I tweaked variable_filament_load_length
this is not related to printing
only for manual filament loading
during printing you dont use the load filament feature at all
so im a biot confused what the actual issue is
So, in case of filament runout or color change, an unload/Load is initiated right? That is at least what I was refering to
on filament runout or color change you still need to maually load the filament
theis feature is not designed to maek everything automatically for you
means you load the new filament, extrude a bit, cvlean the nozzle and then press resume
Sure, so in ratos 2.0 I had it setup that in case of runout or colour change, the nozzle parked un unloaded. I can then do a filament change (away from the printed object) and made sure that the nozzle is fully loaded/charged before I hit "resume". I am trying a similar thing here.
but it does the same
you load new filament, extrude a bit, clean the nozzle and then you resume the print
this is the workflow
if you want to fine tune the amount of extrusion the is a offset varraible in the toolhead macro
one sec
so you can finetune it that it load to the nozzle tip, but still
understood. I have seen that. I believe it is set to -5
you should always extrude a bit manually and then clean then nozzle before resuming a print
otherwise you will never get a good seam when the print resumes
variable_filament_loading_nozzle_offset: -5
yes
you cna use this variable to finetune, but as i said, its still better to extrude a bit and clean the nozzle
Can you explain what to use: variable_filament_load_length or variable_purge_after_load
this is more for idex and mmu operations
Thanx Helge for the assistance
no problem
btw, the "new" primeblob" got me startled a bit. The secand have of the move is MUCH faster then before. Is that correct or did I screw up a parameter somewher (wouldn't be the first time,....)
we made it shorter and faster
this is intended
Cool,.. scarry at first but cool (more filament extruded also with my 0.6 nozzle, also,... is it now more "aware" of the nozzle size and does it addapt to the nozzle size?)
yes, its now nozzle aware
I haven't even tried the new one myself yet, i mathed it out and helge was like "a bit shorter" and this is the result 😂
sometimes shorter is better, dont trust your wife
I have no real success in feeding more filement through after loading btw. After loading the filament I need to extrude about 20mm extra before it oozes out. Added variable_filament_loading_nozzle_offset: 20 after which I still need to extrude approx 15 to 20mm. Also set it to variable_filament_loading_nozzle_offset: 60 with similar results. Any ideas? (I do NOT have IDEX machine, just a simple, good old VC3.1-300)
If you want it to purge after loading automatically, you need to set
variable_purge_after_load to the amount you wish to purge after the filament has been loaded. Do not use nozzle_offset for that (if you do that none of the other filament macros will work correctly).
I can do a sanity check of your config if you post it hereso this is from my VC200 which still has a EVA 3.0 toolhead. and it loads exactly to the nozzle tip of my Rapido UHF
and i dont even use
variable_purge_after_loadn thsi case, its set to 0
if you have a standard eva toolhead and you still need to extrude this hugre amount of filament then something might be wrong
you might want to check if your extruder latch is not too loose
or if you have some drag somewhere in your bowden tube, like a kinked curve or whatever
this should work out of the box
or you have set the overrides on the wrong place maybehe doesn't want it to stop at the nozzle tip, he wants it to purge afterwards
yes, i know that. but he said that he needs to extrude like 20mm until it comes out
there is something wrong
ah fair
if he has set the offset to 20 then it should have come out already
yeah something ain't right
@Arthur_C would you please share your ratos and printer.cfg
Idealy, i want to stop at the nozzle, but it now still needs to feed about 15 to 20 mm to get to the nozzle .. i'l do a sanity check in the morning with a free hanging filament (and delete the earlier mentioned variable value.)
Also set it to variable_filament_loading_nozzle_offset: 60 with similar resultsthere is clearly something wrong alone thi ssetting should have give a huge extrusion amount i assume your heatbreak entrance is partly blocked and your extruder gears could be dirty maybe
HI Helge, Please find attached. (I feel somewhat burdened to ask all of this from you guys... I am used to solving my own issues without troubling other too much...)
all good, want to know what it is
i dont see an y overrides for the varaibles?
how did you changed these values?
stuffed them in the printer.cfg....? (This is the part where you tell me I f#ck-up...)
ahh
yes, sorry
had the wrong file open
no wait,
it isnt there
there is nothing in the printe.cfg overwritten
yeah, this dosnt work this way
these are not RatOS variables
these are toolhead variables
Should it be lower down in the printer.cfg?
you see that
you did put them under ratos
so you actually never changed them
you need to copy and paste this complete thing to your printer.cfg and changing the values there
So all overrides related to T0 have their own macro! And I need to copy/paste the whole thang and not only the variables I'ld like to change?
copy the whole block to the printer cfg
including this header
I was just about to say that I had the feeling that the variable_filament_grabbing_speed also appeared to have no effect... But this explains it.
Whell good to know. Ill make the changes and try tomorrow (kids are asleep and somehow they do not share my 3D printing enthousiasm in the chamber next to their beds...)
Appreciate the assistance here Helge!
Took me 127 prints to dial it in to 1.02493,... Now I must remove it again?
Just kidding of course 😉 ,... Progress is made!!