Bed compensation is not working
Hello! I have noticed the after I start the print job, bed compensation is not activated. I am using a S3D slicer, I have copied and pasted start and end scripts from ratrig page. Is this something missing in start script o something is wrong in the printer's config files?
25 Replies
@miklschmidt maybe it has something to do with the fact that I am using contact beacon mode? 😄
bed compensation is not activatedHow do you figure?
Z axis screws does not move while printing a layer. But I actually have another more important question at the time: communication timeout during homing - is this something physical with the cable itself? or might be something else?
Put a piece of tape on them, and make a little flag, they move 🙂
communication timeout during homing - is this something physical with the cable itself? or might be something else?Depends on the actual error, timeout is usually a host overload / resource issue.
what do you mean "actual error". Where can I see it?
If you couldn't see it how did you know you got a communication timeout? 🙂 Just screenshot the error, or upload a debug zip after it's happened.
here it is
and as for the bed mesh, something is clearly not working, first layer is far from even. Some areas are too close, other are not.
If everything is updated (especially the beacon module), this is most likely a wiring issue yeah, or you have a loose connection in your USB ports etc.
I'd need to see the results of
BEACON_RATOS_CALIBRATE
sounds like axis twist
Are you using a glass bed?
you're using a 6x6 mesh... that's not gonna do much, if you have lots of inconsistent bad spots.Yes, glass bed, 6x6 mesh. For example, I have printed a small part now (picture of mesh is below) and first layer looked exactly like this small mesh - on the left side nozzle was too far away, on the right side it was good/maybe a little too close. So basically it does not compensate anything.
How do I send you all the results? debug.zip? I have made a beacon ratos calibrate, there is bunch of info
Okay I can not do a beacon calibration
Okay I have this info:
Tons of mechanical issues
You have axis latency (there's is noise in your setup, wiring issues), you have >120 microns of axis twist and you're not getting consistent probing results.
Are there any tutorials on how to fix these issues? 🙂 Also, I will try to run the same calibration without glass and not with contact beacon mode, maybe something will be different
There's no easy way, start inspecting. You can run the individual parts of the beacon calibrations one by one. The poke test will check electrical noise. The gantry twist measuremennts will show you how parallel your gantry is in Z (or how poorly your glass bed fits on the metal beneath it). The inconsistent probing is because something in your z axis is moving when it's not supposed to, so something isn't rigid or something is loose.
Start by finding and solving the inconsistent probing
it can be everything from hotend wobble to loose z couplers.
so the "Beacon_ratos_calibrate" is a series of tests that show how well or bad the printer is assembled?
What about now?
That's sort of the side effect of it yeah, it can be used to analyze a whole bunch of things, so we do 🙂
significantly better
Still some twist (around 80 microns in range now, so much better), but this could just be you flex plate, a bed mesh would help diagnose further
It's possible your umbilical is tugging on your carriage at the front (say, if it's not quite long enough)
The only difference between these two "beacon_ratos_calibrate" is that first one is done with glass bed and contact mode, and the second one without glass bed, on the aluminum plate and with scan mode 😄
Yeah, I think that's the case, I will try to give it more length
Makes sense, i'm guessing the glass is flexing too much because it doesn't conform to the plate properly.
Hello. I don't really see this issue as a wiring issue. USB seems to be fixed pretty solid, nothing moves. Unless you have in mind any other wires that can cause it.
Yeah all wires can cause this (not the USB cable), if it shorts anything etc and makes the MCU hang due to protections or actual damage, you get timeouts.
It can also be significant noise and bad impedance matching on the USB cable you're using, but that wouldn't be my first guess as there's very little data being moved between the toolboard and the pi, so less than ideal correction doesn't have much of an impact.
I would go over your toolhead wiring and disconnect stuff that doesn't prevent it from running and see if that solves the issue.
Start with the 4028 for example (if you have any of those wires connected to the toolboard, the default is to connect the PWM wire to the toolboard).