MrHoax82: You mentioned that you were using KISSlicer. I tried it but could not get the gcode to produce anything more than a few stay lines on the cage 3D viewer and it does not print anything even though the code appears in the gcode text box. I am using Repetier 0.84. Any ideas are appreciated. Ricardo
Im using Cura whenever I can, but too many features are lacking to ditch slicer. Maybe they can be solved with plugins, but I cant find any plugins anywhere (other than the included pause plugin). Anyone know ?
THings Im missing in Cura:
- when printing the first solid layer over infill, cura will not enable the fan, and with very sparse infill, that will cause problems.
- Same with bridging, thats an even bigger problem. Bridging with no fan? Good luck with that.
- Not possible to set different numbers for bottom and top solid layers.
- cura doesnt distinguish between perimeters and small perimeters (like screw holes). Thats annoying, the latter typically needs to be printed slower, particularly on the first layer.
Some other things I cant think off right now. And perhaps not a missing features, but the auto fan settings confuse the hell out of me or doesnt work.
OTOH, being able to slice a complex STL in mere seconds where slicer takes 25 minutes for that very same object on my quad core desktop, well thats often worth manually adjusting the fan and speed during the print 
Have you downloaded the latest Cura?
It has a usefull pluging already built in.
At the bottom of this page there are also some plugins.
wiki.ultimaker.com/Category:CuraPlugin
[quote=“bour12@casema.nl”]I used the white PLA ini but still the printing starts at home point and not in the middle of the printbed although the print is in Cura in the middle?[/quote]A tip is to check if you have any G1 commands in your start g-code. If you have, change these to G0 instead. Cause if you have some G1 command with Z-position above initial Z-position generated by the slicer this command will be ignored cause G1 commands check so you’ll never lower Z-lever during a print that would cause crash in your printed object. I have had this problem myself when I wanted the printer to start a few mm above printbed and then lower down to start position of print to create nicer starts.
[quote=“bour12@casema.nl”]I used the white PLA ini but still the printing starts at home point and not in the middle of the printbed although the print is in Cura in the middle?[/quote]What’s in your start g-code? If there are any G1 command, change this to G0 instead cause G1 commands prevent Z-axis to move in wrong direction during print and this can cause the ‘move to middle’-start command to be ignored.
An other thing, have someone else noticed that Cura always tries to move too fast in z direction in the begining of a print?
An example G1 X86.354 Y111.857 Z0.3 F9000.0 is the first line in one of my prints. This force the z axis to move 0.3 mm but too fast when F is 9000. Maximum of F on z axis movements is set to 940.
The result of this is that all skirt starts with an extruded blob and I cant print multiple prints if I want to print one object at a time in Cura print planner.
Hi Snurre,
where did you find that value?
Cheers,
kuraasu
[quote=“kuraasu”]Hi Snurre,
where did you find that value?
Cheers,
kuraasu[/quote]Sorry, my misstake. The value is actually 960. 16 mm/s in advanced config = 960 mm/min (The F parameter in g-code has mm/min unit)
Hi Snurre,
I see, that makes much more sense. Thought you determined the max possible speed on your printer by testing.
The Z axis has a low max acceleration setting in the firmware (100 mm/s²), which effectively limits the speed for short distance moves, e.g. around 4 to 8 mm/s for usual layer changes.
Cheers,
kuraasu
[quote=“kuraasu”]Hi Snurre,
I see, that makes much more sense. Thought you determined the max possible speed on your printer by testing.
The Z axis has a low max acceleration setting in the firmware (100 mm/s²), which effectively limits the speed for short distance moves, e.g. around 4 to 8 mm/s for usual layer changes.
Cheers,
kuraasu[/quote] Yes, I agree with you there. 8 mm/s equals and F command with 480 mm/min but this just makes my question even more important. How can Cura generate a first line like this G1 X86.354 Y111.857 Z0.3 F9000.0 when the max z movement should be 480 or the 960 that I have (think this is from some standard Cura settings).
It usually work printing though if I start the print with the nozzle in zero-position of z axis but the problem is even bigger when trying to print several objects cause then I can’t control the movements from max z position in finished object to 0 position for the new object.
This causes the z-stepper to act really strange cause it’s a big difference between 9000 and 960 (or even low as 480 as recommended)
Hi Snurre,
[quote=“Snurre”]How can Cura generate a first line like this G1 X86.354 Y111.857 Z0.3 F9000.0 when the max z movement should be 480 or the 960 that I have (think this is from some standard Cura settings).
It usually work printing though if I start the print with the nozzle in zero-position of z axis but the problem is even bigger when trying to print several objects cause then I can’t control the movements from max z position in finished object to 0 position for the new object.
This causes the z-stepper to act really strange cause it’s a big difference between 9000 and 960 (or even low as 480 as recommended)[/quote]
that behaviour is expected. The set high feedrate isn’t important for short moves like 0.3 mm. However, when printing multiple objects sequentially, there are of course larger Z moves (downwards in that case) between the end of one object and the start of the next, and for those the acceleration-limit is not enough.
There are two possibilities to solve this. The first would be to get Cura to produce better G-code, for example by splitting up XY and Z moves, but I have no clue whether that’s possible at all. E.g. corresponding to your example above, a possible split code would be
G1 X86.354 Y111.857 F9000.0
G1 Z0.3 F960.0
The second option is to limit the maximum feedrate in the firmware to a value that will actually work. That way, any higher value given in a G1 command will have no effect. The default value is 50 mm/s (which is obviously too high); lowering it to 20 or 10 mm/s could to the trick. Note that every printer will have a slightly different limit, but with a few test moves at different speeds it should be easy to indentify the value. More about this here.
Cheers,
kuraasu
[quote=“kuraasu”]Hi Snurre,
[quote=“Snurre”]How can Cura generate a first line like this G1 X86.354 Y111.857 Z0.3 F9000.0 when the max z movement should be 480 or the 960 that I have (think this is from some standard Cura settings).
It usually work printing though if I start the print with the nozzle in zero-position of z axis but the problem is even bigger when trying to print several objects cause then I can’t control the movements from max z position in finished object to 0 position for the new object.
This causes the z-stepper to act really strange cause it’s a big difference between 9000 and 960 (or even low as 480 as recommended)[/quote]
that behaviour is expected. The set high feedrate isn’t important for short moves like 0.3 mm. However, when printing multiple objects sequentially, there are of course larger Z moves (downwards in that case) between the end of one object and the start of the next, and for those the acceleration-limit is not enough.
There are two possibilities to solve this. The first would be to get Cura to produce better G-code, for example by splitting up XY and Z moves, but I have no clue whether that’s possible at all. E.g. corresponding to your example above, a possible split code would be
G1 X86.354 Y111.857 F9000.0
G1 Z0.3 F960.0
The second option is to limit the maximum feedrate in the firmware to a value that will actually work. That way, any higher value given in a G1 command will have no effect. The default value is 50 mm/s (which is obviously too high); lowering it to 20 or 10 mm/s could to the trick. Note that every printer will have a slightly different limit, but with a few test moves at different speeds it should be easy to indentify the value. More about this here.
Cheers,
kuraasu[/quote] I doubt that this behaviour is really expected cause that makes it impossible to do better movement of the printer so you lift up the nozzle a few mm before you go to the start point of the actual object and lower the nozzle on the way to the target point. It would even had been better if no z movement was set in the first command and the slicer left the editor of start g-code to take responsibility of position nozzle in right height from start.
I will try to report this behaviour as a bug in the cura slicing but wanted to se in this forum before if someone knew a way to get rid of this bug.
The option to limit the maximum feedrate in the firmware is a plausable solution but bad for Cura that it doesn’t act correct on the settings provided. If the Cura slicer override the maximum z speed in combinated movements, the possibility to set this setting is useless.
Hi Snurre,
I’m not sure whether that’s really the case. Perhaps you can find out with a small test?
The movement mentioned had distances (starting from zero / home position, I hope that’s correct) of 86.35 mm, 111.86 mm, and 0.3 mm in X, Y, and Z direction, respectively. So the move is 141.31 mm in total. Using only the max feedrate of 9000 mm/min and no acceleration for this small calculation, the move should take 0.942 s. Thus, the max Z speed is only about 0.32 mm/s or 19.11 mm/min, which is well below the set Z feedrate.
If this is really the way Cura “thinks” (i.e. calculates, whether the Z feedrate setting has to be used or not), then you should see a difference in the G-code for an object that has its starting point near the home position. For example a move “G1 X1.8 Y1.8 Z0.3 F9000” would result in an effective Z feedrate of over 1050 mm/min, which is above the set limit of 960 mm/min and thus should result in either a slower movement (about F8200 for the above coordinates) or in a split-up between XY and Z moves with different feedrates.
Cheers,
kuraasu
[quote=“kuraasu”]Hi Snurre,
I’m not sure whether that’s really the case. Perhaps you can find out with a small test?
The movement mentioned had distances (starting from zero / home position, I hope that’s correct) of 86.35 mm, 111.86 mm, and 0.3 mm in X, Y, and Z direction, respectively. So the move is 141.31 mm in total. Using only the max feedrate of 9000 mm/min and no acceleration for this small calculation, the move should take 0.942 s. Thus, the max Z speed is only about 0.32 mm/s or 19.11 mm/min, which is well below the set Z feedrate.
If this is really the way Cura “thinks” (i.e. calculates, whether the Z feedrate setting has to be used or not), then you should see a difference in the G-code for an object that has its starting point near the home position. For example a move “G1 X1.8 Y1.8 Z0.3 F9000” would result in an effective Z feedrate of over 1050 mm/min, which is above the set limit of 960 mm/min and thus should result in either a slower movement (about F8200 for the above coordinates) or in a split-up between XY and Z moves with different feedrates.
Cheers,
kuraasu[/quote] If it was this way as you describe I would be more than happy. But the truth is that when I with Cura try to print multiple object each object start with this line to each startpoint at the new object (if I print one object at a time, not all at once). This means that with higher objects printed this z movement needed to reach next objects start point just increases and causes the printer to not be able to reach correct z-level and the print is a total mess. This is the main reason why I started to investigate this matter.
Does somebody has the settings for cura with a E3D hotend?
Because the normal settings doesn’t work with it.
[quote=“Citystars”]Does somebody has the settings for cura with a E3D hotend?
Because the normal settings doesn’t work with it.[/quote] Could you please give more information about what doesn’t work for you?
What is it that dosen’t work?
A different hotend shouldn’t affect the settings in Cura so that you can’t run your printer. At moust you need to change
the extruder temperature and you can easily change this setting in Cura printer settings.
When the printer wants to print something the extruder backs up the fillament and begins printing with cura.
Because of this there is no filament coming out and when the “outlining” is almost finished then slowly the filament is coming out.
Tested with repetier and works great, tested with cura doesn’t work.
[quote=“Citystars”]When the printer wants to print something the extruder backs up the fillament and begins printing with cura.
Because of this there is no filament coming out and when the “outlining” is almost finished then slowly the filament is coming out.
Tested with repetier and works great, tested with cura doesn’t work.[/quote]That sounds strange. Probably there’s something with
your start g-code. Could you post your start g-code in cura here so we can see if there’s something wrong.
I guess there is some error with the G92 command. Try to add G92 E0 at the bottom of the start G-code so that the zero-point for the extrusion is at startpoint of the printer.
If the printer still back up the filament when starting a print, check if there’s something in your G-code like G1 E-x or G0 E-x where x is a number in how much to backup.
I guess so.
Because i downloaded the new version of Cura and the start-code was changed and i didn’t have the problem anymore.
;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length againThis i what i have now.
Its practically the basic start-code you get when installing the new version of cura.
Do you have an better start-code?
[quote=“Citystars”]I guess so.
Because i downloaded the new version of Cura and the start-code was changed and i didn’t have the problem anymore.
;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length againThis i what i have now.
Its practically the basic start-code you get when installing the new version of cura.
Do you have an better start-code?[/quote]Sounds nice that the printer seems to work correct now.
I have made some suggestions on faster startup when printing here:
[quote=“SpackofiX”]I’ve the standard extruder which comes with the printer. If I set the extruder diameter to 0.5mm in Cura, there’s a little spacing between each line of filament. In Slic3r, I’ve set the extruder to 0.5mm and it just works fine, so I don’t know why Cura isn’t slicing good with the extruder set to 0.5mm.
In Cura, the object to print also isn’t placed in the middle of the printbed.
- SpackofiX[/quote]
I have no problem using cura without needing to lie to it about my nozzle diameter.