X axis offset on multiple model when changing color with AMS lite

[jmilhau]

Bambu Studio Version

1.9.7.50

Where is the application from?

Bambu Lab Official website

OS version

MacOS 15.0

Additional system information

Since today (since latest Studio update? v1.9.7.50) any print I make with several colors in the same layer gets a x-axis gap a several millimeters. Maintenance did not help.

Black was printed first, then purple then cyan then orange.

Printer

Bambu Lab A1 Combo

How to reproduce

Print a model with 2 colors on the same layer

Actual results

Offset of the first color on the print

Expected results

No offset

Project file & Debug log uploads

test v1.3mf.zip
Cannot add configuration folder (more than 25MB)

Checklist of files to include

• Log file
• Project file

[jmilhau]

Re installing 1.9.5.51 solves the issue

[BastR]

Same issue on A1 with AMS lite on macOs, had to stop print.

[MCKanpolat]

I've just updated the latest version and same issue I have. Mac OS 15

Also reinstalling (clean install) the BambuStudio didn't solved the issue.

[BastR]

I did a few tests with Windows and printing went off without a problem.

Edit: A user on the official facebook group reports that he also has the same problem with Windows.

[ziehmon]

Are you using timelapse by any chance?

[BastR]

In my case no, no timelapse on the A1

[jmilhau]

No timelapse either

[ziehmon]

Alright, can you do another check just to make sure? Try to remove the timelapse_gcode in extruder settings. It's a wild guess but worth a try. The behavior was changed in the new release.

Printing the first layers will be probably enough.

[NicolasABSuarezB]

I have the same problem with mi A1 (Bambu Studio v1.9.7) on Windows
Solved with the reinstallation of Bambu Studio v1.9.5.51

Don't give importance to the texture of the first layer, I'm trying some things

[SaltWei]

Caused by this. Disable timelapse can workaround.

[SaltWei]

Will revert this patch and hot fix this issue

[BastR]

Bump.mp4

@SaltWei @ziehmon As you can see from the video, even with the timelapse_code removed, there is still a layer offset.

You can hear the bed collide with the movement of the printer head, so I suppose that's when the step is lost and there's a shift.

[XunZhangBambu]

@BastR To solve your issue currently, you need to turn off timelpase when printing rather than remove the timelapse gcode

[jmilhau]

Timelapse was NEVER activated for me, so I think this does not solve the issue.

[ziehmon]

@XunZhangBambu when the timelapse gcode is deleted, get_last_pos_from_gcode() would not change the position. The user also had timelapse disabled.

Where do you think the bug is exactly?

It must be happening when AMS is used, because users without one don't face this issue it appears.

[BastR]

@XunZhangBambu As @jmilhau says, the timelapse had never been activated when I made my prints, so I activated and deactivated the timelapse just in case, but I still have the shift.

[ziehmon]

@XunZhangBambu As @jmilhau says, the timelapse had never been activated when I made my prints, so I activated and deactivated the timelapse just in case, but I still have the shift.

You were testing with AMS, right? Could you test using only one color, so no changes in between?

[BastR]

@XunZhangBambu As @jmilhau says, the timelapse had never been activated when I made my prints, so I activated and deactivated the timelapse just in case, but I still have the shift.

You were testing with AMS, right? Could you test using only one color, so no changes in between?

Yes all my prints was with AMS, with only one color no problem.

[jmilhau]

If I summarise:

• What works: Printing with 1 color from v1.9.7.50 / Printing anything from v1.9.5.51
• What does not work: Printing from v1.9.7.50 with 2 colors or more with AMS/AMS lite with or without Timelapse activated

[ziehmon]

@jmilhau @BastR gotcha. That's the hint. I authored the change that probably caused this and I didn't had an AMS to test. But your description is enough to find it.

Update: found the bug. Fix is comming @XunZhangBambu:

[XunZhangBambu]

@ziehmon

The bug occurs in this change. Although the retract and lift are executed before inserting the timelapse G-code, the actual lift will be performed during next travel generated by code, at which point the position may already be at the extreme edge of the printing area. Performing another spiral lift at this point may exceed the machine's printing range, leading to lost steps

[BastR]

IMG_3101.mp4

I deliberately shifted the X axis and you can see that during the last movement the head moves more towards 0.

[ziehmon]

@ziehmon The bug occurs in this change. Although the retract and lift are executed before inserting the timelapse G-code, the actual lift will be performed during next travel generated by code, at which point the position may already be at the extreme edge of the printing area. Performing another spiral lift at this point may exceed the machine's printing range, leading to lost steps

I'm sorry, I don't yet agree with this analysis. There is plenty of room to execute the spiral Z hop. The problem is an inconsistency in the approached position when there is an AMS in use .

I am analyzing this, let's not jump to conclusions.

[ziehmon]

[ziehmon]

I found it. The position where the Z hop inserted via::

is different, when AMS is used. The head is at x=-48.2000 with AMS, and having a Z hop then indeed moves the head out of the bed's boundaries.

I think we just have to change the gcode for filament_change @XunZhangBambu. The head needs to be at x=0.00000 after it, then everything works fine. That's the difference between the AMS gcode and the one without :)

[XunZhangBambu]

@ziehmon lets take the 3mf @jmilhau provided to analysize.We add a comment where we expect the lift happen and set zhop to a special number 0.366

then you will find the lift dooes't immediately happen

it happens in the line 1440 , and the nozzle is out of the bed

[ziehmon]

Yes you're right @XunZhangBambu. I agree and my analsys was only correct when no AMS is used.

The fix is simple: in filament_change_gcode, the printer shall move to x=0.00000 at the end, exactly like it does in timelapse_gcode. This then gives enough room to perform any upfollowing moves:

G1 X0 Y{first_layer_center_no_wipe_tower[1]} F18000 ; move to safe pos
M400

[ziehmon]

The screenshot you showed shows exactly that this is because of the position the head is in when filament_change_gcode is finished! :)

[XunZhangBambu]

@ziehmon What you mentioned could be a solution. However, in order to ensure absolute safety, we need to revert your submit first. After fixes and thorough testing, it will be reintegrated. Thank you for your understanding.

[ziehmon]

Understood @XunZhangBambu. I'll create a new PR, including the change. Maybe you can start testing it soon. For a lot of people this fix massively improved print quality, but I understand that with AMS, this is a nasty bug.

[ziehmon]

I am sorry for this mess. I don't own an AMS and I was unable to test this scenario. The fix for stringing is very nice but it's uncool that it broke people's printers. Sorry guys. At least we can do it better with the next PR 🚬

[SaltWei]

I am sorry for this mess. I don't own an AMS and I was unable to test this scenario. The fix for stringing is very nice but it's uncool that it broke people's printers. Sorry guys. At least we can do it better with the next PR 🚬

This is not your fault. We always welcome PR from community, and our tester should tested more carefully and enough.
Sorry everyone, we will hot fix this issue ASAP.

[jmilhau]

@ziehmon The fact that you are helping to solve the issue is way more important than the bug introduced. MANY THANKS for that. I would suggest Bambulab to send you an AMS for future testing ;)

[ziehmon]

@lanewei120 thanks for your warm words.

I created a new PR that handles this problem. There is a very extensive analysis inside: #4848. I also created a list of testcases we should print to make sure this is not going to happen again.

@XunZhangBambu would you be interested in reviewing and testing this, since you review the original PR?

[ziehmon]

BTW, this was why the fix that caused this problem was introduced originally (printed without AMS....):

[SaltWei]

BTW, this was why the fix that caused this problem was introduced originally (printed without AMS....):

I will ask our marketing colleague whether it's possible to send you one ams lite(not promise). Will let you known if be approved.
:)

[ziehmon]

BTW, this was why the fix that caused this problem was introduced originally (printed without AMS....):

I will ask our marketing colleague whether it's possible to send you one ams lite(not promise). Will let you known if be approved.

:)

That would be absolutely amazing! Even a discount code would be a great gesture, but it's understandable if it doesn't get approved 🙂

[ttt888zzz]

The latest version has been fixed.
Please visit the website at https://github.com/bambulab/BambuStudio/releases and try again.