Hi, I’m trying to both print a large object and move the purge “hockey stick” as far to the edge as it can go.
I have noticed that y=0 isn’t the actual edge of the bed, but on objects at the limit the printer actually goes to the negatives, at least in the slicer…
Modifying the start gcode to print the first purge line at Y0, it doesn’t go to the edge. Here you can see an object that goes to the edge, being lower than Y0:
So my question is, what are the actual coordinate limits of the printer? Can it even go where the slicer tries to tell it to go or will the soft endstop mess with it? I’m trying to print a big vase that goes to the edge (at the top, so it doesn’t overlap with the purge line)… Will I get weird behavior 10 hours into the print or not?
Ha, my first printer was the infamous Anet A8 back in the day
I think the big downside to Bambu at the moment is documentation, the wiki post you linked is quite lacking.
Looking around, {print_bed_min[0]} and {print_bed_min[1]} (what at least in prusaslicer is bed min coordinates X and Y), comes out as X0 Y0 but it isn’t true.
Y min definitely isn’t 0 but (I think) -2mm. I say -2 because that’s the y “offset” of the nozzle in the print settings… Offset from what? The probe is the nozzle, lol
Just so you understand, Bambu is Closed Source so they don’t really provide open access that you may be used to with other printers. They also have a warranty that is pretty much non-existent with those other community OS based printers. A big part of being able to have that warranty is preventing users from monkeying with firmware
Let me tell you something about documentation because it cuts across every product, it doesn’t matter if you are building a 4 lane cable stayed suspension bridge or building the OS as part of the Klipper open source firmware for probably half the 3D printers in the western hemisphere…
Writing, proof-reading, or editing technical documentation is one of the most mind-numbing, tedious, and hated parts of ANY project.
I’ve been involved in several powerplant projects down through the years and I headed for the hills whenever project leadership started talking about documentation and project close-out.
This has nothing to do with open or closed source firmware, this is about operating the tool I bought. GCODE isn’t the source code of the printer, it’s the stuff you use to tell the printer how to move. If I operate a machine, I need to know its limitations and how it behaves given an input. I don’t care about its firmware.
A HAAS VF-1 CNC mill is close source, but the GCODE to operate it and its operating limits are documented, as they should be.
The bambu lab CNC plastic extruder - commonly known as a 3d printer - doesn’t have it documented (well it kinda tries to, but not really).
Owning the printer for a bit let me understand that this one of the main ways they managed to undercut the competition in price, which is OK but not always ideal, like in this case. Keep in mind that me being critic doesn’t mean I’m hating on the product, it’s great. It just needs better documentation. Oh well, this is going off-topic.
Have you tried printing a single layer square, say, at the limits of what the slicer/you think should be? Can you print over the top of the purge line? If you can, then it should be OK at other z heights. If not, then remove or change the purge line. I guess one method, would be to generate the g-code on another slicer, or for a larger bed size. I think Orca slicer would allow more flexibility.
As you can see I moved the purge line down to the edge of the plate (almost, I left a bit of margin if I don’t perfectly align the bed), and to the very right edge of the plate. I left the length of the “L” exactly the same, just moved it.
Works great, even though I’m still confused about why it behaves that way instead of the edge just being 0,0. But I can live with that, lol
The objects in the screenshots I posted in the first post do print exactly like that. I will try OrcaSlicer soon, do the presets just sync between computers like with Bambu Studio or not? That’s a super handy feature to have.
I was just telling you the truth.
I suspect your example HAAS machine has hard coded limits and mechanical stops such that with no cutting tool in place, you can’t effectively crash the machine axes against each other.
If you bought a Bambu printer thinking you can go at it like you’ve got Klipper installed and running Mainsail OS as your frontend, you are going to be disappointed.
What percentage of your total print output even need the 3mm - 4mm difference anyway?
I spent a few years in that Klipper/Marlin ecosystem and a sizeable percentage of that crowd don’t even care about turning out prints.
Their interest is in tinkering with their printer, not printing.
Be mindful of a couple of things, your Bambu printer has a warranty that is almost non-existent in the hobby 3d printer space, AND your Bambu printer is logging every single thing you do to the printer, so be careful you don’t bust out of the boundaries that define the Bambu Lab printers warranty.
I hate to be this direct but you’re rambling, and fundamentally misunderstand a printer’s firmware role, the difference between the firmware and the commands you give to it and how warranties work (why bring it up even?).
A 3D printer is a 3D printer and a tool is a tool, regardleess of its firmware there needs to be documentation on how you use it. Who cares if it runs klipper or Marlin or a fork or custom close source firmware? When you buy a LEGO set it comes with instructions. No need to have access to the manufacturing of the lego bricks.
I’m talking about GCODE and documentation. Klipper is a good example of an extremely well documented system - even just skipping over the installlation on third party hardware (that doesn’t apply to bambu obviously), you can read about every command you can give to the printer and the things you can do with it.
Importantly, every non-standard gcode command is documented in a page with a section explaining how to use it. Again, I don’t care about what the code is, it just happens to be also open source.
You don’t need to see the source code to know how to use SET_FAN_SPEED. It clearly tells you that you type “SET_FAN_SPEED FAN=yourfan SPEED=the fan speed”.
With the HAAS or tormach mill I don’t care about the C code that interprets the gcode, I care to know what the gcode command for a tool change is and how to use it.
With Bambu firmware I want to know what “M221 R” does without having to guess. I couldn’t care less about how the firmware that interprets it does, I don’t need to know and I can’t know, as it’s closed source. That’s OK. What does M221 R do? There’s NO wiki article about gcode. There’s one forum article with people guessing what the different commands do via trial and error, that at some point got noticed by Bambu staff and the author got asked if the post could be added in the wiki… Why??? Just document your own stuff!
I don’t need to know the firmware variable that leads the printer to go to Y-2. I don’t need to know why it goes to Y-2 (although that would be much appreciated). I want to know that it does go to Y-2. So my gcode can make sense.
The “just use a klipper printer then” argument doesn’t make much sense… No, I wanted to get a bambu and I got a bambu. It’s great, I don’t want to tinker. I want to use the machine.
Why do I need 1cm extra? Why do you care? I bought the printer to print big parts. I’m using it to print big parts. It’s great to print big parts.
Bambu absolutely nailed the hardware, they stilll have to work on other things. It’s ok, just don’t be an apologist for it lol. I want them to get better, justifying every sub-par thing doesn’t make them get better.
Now if I go on I’ll start to ramble too, so I’ll stop. If you want to discuss this further please DM me so this post doesn’t go more off-topic than it already has, I’m open to it. I have answered my question by trial and error, and that’s it.
I’m not sure why they have a purge line all the time. On other ‘lesser?’ printers, a skirt does the same job. I’m guessing the ‘L’ shape is so that a blob on the nozzle can get wiped off when direction changes. Glad you sorted it.
the line is handy to avoid having a skirt! When you finish a print or thee nozzle stays hot for a bit without extruding, pressure inside the extruder “relaxes”, and some plastic oozes out. This is normal, but now you have less plastic in it than what it should have, and if you start a print right away there will be a gap as the extruder has to build up pressure before starting to extrude.
You can either do the skirt or print a line right before printing, so the pressure stabilizes while doing that and not while attempting to print the part. A skirt works but it’s way more than you need, and it eats away at printable area, as you basically add a margin around the part. But yes, if you use a skirt you don’t need the purge line, it’s one or the other (well you can do both but it’s overkill lol).
Back in the day I used the skirt to do a “pre-print check” of the bed level, if I saw that the skirt was being printed wrong I could stop the printer before wasting too much material… Nowadays there’s no need to worry about that, lol
I too think they’re doing the “L” to let plastic stuck to the outside of the nozzle can get unstuck with the rapid change, it’s pretty clever. Other printers like the A1 mini (maybe also the A1?) and prusas instead do a very short line while extruding a lot more than usual to build extra pressure, and then a quick move away to let it stabilllize to normal. You get faster priming and a shorter purge line. I don’t think there’s much difference between the approaches, so I kept the standard P1S purge line. The L has worked well to sorta clean the nozzle so no need to change it! I’ll say that it can be way shorter than what it is now, as the current line is quite long. I think it’s that long for the X1, that scans it to calibrate flow before prints.
It can also happen two ways during a print: If you have “smooth” timelapse on, as the toolhead moves out of the way until a picture is taken (and it uses a prime tower to prime the nozzle again before printing), or when changing colors, and it uses the poop shoot right before getting back to printing.
and thanks! hope it’s useful if somebody else has a similar doubt.
Save yourself some angst.
Read this post.
The poster asked the same basic question. You may be surprised to know, when I first bought the P1S I wanted the G-Code because you can get a sense of what is going on under the covers so to speak.
The picture is the original poster also. I’m trying to save you some frustration. No one has answered your question have they?
Yeeeah nah, too bulky too expensive too experimental - and most importantly, no (good) enclosure. I’ll stick to my mk4s for the stuff that don’t require an enclosure… And the smaller things. 256x256 is a good bed area.
I like what prusa is doing with documentation, they’re great at it. Hardware a bit less. A Bambu-prusa hybrid company would be quite nice, they’d complement each other
I do read the forum, I know about these posts. And given the fact that Bambu literally asked one of the dudes who started a gcode reverse engineering post, to add the post to the official wiki… I’d put that statement into the “L1 support saying L1 support things” basket. From GCODE you can only gather as much information about the firmware as the firmware developers want. It’s not an issue at all. gcode is the language you talk to the CNC with, not its brains. They’re trying to stay ahead of the curve, prices as low as possible hardware as good as possible. You have to sacrifice something, documentation is the first to go… Prusa, since you mentioned, didn’t sacrifice it and it’s genuinely a good experience to use their printers, but they sacrificed other things (namely price, and speed at which they innovate and push new things out). It’s all a compromise. Companies decide where to cut and where to push. It’s part of the game. Won’t stop me from complaining about something I don’t like! Angst is the wrong word I’d say, what’s to be anxious about? I like to make my opinion clear. Docs are quite an important part of a tool. I think it would make for a way better experience to the end user, I know Bambu staff reads these forums, so why not say it?
Yes I will die on this hill
p.s.: I’m not trying to be aggressive to you, but to the thing you are saying. Maybe I failed at that, let’s go back to normal conversation I prefer it
That’s fine.
FWIW, quite frequently, like weekly, I would message the Klipper/Mainsail OS folks (politely) and suggest they have like a 30 - 60 day moratorium on doing "the cool s***, implementing this, tweaking that, doing resonance testing with ADXL ToF sensors and update the documentation.
Every month they’d put out “Goals for the Month” and every month would be Update Documentation but whoops, missed our goal on that one last month.
Not that I wouldn’t like to see better documentation on the Wiki but I have no idea how many people are using Marlin or Klipper but frankly, Bambu’s wiki is better than Marlin or Klipper documentation. That’s not saying it doesn’t need to be improved.
hope it’s useful if somebody else has a similar doubt.
