Printing Custom 3d Model G-Codes from Grasshopper

[tmdrn100 (Seung Gu, Kang)]

Hi guys,

Recently i’ve been trying to write my own g-code (except the start & end code given from the bambu studio as almost presets) for 3d models like this.

(Not trying to use the existing slicing method, for design purposes & trying to control the toolpath of the printer to go more than just printing on flat xy planed layers.)

I’ve studied that i’ll need the start code - 3d model code - end code to make the gcodes work from a book called ‘Advanced 3d Printing with Grasshopper’, from Diego Garcia Cuevas and Gianluca Pugliese. And the codes they make could produce things like these.

I’ve tried testing with Creality slicer and Cura Slicer, and they work just fine but for the bambu studio, when i drag & drop the G code, it kind of works (like this in the image)

but whenever i try to print it,

And one more thing that i’ve tried is printing the gcode file directly from the sd card. But in this case, the nozzle and the bed starts to warm up, and the extruder moves but the filament won’t just come out.

https://drive.google.com/drive/folders/18QiTBrhFFy8VEqzqFfaYFrgFdcFszCPh?usp=sharing

(as the gcode is a bit long, i’ll leave a link for the code that i’ve used just in case for testing.)

If anyone had these issues in the past and solved it, could you please tell me how you made it work?

Thank you so much for your response in advance.

[inno]

this is what your Gcode produces (I mean just the lines between 667 and 9501, which are the actual G1 coordinates) and geometrically speaking it looks very fine to me (also: congratulations!)

fast_check_Gcode_points.gh (27.9 KB)

if I had to guess an issue that is not hardware-related (like clogged nozzle and stuff like that) my best guess would be toward E values, which are about the amount of extruded material

as you can notice from here, the E value used on each G1 command is EXACTLY equal to the length of that G1 movement (here calculated as length of the exploded polyline that moves through each and all G1 points)

never worked with a Bambulab before, but generally speaking, there is a command M92 that sets the Esteps, which indicates how many steps the Extruder motor has to turn in order to extrude 1mm of filament (so they will work like a hidden multiplier for the E values on the machine side)

I don’t see that command being used on your Gcode, maybe it’s a setting you can retrieve/set from the control panel of the machine… but may also be that value has to be set on the setup code before the actual printing commands

the first thing I would try, is to open a Gcode that worked and printed very well in your machine, and compare the Δ_xyz_move with the Δ_E_value, and also check if in that Gcode the command M92 was used, and which value was assigned to that (if you have another slicer-generated Gcode that printed well, you can also post it here if you want, and I’ll have a look)

[edit] I just had this far memory from a few years ago (but we were printing clay on a Wasp printer, we still use the sma edefinitions…) that at a certain point we had to lower the number of decimals for the E value… maybe that’s not even a thing, I just have a record of that in my mind… now we are using just 1 decimal for E and 2 decimals tops for XYZ:

[tmdrn100 (Seung Gu, Kang)]

@inno

Thank you so much for the reply.

I’ve never even had a doubt that the E value could be a problem . I just thought that the E value just needed to be the length of the segments. Really, that seems to be the thing i should consider while making gcodes. Thank you for the info.

And with your advice, i made a simple shelled Box in rhino and exported as stl and dropped to Bambu Studio (Slicing Program) to see how it writes the gcode,

[The stl file and the gcode made from the app is in the link below ]

https://drive.google.com/drive/folders/18_YTAK4C4Lj-Quq0aRDtC7G7hjqt4Zty?usp=sharing

and as shown in the image,

1. I suppose the first red box is for the inner lines, and the second one is for the outer, but i have no idea where that E.2833 or E.29437 is coming from, and why there’s line 1384 & 1385.
2. I thought i just needed to put the info as Gn Fn Xn Yn Zn En (n : numerical value) in a single line, but it seems quite sophisticated than i expected making it a bit tough to script in grasshopper . (In case you want to check the codes of the model, i think it’s in between line 1080 to 3100. The rest are the Start & End Codes.)

3. The Start & End Code (is also in the link) is quite different from the Gcode that the program actually made .

These issues gathered, for our mental health and inner peace, i think the best solution for the bambu printers is to just use the existing program as intended and provided. So sorry if it sounded like whining, i was kind of having tough time last few days with this problem.

Thank you again for your kind response, and have a nice day!!

[tmdrn100 (Seung Gu, Kang)]

For anyone looking at this topic in the future,
i’ve tried printing with my second printer sermoon v1 pro.
With the Start & End gcodes provided from the creality slicer v 4.8.2,
i think the way of putting the lines as Gn Fn Xn Yn Zn En (n : numerical value) work!

There were some issues with the model (too much difference in heights)
making the output like this ,

but watching the xy but also z axis move at the same time was a sensation for me .

Hope you guys all succeed in printing, and Cheers!!

-Seung Gu Kang-

[tmdrn100 (Seung Gu, Kang)]

Finally!!

Satisfied with my results!

[inno]

hey! what a nice work you have done there!

just wanted to drop a line about the G1 Xn Yn Zn En Fn, and will reply a bit more extensively later today with a bit more time

each time the G1 command is read, the machine puts in its memory those X Y Z E F coordinates, executes the movement/extrusion to that location with speed F, then reads the next Gcode line

if you are in the case like the last Gcode you shared, sliced in planar and parallel layers, all the points that belong to a given layer have very same Z coordinate: that means that you can give that Z value at the beginning of the layer, like in the very first G1 movement for instance, then omit Z in any other G1 command of that very same layer, because you would be overwriting the Z variable again and again always with the very same value, something like this:

slicers want to give you the lightest Gcode files for your machine, so they of course won’t repeat useless variables again and again… the downside is that it sometimes makes the Gcode a bit less readable, and you have to constantly go up and down if you want to check it

this thing of avoiding repeating the very same variable can for sure be done with GH components, probably much easier via coding, but to be fair I never even thought about it… all my code always had full variable list each G1 line (not a pro )

on a side note, that absence of repeated variables is something you probably wouldn’t notice in the first Gcode you tried to print, because Z axis is always moving up and down, so you would probably need to reclare it for each G1 anyway

@tmdrn100

one thing I would consider for this is min/max layer height, and also that the amount of extruded material should be proportional not only to the length of the line just printed, but also somehow proportional to the distance along Z of each end-point from the previous layer, because the more distant they get (left/right side) the more extruded material they need to create structure?

[tmdrn100 (Seung Gu, Kang)]

Thank you!

@inno

hey! what a nice work you have done there!

And also for this part, too!
But it’s kind of tough to analyze everything that the program produced and
it’s kinda giving me headaches when dealing with the Bambu Studio gcode,
so i just decided to use the custom ones only in my 2nd printer .

@inno

slicers want to give you the lightest Gcode files for your machine, so they of course won’t repeat useless variables again and again… the downside is that it sometimes makes the Gcode a bit less readable, and you have to constantly go up and down if you want to check it

this thing of avoiding repeating the very same variable can for sure be done with GH components, probably much easier via coding, but to be fair I never even thought about it… all my code always had full variable list each G1 line (not a pro )

on a side note, that absence of repeated variables is something you probably wouldn’t notice in the first Gcode you tried to print, because Z axis is always moving up and down, so you would probably need to reclare it for each G1 anyway

and for this part,

@inno

one thing I would consider for this is min/max layer height, and also that the amount of extruded material should be proportional not only to the length of the line just printed, but also somehow proportional to the distance along Z of each end-point from the previous layer, because the more distant they get (left/right side) the more extruded material they need to create structure?

i couldn’t agree more to the thing you mentioned and tried to tweak the script i previously used,
multiplying e values proportionally with gaps in z axis, and it gave me this!

It was sooo close to a successful print, but there was one thing.
The printer head(?) was too thick and it hit the print, making the object to move

Printing Custom 3 Model Gcodes from Grasshopper

during 6-7 & 14 sec, you can see the extruder hitting it making it unstable for the next layer to settle.
But anyways, making gradient extrusion amouts was a success after almost 20 tests.
(Took me a bit in finding the right the values )

Thank you again @inno for your advices, it really meant a lot!
hope to talk with you on other interesting topics in the future!
Have a marvelous day!

Seung Gu Kang