That’s good to have that confirmed. Thanks @Giovanny
Leaving M1005 [In] as a permanent addition to my machine start gcode still works well for me as the correction factor is always applied, including after the machine has been powered off and restarted.
You guys have piqued my curiosity as to why my settings have been kept through power cycles and a firmware update.
I’ve been doing various test prints again this morning to verify that the skew correction is still hanging in there. And it’s still being corrected as my parts aren’t skewed, verified by measuring and with a machinist square holding up to the light and verifying the light gap is consistent (this method really shows print imperfections, but is a quick and dirty way of verification).
Going back in my memory, the ONLY thing that I can think of that I did was a day or two before learning about M1005 command, I had done a ‘factory reset’ on my printer.
It was acting weird, and I thought a ‘factory reset’ might correct it (it didn’t, but cleaning/lubricating screws and setting belt tension did).
The worst thing I learned from doing a ‘factory reset’ was I lost all my K values for my filaments. I forgot that they are stored on the printer. I didn’t write them down either. And this was right before the new Beta of Bambu Studio where you can create the K value profiles without printing anything. And I didn’t know that Orca slicer you can enter the value in the filament preset.
@MrDB42 Could it be the firmware update you did? Perhaps the bug confirmed by Bambu in their reply to @Giovanny is in firmware version 01.07.02.00. If you started using M1005 with an earlier version of the firmware that version might have saved your compensation factor and that is now being recalled when you power your printer off and restart it.
But I’ve just checked Bambu’s reply again and they say the bug causes the saved parameters to not be read…
This may help things along, at least our side of things. Here is the syslog results of the M1005 X79.52 Y79.60 command.
Apr 13 15:24:08 info forward[1037]: [MCU][BMC]M1005:M1005 X79.52 Y79.60
Apr 13 15:24:08 info forward[1037]: [gparser][358] MCU seq: 23 size: 1024
Apr 13 15:24:08 info forward[1037]: [MCU][BMC]M1005:current XY_comp_ang = 0.0000
0
Apr 13 15:24:08 info forward[1037]: [MCU][BMC]M1005:new XY_comp_ang = 0.00101
Apr 13 15:24:08 info forward[1037]: [MCU][BMC]M500 : M500
Also with M1005 I0.000252
Apr 13 15:28:23 info forward[1037]: [MCU][BMC]M1005:M1005 I0.000252
Apr 13 15:28:23 info forward[1037]: timeout: 20000
Apr 13 15:28:23 info forward[1037]: [MCU][BMC]M1005:current XY_comp_ang = 0.0010
1
Apr 13 15:28:23 info forward[1037]: [MCU][BMC]M1005:new XY_comp_ang = 0.00025
Apr 13 15:28:23 info forward[1037]: [MCU][BMC]M500 : M500
On a clean boot after the M500 you see this.
Apr 13 15:36:08 info forward[1047]: [MCU][BMC]M1005:M1005 I0.000252
Apr 13 15:36:08 info forward[1047]: timeout: 20000
Apr 13 15:36:08 info forward[1047]: [MCU][BMC]M1005:current XY_comp_ang = 0.0000
0
Apr 13 15:36:08 info forward[1047]: [MCU][BMC]M1005:new XY_comp_ang = 0.00025
Apr 13 15:36:08 info forward[1047]: [MCU][BMC]M500 : M500
@EdStreet How did you access that log file? I can extract the printer log to SD but the file is encrypted.
Are you using X1Plus firmware?
Was there any response after the M500 commands?
Nothing about m500 after that. Yes I am using x1 plus and it’s in syslog.
I think I know why my printer holds the skew correction on a power cycle. I need someone else verify this anomaly that makes absolutely no sense to me.
I don’t understand why this works, but it works on my printer. I am working with firmware version 01.07.03.00.
The trick is to put the:
M1005 X[n] Y[n]
M500
at the TOP of the “Machine Start G-code” window. i.e.
Then wait for the printer to “sleep”, then power cycle the printer. And what I mean by sleep, is wait for screen to turn off, and ALL the fans to turn off.
Being slightly OCD (ok, I lied… VERY OCD) I was curious as to why so many were having issues with the skew correction not staying on a power cycle. So, I’ve spent the last couple of days experimenting and wasting about a 1/4 roll of filament.
I recreated the steps that I did the very first time.
Try again, curse some more.
Update to 01.07.03.00
Try again, curse even more.
Try waiting for the printer to go to sleep first. Try again, curse even more. I kept going with every various ideas. Nothing worked.
Finally, it dawned on that besides having OCD, I can be lazy. I HATE scrolling down and I finally remembered thinking at the very beginning “Hey, I’m just setting a value in NVR, I can put that code anywhere, so why not put it at the top of the start G-code so I don’t have to scroll down.”
So, I tried again, putting the M1005, M500 sequence at the top. Ran through the iterative process, then power cycled the printer. Reran the print, and dang it, it was still skewed.
Tried one more time, thinking maybe, just maybe it might stick if I wait for the printer to sleep, because does it really write to NVR, or does it write to a config file? And if it’s a file, it may only be updated when the OS goes to sleep. I don’t know, Bambu is doing their “own thing” with a Linux OS underneath. So, I tried it all again and I waited for it fall asleep, power cycled, reprinted and measured.
BINGO! Finally on power cycles the skew correction is sticking.
I haven’t tried this with:
M1005 I[n]
M500
at the top and waiting for the printer to sleep. I’m tired and just happy to have the skew correction working again.
@MrDB42 That’s interesting. Well done for all your testing!
Ill try that when my current print has finished.
I think I saw a reference to a bug in one of the other firmwares (perhaps some version of Marlin) where M500 wasn’t working unless it was called twice.
My (unedited) Bambu Machine Start G-code calls M500 3 times. So if that bug applies to Bambu firmware, puting:
M1005 X[n] Y[n]
M500
at the end of the start G-code wouldn’t work, but puting it at the start would.
But you seem to have identified the factor that makes M500 work is waiting for the printer to ‘sleep’. So I’ll try that. I’ll let you know how I get on.
I’ve spent the last couple of days experimenting and wasting about a 1/4 roll of filament.
Humor me here. Do a test and show the results. I think you will find it to be most interesting.
Leave the M1005 at the top and REMOVE the M500 and see if that retains after the power cycle.
@MrDB42 I don’t get the same result as you. The compensation factor is not retained through a power cycle. I tested it on v01.07.02 and v01.07.03
I put:
M1005 X[n] Y[n]
M500
at the start of the Machine start G-code. I waited for it to ‘sleep’ before power cycling it.
@EdStreet Have you tried this? Is the compensation factor retained?
The assumption is it is NOT M500 but something dealing with the save system state and with the power recovery feature. The test would validate that one way or the other. I have a 25H print going and should be finished late tonight or I would have tested it yesterday
If you call M1005 at the start of the machine start gcode without M500 after it, there are still 3 M500s in the start gcode that will be called after M1005
I’m assuming the intention of Bambu’s M500 is to save ALL configurable settings
I see what you’re getting at.
But I had a weird issue last night. I did a print, but the printer wouldn’t go to sleep (I believe it’s the PSU fan is the last fan to turn off) after 2 hours of sitting. I just powered it off and went to bed. I saw your post, decided to do one verifying print before making any changes, and !#$%&*@%!! it was skewed back to its original error.
I’ve been playing around since, and I just can’t get the settings to stick for some reason.
Looking though the in the Start G-code, something just caught my attention, what is M500 R in the “laser and rgb calibration” section? I know M500 but what is M500 R?
my assumption is rgb calibration. This also leads to the next question, what OTHER params does M500 take…
;=========== laser and rgb calibration ===========
M400
M18 E
M500 R
I saw the R parameter too. Here are a couple of possibilities:
A similar function to Marlin’s M501: Restore settings (Load all saved settings from EEPROM)
A similar function to Marlin’s M502: Factory Reset (Reset all configurable settings to their factory defaults. This only changes the settings in memory, not on EEPROM)
The first is perhaps more likely than the second. Unfortunately we don’t know how Bambu have implemented M500. I’d like to try M501 M502 M503 M504 but I don’t have access to unencrypted log files to see how the printer responds.
Looks like nothing is setup for that and it ignores the values.
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]Set hotend to 220.00
Apr 21 18:55:46 info forward[1046]: [MCU][MISC]sub stage set to:(0)
Apr 21 18:55:46 info forward[1046]: [gparser][358] MCU seq: 23 size: 1024
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]M1005:M1005 I0.000252
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]M1005:current XY_comp_ang = 0.0005
0
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]M1005:new XY_comp_ang = 0.00025
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]M500 : M500
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]Set hotend to 220.00
Apr 21 18:55:46 info forward[1046]: [MCU][BMC]Wait hotend to 220.00
Apr 21 18:55:46 info forward[1046]: [MCU][MISC]sub stage set to:(2)
Apr 21 18:55:46 info forward[1046]: dump: 1760 1598 7040 1010 2 2 0 16b 0 2 ff 0
2 3 ff ff 0
Apr 21 18:55:46 info forward[1046]: [MCU][SYS]Cpu.Max=6159.9903 Ramleft=1420
Apr 21 18:55:46 info forward[1046]: [MCU][SYS]Task main cpu.max=3341.9597 stk.ma
x=0x20000f0c.0x20000010 stkSz=4096 stkFr=1696
Apr 21 18:55:46 info forward[1046]: [MCU][SYS]Task GcodeRunner cpu.max=0.9856 st
k.max=0x200075f4.0x20006d08 stkSz=2816 stkFr=1224
Apr 21 18:55:46 info forward[1046]: [MCU][SYS]SIO r_ts=183 i_diff=7045 i_cnt=-61
5673864
Apr 21 18:55:46 info forward[1046]: [MCU][SYS]Dev[uart0]fw_cnt724875 tx=48361062
rx=833256 dis=65407 he=177 pe=60
This is my experimental print start 
;M1005 X79.52 Y79.60
;
;
M1005 I0.000252M500
M501
M502
M503
M504
@EdStreet That’s really useful. Thanks!
I’d like to try X1Plus to get access to unencrypted log files but Bambu Lab’s statement about rooted firmware where they refer to it being ‘a one-way ticket for customers’ makes me hesitate, although they then seem to contradict that statement by saying: ‘We will try our best to allow users with third-party firmware to revert to the OEM Bambu Lab Official Firmware’.
Do you have any thoughts on the ‘one-way ticket’? Do you think it just applies to the warranty (which wouldn’t bother me)?
The gotcha they imposed is this. You can easily replace the AP board and be 100% back to factory spec with 0 issues. the AP board is the secondary system while the MP board is the guts of the machine.
I can say with 100% fact that the X1 Plus team is outstanding technical skills and ability. They have so far been above and beyond in what they are doing.
I can also say that Bambu’s statement is a CYA approach and meaning they have no control over things when you do X1 Plus. However, that being said Bambu is also working WITH the X1 Plus team on various things.
That’s great. I thought there was some issue replacing the AP board. I’m going to try X1Plus. As well as unencrypted logs, lots of other features in it interest me.
Thanks.
There is a skew correction that does save between sessions now as well 