Ok, Iām testing it nowā¦
Some interesting (and weird) resuts:
So it has applied a scaling factor (correction) to my axes. But I canāt find the M290.2 command in my syslog. And at the end of my test print after applying the correcion, my print head collided quite firmly against the endstops. I need to do another print after a restart to check for collisions and to see whether the correction is persistent.
EDIT: for clarity the M290 was applied in my start gcode and the collisions ocurred at the end of my test print.
It should be M292.2 no? Guessing the 290 is a typo?
The collisions werenāt severe (like when I tested extreme skew angles) but it didnāt sound right. Iād like to run that again but we donāt (yet) have a way to reset the correction if itās persistent. My current test print should check if itās persistent.
@Nebur @EdStreet Here are the results after I power cycled the printer:
So the correction isnāt persistent. (I did apply M500 after M290.2 in my previous print).
I think Iāll run these tests again and watch carefully for collisions at the end. Iāll also look at syslog again. Then try different sized prints.
The previous print did correct the scaling of my axes. Thatās encouraging.
Has anyone tried for sh!ts to use [M500] in the [Ending gcode] section?
Still havenāt loaded up X1Plus and I wonāt most likely until we receive the next full firmware version. But remember base marlin having [2] methods of saving to EEPROM. Iām really frustrated at the fact BL hasnāt simply released a full wiki of all the codes. . .
Yes, weāve tried that. Bambu have confirmed that itās a bug that they hope to fix in the next version of their firmware.
1 Like
At the risk of sounding rude (not trying to) ā¦ Have you read the machine gcode sections?
M500 is in there more than once.
@Nebur @EdStreet Be careful if youāre testing the M290.2 gcode with a test print. I tested it again and it does cause the print head to hit the end stops faster than it normally does. I suspect that the print head normally decelerates when it gets close to where it āthinksā the end stops are and M290.2 might be throwing that off. Itās not a violent collision, at least not with the small correction I applied.
This really is increasingly frustrating. And I get the feeling itās not so much a decision they have made, but rather a case of no-one having time or being assigned to do it. They likely even have a complete reference, just not in English so itās a matter of (somewhat technical/challenging) translation.
2 Likes
M1009 is a command that does nothing by itself. It appears that itās intended as a sort of wrapper for any Gcode sequence Bambu printers publish to themselves. For example, speed adjustment.
The printer publishes the following:
M1009 L1 O1 M204.2 K1 M220 K1 M73.2 R1 M1002 set_gcode_claim_speed 5 M1009 L1 O1
Whereas we send every part of that sequence except M1009 L1 O1. There is no callback or setting associated with M1009, so my educated guess is itās used to ensure the message can always be parsed. The beginning and end of the string can be chopped off without invalidating the command(s)
I am working on a Wiki page for this, but if you would like to see other undocumented Gccode commands, see this commit of mine: gcodegenerator.js
Could you please provide the full path to the syslog where you are finding these extracts?
Iām SSHing into X1+ via MobaXterm and none of the logs I can find include anything like the extracts - no M codes, no āinfo forwardā lines, etc.
/tmp/syslog.log. Itās a rotating log file so just ignore the numbered files for now.
Bambuās log path is /userdata/log/syslog/syslog.log, but you wonāt see much activity there since you installed x1plus
Thanks, found it. Wouldāve sworn I looked there beforeā¦
Having encountered the skewness issue some time ago I thought of a method to deal with it which I have not yet read in this conversation. Though I did not read each and every post.
- Since the scale of the X and Y axes is dictated by the timing belts they are fundamentally equal
- When printing a square with skew axes, the result wil become a rhombus
- A fundamental property of a rhombus is that the diagonals are orthogonal
So, when rotating the print object over 45 degrees the result will be very close to rectangular. Strictly, the rotation needs to be 45 degrees minus half the skewness angle.
This comes at the cost of the original X and Y sides not being exactly equal any more.
If needed, in bambu studio X and Y can be scaled independently and X and Y scaling is preserved during rotation of the object.
Drawbacks:
- the size of the object is limited to roughly 70% (square root of 2) divided by 2
- the infill must be rotated as well
I have not tested this yet!
Hi @olxs
Iām not sure what you mean. Perhaps some diagrams might help me understand.
A limit on the size of a square you could fit on the printbed when it is rotated by 45 degrees?
EDIT: I think I see what youāre saying now. I need to look at it again tomorrow.
The skew is still present and thus with a 45degree rotation shows up on the lengths of the walls. to compensate for this we need to change the formula and change XY lengths.
Hi @klomar
I mean rotation around the z-axis.
Took me a while to make a drawingā¦
ā¦It seems I am not allowed to upload any drawings. Is there a reason for this?
Will post the drawing when this is solved.
Bottom line, by rotating the original print object by 45 degrees a square becomes a rectangle (with perpendicular sides) instead of a rhombus. It should be possible to measure this back in those octagon prints.
Yes, 70% of the max-size which fits on the printbed