Hi All,
Has anyone generated gcode in cura and then matched with snapmaker gcode for the same stl?
Thanks.
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.
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?
1 Like
@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.
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.
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.
1 Like
@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.
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.
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.
1 Like
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
So the drop is happened after End G-code (X = 0, Y = 125), then seems like it is not gonna hit the vase?
It drops and then it goes Y=0 and Y=125.
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.
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.
1 Like
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.
I received my SM and although I have only done 3D printing I am very impressed with the quality of the work.
I have also noticed that there are movements executed at the end of a print job that are not in the gcode, Because of space restrictions in my print area I prefer to have the bed move to the Y 200. position and remain there, but it always does the above described XYZ moves and ends up with the Y axis near the max value, that is, the table extended out beyond the front of the machine. I tested several options, removed the M84, added M02 (program end) and the movements persist, UNLESS you run the program via the serial USB cable, then the program executes as expected and degined by the gcode. If I run the exact same code from the flash drive THEN the moves take place, regardless of any code at the end of the program.
There must be a routine that is automatically executed whenever a program from the flash drive ends.
Can this be modified to avoid it ???
Has anyone answered your question? I have the same issue that my bed y moves all the way forward and I would like to modify the default end code to stop it in the middle so it doesnât stick off the edge of the table where someone walking by could hit it.
Alan
That should be controlled by the very last G1 line in the Luban gcode:
G1 Y160 F3000 ;so the head is out of the way and Plate is moved forward
You may have a different value for Y (I have an A150, so my bed size is 160mm). Anyway, if you want the bed to stop somewhere else, try adjusting the Y value in that gcode line.
I have not tested this.
Or stick an M600 pause command into the end gcode. That should hold everything in place indefinitely (although you may have to power cycle and refuse recovery to terminate the print).
No reply yet, I received email from âTracyâ on Aug 24 confirming problem as I described it and âI escalated the issue to the RD teamâ.
I am discouraged but if I get any reply with a solution I will share with you.
Regards.