Alright fella’s, Noticed I had a weird 1st layer shift…
Only removed the M1005 Innn value which was I-0.003506
I just spent some time going back through the comments but, am I missing something here as to what’s current??
I reset the skew value M1005 I0M500
Then reapplied after a new test and the X1C went HAM into the Endstop…
Dancing against it like those 90’s bouncing hex balls that vibrated…
Soooooo I did use the OP Calculator up top or do we have a more current post other than this?
Create a new post and I’m sure someone will come along and help. Jumping into a thread that is totally irrelevant to your problem will get you nowhere.
The only time I had endstop collision with the M1005 In command was when I tried extreme skew values, but I-0.003506 is not extreme.
Is this the sequence of events?
M1005 I-0.003506 applied in Start gcode
weird 1st layer shift
removed the M1005 I-0.003506 command
reset skew value with M1005 I0
reapplied M1005 I-0.003506
new print - X1C went HAM into the Endstop
If that is not the sequence you used then please specify what it was.
Are you using the M1005 command at the End of the start gcode?
The skew calculator still works and gives the correct values.
What firmware are you using? I’ve only tested this on v01.07.03
Have you verified the collisions only happen when you don’t have bed levelling active?
My apologies for the inconvenience caused to this topic, I was just reaching out as I couldn’t find how to start a new topic.
Okay I was clutching at straws.
Apologies again, have a good day.
This is exactly what I had and I’m currently running the latest. This whole time i’ve had this added it’s been M1005 I[nnn]M500 in the [start gcode]
Something was off when I all a sudden noticed 2 models I finished were shifted only on first layer to the eye but measured and the skew followed so I thought something changed or somehow added to the value idk so I restarted the process but apparently simply adding the [M1005 I0 > M500 > M1005 I[nnn] > M1005 P1] isn’t a great idea… so It just went to the Rear Right-Hand corner and started doing it’s break dance.
I was able to get rid of it by removing and adding the reset M1005 I0
then starting a print to read the sequence. Then was able to re print the calibration square > calculator > add back valued I[nnn] and all is good again.
yes, I had it dance in the corner twice which both times all calibration functions were off.
After the 2nd time, I activated bed level only and it ran normal. So simple power cycle didn’t erase a value of some sort. I really just need to hop on the x1plus game
Why did you use parameter P1 with the M1005 command?
@Thermal_Runaway said that M1005 S1 and M1005 P0 disables and enables skew compensation in firmware 01.08.00.00 but I don’t see anyone in this thread suggesting that P1 should be used as a parameter.
I think a current summary of the advice in this thread is to use the M1005 gcode command with the In parameter for skew correction and to place that command at the end of the Start gcode. The behaviour of the M1005 In command was verified in this thread on Bambu’s v01.07 firmware. We need to check that Bambu doesn’t change the way that M1005 works in later versions of their firmware. I have not been able to test it on v01.08 because I’m currently using X1plus.
It is probably not a good idea to try random parameters with the M1005 gcode as it might damage your printer.
If anyone has tested M1005 In on the v01.08 firmware please confirm if it continues to work as it did on the v01.07 firmware.
EDIT: removed reference to P1 being an invalid parameter
After some more testing I found that M1005 S1 enables skew
and M1005 S0 disables skew
But to make this confusing, P0 also disables skew. I have not tested to see if the state of “comp_enable” is saved to EEPROM, so for now the safest thing to do is set skew to 0 to turn it off.
I am running 01.08. What exactly should I be testing?
When you say shifted, do you mean one layer is offset from the rest or the entire print shifted at a certain point? When I was messing with skew mid-print, I was able to cause layer shifts but only along one axis, which doesn’t make a lot of sense to me
Could you confirm that M1005 In can still be used to correct skew, that it is not iterative (i.e. that it overwrites a previous setting rather than applying a new correction factor to a previous one) and that M500 still doesn’t save the correction factor when the printer is power cycled?
I’m not sure what you mean. Which values? I asked if someone who is running Bambu’s 01.08 firmware could test that the M1005 In gcode command behaves the same way as it does with the 01.07 firmware. i.e. that Bambu have not changed the behavior in the new firmware.
The tests could involve running the gcode command, printing a test model and measuring it with digital calipers. These tests could be done on a printer running Bambu Labs official firmware or on a printer running X1plus firmware.
OK. I had only done it using X1+ on the 1.07.03 base firmware, which let me use the console to change/query the M1005 settings and view the results in the log. That is a lot easier than making actual test prints, but not yet a possibility until X1+ is updated to use the 1.8 firmware.
X1Plus has been running on 01.08.00.00 for several weeks now. There just isn’t an official release that runs on 01.08 yet. There should be an initial release candidate ready for the next major release of X1Plus within the next few days or so. Lots of changes