Why don't you use Cura slicer?
-
one thing with cura as I think I found yesterday a friend of mine said that if he tried to reprint a part sliced in Cura his printer went haywire and doing some very funny moves. Checking his code file found this at the end of it
M82 ;absolute extrusion mode
M107
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
M107 ; Pump Off
G91 relative positioning
G1 Z200
M83 ;relative extrusion mode
M104 S0
;End of Gcodethis is his end script
M104 S0
M140 S0
M106 S0
;Retract the filament
G92 E1
G1 E-1 F300
G1 Z200 F6000
;G28 X0 Y0
;M84 Turn Off Stepperswhy is Cura putting that G91 in the ending part of the code file?
so do beware of that, not sure if it his config or not as I don't use Cura myself
Doug
-
Interesting, as far as I can tell, the G91does not get generated by the back end so it must be coming from the front end and that could either be because the front end code generates it or it is in the printer profile or the user has put it into a script.
I notice two things in the above gcode: (1) there is no ; between the G91 and the following comment and (2) the line above the G91 has a comment that includes the word Pump which cannot be found in the Cura git repos so I think that's something the user has put in (maybe along with the G91?).
-
OK got to the bottom of it he had that G91 line in one profile not the other! doh I have told him off lol
Sorry for the trouble.
-
This is the STL I looked at:
https://www.dropbox.com/s/73grb7v7kluomer/pb4-vmon-enclosure-tube.stl?dl=0
Sorry, I know nothing about multi-part printing with Cura other than I know that it can support up to 8(?) extruders.
Cheers for that. I tried the stl in the link and the sliced gcode from Slic3R looks fine.
Sorry to be a pain but if you get chance, could you try slicing this stl https://drive.google.com/file/d/1KkKqj7XFhuZ5ue1plYmIRYN014zYtFcB/view?usp=sharing. It's simply hollow cylinders of various sizes. I sliced it just as one or two perimeters (can't remember which) with no infill so all the segments for given cylinder should be the same but here is a random sample of the resultant gcode file from Slic3R.G1 X181.823 Y172.046 E0.08974 F2700.000
G1 X181.670 Y173.055 E0.08900
G1 X181.455 Y174.056 E0.08924
G1 X181.180 Y175.043 E0.08926
G1 X180.847 Y176.008 E0.08898
G1 X180.656 Y176.489 E0.04517
G1 X180.238 Y177.417 E0.08871
G1 X179.759 Y178.330 E0.08978
G1 X179.222 Y179.216 E0.09037
G1 X178.651 Y180.043 E0.08757
G1 X178.338 Y180.456 E0.04515
G1 X177.684 Y181.240 E0.08904
G1 X176.984 Y181.983 E0.08895
G1 X176.613 Y182.344 E0.04511
G1 X175.849 Y183.021 E0.08901
G1 X175.043 Y183.653 E0.08927
G1 X174.200 Y184.234 E0.08922
G1 X173.327 Y184.762 E0.08900
G1 X172.871 Y185.010 E0.04517
G1 X171.956 Y185.456 E0.08871
G1 X171.005 Y185.850 E0.08978Just looking at the "E" values, every now and then there is an odd one that's about half the value of the others. I haven't looked at the XY coordinates but I'd guess that the odd "E2 values are due to equally odd segment sizes.
It doesn't do it with every cylinder. Some are spot on, some have larger variances that those above - really strange.
Anyway, I'd be interested to know what Cura does with that file (or any other slicer come to that).
Thanks
-
Sorry, I only have small printers, your cylinders won't fit on the build plate. Can you put them inside each other please or otherwise arrange so that the overall area is reduced.
-
I put your sample of gcode into craftware (great gcode viewer) and most of the line segments were empty because the extrusion amounts are so ridiculously small (like less than 1um of extrusion). I don't know what your steps/mm are but I would be surprised if you have sufficient extruder resolution to be able to print that line at all, let alone good quality.
-
I put your sample of gcode into craftware (great gcode viewer) and most of the line segments were empty because the extrusion amounts are so ridiculously small (like less than 1um of extrusion). I don't know what your steps/mm are but I would be surprised if you have sufficient extruder resolution to be able to print that line at all, let alone good quality.
Not sure what you mean by that. It's a high res file for sure but those extrusion amounts are mostly around 0.08mm (roughly 80 um), which at around 400 steps per mm is 32 steps. It prints fine except when I enable pressure advance.
-
I put your sample of gcode into craftware (great gcode viewer) and most of the line segments were empty because the extrusion amounts are so ridiculously small (like less than 1um of extrusion). I don't know what your steps/mm are but I would be surprised if you have sufficient extruder resolution to be able to print that line at all, let alone good quality.
Not sure what you mean by that. It's a high res file for sure but those extrusion amounts are mostly around 0.08mm (roughly 80 um), which at around 400 steps per mm is 32 steps. It prints fine except when I enable pressure advance.
Ooops, yes, my bad, totally ignore that last comment from me.
-
Ooops, yes, my bad, totally ignore that last comment from me.
No worries.
So I've just been playing around with OpenScad and Slic3R. Created a very simple cylinder, diameter 100mm, height 0.9mm (3 layers). Sliced it with no solid layers, no infill and just a single perimeter. So basically just giving one circuit 100mm diameter. Initially I set $fa to 0.5 and $fs to 0.5. If I understand it correctly, that should generate segments every 0.5 degrees but limit the smallest segment size to 0.5mm. When I sliced it, the resultant gcode file had a lot of variations between each segment. I then progressively changed $fs in 0.5 steps, rendered and sliced. As the segment size increased, the variations in the gcode became less. When I got up to 2.5 mm segment length, there was no noticeable difference between the individual segments in the gcode file.
So that's very odd slicer behaviour.
If you can find time can you run this stl through Cura https://drive.google.com/file/d/1WIgDLucrZK6HuzopwRnsGSMnyaPR0nD3/view?usp=sharing
It's a very simple hollow cylinder 100mm diameter, single perimeter, no solid layers, no infill. In theory the segment size should be about 1mm. Slic3R shows wild variations between each of these segments. e.g:
G1 X228.900 Y161.126 E0.10235
G1 X229.215 Y163.083 E0.10233
G1 X229.452 Y165.053 E0.10240
G1 X229.540 Y166.038 E0.05104
G1 X229.659 Y168.018 E0.10240
G1 X229.699 Y170.000 E0.10233
G1 X229.659 Y171.982 E0.10233
G1 X229.540 Y173.962 E0.10240
G1 X229.452 Y174.947 E0.05104
G1 X229.215 Y176.917 E0.10240
G1 X228.900 Y178.874 E0.10233
G1 X228.507 Y180.819 E0.10239
G1 X228.282 Y181.782 E0.05104Cheers
-
Indeed, with Cura, the segment size is very close to 1mm with approx +/- 1 micron variation in extrusion length per segment. The only exceptions occurred once per revolution where 1 segment was longer than the others so I assume that's what gets left over when openscad divided up the circle. The long segment appeared in the same position on each wall and layer. Here's some of the gcode to compare:
;TYPE:WALL-OUTER
G1 F2400 X34.738 Y35.613 E0.04107
G1 X34.017 Y36.301 E0.04143
G1 X33.289 Y36.97 E0.04111
G1 X32.546 Y37.626 E0.04121
G1 X31.789 Y38.268 E0.04127
G1 X31.019 Y38.895 E0.04128
G1 X30.237 Y39.506 E0.04126
G1 X29.443 Y40.101 E0.04125
G1 X28.638 Y40.68 E0.04123
G1 X27.82 Y41.243 E0.04129
G1 X26.988 Y41.792 E0.04144
G1 X26.154 Y42.32 E0.04104
G1 X25.304 Y42.833 E0.04128
G1 X24.441 Y43.331 E0.04142
G1 X23.571 Y43.811 E0.04131
G1 X22.697 Y44.27 E0.04104
G1 X21.805 Y44.716 E0.04146
G1 X20.914 Y45.14 E0.04102
G1 X20.005 Y45.55 E0.04146
G1 X19.096 Y45.938 E0.04109
G1 X18.177 Y46.31 E0.04122
G1 X17.245 Y46.666 E0.04148
G1 X16.315 Y46.999 E0.04107
G1 X15.375 Y47.314 E0.04122
G1 X14.423 Y47.613 E0.04149
G1 X13.471 Y47.891 E0.04123
G1 X12.518 Y48.149 E0.04105
G1 X11.554 Y48.389 E0.0413
G1 X10.58 Y48.611 E0.04153
G1 X9.616 Y48.811 E0.04093
G1 X8.64 Y48.993 E0.04128
G1 X7.656 Y49.157 E0.04147
G1 X6.679 Y49.3 E0.04105
G1 X5.695 Y49.423 E0.04123
G1 X4.703 Y49.527 E0.04147
G1 X3.714 Y49.611 E0.04127
G1 X2.729 Y49.675 E0.04104
G1 X1.733 Y49.72 E0.04145
G1 X0.741 Y49.744 E0.04125
G1 X-.248 Y49.749 E0.04112
G1 X-1.239 Y49.735 E0.04121Hope this helps.
-
BTW, looking at your small sample of gcode I can see that the extrusion rate is the same for all of the segments. So although some don't extrude as much, they are correspondingly shorter and so the rate remains the same.
-
BTW, looking at your small sample of gcode I can see that the extrusion rate is the same for all of the segments. So although some don't extrude as much, they are correspondingly shorter and so the rate remains the same.
Many thanks for that. I note that your E values are all lower than mine but that is easily explained by the fact that my default nozzle size is 0.5mm while I believe yours is 0.4mm.
It seems that Cura is doing a better job of keeping the segment sizes all the same. Ref the issues with Slic3R, yes I agree that the extrusion rate is proportional to the segment size but that the segment size itself varies. It seems to do a few segments all one size but then chuck in the odd small one. That's probably what is triggering pressure advance part way round an arc which in turn leads to the problems I've been having, especially with high pressure advance as is needed when trying to print at high speed with multiple extruders running.
It looks like it's time I took another look at Cura. If it handles multi part objects or has some means whereby I can assign different tools (colours) to different sections of an object then it'll be ideal.
Thanks again.
-
Hi folks, the Cura thread has popped up again with some interesting news that's actually related to the original intent of this thread.
Just letting you know that Cura 3.3 beta has been released today with a whole bunch of new features (and new bugs, of course). A couple of items you may be interested in are:
1 - experimental bridge settings that let you frig speeds/flows/fans etc. when printing bridges and overhangs. This is one of my efforts.
2 - experimental support eraser - this gui feature let's you position blobs where you don't want support to be created so it's a step towards having full-blown manual editing of support. This isn't my work.
If you try 3.3 beta out and have any feedback, please post on the Cura forum (https://community.ultimaker.com/forum/108-cura-plugins/) or github (https://github.com/Ultimaker/Cura) rather than here.
I have written a few notes about the bridging here https://community.ultimaker.com/topic/22195-introducing-the-experimental-bridging-settings/
-
Is there a way to change the size of the support blocker or to have it applied to an entire surface? The default setting is very large and leaves an odd rectangular area that is well beyond where I want the support to be blocked. S3D had an option to change the size of the supports or removal of supports. Cura has definitely gone a long way once you turn on all the options.
It would be nice to have options for speed based on a percentage from the max speed, but I can set profiles. The only issue I see with the profile is that it does not define all the speeds. If I set a bridge wall speed, there is no option to change it in the "global settings" tab. I only see an option to "Enable Bridge Settings". Its not a show stopper, but it would be nice to have all the speed settings for every option in the profile settings so the user don't have to dig through the config to set them for each profile.
In the layer view, I don't see an option to show the retraction locations. Maybe I just didn't pick the right options. It would be nice to see the rectraction locations to adjust the settings to optimize if needed. S3D shows the location as a big blob so it makes it easier to see. I really like Cura's option to show the travel path. There is a slider to change layer and to show the motion within the same layer with a separate slider. That is a nice feature.
Its definitely looks like it can compete with S3D.
-
Its not a show stopper, but it would be nice to have all the speed settings for every option in the profile settings so the user don't have to dig through the config to set them for each profile.
Well, it's an experimental feature right now and that's why the settings are all in the experimental section rather than being in the sections that they could ultimately end up in.
-
Its not a show stopper, but it would be nice to have all the speed settings for every option in the profile settings so the user don't have to dig through the config to set them for each profile.
Well, it's an experimental feature right now and that's why the settings are all in the experimental section rather than being in the sections that they could ultimately end up in.
That was just an example. There are lots of other speeds in the custom or advance settings that is not populated in the profile section.
ie:
Wall Speed- outer wall
- inner wall
Support Speed
-support infill
-support interface
-initial layer speeds
Skirt/Brim Speed
If there was an option to set the speed are based on a percent from a max print speed, it would be easy to change one parameter and have all the other speeds relative to that print speed.
-
Ah, I see what you're saying. I guess that the Cura devs don't think that way. Actually, I don't either but that's irrelevant.
-
Hi folks, the Cura thread has popped up again with some interesting news that's actually related to the original intent of this thread.
Just letting you know that Cura 3.3 beta has been released today with a whole bunch of new features (and new bugs, of course). A couple of items you may be interested in are:
1 - experimental bridge settings that let you frig speeds/flows/fans etc. when printing bridges and overhangs. This is one of my efforts.
2 - experimental support eraser - this gui feature let's you position blobs where you don't want support to be created so it's a step towards having full-blown manual editing of support. This isn't my work.
If you try 3.3 beta out and have any feedback, please post on the Cura forum (https://community.ultimaker.com/forum/108-cura-plugins/) or github (https://github.com/Ultimaker/Cura) rather than here.
I have written a few notes about the bridging here https://community.ultimaker.com/topic/22195-introducing-the-experimental-bridging-settings/
Thanks for this! I use a slightly older version of cura often so i will try the update.
-
That is how S3D sets the speed parameters in relation to the print speed. It would definitely be a feature that would make the transition from S3D to Cura a lot smoother. I really like Cura and the option for ironing the surfaces. I'll play around with it and hopefully switch over once I am happy with the print quality. I really like S3D 4.0's new feature with variable infill for thin walls. It makes filling in small gaps a lot smoother and the machine does not have to make quick jerk movements to fill small gaps in the previous revisions. I haven't played with Cura enough to see if there is a similar function.
-
Just coming back to say that I've been making an effort to use Cura more with the latest releases and I'm happy to report that some of my prior complaints have been resolved.
The new bridging parameters especially have been a big help. It's not as plug and play as Slic3r, there are a lot of settings to tweak and tune, which is both good and bad. The defaults worked good for me on short spans, but poorly on longer ones. Somehow Slic3r always seems to automatically do well, but with some more testing I think I will have a good handle on it. With the Tweak at Z plugin, you could vary the bridging settings as dictated by sections of the model. It's not automatic, but I appreciate the configurability.
My next favourite aspect of Cura is the per move type jerk and acceleration settings. It's helped shave quite a bit of time off prints while still maintaining quality where it matters. And the time estimates are more accurate.
Firmware retraction support can be added with a plugin now, but it would be nice to have that in the main release.
The variable layer height functionality is there now and works well, though it is more automated than I'd like.
There is still no small perimeter speed setting to help with holes, but I've found using lower acceleration values works well enough to allow for good small hole performance and still allow for higher speeds on straight perimeters.
My biggest complaint right now is GUI performance and slicing speed. Even using the menu tree can be a frustrating experience at times, and certain models with certain combinations of settings can result in very long slice times. Over 30 minutes at times! My laptop is a top of the line MacBook Pro from 2013. A little dated now, but Slic3r chews through the same model in less than a minute. As I said this is likely due to certain settings causing slicing to slow down so much. Optimizing perimeter order, try different line thicknesses, etc which slic3r lacks. So I am getting what I ask for, but even with default settings slicing is slow enough that enabling auto slicing is just asking for frustration.
All and all it's come a long way since my last list of complaints and I look forward to seeing where it goes from here. This is in no small part thanks to @burtoogle Good work!
