You printed by object but it’s just one print job to the firmware with compensation to be applied to all moves and positions.
1 Like
I know I said this above too. I’m just sharing observations right now, not sure how to interpret it until I have some more data.
Part of the reason I did it by object and not by print is because I do not want to start a print with a large skew applied and watch my toolhead self delete. You can’t apply a very large skew before it starts bumping the toolhead into what are supposed to be endstops.
That being said, I started that print with a skew value of -0.002 and my calculated skew is around 0.0011 at the moment. That alone should have altered the dimensions of those cubes, but all of them measure between 19.90 and 20.00. I didn’t really want to wait to say anything because i won’t have an answer until sometime tomorrow.
1 Like
This could take a while to hear back from Bambu about if there is a problem, and I’m not exactly sure who on their teams works on this stuff. So if anyone else manages to test and confirm this let me know… but don’t break your toolhead testing large skews. My toolhead lost a bit of its cover after hitting the side
So as I originally said for adjustments in calibration first start with a blank slate with no adjustments. Run skew calibration then run length of x and y calibration. Should just need to run skew print one time.
So print 1. Everything at default and no adjustments, measure I for skew. M1005 Innnn.
Print 2. Measure X and y and set M290.2 Xa Yb
Print 3 should be perfect in all regards.
Ok but now you’re applying a second gcode command. And how to make prints dimensionally accurate is not my question actually. My question is why print dimensions remain constant regardless of the skew value?
This command doesn’t appear to be working as we’re assuming it does.
Well. Do this. Measure the X and the Y. Then set x and y to whatever value (preferably the adjustment needed) then print another and measure. You can see the results. As long as the difference is under 0.5mm it should not be a problem.
the gcode should be M290.2
YES, I will corrrect that now. was doing the reply from mobile.
One seems to affect the angle only and the other affects the length of all lines. So possible to have both calibrated. There is a difference of where the printer thinks it is at and where it actually is at.
Yes you would think, and it works out that way on paper, that angle changes does change the length but here we have steps / rotation and substitution of X and Y uniquely being changed.
But to me this still indicates a potential problem.
If skew does not scale the print’s dimensions unless M290.2 is also run, then I doubt this is intended because Bambu is trying to replicate the Klipper/Marlin feature here.
I will test when I’m home from work whether I am able to get skew factor to alter print dimensions under any circumstances because I could be misinterpreting my previous results. Skew should result in translation of coordinates, but the print should be scaled at the same time.
Also note that I’m running the latest firmware version in which there is an update to how this command works.
Did Bambu mention this somewhere or are you seeing a difference in the logs? EDIT: Ah, you mentioned the log changes above.
1 Like
New discovery (as of 01.08.00.00, not confirmed on older versions)
M290.2 still has no log output associated with it, however M290 X Y does! The default values stored on my printer were 40, which would be set via M290 X40 Y40
2 Likes
OK, everyone, I have a reply!!
2024-05-09 14:40:24
Dear Customer,Additionally, the solution involving M1005 is temporary. Our team is currently evaluating and testing alternative methods, and we plan to release them in the future. Thank you for your attention and understanding.
Kind regards,
Bambu Lab Support
So don’t fall in love with M1005 as that is a temp solution and will have something else coming soon™
It is also my understanding (opinion maybe?) that there is enough data in place currently that the skew angle AND length corrections should be able to be calculated and applied without the end user having to do a single print.
2 Likes
I hope Bambu’s next printer will have this ability, but I believe the X1 would at least need endstops to make this possible. It has to do too much guesswork to figure out where the toolhead is currently
Doesn’t it know when it reads the build plate ID?
It’s able to determine with enough accuracy where the build plate marker is relative to the sides of the printer. And I would think that the 7x7 reference grid would be better for determining its absolute position since it’s actually fixed in place on the bed.
I’m not sure the camera is high enough resolution or has good enough operating conditions to be able to determine anything about the absolute positioning. The lens is also not perfectly parallel with the build plate, so there’s a bit of error to compensate for there.
1 Like
Latest discovery:
M1005 S1
disables skew compensation. This does not erase the stored value
M1005 P0
enables skew compensation
8 Likes
with which firmware is this for?
Only on 01.08.00.00+ as far as I know