first layer issues
Hello everybody
I have massive first layer issues. I can’t get only one print since I have this printer.
I always start the print after 30-60 mins so the printer is heated up.
But no matter what I do the first layer is not acceptable.
What I already does:
- Checked the beareings from the z if I mounted it in the right order.
- Set the speed to 50mms for the first layer
- Acceleration for first layer is 4000
- Did an beacon contact calibration
- Did an beacon scan compensation
- Set the z offset multiple times new
- Checked the flow from the filament multiple times
- Tested with 0,5mm width for first layer
but no solution.
All 3 spindles are bend. Don't know if this cause the problem. (Like you see in the picture I measured with an hair lineal wich is 100% straight)
Don't know what I can do else.
658 Replies
I assume the printer is fully enclosed? What temperature is the bed at when you are trying to printer. When you preheat the printer where is the tool head parked at?
Yes it is enclosed
100 degrees and i have preheat 1 hour the tool head is parked at 250,250,5
That should do it but I would move the z down to 2. That has worked best for my vc3 and vc4
Yesterday I tested with 2 hours of preheat so I think it should not be so much difference between 2 or 5 mm distance
It may or it may not. What is the fist layer thickness you are running in your slicer? I found 0.3mm the be a little more forgiving. I don’t have perfect first layers either but find it good enough most of the time to let the print continue.
I have 0,2mm and tested with 0,24
What is your:
variable_bed_heat_soak_time:
variable_hotend_heat_soak_time:
?
I understand that you heat soak the bed, but do you heatsoak the hotend as well?
[gcode_macro RatOS]
variable_bed_heat_soak_time: 0
variable_hotend_heat_soak_time: 240
variable_start_print_park_in: 'primeblob'
This is what I have for the hotbed
Hotend *
Here is my printer.cfg
Today I checked again the z axis and make ratos completely new but yeah what should I say … the same result
And that is without any manual babystepping?
What do you mean with babystepping ?
Manually changing the z height during the first layer by small steps like 10um
Yes this was without only at the beginning but that is not on the picture
Ok. So the result does not indeed look like a result of temperature expansion, as the distance varies up and down. Have you checked the leadscrew couplers, so that there is no possibility for them to slip?
What do you mean with leadscrew couplers ? Sorry my English is not the best 😁😬
The couplers that couple the leadscrews to the motor shafts
Ah yes they were overtightned haha I had to order new ones
But yes they are now tight enough
Hmm.. so.. somethin is now making the distance vary rather randomly. Have you checked the printhead and nozzle that there is nothing loose there?
Yes there is everything tight too
One possibility would be to see what the result would be if you run without a heatmap, so that we could rule out anything in the motors or leadscrew rotation. If the randomness issue continues then the problem probably would be somewhere in the xy motion system, and not in the z movement system. There would of course be the bed slope visible, but that would not cause sudden changes like you see now, from one line to the next.
Okay this is a good step
Then I know where to search
How can I disable the mesh
Hmm.. not sure what the best way would be. You could define ’faulty_regions’ that cover the area you print, or you could modify the start_print macro so that it does not do BED_MESH_PROFILE. Or then you could create a dummy profile with zero correction.
Where can I found the start print macro v
I think I found something to deactivate it will test it now
And once you do, also make sure that the leadscrews do not turn at all during the first layer. The seams on the couplers are a pretty good indicator to follow
Okay I have turned it off
But the problem is I have 0,27 diffrence on the bed
Is that also within the region where you print?
Yes it’s all oder the bed
Ok, so you cannot print the first layer at all? If so, then I would babystep 25um at a time, and keep a note of when I move. That might still show whether the random stuff stays or not.
Yes
This is the same z offset
I think there we can see that the problem is here too
Yes. If you did not babystep, then that does seem like an uncommanded shift somewhere.
No on this print I don’t
Ok. So, now it would seem like the first suspect would not be the z movement system. How about the carriage? or carriages, both x and y might have effect
XY joiners and their screws? Could there be slack there?
If everything doesn’t deceive me, something has to make sure that the X-axis adjusts in height. That’s not offset or anything like that, is it? Means something moves up or down at the XY axis.
Could that be due to the extruder?
Yea, I guess we do not know. But as you said, since the issue is visible even without the z motors turning, and the nozzle seems to go up and down, it would not be likely that the proble is in Z. The extruder by itself would should not cause this, but something now needs to be loose, otherwise this change should not be there. The worst case would be that the rail/carriage is loose and there is some residue in the bearings which moves the head up/down, but that seems a bit far-fetched.
I'm sure you have gone through every screw in the head assembly..
I tightened the screws on the rail with 2.2nm every screw
Yes I think I got everyone
But I will do it a 3th time maybe I don’t see something
At this stage I might even go as far as disassemble the whole head and re-build it. Lots of work, I know..
Btw, what does your beacon tilt measurement show?
And have you checked the umbilical / filament paths so that there is nothing that would lift/push? I gues the same issue is visible also with the top lid off?
While the direct push of the umbilical should not be strong enough to make a significant change, a lateral pull might just twist the x-rail to show something like this. Not that the pattern would fit quite well to that explanation, just throwing it out for consideration.
Oh that is okay I am looking since 3 weeks for this problem so these hours are pretty good if it works after 😁
Yes tested while I am holding and without the top lid
How strong should the screw of the extruder be ?
You mean the screw that pushes the filament?
Yes
Tight enough so that filament does not slip, but not too tight to cause major deformation in the filament :). Sorry, I do not have any good rule-of-thumb, and it also depends on the filament you are pushing. I would be surprised if the issue you see would be caused but that screw, though.
If you disasseble, try to see if there is any slack in the carriage when you move it along the rail. Try lifting/twisting/bendig in different directions, to whether there could something the could explain the sudden changes you see in z.
The good thing is that the same issue is not visible in all vc4's, so there is something different. Now we would just need to find out what it is :/
I will test this later or tomorrow in the morning now I have to take time with my kids 😁 thank you I will write back if I tested this
And while you are at it, also make sure the three screws attaching the hotend heatblock to the heatsink are reasonably tight. That is, if you are using the Rapido hotend.
Okay I was wrong the mesh kompensation was active I did another print and saw that it was active but I think I found the problem why it was on and will test this in round about 30 min and send you the update
this should be 0.98NM
Oh okay good to know thank you
Thank you
This was without mesh and Kompensation maybe there is a little hoppings but don’t know safe what do you think (every picture is a different print)
Will make tomorrow morning more tests with a preheated chamber (maybe on the pictures the x gantry was getting warmer and that’s the difference between the pictures)
I think you have a z-stepper issue. Possibly a loose connection in the wiring or maybe even a bad motor (although that is pretty uncommon).
Yes maybe I will measure the wiring today
Hi I made a new test to figure out what is defect
I make a z tilt and then a mesh after the mesh I drive the z axis up down up down a few times and do a mesh again without z tilt to see if anything changes because only with up and down and don’t do anything else the z should stay stable.
So after doing this some times I can see in the mesh that it variates first mesh was min -0.172 and the max 0.054 the 6th was min -0.110 and my 0,107.
So it variates the min and max but the only thing I did was to drive the z achxis up and down
What do you think now ? Are the z motors defect or are there anything else ?
These seem pretty good, at least compared to some you got earlier. It would seem like there is more fluctuation at one corner in each of the samples. Is that the corner where the printing starts from?
This was on the complete bed the mesh
So in the right back and left back it’s the different
Not sure if I understood 🙂
Ah Sorry I thought it was something different
It started on the right side
And if I make a mesh after the print then the left corner is higher
There is definitely an issue in your Z system yes.
Ok. And the result would seem to be that if you do not use mesh compensation, the result is pretty smooth. But if you add compensation, there are more or these sudden changes
that's a 500 50 micron difference in the min, that's a lot.
50um, i think..?
yeah you're right, zeroes are hard 😂
Yes I think so too have ordered new z motors and then I will see the results, I really hope it’s getting better.
What does probe_accuracy show?
I'd run
PROBE_ACCURACY SAMPLE_RETRACT_DIST=50 near each lead screw. Like use the z-tilt coordinates.Okay will test now
That's the rear z-motor (stepper_z1), looks fine, you can rule that one out.
Front left, also looks good.
Front left you mean ?
yeah corrected it 😂
Ah haha yeah😁
Here is front right
Again front right
could be a unconsistent filament diameter too.
Tested multiple filaments and measured them
what happens if u move the first layer test to another part of the printbed? Same result? if yes then i expect its somehow gcode related.
Don’t test it now
But the weird thing is the sound the z motors are make
Don’t know if I send it here so here is it
And this sound makes all 3 z motors
did u use grease for the Z spindles?
Yes
The sound is only while printing the first layer
After this they sounds normal
yeah that sounds horrible wrong
If I make manual 100mm down then they are normal
what grease or oil did u use? POM friendly?
This one
seems good
do u feel any vibrations while your Z achsis making those sounds?
If I take my fingers on the couplers from z motors to spindles yes the same Frequenz as the wired sound
But if I put my fingers on the motor itself then it’s minimal
thats your problem, i think you should check your POM threaded guides on the vibrating Zs
it looks to me as if they are worn, have tolerances or are simply a production fault.
And why is the sound only there in the first layer
Can you explain this ?
I will check these
adaptive bedmeshing makes the bed moving alot up and down during first layer to compensate for height differences in the print bed.It's just a guess, of course I can't say for sure that this is the reason. 3d printers are sometimes just bitches 😉
Oh yes they are all time bitches 😂
the range here is concerning
17 micron drift on 10 probes is a problem.
Is this normal ?
That slack is normal, but the variance 17um is not. It seems like something there occasionally binds. Time to reassemble that z arm 🙂
Will reassemble all 3 now
thats not normal... i have zero tolerance there
And this ?
There is little bit of wiggle room
are u hitting the Z motor axsis with the Z spindel? through the coupler? is the coupler screw too loose?
No
They are tight
Really thought
Thgiht
Tight
😂
The spindles don’t move
when you grab the spindle and try to move it up and down, the noise like in your video doesn't come out, does it?
ok i see...
No can’t move it up and down
then it can only be the POM bearings imo
I can wiggle it a little bit left and right but don’t up and down
have u checked those Bi-Material Lead Screw Decouplers too? Those things the pom lead screw is screwed on?
What can I check there ? If I can move them up and down ?
if they have up and down tolerances
its unlikely but who knows 😛
check if they are screwd to the printed part tight and cant wobble up and down
same for the pom part
if thats all ok
That is interesting. I assume you are fading the mesh compensation within the default height, which I believe is 10mm?
Yes I don’t change there anything
i would try to change the lead screws... and see if the problem is gone
Leadscrew Nut - POM - TR8*4
Leadscrew Nut - POM - for TR8*4 mm lead screws
there is no other way i can explain the rattling of the spindle.
especially because I don't have that and my guides are completely stable without any play.
Now why would it only do these on the first layer..? I would be tempted to test this by placing the bed ”sloppily” on the arms so that the first layer would correspond to a different place on the z-spindles. Could there be some dirt/residue on that spot in the spindles?
No dirt or anything else
id make a sound record of mine if my headbead thermal fuse hadn't tripped for no reason yesterday at 80C...
Oh shit 😐
Do you know what is the difference between tr8x8 and tr8x4 leadscrew nuts
i highly expect this problem to exist in every of his layers... but its only heavy visible in the first
There is a little play
if the z spindle tries to screw down the bed but the motion does not reach the bed due to tolerances in the lead screw... yeah thats a very possible explanation for poor first layer imo.
What do you mean sorry don’t understand
movements of the z-axis arrive at your print bed “delayed” due to the play of the lead screw.
i think thats why your first layer is bad and your probe results are inconsistent
I will change these and have a look
yes, it's stupid that you have to wait for parts again... but that's the way it is sometimes. But I very much think that your problems will be gone afterwards. If they still exist, it's because of the Z spindle ... but I would rule that out for now.
your grease shouldnt be the cause of all this according to this:
https://www.super-lube.com/Content/Images/uploaded/documents/Compatability%20Charts/Super%20Lube%20Compatability%20Chart%20for%20both%20Polymers%20and%20Elastomers.pdf
Yes this grease was recommend from a 3d manufacturer so I think this should be good
yeah
Do you know what is the difference between tr8x8 and tr8x4 leadscrew nuts
the first number is the diameter and the second is the lead ("pitch of the threads")
Ah thank you can you speak German ?
im german yes
Haha perfekt ich auch
-.-
😂😂😂
Und ich quäle mich hier mit dem Englisch 😁
naja macht schon sinn, viele können hier im dc kein deutsch 🙂
Ja das stimmt
aber ich denke es ist auch alles gesagt.
tausch die pom lager und dann gehe ich stark davon aus das alles gut wird
Ja meinst du die gibt’s in irgendeinem Laden zu kaufen
die lager sind nicht unüblich im 3d druck
sollte man online schon bekommen
bei ratrig selber
oder hier z.B.
Princore GmbH
Trapezgewindemutter TR8 POM (Steigung 2/4/8mm)
POM Trapezgewindemutter Trapezgewindemuttern (Flanschmuttern) aus dem Werkstoff POM. Verwendbar für 3D Drucker mit Trapezgewindespindeln (Durchmesser Trapezgewindespindel 8mm / Steigung 4mm). Die Verwendung von POM (Polyoxymethylen) als Werkstoff für Trapezgewindemuttern verhindert, dass das Druckbett durch sein Eige
Ja habe sie bei Amazon jetzt bestellt sind morgen da
bei amazon bestimmt grausam überteuert... das son typischer china dropshipping artikel befürchte ich
That slack should not really be a problem. The accuracy of the z system does not depend on the pom being slack-free in that direction. As long as the gravity pulls the system down consistently, you should be good to go.
Ah okay so you have another idea what causes this problem
Not really. Just saying that that the slack is not unexpected, and a system with slack can work quite repeatably. In cases where the slack ( or the lack of it) is important is when something in the system prevents gravity from pulling the bed to the correct height. One item to check would be the amount of grease you have on the lead screw. It might (speculating here) be that you have too much of it, so that it forms a “thick” bed between the pom and the screw, which then prevents gravity from pulling the pom down to touch the screw. As a test, you could wipe most/all of the grease away and see the probe_accuracy results again.
You should excpect to see a sub-micron standard deviation for 10 probes, something you see with the other leadscrews.
I don’t have much grease on it
Maybe a dumb question but the z linear rails can’t be the problem or ?
Sure they could. Why would they not be a potential candidate?
If they bind or do not move freely then they quite well could cause z-height issues
Could the linear rails be tightened with too much torque? This could lead to deformation of the rail. I seem to remember that something like this was mentioned in the instructions.
Okay yeah but they seam to be okay they move freely and are straight measured with a hair Ruler
You want it to have a bit of wiggle room. Gravity takes care of any backlash anyway.
Okay now the only thing that can be the problem now are:
- the motors
- the leadscrew
- the Controller (octopus maybe a defect 🤷🏽)
(the cables are okay I measured them )
- I can’t rule out a defect on the beacon 100%
I think only these are the possibilities 🤔
you can rule out the octopus, you'd be getting errors if that didn't do what's expected (it's just relaying steps to the driver with specific timing).
I'm suspecting a motor issue
Did you check the cables?
I would think the motor, the screws, the pom nut, the oldham couplers, the rail carriage.
possibly just a loose terminal or something.
Does it give any errors if the steppers don’t work well ?
to a degree, but only in terms of under/overvoltage and shorts.
Hmm okay so maybe there have an defect (I am only writing the possibilities to cross every out which I have checked)
What do you mean with rail carriage ?
Could this cause some problem if one side is not going like butter ?
The linear rail/ carriage combination. I do not think we can rule anything out just by trying how smooth it seems to be moving, or what it looks like. The issue could manifest itself only in specific conditions, and the changes you see are very small, just a few tens of microns, so it might not be possible to detect them easily. But the good thing is that you seem to have a way to easily introde the error situation (probe_accuracy), which should help in determining what affects the behaviour. And since you have two points/screws that work ok, you can systematically change the components and see which components the error follows.
But isn’t this one okay ? And it was just Coincidence that the first have 0,017 different ?
Ok, i did not take it as a coincidence, I thought that was the indication that that specific point was the problematic one. If you cannot reproduce the error then it gets to be a bit more problematic.
Yes that is the problem I cannot reproduce the error
Hmm.. then it is a problem. But anyway, getting a variation of 17u can hardly be considered normal or just noise, it is abt 10 times the expected variance.
Yeah the next step is to change the motors and the leadscrew
The post says it comes tomorrow
Fwiw, i cleaned my screws and removed almost all grease in my vc3.1 when I had z accuracy issues. It seemed to help, but then again I was not very methodological about it and did not write the results down, so take it with a grain of salt. It might have been something else as well. But just be aware that using grease in the z screws is a bit controversial as it increases the risk of dust getting trapped in the bearings.
Yeah will test this too thank you
So after changing the motors cleaning the z spindles , the Pom nuts and the oldham couplers the weird sound is still there and the result is also the same
You can see it here the difference
There certainly is an issue, but now looking at the first layer it seems like it does not have the sudden up/down changes in the pattern that were visible earlier. Is it just the picture, or would you say the same?
Yes I think the same
And if I slow down to 30mms for the first layer it is better
Not good but better I think
Perhaps. If the speed affect this, then it could also be an issue in extrusion not keeping up. What happens if you leave out the bowden, and just support the filament manually? But then again, the difference could be because of a different starting height. One thing to try is increasing the hotend soak time? But anyway, the pattern looks cleaner now, even with the drift
I had feed the filament directly but no changes
What time do you think ?
10 min ?
That should be plenty
I don’t think this is the reason because on the beginning you can see there is the same issue
Here
In this video you can see the nozzle should be the same it’s only seconds different between right and left but you can see left is too close and right too far away
You are absolutely right
That is not because of thermal expansion
I have tested with space here too now I can say that not the bearings are the problem
Just as a test, what happens if you change the infill direction from 45 to 135, so that the printing starts at the opposite corner?
Will test it now
That might not be healthy for a long-time use, as now the weight of the bed is directly on the motor bearings. But probably a good troubleshooting step
Yes will change it after this print
Same result left is too close and right to far away
Ok, good. This would suggest that the height compensation map is not correct or is not getting applied correctly.
But why that would be the case is a mystery
It’s like the map left too close right to far away
Are the z motors turning during print? I mean that you disabled height map at one point, but probably turned it back again?
Yes
They are turning
Yea.. this is interesting. Do you use tilt compensation?
Tilt compensation ?
The beacon tilt measurement and the corresponding compensation. Forgetting the correct term 🙂
This is the only thing I have changed between the standard
Ah do you mean beacon scan compensation
Yes, that is the one
Yes tested with and without
No changes
And the beacon ratos calibrate says that I don’t need the scan compensation
Ok, this should be good then. Just wondering, an extremely long and improbable shot, but can you somehow make the ”default” and ”ratos” profiles to be the same, or essentially the same? To see whether the printer is now applying the ”ratos” map when it should be applying the ”default” map. Highly unlikely..
I can delete every map
So then there is only the ratos map
Or how do you mean to make them the same ?
You could copy a section in the printer.cfg and name it ”default”
The height maps are at the end of that file
Yes have copied the ratos to default
But now if I start the print it will make a new ratos
Yes. But it should be close to what you have now as the ”default”
Both should have roughly the same variance etc
Okay then I will make now a mesh
Okay then I will delete every mesh and do a new and directly after I will start the print then it should be the same
Yes, that should do it
There is a big difference but I only made the map -> save config -> start print
Hmm.. do they look like they have the same general shape?
Yes
Same result in the print
Yea, it was not a very probable fix. But this is now quite a challenge. What if you print on different spot on the bed? Sorry, I do not have any real idea what could cause this, so this is just throwing things on the table
Don’t test this till now will do it now
Okay I really think the mesh doesn’t work good
If I print in an area where the mesh is the same ( in the middle)
It looks good from the beginning till the end
Quite strange. It would be interesting to debug the commanded z shift/steps at some of the locations and compare those to the values in the height map. Unfortunately I don’t know how to do that. Anyone?
So it looks like the problem is that the mesh doesn’t compensate enough and that is the problem
(To knew the problem is a big step for me 😁)
@miklschmidt maybe you know why ?
If you follow the ”live view” on mainsail while printing, it should show the adjusted height. Does that coincide with the values in the height map?
Will test it now don’t know that before
Where do you mean ?
In the left side the mesh is to close and on the print it is too close on the left side
If it was overcompensating then it should there be too far away or not ?
Ah yeah you're right, i didn't read it right (the axis labels are missing so it's difficult to tell 😄 )
Yes sorry
So you don’t think it is a software problem ?
So you don’t think it is a software problem ?
If it was, everyone running klipper would have bed mesh issues
we're all running the same software
How can I make the mesh closer to the bed ?
@03Julian04 Try this:
How can I make the mesh closer to the bed ?
i don't know what you mean
The mesh is generating with 5mm distance ?
So from these 5mm to 0mm (so the nozzle can print) must be the problem that the mesh is changing so it can’t compensate
So if the mesh is generating with only 1mm distance it should be better
MAYBE 😁
I'm not following the logic here.
If the software was okay
horizontal_move_z is 2mm. The mesh is scanned with the nozzle at z=2.
If the software was okay then it is mechanical
If the software was okay then it is mechanical so if I make a mesh at 2 mm and then it starts to print at 0,2mm then at the distance from 2 to 0,2 must be changed something that the mesh ist right
You know what I mean 😁
I was looking at your screenshots, and you seem to have an applied z offset of just below 2mm. If the bed mesh module looks at adjusted z and not requested z to apply the fade, that means you'd be in the default fading interval (from 1mm to 10mm), so that's why i suggested you changed that.
That's one thing we didn't think about when adding the hotend expansion compensation.
How would the z height change the shape of the bed?
Okay forgot this 😁it was just a quick Thought
In the toolhead section, just above the Z box
I have no z changes or?
The gcode would not know anything about them
This is internal to klipper
Ah okay and how can I see then z ?
The mainsail display, toolhead section, the number above the z box
Ahh there you mean
No changes
Oh men this makes me crazy 🤮🤮🤮
How does hotend compensation affect the heightmap? I would think that you first calculate an offset, but then keep that fixed offset and not recalc when the commanded z changes. Is that how it works?
It doesn't affect the height map, it's just a z offset
literally the same as babystepping
SET_GCODE_OFFSET Z=result
and yes it's static
What i meant is, if the offset ends up being z=2, then you're within the bed mesh fade range (default is 1 to 10)
causing the bed mesh z adjustment to be reduced by a factor of however far you are between 1-10.
1 = 0, 10 = 1 (no more mesh adjustment)So in this case the potential would have been a 10% reduction
But that did not seem to be the cause :/
yeah it's too tiny to make sense, grasping at straws at this point.
Now I made a video from x y and z and now I will compare it with the mesh
Good! I was going to suggest streaming the data from klipper API, but a video would probably be the faster way 🙂
You should probably file this down to fit better, but this wouldn't affect Z height (so no rush).
Okay I did a little grease on it and now it’s like butter
that works too (even though people may scream at you because POM is self-lubricating 😂)
From the left side
The strange thing is that the first point is 0,035 but z was on 0,249
the bed mesh adjustment is added on top of your z-offset.
If bed mesh is +0,035 and your z-offset is 1, it results in an actual z offset of 1,035.
Where is the z offset saved ?
So I can have a look which offset I have
The z offset is set based on your hotend thermal compensation. The actual offset from beacon trigger point to nozzle is baked into the beacon model, and thus not visible to the system during runtime.
Ah okay
~0,2mm seems normal for hotend thermal expansion at print temp.
Now I ask myself
On one point I have 0.191 real z and the mesh said -0,012
Then the z must be 0.188 or not ?
If by "real z" you mean whatever is in the mainsail box for Z, that is actually "requested Z", ie whatever your slicer has output.
Yes that is what I mean
so i'm assuming you're using a layer height of 0.2mm?
Yes
That means 0.2 = 0.191 - bed_mesh[x][y] - runtime z_offset
if your gcode actually says Z0.2
Okay so if bed mesh is -0.012
0.2 = 0.191 - 0.012 - runtime z_offset
And the runtime z offset is what I can’t see or ?
You can, it's in the square brackets above the box (it includes all adjustments, z_offset, bed_mesh, axis_twist adjust, z_thermal_adjust etc etc)
If you run
GET_POSITION it'll show you the positionsOkay I don’t know what I can do else
Wait what? Your gcode would be requestinh a z of 0.91? I’d think it should be 0
0.2 for printing the first layer, if first layer height is 0.2
Yea, sorry, meant constant, not zero
Is it possible the beacon is defect I mean this is the last thing I can image
That the beacon measures the distance false
true, the requested Z should be constant during the same layer
No, then the calibration would fail
You can also consider doing the bed mesh by beacon contact. Slow but avoids a few errors
worth trying
Okay how can I try this
If that helps, the beacon scan compensation is the only way to fix this issue, but that would mean your flex plate is all out of whack.
sec, let me find the right variable
This one ?
yes
Set that to True
Okay
then your bed mesh will use contact instead of scan
Do I have to set the scan to off ?
contact_bed_mesh: True, means it' will use contact for the bed mesh.
It is waaaay better
In the left corner I have changed that offset and then it’s from left to right really good will make a new test now with the same z offset
Interesting. In that case scan_compensation would solve your problem as well.
The issue must come from the flex plate.
I have one here with 360x360 can I use this ? How can I set the z tilt to the point of the plate
Strange. I would think the beacon calibration took care of this, since the height map seems to be rather slowly sloping. Have you tried turning the flex plate 90 degrees?
No, because I can’t explain why that is
Can you explain that to me again @miklschmidt
Change the z tilt points, klipper docs has the params to change. But be careful, the print blob might be an issue if you do not change the bed dimensions
But I will print a second test let’s see how this comes out
Ah right I can place there another plate 180x180 I have also 😁
This is good way to confirm or deny if it's the flex plate.
You don't need to change the z tilt points
Unless it's smaller than your bed of course
😅
The problem is that these hotrolled springsteel plates have a tendency to cool unevenly when they're produced, so you get awful variance in the thickness of the metal, which affects the eddy current induced by the beacon and thus fucks up the reading.
Same issue if the coating is different thickness across the plate
Yes my bed is 500 and the plate only 360x360 😁
Yea, i guess I was jus assuming that those differences would be a bit more ”sudden”, but now thinking about it, i guess the change can be very slow as well
Ah okay Crazy don’t think about this
Scan compensation is very good at compensating for this, provided you give it enough points
Yeah it’s kind of unpredictable, the ones i’ve seen looks a bit like wrinkles in a piece of cloth. Like this
And the coating on top makes it mostly flat. Enter eddy current confusion 😅
I kinda miss my euclid
I think the beacon is miles better (and faster), but it does require different forms of compensation to deal with unoptimal situations like this.
That said i do like my euclid as well
Beacon+contact has many undeniable advantages, but being high-tech need you to understand & learn quite a bit of new stuff. I’m still trying to understand the polynomial fitting they do for the model 🙂
But that is not the main point now. So it is either another build plate or scan compensation. I might go directly to compensation. After checking the 90degree turn.
What is the meaning of Euclid
It is a zprobe based on a mechanical microswitch
Very little temp drift, repeatability of a few microns
But it can’t measure head/gantry twist 🙂
Ah okay
0,08 with the other plate
(With scan )
Before it was 0.240
Now the z offset is false but it is everywhere the exact same high or Depth
I think that was the problem
Should I create the beacon_scan_compensation with the bed turned 90 degrees or normal ? @miklschmidt @mazas
In normal position
Ah okay then I hope this will help because last time I did this it doesn’t helped
Which plate will be better ? The Prusa xl plate has the same problem it only works with beacon contact mesh
The one that shows the least such variation that follows the turn
So this one wich is the same if I turn it 90 degrees ? Do I understand right ?
Yes. Although if ther is no change when you turn the plate, I am not sure how much compensation will help, as then it is not obvious that there is something to compensate. But there still can be.
Yes because on my plate if I turn it I can’t see anything but as we can see there must be anything but yes I will give it a second try
How many points do you recommend?
And a very very big thank you to you @mazas and @miklschmidt without you I think the printer were on the rubbish 😂
Well, it is not fixed yet 🙂 But I am not sure about the raster needed. Typically more is better, but I have just used the RatOS defaults. I guess it depends on how steep/sudden the changes on the bed are.
Yes but I think we are getting closer
So now another problem
These are two different prints and if I adjust the z offset
Then it looks like this
But when I do save_z_offset and after the print the save config
And restart the print then it is roundabout the exactly same distance
But if I adjust the z offset again I can see that it is the same height after the last print
So now the question is, does the beacon_contact_mesh or another beacon feature overwrites the z offset
Maybe one of these two ?
those are only applied when printing the primeblob
You should probably redo the hotend thermal compensation calibration
You can see the multiplier in the
ratos_variables.cfg file, that's what changes when you run SAVE_Z_OFFSET except if the multiplier is going to go into the negative or otherwise invalid.
From what i can tell your multiplier is too low.
It'll print what it does when you run SAVE_Z_OFFSET if you enable debugging: ENABLE_DEBUGWhere should I enable enable_debug ?
How can I reset the z offset to zero so I can start from beginning
It is not too low it is really high 0.41
But even if I set it up to 0.6 the print looks the same
Same like the offset with 0.4
Here it is with 0.6 z offset
Type it into the console
This is the issue, i would redo the calibration
Okay then first set z offset to zero and then do the beacon calibration again ?
Doesn’t matter they will be overwritten
Ah okay so I only have to make the beacon ratos calibration ?
Yeah just do the inital calibration and the hotend thermal expansion calibration
Can I do the complete beacon ratos calibration in Auto Modus or should I do it manually ?
(Have you read what I have written in the ratos developer group ? Should this solve the problem or)
You only need to do 2 of the steps, initial calibration (to recalibrate the model) and hotend expansion calibration (to fix your borked multiplier after multiple bad adjustments)
Okay and why does he take the z offset and Added it to the mesh ?
Here is it
Right, so now try a print again, before you start the print, run DEBUG_ENABLE, then do your z offset adjustments (it should output a debug line each time you do that) showing you the new multiplier as well as bunch of other information. When you're done adjusting run
SAVE_Z_OFFSET this will output a bunch of stuff again.
Either copy paste the entirety of the console here, or send me the klippy.log afterwards.
given that you multiplier is 0.47 and it's too close to the bed, it should increase the multiplier when you run baby step.Before this should I do the re calibration of beacon ?
no we'll do that if everything else fails
I'm curious what's going on right now, because you should not be saving the offset to the model
Okay
Have you disabled the hotend thermal expansion compensation?
good
Aight, enable debugging and baby step, let's see what happens
Okay will do this in 15 min round about
Actually because you've baked so much offset into the beacon model you may want to redo that first.. (sorry for the back and forth here)
Okay than I do now the first calibration again
Your model isn't valid anymore. To clarify:
1) Run
BEACON_INITIAL_CALIBRATION
2) ENABLE_DEBUG
3) Start a print
4) Baby step until layer is good
5) SAVE_Z_OFFSET
6) Download klippy.log and post it here
only BEACON_INITIAL_CALIBRATIONCould i please get the raw log?
why did you convert it to a pdf?
it's impossible to work with
Sorry 😁
You have disabled contact calibration
That's why your offset isn't getting adjusted
Somewhere you have
variable_beacon_contact_z_calibration: False
That also means you're never zeroing relative to your nozzle
So you're always relying on scan
no wonder you're having issues 😅Oh okay I thought I don’t need it if I set the offset manually
You have completely disabled contact.
My best advice to you is to delete all your overrides in printer.cfg, rerun the entire BEACON_RATOS_CALIBRATION
Then add:
And run
BEACON_CREATE_SCAN_COMPENSATION_MESH BED_TEMP=85 CHAMBER_TEMP=45 PROFILE=Contact to create a new contact mesh.
leave this
delete all of that
So these two thing delete ? And then that what you told
Don't delete the first part
(it will be overwritten during calibration)
Okay
How many points do you recommend for the beacon scan compensation ?
@miklschmidt so after I am doing all what you say I am at the beginning left it is okay and right it is too far away don’t know why ( the beacon calibrate mesh is activ)
Is it possible that my beacon scan is defect ? Because now I am using the contact again and now it looks good
This was with beacon contact mesh
This looks good to me?
But the holes on the right top
Which you can see on the second picture
Did you set up the scan compensation?
Ah you mean this no not really on left front it is much way to far away
Yes
This is too inconsistent to be a mesh issue imo…
Here it was enabled
What’s in the picture looks perfectly usable to me
Wait
Yeah. I’m not sure what more you want here.
This is left front
You see it is too far away
This is with beacon contact mesh and this is okay for me to use it
Or underextruded.. i see it on the close up, i also notice what looks like a difference in extrusion temp. Quite drastic too.
This one is both under and overextruded within a couple of centimeters in the top and it’s always diagonal… i’m starting to suspect your hotend / extruder.
Here it is good (the same picture as this)
Hmm but what can be the issue ? The filament is feeded directly into the extruder
That could be one
Too much tension, poor thermistor connection etc
Can i see your temp graph during one of those prints?
Can I only see the 20min from before or is there a way to see more ?
Mainsail limits it
btw what filament are you using for these tests?
Abs
I was hoping you’d be more specific than that
Sorry haha
Standard ABS from CR3D
Sorry don’t found it
I was trying to say “no” 😅
Ah okay haha
Then I will do a print now and send it
Here it is 😊
@miklschmidt how can I make a beacon contact mesh kompensation for a 360x360 plate ? So how can I say where to start and where to end the contact mesh kompensation ?
That seems quite erratic, but stable… just to be sure, PID tune both the hotend and the bed.
You need to change your [bed_mesh] parameters
A quick question
Where can I set the probe counts to less than 15,15
Okay what do you recommend
In bed mesh
I recommend you find out what your new min/max is for x and y.
What do you mean
Where is bed mesh ?
Just write a [bed_mesh] section in printer.cfg. See the klipper documentation for the parameters.
Yes found it thank you 👍
Here is another test same result with beacon contact
It's really odd that all your issues change along a diagonal move.
Looks like huge temp fluctuations too.
Okay I will do an pid calibration of the horned
Hotels
Hotend
Seems a little odd that you're printing at 275C..
Why ?
Regular ABS is usually printed around 250-260
Yes but at more speed I print with this
I print with 275 on my Prusa xl and on my Bambu
CR3D recommends 255-265
This is a bad idea..
I have also made an temp tower
If you have to raise temp to extrude faster, that means you're at your hotends limits and you'll get inconsistent results with varying speed as you'll either cook your filament or under extrude.
But yeah I will try with 260 degrees
I will try everything
😁
Aight i just want to reign things in to normal ranges here
It's a really bad idea starting to employ hacks for "printing fast" before even being able to lay down a first layer.
Yes of course I print now with 260 degrees
Yeah you are right
Same bad result with 260
I’m really getting desperate 😁
At which speed should I print the first layer ? @miklschmidt or @mazas
Try 50.
I have read something about problems with the smart sensor for the orbiter extruder
Can the smart sensor cause this problem ? (I have one installed)
Another question can someone tell me how to heat the nozzle to 200 degrees before a mesh, then it should go where the „cleaning brushes“ are and drive back and forth a few times and reduce the temperature to 150 degrees in the meantime
(So the nozzle is always clean for the beacon contact mesh)
Wie mache ich das am besten ?😬😊
I can't see how it would
You can override
_USER_START_PRINT_AFTER_HEATING_BED
If you want to do it after preheating the nozzle, override _USER_START_PRINT_BED_MESH instead.Ah okay where can I found those ? To know what is there at the moment
Okay good
I read something because more resistance on the filament
You don't find things, you write them in printer.cfg
Ie, to override the
_USER_START_PRINT_BED_MESH hook, you add the following to printer.cfg:
Ah so this is what he does before it start the print bed mesh
All _USER prefixed macros are empty by default, they're for you, the user.
The internal logic that is executed before the bed mesh is in
_START_PRINT_BED_MESH. That stuff will still be untouched.Ah okay good to know
Okay nice thank you
👍
Is there a code in the idex printer for cleaning the nozzle ? (What I can copy maybe 😁)
There's some documentation on that here btw (applies to 2.1 too): https://os.ratrig.com/docs/configuration/macros
Configuring RatOS Macros | RatOS
RatOS comes with a bunch of flexible predefined macro's that can be customized via variables and macro hooks.
Perfect thank you
specifically about user hooks: https://os.ratrig.com/docs/configuration/macros#user-macro-hooks
Configuring RatOS Macros | RatOS
RatOS comes with a bunch of flexible predefined macro's that can be customized via variables and macro hooks.
Yes but it uses the ooze guards. Search the repository for
_CLEANING_MOVErepository ? Where can I found this or what is this 😬 sorry for the question
the contents of the
RatOS directory is a repository. Specifically: https://github.com/Rat-OS/RatOS-configurationGitHub
GitHub - Rat-OS/RatOS-configuration: The RatOS modular klipper conf...
The RatOS modular klipper configuration. Contribute to Rat-OS/RatOS-configuration development by creating an account on GitHub.
Ah okay thank you
Do you know By heart in which file I found this ?
search says
load_filament.cfgWe are. There are dozens of ppl on here having the same ripple effect on their first layer. It was not always there. It happened after a klipper update a few weeks ago.
I am still having the exact same issue and it's happening on two entirely different printers out of nowhere. My VCore 4 and my troodon 2.0 both suddenly have this ripple effect. My troodon has had absolutely perfect first layers for months. My VCore was fine too and now both suck. The only commonality between them is klipper.
You can hear the nozzle grinding against the plate on both machines.
Ok so here are two samples - 2 different machines running klipper. The black is VCore 4 with pla and the Grey is punkfil petg on a troodon(voron clone). Same ripple effect.
This my print on the ratrig after that bad first layer. The top surface is perfect despite the bottom layer not being perfect. Same thing happens on the troodon.
Sorry here is the vcore photo of the first layer
Ok it's defintely related to z offset
I just started a new one with arch pattern instead of mono and same thing but then i noticed z offsetr was set to 0!. I ramped it to 0.220 and its way better now.
So it would appear the z offset was reset/or not being saved...maybe after that klipper update?
Of course that grinding noise was my real tipoff, I just couldnt fathom how it changed out of nowhere.
Ran BEACON_RATOS_CALIBRATE over again and the 1st layer test afterwards came out pretty much on point without much adjustment needed.
Yes in my case the beacon scan function doesn’t work
I have made an beacon contact mesh compensation but it still doesn’t work.
This may have been said already but when you followed the commissioning guide and did step 1 and 2 - then typed in save_config and then did Step 3 Z offset Beacon- did you adjust the offset while printing the sample and then type in Save_Z-Offset WHILE it was STILL printing?
Yes
And after the print I type in save_config
And now with beacon contact mesh it is way better
And the only thing I changed is from scan to contact mesh
maybe your scanner is tweaked
What do you mean ?
The board that does the scanning
the beacon
Yes what do you mean with tweaked ?
Sorry my English is not the best😁
Sorry that means broken
or out of specification
Ah yes this is what I think
But if Contact works then i dunno
Maybe only the scan function
Because if I use contact it works but the scan not no matter what I do
How good is the print when you use contact?
is it still like the last pic you posted?
I am still testing but this was the last result yesterday
looks good
Was alot of effort to get to that though
Here is it a little bit too far away but maybe there was the nozzle dirty which is gone in the second round
Oh yes because I searched for z problems and something like this instead of the beacon problem
Indeed
Here is a 400x400 and the only problem is the left back corner
Mesh was did with the beacon contact
Is there something like a while loop or do I have to make it with a if else ?
That back corner could be the extruder skipping steps. Open the door on the front and print a layer test only in that corner. Listen to the extruder and see if it is skipping and also watch the spool and see if it is moving. You could have some binding of the filament path when the toolhead moves that close to where the filament tubing enters the chamber.
To avoid this I printed this with feeding directly to the hotend from the spool so there can’t be a sticking filament
And you did the full plate like that?
Does your mesh show the plate is low or high in that corner ?
Yes the full plate
Don’t know now because I don’t safe the mesh but will try again later and then I will look and post it here
That is my mesh now ( have changed the foots of the printer so on the last print it looks different)
And a foto of the print I will post later
The mesh range ain't too bad. Have you checked under the plate and inspected the magnetic sheet for debris ?
Yes there is nothing
Either way the printer should compensate for all this. But if for some reason it cannot then try washing the plate with dish soap and hot water as usual but lightly scuff the entire plate with steel wool. The objective here is to remove any high spots that have been caused by all this troubleshooting and nozzle possibly digging into the plate.
Then mesh it again
This was the new mesh
I will test it
FYI: I have had the same issue as 03Julian04, and have learned a lot from this thread and have improved my prints 100% by following your advice about putting "[gcode_macro RatOS]
variable_beacon_scan_compensation_enable: True " in printer.cfg. But I never personally did anything with that previous macro code because of this:
This is how it looks right now with t this mesh
The reason i don't think this has anything to do with a mesh issue is because your artifacts follow the print direction. A few lines with problems and then the next line is completely clean. There's something going on with your extrusion rate.
You can also tell by the irregularities in the lines, they all have a different sheen.. Something is up with your hotend / extruder.
@03Julian04 could you post a debug zip (download it from the sidebar in the configurator)?
If this was actually a mesh issue there is no way in hell you could have a completely clean diagonal line right next to a rippling one.
Yes of course
Here is a picture of how I feed in the extruder 😁 so there can’t block anything if this is the reason then it must be on the extruder or nozzle
I have the problem it won’t download more then 7,4MB then it is loading with no end (until now)
Yeah you could be right
But have a look to the mesh on this corner
Here is much up and down
And I only made a 15,15 mesh so maybe my plate is so „bad“ that actually these points gets to high or the nozzle to low but the mesh didn’t recognise these points
I will order a new bed and will test it with this can you recommend one ? Does the beacon also works with an FR4 Plate ?
But yeah the other point is after reducing the speed from 100 to 60 for the first Layer it is getting way better
(The only thing i did since beginning that helps, was to made the mesh by contact and reduce the speed to 60-50)
It stops with an error twice
Is there a way to test the extruder ? Or / and nozzle ?
Maybe with measuring so I make 30 bloobs and measure the weight and they should all have the same weight
Man this looks odd.. It seems to follow the same diagonal pattern.
Or at least a similar diagonal pattern.. It's actually the opposite direction relative to your print artifacts.
Are you on the latest version of the RatOS configurator?
Yes
Might be your klippy.log is huge.
I actualise it yesterday
then try again
Okay
Instead of ratos I use my printer name I think or ?
Will do this tomorrow morning
yes indeed
I've pushed a fix for the configurator, shouldn't be necessary to truncate, just update the configurator through the mainsail machine tab (make sure to refresh the update manager to check for updates), and the debug zip link should work.
Feeding without a bowden will cause more variation for the friction of the in-fed filament. It will also cause x-gantry twist, and especially variation of that twist. A bowden tube that is fixed at both ends (at the extruder and at the filament roll end) will prevent the head movement from yanking out the filament, and will force the extruder to do the pulling, making the filament unrolling speed more consistent, and reducing the twist tendencies. Also, without the tube the angle of entry of the filament into the extruder varies, which changes the friction and might cause binding-like behavior. So, for production a bowden would be good, but I do not think it is an issue here, as I understand you are hand-feeding. But if you want to be sure, add a bowden and fix it at both ends.
And check that filament tightening screw is not too long. I had an issue with my unit, which caused the first layer to to be extremely uneven. The root cause was that the screw was too long, and the spring dis not compress enough. In the photo you see the difference in length of good (short) vs faulty (long)
The fix was to add a few washers. The length of the shaft in the faulty one is 22.8mm. The good one is in use right now, so I do not know the correct dimension
The ”correct” length seems to be 20.9
Ah okay thank you will check this
Perfect 👌
Nice now it is working
Here is the file
Yes mine is 20.9 too
Are we supposed to tighten these until they bottom out?
no
tighten them until the extruder grabs the filament and not much more than that.
tightening it harder will decrease effective flow rate since it's using more force squeezing the filament through the gears, tightenening it less will make it slip. It's tunable like everything else.
Did you had time to look at my ratos-debug.zip if there is anything wrong or false ?
nothing out of the ordinary i'm afraid
Oh okay do you think a new print plate could solve this ? I mean this will cost round about 200€ but if this could solve the problem I will give it a try
I don't think it's related to the bed at all
It looks like an extrusion or x/y issue causing toolhead tilt to me depending on motion.
But a tilt means there must be anything loose
it's quite obvious from this result that it has nothing to do with the shape of the bed or meshing or compensation or anything like that.
And I mean I checked everything multiple times
or something pulling on the toolhead
binding in the rails etc
something
Hmm but if so then it should be in the complete x side or y side or not
So it must be on the complete back or left but it is only on the back
And if it was the rails then it must be like the white signed one because it doesn’t matter if the head is on X : 10 or X:380 if the y rails have a problem the same on y
If x have a problem then it doesn’t matter if it is on y:10 or y:300
Am I thinking right ?
this very well could be part of your problem. You want reverse bowden.
I don’t think so because 70% of the tests here were made with the tube
I changed it for the 4 or 5 last Prints to test if this could be a problem
Just making sure: a tube that was fixed at both ends?
No not directly but then I think it must be more random and not all in one corner or ?
(But yeah I will test it with both ends fixed)
It would be somewhat random, but not totally. I once had a printer (an IDEX) where there were z issues at two corners, and it took me a while to realize that it was caused by the drag on the umbilicals. But with a filament it would indeed be a bit more random.
And of course the bowden does not have to be fixed at the very end, it is enough that it is fixed (relative to frame) somewhere along its path. This assuming that the filament roll does not move around 🙂
Oh yes it is fixed at the frame like in the description, directly on the frame. Do you think this is enough?
Yes, that is enough
Okay then this is not the problem
So do you have any ideas what I can test else ?
I will test everything 😁
This has also been my experience but as soon as I run additional prints my first layer gets messed up.
It's like the printer gets amnesia after the first print.
This should be fixed in a new update check your updates
Says I'm up to date, 149
Trying to run beacon calibrate just fails with samples exceed tolerance
Have you changed the microsteps of the Z motors to 16 ?
Wasn't aware I was supposed to
In printer cfg?
Yes
But it is in ratos.cfg
Then go to z motors copy the 3 z motors and change the microsteps to 16 instead of (I think) 64
Ok
Just did that, trying again
I am curious why
there's a major bug in klipper, i'll make a report soon.
we finally identified it
it should not affect beacon scans, but it will affect contact. Basically probe moves that moves Z will miss steps depending on speed an microsteps because the timing used to compensate between the halt and trigger positions is offset from an endstop oversampling procedure that exists to combat endstop signal noise on old shitty printers.
I understand. Unfortunately, same error again. I will re-attempt.
I'm not sure 149 is the latest, did you remember to refresh the update manager?
Hmm.... I think so?
will try again
Yes
Says up to date
Okay this must be the newes mine is on this too
Is there a reason the beacon calibrate is doing contact now as well? i feel like i dont remember it doing that when i first set it up.
after clicking the refresh button in the top of the that panel?
Yes
Ah this confirms it's updated.
contact is enabled by default
ok got it
so that's a good thing
yes
i guess the next step is just keep waiting for this bug to be fixed then, as i probably wont be able to calibrate beacon without the contact bug fixed then?
my mesh is really good, so i dont think it's a physical problem
It already works as you can see over in #ratos-development and #beacon-contact
so when my calibration keeps failing at some point with this i just keep trying?
Wow. Congrats. Not everyday you run into bugs that involved.
No you fix the mechanical issue that’s causing it.
(Check the nozzle is clean and hotend is empty before calibrating)
Make sure your motor/leadscrew couplers are tightened hard, etc et
hmm.....i'm pretty sure i cranked them but i can check again
Do we need to change this microstep setting still with the latest update? This is my first time hearing of this.
@03Julian04 Mikl thinks you have extrusion issues-if it's not the tube or the filament path or the screw then might it be the electrical wiring between the extruder and the toolboard? If you have a poor connection on one of the leads it might only surface at certain point on the bed where the umbilical twists and binds in just the right manner to cause a disconnect. Zip ties do not solve this problem nor stop it. This is an issue I had early on in the commissioning of my build and also in my VCore 3 build.
Hmm this could be a reason but I have checked the electric already but yeah I will check it again
It should not be needed because beacon scan doesn't move in Z.
So my perfect first layer (450x450) with beacon scan 😍👌
I don’t know why it was now a success but I tested 3 times and 3 times it was a success maybe one update has changed anything that solved the problem
What I did:
Make a complete new calibration of the beacon scanner and a new beacon contact mesh compensation After this make a print , babystep safe z offset and after the print save config and then it was perfect A big thank you to @miklschmidt and @mazas for your great help 👍
Make a complete new calibration of the beacon scanner and a new beacon contact mesh compensation After this make a print , babystep safe z offset and after the print save config and then it was perfect A big thank you to @miklschmidt and @mazas for your great help 👍
Tnx, glad you got it figured out!
@03Julian04 I've been reading this thread from the beginning because I had the same print problems as you. Enabling the Beacon contact is what fixed my problems. I am on the latest ratos now and all the settings and calibrations seem good. I am curious what the print speed was in your final successful print? Anyway, I'm glad you got it fixed, and like you, I'm super grateful to @miklschmidt and @mazas and others.
My speed is 50mm/s
You have still problems ?
Can you send your printer.cfg here ?
Sorry maybe it is my old eyes but when I open that image in browser and fullsize it, it doesn't look perfect. It looks better but not perfect. Am I being too critical and asking too much?
I agree with you, it's not perfect but realistically for a 3d print, the minor changes should equalize over the height of the print, so if this was a real print, the variance wouldn't matter.
So basically a little more tuning to balance out the variance front to back and the wriggles?
Personally, I would say filament tuning, nothing to do with the beacon at this point
Yes that is what I meant.
It's really weird. Just when I think everything is finally good, I get an uneven first layer that makes me think the bed mesh is no longer being used. I am running the latest RatOS though, so it should be okay. Tuning the pressure advance helped, and just as impactful is the associated smooth time. I added smooth time to printer.cfg but while it doesn't cause an error, RatOS (mainsail) doesn't appear to load that value like it does the pressure advance.
Yes you are right but for me it’s good enough because if I print in normal situation the next layers then it doesn’t matter
How can I Determine the smooth time ?
I printed a 50mm cube with a single wall and changed the smooth time every 12 layers, just like they change the pressure advance. I manually incremented the value in RatOS.
Ah okay how do you changed the smooth time every 12 layers ? What gcode is it ? Do you use orca ?
I drew it in onshape, sliced it with prusaslicer2.8.
Ah and how do you changed the smooth time in the slicer ?
No, in RatOS / Mainsail.
Ahh okay
So you write it in the console ?
And what do you do first ? Input shaper or smooth time?
The whole time the PA was .05. The smooth time started at the default .04. Then at layer 12, I went to .00 smooth time, and you can see the instant bulge.
Then at layer 24 I incremented it to .01, layer 36 = .02, etc.
It was pretty hard to see which layer was the best, but I decided on the area with the black marks, which was about .09 smooth time.
What do you write in the console ?
Smooth_time:0.0
And so on or ?
Yes, the last 10 layers were a smooth time of .12. The whole print was a pressure advance of .05. It's possible with the modified smooth time, a different PA might be appropriate.
And why do you choose 0.05 pa for the tests of smooth Time ?
Not in the console, just enter it in the window.
Ahh I don’t see it until now
Thanks
Have you done the regular Pressure Advance tuning yet?
Yes
I feel edjamacated now
But I do it with smooth time 0.04
I chose .05 PA because the PA test cube showed .05 was best in my case, but that was at the default smooth time of .04. Now that I've changed the smooth time to .09, it's quite possible .05 is no longer the best value for pressure advance.
Ah okay
And the smooth time is with every filament the same or ?
Hopefully the PA and ST numbers will work for all PLA's, but it's likely it will vary from brand to brand.
what you see in mainsail is just a subset of state in klipper, mainsail just doesn't have UI to show the smooth_time apparently it does 😄
Ahh okay yes I calibrate every pa for every filament but I thought the smooth time is the same
Yes, but if you look above at the the smooth time line I added in printer.cfg, it doesn't load into RatOS/Mainsail at print time like the PA does.
where did you put this?
In printer.cfg
It's prolly getting overridden
after
[include RatOS.cfg]?
So yes, after RatOS.cfg
I thought it might be a long shot that the smooth_time var name was even recognized, but it didn't give me an error when I saved it.
@miklschmidt how can I add a macro to the userstart…
It doesn’t take this
Won't take a smooth time value?
weird
I wasn't sure it would, but since it didn't give an error I thought it took it.
Read the klipper documentation: https://www.klipper3d.org/Command_Templates.html
ok
it's
pressure_advance_smooth_timeWell shit. I'll try that!
i'm suprised it didn't complain about
smooth_time
Also be aware that increasing smooth_time will make it act strange at higher accelerations, basically negating your pressure advance setting.Does this ratos rev preserve the beacon_create_scan_compensation_mesh values?
yes
good.
I'm glad you and 03Julian04 had this discussion, because that was my problem too. The contact mode was running in mine until I did that.
was NOT running
Yeah there's been quite a bit of confusion around the variables and their naming
You know better than anybody, that there's a million things to keep track of. It's a huge challenge.
I feel like this is a bad joke. How could my contact mesh fail 15 minute in with values that are almost exactly the same each time, but "exceed tolerance".
Doesn't this mean my Z motors are mis-stepping?
i physically cannot tighten the set screws on my motors and couplers any further
there's a 20 micron differential between each probe which is a lot.
right but i'm trying to figure out why
right now im thinking there's an issue with my temp sensor
why?
How do you make sure that every start of the print the nozzle is clean for the real z contact ?
I am also curious about this. We installed these felt wipers and never use them. Shouldn't they be used to wipe before running the initial poke test?
I changed them to a nozzle wiper from bambulab a1 mini and made a custom gcode after heating the bed
Good plan
I am waiting till my printer is reliably printing before further mods
Yes mine is now printing good but exactly today come the idex + hybrid update 😂
Thought it would be more plug and play than this, fell for marketing
Does your extruder click?
Yes but I like it so we can learn more about this printer and if it is working and we have a problem again (which is normal in 3d printing) we can solve it
No I think this is not a good sign haha
Agreed
Not perfect but not bad
Maybe more z distance ? 0.025 more
nope, next ones went to shit
im going to start my own thread, i assume i have other issues
Okay send a link here I want to read and if I can , help too
https://discord.com/channels/582187371529764864/1291715677295611955/1291715677295611955
im going to have to come back to this later. i'm worn out after 10 days trouble shooting
i've been trying to get printing for over 50 hours at this point
@miklschmidt @Rewire @chicken here I am again… got the same problem again don’t change anything I even don’t move the printer but yeah same problem…
I have not had time to redo my VC4 yet. I upgraded everything and wiped out Beacon. Been working on my kids minion and got that mostly finished last night. Will jump into this over the next few days
How do you mean wiped out beacon do you use another thing ?
Nice how old are your kids
I deleted all of the beacon config from printer.cfg and all of the meshes as well.
Going to start on beacon setup from scratch
Kids are 11 and 13 now. They love their minion
I also thought this was the same for me. But continuous issues. I have now gone through and loosened, then re-tightened, every bolt related to movement. Then I re-did my bed mesh. Then I was able to successfully calibrate finally. Still had to use contact bed mesh compensation
Seems fine so far, now I'm dealing with filament issues instead, since there are no "out of the box" profiles except for punkfil filament, which imo is overpriced.
First layers are all coming out good though, every time i try
So you are using the beacon contact for the mesh of the first layer now or ?
That what solved most of my issues... My nozzle was persistantly 0.4 mm above the bed. I tried to log my battle here https://discord.com/channels/582187371529764864/1292556582336335904.
Not it still does a scan, but I have
variable_beacon_scan_compensation_enable: True # Enables the beacon scan compensation enabled in my printer.cfg
which, as I understand it, uses the contact mesh to compensate for the scani have not tried a full bed print, but my first layers all look good enough that I would say they are perfect
you will want to calibrate the filament to your printer anyway. Too much hardware variation to have preset profiles
This is for enabling the Gantry-twist compensation (still in beta) https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/configuration/beacon_contact.md#5-beta-automated-beacon-scan-compensation
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
On IDEX yes, they should be positioned so that the nozzle travels through it when parking / unparking.
Got it, so they'll be used for IDEX, but not single head