Cura 15.01-RC8

[Daid 306]

Just uploaded RC8 to:

http://software.ultimaker.com/Cura_closed_beta/

Compared to RC7, this contains changes for:

* New version of TweakAtZ from Dim3nsioneer

* Improved memory handling a bit, so big models slice a bit better (less chance of "MemoryErrors")

* Fixed UltiGCode plugin handling (material and time was not filled)

* Finally fixed the #F_AMNT# and friends tags in the start GCode.

* Added 3D clips to the UM2 bed, and fixed the clip sizes on the right size. You have slightly more print area now.

* Added the single-layer-view button by pm_dude

* Fixed a few minor issues

New UM2 firmware update:

* Added option to change material when the print is paused, still a bit experimental, the feature works fine. But I'm not happy about the menus just yet.

* Made "PauseAtZ" function the same as a pause on the printer menu. (So you can use the above feature with the PauseAtZ plugin)

* Few tweaks on the dreaded "HEATER ERROR"

* Temperature display jitter removed (by TinkerGnome)

* Fixed the "umlaut" bug for SD files. See: http://umforum.ultimaker.com/index.php?/topic/9093-special-chars-in-filenames-printing-with-ultictrl/

New UMO firmware update:

* Fixed the "umlaut" bug for SD files. See: http://umforum.ultimaker.com/index.php?/topic/9093-special-chars-in-filenames-printing-with-ultictrl/

We are closing in on a new official release. So this can be considered very stable.

 

[IRobertI 520]

I have a bug for you regarding slicing where two flat surfaces are close to each other in the z-axis. Here's a Gcode-file and the STL:

https://www.dropbox.com/s/d8zd44i76zb4h45/example_for_daid_replicator_block.gcode?dl=0

https://www.dropbox.com/s/fmim13hsodwheku/example_for_daid_replicator_block.STL?dl=0

If you look in layer view at the lower right area where the custom support meets the main body of the part there's some weirdness going on. I put a solid top on the support piece to create a better looking surface of the main part but something strange is happening. I get a solid top, followed by a couple of layers of infill, followed by the air gap (as it should be), followed by some infill lines, followed by solid. It should be solid - gap - solid.

 

[Daid 306]

That bug has been around forever. It's an optimization thing. If the "gap" is smaller then the top/bottom thinkness, strange things happen in the top/bottom skin.

 

[IRobertI 520]

Oh, poop. I guess I've never run into it before. Too bad, I really wanted to improve the bottom surface there. Since it has been around forever I guess we can't expect any fixes in that area?

I really need to spend some time getting another slicer up and running for fringe cases like this.

 

[chrisr 18]

That new "Heater error" catches me out every time. I'm using a custom fan shroud and I've got to be careful to keep the fan speed below 40% (when the nozzle is printing close to the bed) or else it cools the nozzle down too much and up pops the error.

When the nozzle's above 2-3cm over the plate there's no problem. Think I read on the forums another thread about the wash from the fan kicking back up to the nozzle (with custom shrouds) or something similar...

Just thought it worth pointing out here for anyone else using custom fan shrouds. :-)

 

[dirkdirk 5]

Would it be possible in the future that the mac version of cura is not identified with the yellow tag ?

 

[Daid 306]

Would it be possible in the future that the mac version of cura is not identified with the yellow tag ?

I think that's the "this developer is not known by apple" warning. Which is a horrible move for small independent developers.

Every time you see that flag, remember yourself, that if Apple has it's way, then Cura would never have seen the light of day. As Cura started in my own free time, with zero funding. See the tag as a "I bought equipment from a company that wants to restrict freedom" tag.

 

[dirkdirk 5]

I think that's the "this developer is not known by apple" warning. Which is a horrible move for small independent developers.

Every time you see that flag, remember yourself, that if Apple has it's way, then Cura would never have seen the light of day. As Cura started in my own free time, with zero funding. See the tag as a "I bought equipment from a company that wants to restrict freedom" tag.

sorry, but english is not my native language so I understand possibly not the sarcasm or jokes. But in any case cura is the only program that has this tag, whether verified developer or not. The tags are, for example, to sort of specific personal files that can be quick accessed by the finder with tags. And the yellow tag of cura not fit in there with me. And every time cura gets an update i have to uncheck the yellow tag again. (right click ->tags..->disable yellow tag)

http://www.maccomputerlessons.com/how_to_use_add_edit_coloured_tags_names_finder_sidebar_apple_mac.htm

http://macs.about.com/od/Mavericks/fl/Using-Finder-Tags-in-OS-X.htm

 

[eldrick 65]

I've had exactly the same problem as ChrisG with a custom fan shroud.

 

[IRobertI 520]

Hi Robert,

can you post a picture of that issue you are talking about? For me it looks good in Cura 14.09, .12.1 and RC7

I may be missing the point though...

Try loading the GCode file I supplied into cura (you can just open it like a normal file) and check the layer view there. It will be very obvious when you check around those layers you posted a picture of.

 

[IRobertI 520]

You opened and sliced the STL. I can tell because there's brim visible in your screenshots and I didn't use brim when I sliced There's no spiralize involved. Either way, daid has already said that it's a known issue.

 

[pm_dude 27]

New UM2 firmware update:

* Added option to change material when the print is paused, still a bit experimental, the feature works fine. But I'm not happy about the menus just yet.

* Made "PauseAtZ" function the same as a pause on the printer menu. (So you can use the above feature with the PauseAtZ plugin)

 

Awesome. Cant wait to test that.

In addition to the list above:

- Pause At Z now have a move Z parameter

- I added a SD Card folder replication in the Preference window. I still have a few things to add to help this but for now you can set a base folder from which you work and what ever folder structure you have in there will be replicated if the STL file that generate the gcode come from those folder.

 

* Added 3D clips to the UM2 bed, and fixed the clip sizes on the right size. You have slightly more print area now.

 

UM2 layout look like this now in RC8. Is it normal?

 

[chrisr 18]

UM2 layout look like this now in RC8. Is it normal?

 

I think that offset of the printing space to the left is to show where the (single) print head can reach to.

 

[pm_dude 27]

make sense

 

[anon4321 16]

:sad: We HBK owners have clips too ....

 

[pm_dude 27]

Daid, is the test for the clip now have a max height that could allow printing over the clips if the model have a slope?

[brictone 0]

I think this has come up before but is it possible to compile cura for 64bit windows? I've been printing more and more highpoly models, 1million+ and the slicing quits when the curaEngine.exe hits about 4gb of RAM.

I can scale the model down or use larger layer heights or reduce the poly count but all of which reduces the quality I'm going for.

Is there a step by step on compiling it for 64bit? or does this require some significant code revamp?

 

[Daid 306]

I think this has come up before but is it possible to compile cura for 64bit windows? I've been printing more and more highpoly models, 1million+ and the slicing quits when the curaEngine.exe hits about 4gb of RAM.

I can scale the model down or use larger layer heights or reduce the poly count but all of which reduces the quality I'm going for.

Is there a step by step on compiling it for 64bit? or does this require some significant code revamp?

 

The latest official release has a bug with high poly models, causing it to use a lot more memory then needed. The beta solves this problem (not sure which RC had this patch).

I'm actually using a 3mil poly model for testing these issues now. And that model slices fine. But, if you have a model that still crashes the CuraEngine with the latest RC, send a copy of the model in my mail (I never share any models that I get from other people, not even in the office, so it's safe with me) at d.braam@ultimaker.com

And the engine compiles fine in 64bit. As it runs as a 64bit application on linux and OSX.

 

[Daid 306]

:sad: We HBK owners have clips too ....

 

Yes, but they are not in the build space for the UMO.

 

[anon4321 16]

Yes, but they are not in the build space for the UMO.

 

Oh, I didn't think about that...

Never mind, move along, nothing to see here....

 

[pm_dude 27]

@Brictone, regardless of the model triangle density just make sure the density per cm is not too high for the printer to handle. Just 3 days ago, one print couldn't reach the 50mm/s speed due to high density. I think it didn't go above 20mm/s. The model was just 100k faces but it was 60mmX10mmX3mm.

@Daid, would there be a way to detect that? In a shader view (similar to a texel density shader) or in the layer view maybe. Showing sections where there are so many codes that the target speed will not be achieved.

 

[brictone 0]

@Daid, I actually just tried the model with the new beta and it did slice at .04mm, so yeah you really did fix the bug. I even tested it at .02mm, it used more memory but still sliced. Then the final nail in the coffen I tested it at .01mm and it failed when the memory usage hit 3.4gb or so. This is obviously not my goal printing at .01mm but just pushing the limits on this 1.5million poly for you.

One other thing, Not sure if it's possible but thought it would be a nice feature. Would it be possible to either implement a delay after changing a setting, like Scale or rotate layer height, before it attempts to re-slice? I know the slicing is extremely fast it just chokes up for a few seconds before allowing the change. Maybe an non-default option to click to slice? For now my workaround is to change as many settings before I even load the part so I don't have deal with the delay. Has this been brought up before? What do you think?

Thanks for a great slicer!

 

[pm_dude 27]

The change in the bounding volume is quite costly with large objects. Its true it would be good to have some freedom before the validation code or heavy computation start so the user can play around with the rotation and scale. Maybe pushing that part to another thread (making the object invalid in the meantime?).

 

[Daid 306]

One other thing, Not sure if it's possible but thought it would be a nice feature. Would it be possible to either implement a delay after changing a setting, like Scale or rotate layer height, before it attempts to re-slice? I know the slicing is extremely fast it just chokes up for a few seconds before allowing the change. Maybe an non-default option to click to slice? For now my workaround is to change as many settings before I even load the part so I don't have deal with the delay. Has this been brought up before? What do you think?

 

There is a 0.5 second delay already. But in the released version there are still some bugs causing less then optimal behaviour, with the beta it should behave a bit better already.

Also note, the slowdown when scaling/rotating is due to boundary box calculations, not the slicing process starting. (Something pretty much impossible to change in the current code architecture without causing a shitload of other bugs)

 

[jweaver 2]

I went to download RC8 last night and found RC9 so took that instead.

I did my first print and it was fine, but I left CURA running afterwords.. Came into the study this morning to find my PCs fans running flat out.. Looking at Taskmanager, CURA/Python was using 25% of memory (even though it was idle) and when I tried to exit, it hung (Not Responding)

It could be a co-incidence.. But I have done 100s of prints with 14.12.1 and now this happened on my first attempt with 15.01.RC9. Infact, during the entire time I was using 14.12, I don't think it crashed on me once.

I obviously need to do more testing, but I just thought you might be interested...

Jon