is it no longer a materials.txt on the SD card with overrides for the same settings a profile profile has in the plus firmware?
@foehnsturm, if it happens reliably with a certain model, could you give us a link to that model? If we can reproduce the issue it will be much easier to fix it ;-).
@MarcusWolschon, I was talking about adding a material to the dropdown in Cura 2.1, not about supporting said material in the UM2(+).
To be honest, I had no idea about the materials.txt file; I have a UMO myself, I am sometimes surprised by how things work with UltiGCode.
foehnsturm 970
@foehnsturm, if it happens reliably with a certain model, could you give us a link to that model? If we can reproduce the issue it will be much easier to fix it ;-).
For instance the robot https://www.youmagine.com/designs/ultimaker-robot--2 and the supplied dual extrusion base file.
Support Extruder=0 works
Support Extruder=1 even freezes with support disabled ...
The last lines of a super-lenghty error dump
Date/Time: 2016-05-04 12:58:30 +0200OS Version: Mac OS X 10.11.4 (Build 15E65)Architecture: x86_64Report Version: 22Command: CuraPath: /Applications/Cura.app/Contents/MacOS/CuraVersion: 2.1.0 (2.1.0)Parent: launchd [1]PID: 28222Event: hangDuration: 1.60s (process was unresponsive for 51 seconds before sampling)Steps: 16 (100ms sampling interval)Hardware model: iMac12,2Active cpus: 8Fan speed: 999 rpm--------------------------------------------------Timeline format: stacks are sorted chronologicallyUse -i and -heavy to re-report with count sorting--------------------------------------------------Heaviest stack for the main thread of the target process: 16 start + 52 (Cura + 3044) [0x100000be4] 16 main + 650 (Cura + 4474) [0x10000117a] 16 ??? (Cura + 10075) [0x10000275b] 16 ??? ( + 954763) [0x1041e918b] 16 ??? ( + 956993) [0x1041e9a41] 16 ??? ( + 767631) [0x1041bb68f] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806608) [0x1041c4ed0] 16 ??? ( + 790736) [0x1041c10d0] 16 ??? ( + 757757) [0x1041b8ffd] 16 ??? ( + 767631) [0x1041bb68f] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806608) [0x1041c4ed0] 16 ??? ( + 790736) [0x1041c10d0] 16 ??? ( + 224672) [0x1093c1da0] 16 ??? (<6E8DC006-7871-3101-8B7A-D6829ACF458B> + 1972853) [0x1081e1a75] 16 ??? (<6E8DC006-7871-3101-8B7A-D6829ACF458B> + 1960956) [0x1081debfc] 16 ??? ( + 135903) [0x10c3022df] 16 -[NSApplication run] + 682 (AppKit + 249476) [0x7fff8d50de84] 16 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454 (AppKit + 295722) [0x7fff8d51932a] 16 _DPSNextEvent + 1067 (AppKit + 298746) [0x7fff8d519efa] 16 _BlockUntilNextEventMatchingListInModeWithFilter + 71 (HIToolbox + 198063) [0x7fff8ca005af] 16 ReceiveNextEventCommon + 432 (HIToolbox + 198511) [0x7fff8ca0076f] 16 RunCurrentEventLoopInMode + 235 (HIToolbox + 198965) [0x7fff8ca00935] 16 CFRunLoopRunSpecific + 296 (CoreFoundation + 560856) [0x7fff9e357ed8] 16 __CFRunLoopRun + 927 (CoreFoundation + 562399) [0x7fff9e3584df] 16 __CFRunLoopDoSources0 + 556 (CoreFoundation + 565180) [0x7fff9e358fbc] 16 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 698497) [0x7fff9e379881] 16 ??? ( + 140177) [0x10c303391] 16 ??? ( + 137998) [0x10c302b0e] 16 ??? (<6E8DC006-7871-3101-8B7A-D6829ACF458B> + 1974770) [0x1081e21f2] 16 ??? ( + 221615) [0x1093c11af] 16 ??? (<13D4402F-4C94-34F9-9E32-8CE29992039F> + 209630) [0x1098ce2de] 16 ??? (<13D4402F-4C94-34F9-9E32-8CE29992039F> + 199035) [0x1098cb97b] 16 ??? ( + 221463) [0x1093c1117] 16 ??? (<3C217D3E-DF2D-30E3-80DF-A1948B1CE758> + 14400) [0x1074b9840] 16 ??? (<7F394314-DF14-3BEB-8F35-3E47E63138B2> + 18517) [0x104352855] 16 ??? ( + 804677) [0x1041c4745] 16 ??? ( + 52327) [0x10410cc67] 16 ??? ( + 128717) [0x10411f6cd] 16 ??? ( + 52327) [0x10410cc67] 16 ??? ( + 204240) [0x104131dd0] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806721) [0x1041c4f41] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806608) [0x1041c4ed0] 16 ??? ( + 792836) [0x1041c1904] 16 ??? ( + 52327) [0x10410cc67] 16 ??? ( + 204240) [0x104131dd0] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 792836) [0x1041c1904] 16 ??? ( + 52327) [0x10410cc67] 16 ??? ( + 204240) [0x104131dd0] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806721) [0x1041c4f41] 16 ??? ( + 770778) [0x1041bc2da] 16 ??? ( + 790465) [0x1041c0fc1] 16 ??? ( + 806608) [0x1041c4ed0] 16 ??? ( + 790736) [0x1041c10d0] 16 ??? ( + 8784) [0x107114250] 16 ??? ( + 58075) [0x1071202db] 16 std::__1::thread::join() + 23 (libc++.1.dylib + 286357) [0x7fff9c0aae95] 16 __semwait_signal + 10 (libsystem_kernel.dylib + 94474) [0x7fff99bf610a]*16 semaphore_wait_continue + 0 (kernel + 1029504) [0xffffff80002fb580]Process: Cura [28222]Path: /Applications/Cura.app/Contents/MacOS/CuraArchitecture: x86_64Parent: launchd [1]UID: 501Task size: 85943 pagesCPU Time: 1.505sNote: Unresponsive for 51 seconds before samplingNote: 2 idle work queue threads omitted Thread 0x64736f DispatchQueue 1 16 samples (1-16) priority 46 (base 46) 16 start + 52 (Cura + 3044) [0x100000be4] 1-16 16 main + 650 (Cura + 4474) [0x10000117a] 1-16
Edited by Guest
Hello!
Quick question, where can I find the print bed dimensions? I have a generic prusa i3 made by a chinse manufacturer and I wanted to be sure that the print area in Cura is correct for me, but I can't seem to find a place to check this. I tried to open the printed profile in the .cura folder, but the profile stored there does not have that information.
Thanks in advance
Check the .json file (https://github.com/Ultimaker/Cura/blob/2.1/resources/machines/prusa_i3.json)
It defines a 200mmx200mmx200mm size.
- 1
so for 5 materials and 7 nozzles I need 35 profiles per printer?
You could do it with 35 profiles, but it's also possible with 12 (7 "nozzle" profiles and 5 material profiles.)
Note that this is subject to big changes for the 2.2 release.
Care to share a bit more?Note that this is subject to big changes for the 2.2 release.
I really hope for some serious simplification.... getting rid of the nozzle vs material settings in the printer, and setting temp during slicing ....
Am I the only one who has issues with retraction not working at all?
Edited by Guest
Note that this is subject to big changes for the 2.2 release.
Care to share a bit more?
I really hope for some serious simplification.... getting rid of the nozzle vs material settings in the printer, and setting temp during slicing ....
We can't get rid of nozzle vs material settings. There are tons of settings that need to change depending on your nozzle / material selection.
Right now there are a number of issues with profiles. One of them is that we can only change values of settings (and not ratio's) depending on material / quality / nozzle. In 2.2 this will be possible.
Originally it was not intended for profiles / materials to be in 2.1 release, but they were added at a very late stage due to the release of the 2+
I was not clear. Sure we need it. Just think it's better to do it in cura and not in the printer. That way it's more visible and users will learn from it as they see the used profile settings. And we can get rid of the hassle of the setup of the material file in the printer.
Oh and it would probably result in a more unified experience between umo and um2....
Minor issue: font in menu looks weird.
The screenshot somehow looks better than the actual program, but I think it's still noticeable - especially compared to old Cura:
I'm using Windows 7 64Bit, ClearType is disabled.
I've tried to see if someone else had this already, but apparently there is no search in thread function? Or I simply missed it...
(Also, I realize this is a very minor issue compared to things like retraction problems or having to maintain dozens of profiles. But it's what jumped into my eye when I started Cura 2.1 and it's something I find highly annoying, to the point of actually not using a program if it's too much. It's not too bad in Cura, though. Or rather, Cura is important enough to endure it.
I know I've seen this before in other programs, so I blame Windows.)
Edited by Guest@Rejutka this is an odd one. It is not something I can reproduce. Could you show a screenshot with the Setting Visibility page of the preferences dialog open? I'm curious if that is also using the broken/wrong font.
It may be something related to your installation of Windows specifically (unless someone else is seeing the same?)
Update: it is because you have cleartype turned off. If you turn it on it should render correctly. Could you check?
I'm not sure if we will be able to do something about it, other than reporting it to the Qt project.
Edited by GuestReproduced it
Is it possible that changes in layer height and/or changes in infill amount at different stages of the print will be available in 2.2, @nallath ?
Interface suggestions:
In the 2.1 GUI when changing Infill Density % or Line Distance mm, it seems that either one directly affects the other, however the changed value of one doesn't show in the other. ie: If I change from 50% to 25% the Line distance increases, but in the Line Distance box I still see an unchanged length. I think it would help new users better understand infill variables if the changes showed up instantly in the numbers there.
Another not-intuitive GUI-related item is the Speed category. I typically use one speed for all sections of the print, so I didn't think it was necessary for me to enable the sub-category settings like: Infill Speed, Outer Wall Speed, Inner Wall Speed, Top/Bottom speed. But then when I started printing the file I noticed big changes were happening to print speeds. So then I went back to Cura 2.1, enabled the viewing of those settings, and realized they needed to be manually normalized. Maybe by default all those speeds could be the same, or all those fields should be visible by default? Otherwise more people will get surprises while printing I think.
Edited by GuestPause at Height works overall, but in Cura 2.1 the Pause code is written at the end of a layer, instead of at the beginning of a layer as it did in 15.04.x. This probably shouldn't make any difference, however there's now a weird movement line after the Pause.
So the printer pauses, then goes back to old spot on the previous layer, leaves a small blob, then goes on to a completely different place to start the next layer, and continues from there as normal.
If it's possible to eliminate that jittery motion it would be awesome. Right now I'm fixing it manually by removing the rogue movement line of the gcode, but I know I'm going to end up messing up a print or two in the long run if I do this manually (that's how it usually works when I edit code anyway)
Windows 10 here, if that makes any difference
Is it possible that changes in layer height and/or changes in infill amount at different stages of the print will be available in 2.2, @nallath ?
Nope
Interface suggestions:
In the 2.1 GUI when changing Infill Density % or Line Distance mm, it seems that either one directly affects the other, however the changed value of one doesn't show in the other. ie: If I change from 50% to 25% the Line distance increases, but in the Line Distance box I still see an unchanged length. I think it would help new users better understand infill variables if the changes showed up instantly in the numbers there.
Already implemented in 2.2
Another not-intuitive GUI-related item is the Speed category. I typically use one speed for all sections of the print, so I didn't think it was necessary for me to enable the sub-category settings like: Infill Speed, Outer Wall Speed, Inner Wall Speed, Top/Bottom speed. But then when I started printing the file I noticed big changes were happening to print speeds. So then I went back to Cura 2.1, enabled the viewing of those settings, and realized they needed to be manually normalized. Maybe by default all those speeds could be the same, or all those fields should be visible by default? Otherwise more people will get surprises while printing I think.
Fixed for 2.2
- 2
With pause I had the issue,
that during the pause gravity made sure all filament leaked out of the nozzle over time.
Then it resumed without pushing filament first and thus created a highly underextruded layer, breaking the object.
This makes it impossible to pause a long running print to catch some sleep and resume the next day.
Edited by GuestI don't think it has ever been the intention to pause for a full night... would also make no sense as you would be wasting much energy as the heated needs to stay on anyhow...
The use imho is material change and inserting objects like f.e. nuts.
When you use a custom feeder or the + feeder it's easy to manually push some fillament to prime the nozzle.
I don't think it has ever been the intention to pause for a full night... would also make no sense as you would be wasting much energy as the heated needs to stay on anyhow...
The use imho is material change and inserting objects like f.e. nuts.
When you use a custom feeder or the + feeder it's easy to manually push some fillament to prime the nozzle.
It should be possible to change the script in such a way that this works (eg; retract before pause and prime after) . But most people do short pauses, so the current implementation is geared to them.
Edited by GuestHi, I'm having a weird issue when changing the Infill Density to 100%, it updates the shell layers out of proportion
Because there isn't really a bottom layer any more. If I recall correctly, the density of 100% is faked by setting all layers to bottom layer (and thus being fully filled)
Edited by Guest
Recommended Posts
Top Posters In This Topic
64
34
23
16
Popular Days
Apr 15
24
Jul 1
18
May 2
14
Apr 14
13
Top Posters In This Topic
nallath 64 posts
MarcusWolschon 34 posts
ahoeben 23 posts
nilrog 16 posts
Popular Days
Apr 15 2016
24 posts
Jul 1 2016
18 posts
May 2 2016
14 posts
Apr 14 2016
13 posts
Posted Images
foehnsturm 970
Sorry to say, but Cura 2.1 doesn't work reliable with dual extrusion used for support (Mac OSX 10.11.4) (I know dual support is not official yet)
Just take a machine profile which allows to set "support_extruder_nr" (like the sample dual_extrusion profile). Slicing with support activated and support_extruder_nr=0 works well. Same settings but support_extruder_nr=1 makes the slicing process freeze after some time. This occurs not with all but with like 90% of the stl files I tried.
Edited by GuestLink to post
Share on other sites