Jump to content
SandervG

Introducing Ultimaker Cura 3.2 | Beta

Recommended Posts

Posted · Introducing Ultimaker Cura 3.2 | Beta

The initial layer height is always fixed because it's needed for proper bed adhesion. It also stays 1 step size above 0 to prevent empty layers. Since the default layer height here is 0.1 and the max. offset is 0.15 (totalling to 0.25), the initial layer heigh of 0.27 is still a little bit taller, so it appears in the spectrum. But the actual yellow part of the model will be 0.25 (except the first layer ofc). So indeed it's intended.

  • Like 2

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta
1 minute ago, ctbeke said:

The initial layer height is always fixed because it's needed for proper bed adhesion. It also stays 1 step size above 0 to prevent empty layers. Since the default layer height here is 0.1 and the max. offset is 0.15 (totalling to 0.25), the initial layer heigh of 0.27 is still a little bit taller, so it appears in the spectrum. But the actual yellow part of the model will be 0.25 (except the first layer ofc). So indeed it's intended.

 

Ahh that makes sense, of course not sure how that slipped my mind for some reason my brain was thinking that gauge was only showing the adaptive values not the overall model :/

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta
12 hours ago, ChrisRiddell said:

Just had a quick look and it seems to be grabbing the initial layer height lowering that value then gave me the expected max layer height.

 

OK, that explains the graphics.

I also understood the attitude a bit wrong, now everything is clear to me.

 

thanks

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

playing with tree support, I've found some problems shown in the image.

 

(a) lot of material. Why do not go straight to the point over other branches?

(b) and (c) who supports the support?

(d) too few support structures to sustain.

 

tree.png

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

Hello,   i just managed to get the beta up and running ..

 

Also had issues with old setup...crashing..  was solved by the renaming trick ..  ( in appdata/roaming...  ) 

Observations here:

 

Changelog wrong...still  3.1.0 

Still does not remember where it last saved Gcode..   default to nonsense "usbdrive" location instead of FOLDER . This i saw discussed in 3.10 threads..

 

I think the slowdown issues after slicing got a bit better at least here...  will test later with a bigger model..

 

 

 

 

 

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

So, I got the configuration translation issue, so I cleared the files. Now I can start the program, and thought I would add my printer. What happened to the Octoprint connector? I'm not even seeing a plugin for that.I know they did something new with it to make it more intergrated, but I am not even seeing any mention of it. Frankly, the improvements promised sound awesome, but this doesn't even feel like it's ready for Beta yet.

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

Okay, I found the plugin and got it functioning. Then I tried a sample slice with tree support. Boy, what a mistake. Ate up 2.5G of RAM trying to slice it, and got stuck half way through. For compairison, 3.1 sliced it in 1.6G of RAM and powered through it to the end with normal supports. Is this what we can expect with 3.2 overall, or are they working on tightening it up a bit? I get the feeling that if I used regular support 3.2 would still not be as efficient, and that was really causing me issues in 3.1 already. 3.0 was okay, but 3.1 fixed rafts and support interfaces so nicely, that I was willing to overlook some of the clunkyness. I'm not too keen on what I am seeing in 3.2 so far. the 3.1 beta was a lot more polished that this. Are they pushing this out too early? Will they have a beta update to clean a bit up before going production? I hope so. I like the promised features, but this release is a bit bloated and clunky.

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

Cura automatically adds temperature commands at the beginning of the gcode, if the variables are not found in the start script.

 

I just noticed, that the behavior has changed for 3.2 BETA. It now inserts the standby temperature for the inactive nozzle.

That leads to an issue, if the subsequent start script wants to prime the nozzle afterwards. It just does not work anymore, because the standby temperature is usually too cold.

 

Adding the available variables to the start script does not work either, because there's seem to be still no separate variables available for multi extruder machines.

 

Is this on the todo list? Or is there another way to heat up each extruder to its own configured temperature?

 

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

I have been using 3.2 for one day on Fedora Linux and observed the following:

 

1. The "lay flat" appears to always reorient to the original vertical. Not the closest plane.

2. When printing via USB starting a new job always fails complaining that the printer

    is not available. It then presents the option to abort. Clicking abort then allows a

    new print.

3. Using the default parameters the support material seems much more difficult to remove.

 

Comments in relation to 3.1.

 

The finished prints look better. Much less strings and the first layer is great.

Share this post


Link to post
Share on other sites
Posted (edited) · Introducing Ultimaker Cura 3.2 | Beta
On 2/3/2018 at 4:41 PM, tinkergnome said:

Adding the available variables to the start script does not work either, because there's seem to be still no separate variables available for multi extruder machines.

 

Oh, yes, there is. In the 3.2 beta, replacement patterns have been extended as follows: The replacement pattern is (optionally) extended with an extruder_nr: {setting_key,extruder_nr}. The extruder_nr can either be a number (-1 for the global stack, 0 or higher for an extruder), or a setting keyword such as support_extruder_nr etc. If an extruder_nr is not specified, the value is taken from the same stack as before.

  • {material_standby_temperature} in start gcode gets the (resolved) setting value from the default stack (the first used extruder), as before
  • {material_standby_temperature, 1} gets the value from the 2nd extruder (extruder nrs start at 0)
  • {material_standby_temperature, support_extruder_nr} gets the value from whatever extruder is set as support extruder

For details, see https://github.com/Ultimaker/Cura/pull/3068

 

One thing I realised just now, is that if you use {material_print_temperature, 1}, Cura will probably not recognise that as {material_print_temperature}, and as a result it will still add its own preheat sequence in front of the start gcode snippet. This should be easily remedied by putting {material_print_temperature} in a comment somewhere in the start gcode. I will try to get this fixed for a future release.

 

PS: yes, better release notes would be nice, mentioning changes and additions like this. A blogpost with highlights is not an alternative to proper release-notes.

 

Edit: I forgot to mention, there's also an 'initial_extruder_nr' pseudo setting that can be used as follows:

M104 T{initial_extruder_nr} S{material_print_temperature_layer_0, initial_extruder_nr}

 

Edited by ahoeben
fixed last example
  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

Groots! That gives much more control for multi extruder printers. Dank je wel!

 

And i agree - if Ultimaker likes to see more contributions - documentation is the key...

  • Like 1

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

I did two prints with the Beta 3.2.0 and an odd thing happened at the end of both: the printer nozzle was pressing down on the build for a couple of seconds before retracting, grinding the filament in the process, leaving the print with a nozzle-impression and some spaghetti on the top. I was using the adaptive layers function in both cases.

clip_filament (1).stl

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

About multi build plates,

1- Cura almost always freezes when I create 4 or 5 build plates sending parts to there (number of parts influences that, and also over only one plate).

2- Would be nice if each build plate could have different properties. All parts could be saved in one project.

3- Also would be nice to slice only the current build plate.

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta
On 1/30/2018 at 6:55 AM, Msuurmond said:

Can you describe what goes wrong? Or post a screenshot?

Just downloaded Cura 3.2 release. It's still coming up with "You have OS x 10.10.5. The application requires OS X 10.11 or later."

Share this post


Link to post
Share on other sites
Posted (edited) · Introducing Ultimaker Cura 3.2 | Beta
On 3.2.2018 at 5:31 PM, ahoeben said:

Edit: I forgot to mention, there's also an 'initial_extruder_nr' pseudo setting that can be used as follows:


M104 T{initial_extruder_nr} S{material_print_temperature_0, initial_extruder_nr}

 

Sorry,
maybe you have prescribed yourself?

(it does not work)

 

material_print_temperature_0 should read material_print_temperature_layer_0 ????

Edited by zerspaner_gerd
== changed to should read
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta
1 hour ago, zerspaner_gerd said:

material_print_temperature_0 == material_print_temperature_layer_0 ????

 

The programmer in me does not agree with your use of the == operator, but you are right, it should have been material_print_temperature_layer_0. I corrected the example in my comment.

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta

Great:D, it also works with:

switch_extruder_retraction_amount

 

Are all variables working?

 


Is there a possibility with this variable:

switch_extruder_retraction_speed

to work, so with mm / min in gcode spend.

 

49 minutes ago, ahoeben said:

The programmer in me does not agree with your use of the == operator

Oh sorry, just wanted to abbreviate it. I will change it.

Share this post


Link to post
Share on other sites
Posted · Introducing Ultimaker Cura 3.2 | Beta
8 hours ago, zerspaner_gerd said:

Are all variables working?

They should. All settings from fdmprinter.def.json.

 

8 hours ago, zerspaner_gerd said:

Is there a possibility with this variable:


switch_extruder_retraction_speed

to work, so with mm / min in gcode spend.

 

You can't change the unit easily. The setting should work, but the unit is mm/s. Could you clarify your usecase? If it is large enough, I think I can make a plugin.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited) · Introducing Ultimaker Cura 3.2 | Beta
On 18.2.2018 at 9:13 AM, ahoeben said:

You can't change the unit easily. The setting should work, but the unit is mm/s. Could you clarify your usecase? If it is large enough, I think I can make a plugin.

 

Is not so important.

G1 F{switch_extruder_retraction_speeds, 1} E-{switch_extruder_retraction_amount, 1} ;switch T1

 

Edit: If necessary, I could write a post processing plugin myself.

Edited by zerspaner_gerd

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!