Cura 2.3 Beta Awesomeness and Some Issues

[ungutknut 4]

Hi There,

When i try to download 2.3.0 Beta it loads a file called... 2.3.0 beta but installs 2.1.99 master something. Can you help  or can you tell me where to dowload latest build for 2.3.0 beta thanks.

 

I've got the same problem. When I start 2.3 beta the splash screen says 2.1.99 master something but the welcome-message says 2.3 beta. Help-->about says 2.199, installer says 2.1. This is confusing.

Strangely this only happens on the windows (64bit) installation - the one for linux (.deb 64bit) displays the version numbers correctly.

[berndjm 16]

@ungutknut:

this is not a bug - this is a feature

Make sure that "Mesh Fixes" --> "Union Overlapping Volumes" is not checked

[ungutknut 4]

@ungutknut:

this is not a bug - this is a feature

Make sure that "Mesh Fixes" --> "Union Overlapping Volumes" is not checked

 

Thanks for that advice! Yes, that was the cause for my problem. *facepalm*

[ahoeben 1,948]

We're sorry about the 2.1.99 confusion. An internal build seems to have gotten posted to the public server by accident. The good news for you is that it has a number of fixes in it that the official beta doesn't have. That bad news is that it has some other bugs, and it says that it is 2.1.99.

[yellowshark 153]

Hi @nallath @SandervG I wonder if you can pass this onto the appropriate developer(s) – I was not sure if I should use the support system to report a bug with a beta release of software. In 2.3 there seems to be a bug in the g-code compiler/generator with command G1 and probably G0 (RepRap treats them as the same command) and the calculation of the travel speed.

It worked on 15.04.4 but fails with 2.3.

The travel speed entry in Cura, both 15.04 and 2.3 uses the units mm/s.

In 15.04.4 the placeholder {travel_speed} was used – or at least that is what I used and it worked. In 2.3 it does not work.

Firstly, it generates the g-code G1 F{travel_speed}.

Cura printer End gcode

G91 ;relative positioning

G1 E-1 F300 ;retract the filament a bit before lifting the ;nozzle, to release some of the pressure

G1 Z+0.5 E-5 X-20 Y-20 F{travel_speed} ;move Z up a bit and retract filament even more.

Result

G91 ;relative positioning

G1 E-1 F300 ;retract the filament a bit before lifting the ;nozzle, to release some of the pressure

G1 Z+0.5 E-5 X-20 Y-20 F{travel_speed} ;move Z up a bit and retract filament even more

@ahoeben kindly suggested I try the place holder {speed_travel}; this partially worked.

 

Cura setting

[media=21114][/media]

Cura printer start code

G1 F{speed_travel}

M117 Printing...

Result

G1 F200

M117 Printing...

With my travel speed set to 200mm/s in Cura, it generated G1 F200. This is wrong because G1 uses the units mm/m and it should have generated G1 F12000 (Cura travel speed * 60).

My printer is not a UM printer. I generated a custom printer and selected RepRap Marlin/Sprinter as the firmware, the same as I had in 15.04.4. Under the same conditions 15.04.4 correctly generated G1 F12000.

[nallath 1,120]

The {speed_travel} simply puts the direct value of the travelspeed there (which is in mm/s), without attempting to do any form of conversion.

[yellowshark 153]

The {speed_travel} simply puts the direct value of the travelspeed there (which is in mm/s), without attempting to do any form of conversion.

 

Fine, but the point is really that {travel_speed} is not working. At the moment whenever I slice I now have to go into the gcode and change several lines of code because they should be saying F12000 but they say F{travel_speed}. It is a real PIA, especially when it worked fine on 15.04.4 and prior versions. It is not the only thing that does not work now with the gcode generator, but did work in previous versions but I can live with the other two because Cura now generates them automatically where I need them.

[ahoeben 1,948]

At the moment whenever I slice I now have to go into the gcode and change several lines of code because they should be saying F12000 but they say F{travel_speed}.

 

What if you use F{speed_travel} instead? In Cura 2, many of the variable names changed (for consistency). See the names in fdmprinter.def.json

Edit: ow, wait, you're already doing that.

Edited October 11, 2016 by Guest

[ahoeben 1,948]

How badly do you need the travelspeed in your start and end gcode to depend on the setting you can set in Cura? Why not simply hardcode the value in the start and end gcode?

[crystaldragon141 0]

I have a bug where the slicer leaves out the infill on small features.

Update: I thought I'd add that the infill isn't bonding to the wall properly. It seems to be leaving a little gap. I can post up a picture of an actual print if necessary.

Edited October 13, 2016 by Guest

[Titus 170]

Haven't gotten to printing stuff, but the GUI looks nice, all the material settings, and adding printers. This beta is one hell of an upgrade for power/commercial/industrial users. Cura maturing into a product no longer perfect for enthousiast, but also for mainstream/large scale users.

Had some trouble with Cura freezing up for a second or 10 upon loading some models, before it started slicing. Others went really fast. I believe a rough surface quality of the model messes the slicer up. But hey, that's to be expected right? Can send you the model, it seems to have disappeared from Thingiverse.

1 other thing I noticed was that it couldn't open gcode files and display the layers. Even gcode generated from this version of Cura.

[ahoeben 1,948]

1 other thing I noticed was that it couldn't open gcode files and display the layers.

This is planned for a future release.

[yellowshark 153]

How badly do you need the travelspeed in your start and end gcode to depend on the setting you can set in Cura? Why not simply hardcode the value in the start and end gcode?

Lol I did that couple of days ago. As an ex IT developer I do not like hardcoding variables as it will come back in the future to catch you out. But yes, given that travel speed is rarely changed, albeit I changed it for the first time a couple of weeks ago testing nGen, I can live with it

[yellowshark 153]

How badly do you need the travelspeed in your start and end gcode to depend on the setting you can set in Cura? Why not simply hardcode the value in the start and end gcode?

Lol I did that couple of days ago. As an ex IT developer I do not like hardcoding variables as it will come back in the future to catch you out. But yes, given that travel speed is rarely changed, albeit I changed it for the first time a couple of weeks ago testing nGen, I can live with it

[ahoeben 1,948]

Note that I'm only talking about travel speed in the start and end gcode (ie: while starting and finishing the print), which should have no effect whatsoever to the print quality during printing.

Edited October 14, 2016 by Guest

[yellowshark 153]

Note that I'm only talking about travel speed in the start and end gcode (ie: while starting and finishing the print), which should have no effect whatsoever to the print quality during printing.

 

That is OK, so am I 8)

[crystaldragon141 0]

bump

 

I have a bug where the slicer leaves out the infill on small features.

Update: I thought I'd add that the infill isn't bonding to the wall properly. It seems to be leaving a little gap. I can post up a picture of an actual print if necessary.

 

[neotko 1,417]

Well it isn't a bug. It can't fill a gap that isn't proportional to the nozzle line setting. You can force to overextrude by increasing the infill gap. Or just change the wall line size until it fits. Measure the distance between walls and split it by two or three, use that number for the walls and it should work.

Edited October 19, 2016 by Guest

[DaHai8 74]

OK, perhaps not a bug, but I'd like it to be an enhancement.

I see this issue when the Wall Line Count is set to > 1 and the width of the wall in my object is between 2x and 3x my Nozzle size. As you say, this produces a gap less than the Nozzle size...

However, it would be really sweet if Cura could automatically decrease the flow rate (or Line Width) for those gaps to the percentage needed to fill it in.

The odd part (that makes me think this is a bug), is that: If I set the Wall Line Count to 1, Cura will fill in those gaps - even if it is less than the Line Width / Nozzle size). So...why does it not do that for Wall Line Counts > 1 ??

And it is usually not desirable to print the entire Object with a Wall Line Count = 1.

Edited October 19, 2016 by Guest

[ChrisRiddell 13]

Now that Cura 2.3 is stable is it worth plugging in the UM2+ and running the Extensions > Update Checker ?

Or is it the same as version 15.04.7-RC5 (as shown on my UM2+ screen under maintenance) ?

[00D00B 58]

Hi,

Just have a question about printcost calculator.

Having the weight estimation back is pretty cool but why can't we change all the cost per filament in material profiles ? Something coming up later ?

[the_mechanical 0]

Performance Issue / Idea

I'm using Cura 2.3 Beta under Linux since it's here, I'm relatively new to 3D-Printing, so I don't know Versions before 2.1.

I'm fighting with performance under Linux because I usually print small parts. These are often one model which were duplicated more times in Cura. Every time an action is done Cura is automatically slicing. If you have more than 1 part and duplicate it Cura tries automatically to rearrange. Your arrangement made by hand is destroyed (especially when you have for example 10 small parts or more it is really annoying) and it takes a lot of ressources. As soon this is done, slicing begins. But if the count and arrangement isn't done these needed resources are only time wasting (and not too little).

Would it be possible to start slicing not before the positioning and editing the Print Setup is done? I could imagine a "Start Slicing" button, and maybe a checkbox if slicing shoud be done immediately or after pressing the button.

Another idea would be a duplication/arrangement where you can define the count and the order f.ex. 10x, 5 rows and 2 colums, with given distance or automatically calculated distance.

Similar to the arrangements how used in CAD-Systems.

If these things already exists and i have not seen it, please tell me ;-)

Maybe worth thinking about it.

Thanks

[crystaldragon141 0]

Well it isn't a bug. It can't fill a gap that isn't proportional to the nozzle line setting. You can force to overextrude by increasing the infill gap. Or just change the wall line size until it fits. Measure the distance between walls and split it by two or three, use that number for the walls and it should work.

 

That may be, but I don't think that's the case because I don't have that problem with 2.1 or Slic3r. Actually I've temporarily switched to Slic3r until 2.3 final is released because it is ruining my prints, it's way too weak where it doesn't fill. It's also not properly bonding the walls and the infill which is also different from 2.1.

update: I see that 2.3 final is in fact now released. I'll test it out and see if the issue is resolved.

Edited October 19, 2016 by Guest

[neotko 1,417]

Old cura slices at the nozzle size 0.4. New cura uses 0.35 with a 0.4. So you actually need to open the hidden settings by default and edit the line width

[peggyb 169]

Downloaded the 2.3 version and tried a dual print with PVA, just to see what happens..

The temperature for PVA says: 215 degrees... Thought this melted (according to the data sheet) around 160...?