Cura and snapmaker gcode compare


#1

Hi All,

Has anyone generated gcode in cura and then matched with snapmaker gcode for the same stl?

Thanks.


#2

I hadn’t before, but I do have the GCode for the mini printer test, sliced in Snapmaker3D and JS handy. I intend to slice the same object in Cura one of these days.

Looking at the GCode generated by Snapmaker3D, a comment in the header is
;Generated with Cura_SteamEngine 2.7.0

And a header in the GCode from SnapmakerJS is
;Generated with Cura_SteamEngine 3.6.0

The only file I have handy (different objects) was generated in Cura
;Generated with Cura_SteamEngine 3.4.1

So I’m pretty sure you’re going to see a lot of similarities. But even if it’s all Cura on the backend, there are some difference. The 3D GCode has a comment saying ;LAYER_COUNT:295, while the JS comment is ;LAYER_COUNT:296. Both were generated using a copy of ‘High Quality’ print mode, but with the initial layer temps raised by 10ºC (it helps my first layer adhesion).

After that, the differences between 3D and JS become pretty big. In 3D, the first stanza has a comment of ;TYPE:WALL-INNER, and takes 5 lines. In JS, the same first stanza takes 16 lines. Overall, the 3D files is 172k lines, and the JS file is 134k lines.


#3

Hi @venuasg this is super easy to do. Just slice and then open in notepad.

Curious what you are looking for.

I’ve noticed that no matter what the ending gcode of a file, there is some programmed “end code” that really doesn’t seem very good - in that it lowers the module then moves the plate, which might smash into tall prints. Has anyone else experienced this lately? Found a fix?


#4

@NilartPax
The “End G-code” actually higher the module (to maximum Z = 125mm) and then push the plate to you?. Have you experienced the smash?

@clewis
There are many differences between Cura 2 and 3 and more options you can config in Cura 3. In Snapmakerjs we added Snapmaker specific configurations (like stepper acceleration, machine size, filament diameter, etc.) based on its base config.


#5

Thanks for the reply. What i meant was As the latest SnapmakerJS uses Cura engine 3.6.0 and i have taken a sample STL file and generated with Fast Print Quality and was able to match the settings for snapmakerJS on Cura and generated gcode in cura and tried to compare both files. However i was able to match most of the things but after Layer3 everything is different. Just to know if anyone was able to compare.


#6

Yes it does bring it higher, and move the module to X0. But then it lowers the module and pushes the plate to Y0 then Y125. This is not what is at the end of my gcode files, it’s something that happens no matter what I slice in. Cura or snapmaker.


#7

@NilartPax, there was a discussion about the Z axis falling after a print completes. Although those sounded like they were relatively slow, and only really a problem when the print finished while unattended.

When your print finishes, is the descent powered or unpowered? It might be hard to tell the difference with the bed still moving. If you gently try to interfere with the descent, does it prevent the descent? I wouldn’t try very hard to prevent the descent, just a little bit of upward force to see if the module is being driven or if it’s falling due to gravity.

Do you have anything attached to the X axis? I printed a little box (I can’t find it on thingiverse) that attaches to the X axis and holds the CNC clamps, bits, pallet knife, and tweezers. I had to stop putting the knife and tweezers in there because it caused the Z axis drop. But it’s been fine ever since I stopped adding extra weight.


#8

It seems motorized, since it is a controlled drop of about 2 cm. Everything would be fine if the Y axis didn’t go back and forth… But I can’t seem to stop it from doing so no matter the end gcode. It’s not the nozzle the hits. The nozzle is 100% cleared of the build surface in the X direction. It’s the edge of the module that wracks my prints sometimes. Mainly vases.


#9

If you’re paying attention, just turn it off when it starts to raise.

You could also try editting hte GCode yourself. For example, in some SnapmakerJS GCode, I see
;End GCode begin
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G90 ;absolute positioning
G92 E0
G1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G1 Z125 E-1 F{speed_travel} ;move Z up a bit and retract filament even more
G1 X0 F3000 ;move X to min endstops, so the head is out of the way
G1 Y125 F3000 ;so the head is out of the way and Plate is moved forward
M84 ;steppers off
;End GCode end
M82 ;absolute extrusion mode
M104 S0
;End of Gcode

I only see a single absolute positioning in X, Y, and Z. Maybe just comment out all of the G1 lines after G1 Z125? So steppers off after the Z position and second filament retract.


#10

here is my end code. Nothing in here should make it behave the way it does at he end. AFTER all this code, it appears to perform some other actions described above.

End Code:
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off
G90 ;absolute positioning
G92 E0;
G1 E-1.5 F300 ;filament retraction before lifting nozzle
G1 Z125 F3000 ;move Z up a bit and retract filament more
G1 X0 F3000;
G1 Y125 F3000;
M84 ;steppers off


#11

So the drop is happened after End G-code (X = 0, Y = 125), then seems like it is not gonna hit the vase?


#12

It drops and then it goes Y=0 and Y=125.


#13

Very strange. In your End G-code you “G1 Y125 F3000” moves Y axis to 125 already, but you described it went Y = 0 and then Y = 125, the back and forth is apparently not the behavior of End G-code but rather some end behavior of Firmware.

Updated: Confirmed Firmware issue (v2.11). When stopped, there will be 3 movements: moves Z axis up 10mm, moves X axis to 0, and then moves Z axis down 10mm (back to stop position). When the model is higher than 115mm, the first movement will move the Z axis higher than 125mm, limited but it doesn’t know we don’t have a limited switch on Z+ direction, the third step will still move Z back to 115 (125 - 10). This is how Z drops.

What you can do to avoid this issue is to place your model a little bit right (X+) and avoid the Z drop collision.
We are focused on SM 2.0 develop and delivery so the SM Original firmware update will be deferred later.


#14

Understandable. Something to watch for though as you develop the SM2 firmware though. It effectively cuts a corner off of the workable volume.

Just a simple change in order would fix this (move Y before final Z movement) in the firmware.


#15

Don’t know if this helps but:
Remove the M84 Command as this turns off the stepper motors and once they are off there is nothing holding them in position so a heavy z-axis will slide down uncontrolled if your slides are a little loose. There is no reason to turn off the servo motors at the end of a program. Leaving them on will hold the last movement command.