New v17 release of Cura LulzBot Edition enters Beta TODAY

Major new features:

Known issues:

Where to provide feedback:

How to provide feedback:

  • Unhelpful: “This software sucks, fix it.”
  • Helpful: “I’m using Cura Version 17.04 on Debian. When printing in t-glase with the High clarity profile on my (known working) LuzlBot Mini the quality (picture here) is not as good as when using a layer height of XXX (picture here).” Problems get fixed much faster with detailed bug reports like this.

Download here:
http://devel.alephobjects.com/software/cura/packages/test/

Happy Beta testing,
~Nick

Just added .RPM build and .TAR.GZ of source code

We now have an OSX build

OSX version crashing on startup in OSX 10.10.5.

Full details sent via PM to NickTheTait (has detailed system info so I’m not posting in the open forum).


Chazz

Well, I tried PM’ing Nick, but apparently he doesn’t accept PM’s. I will wait until my account is approved for Phabricator. However, I may not be able to post the full crash report (will have to see what the access looks like).


Chazz

Swapped my account to accept PMs now. Wasn’t aware that I had turned that off, sorry! Thanks for reporting this issue to us.

We now have a new build 17.10 which includes:
Updated quickprint profiles (located issues in a few nylons)
Documented UI bugs are all resolved now
Fixes for a few other minor issues that were discovered this week

Only platforms for 17.10 are Debian and Windows so far.

Have a great weekend!
~Nick

Thanks, Nick. I have posted to Phabricator under T47 and also sent you the full crash report via PM.

Also added a bug report, which I should have done in the first place!

I also tried installing on my MacBook Air with the same results (I have had issues with getting 123D design to run on the MBP but it will run on the MBA so I thought I would give this a shot).


hemocyanin: Have you tried running on your Mac yet?


Chazz

Just gave it a shot, OS X 10.10.5 on an older iMac (core2 duo 3ghz). It wouldn’t launch. I tried a clean install after using find to root out anything cura related and rebooting, no dice. I’ll PM you the crash report.

Two things I noted, don’t know if they matter. The new Cura crashes before it creates the default config folder and file in Library/Application Support. Also, in the app itself, in Resources, there is a link named “include” which directs to a file I don’t have ( /Users/ao-osee/.virtualenvs/curad/include ).

Got the report; looks like the same issue as mine. Phabricator log notes a similar issue going back to August 5th.

I did figure out what was crashing 123D Design on the MBP; I had a third monitor running and either the hardware (USB3 to HDMI/DVI adapter plugged into my Thunderbolt dock) or running three monitors was the cause: unplugged the adapter and 123D started up fine. It’s not the dock, since 123D crashes with the adapter plugged into a USB port on the MBP, too. Now I need rearrange my hardware so I can use the extra monitor with the MBA!

I confirmed the 17.04 build was not working on OSX 10.10.5 but did run on OSX 10.10. I’ve rebuilt 17.10 which should now work with OSX 10.10.5. Here is the build: http://devel.alephobjects.com/software/cura/packages/test/Cura-17.10-MacOS_10.10.5.dmg

Unfortunately this one crashes on my MBP also (and the MBA, too).


Chazz

I got it running on my machine, OS X 10.10.5. :wink: … but not without issue:

Out of the box, it would crash before it even got to writing the Cura library folder.

I poked around inside Cura.app again, and noticed that the python version called for in Info.plist is 2.7.10, my system only had 2.7.3, so I went to the Python website and downloaded and installed the newest version. Still crashed.

I noticed again in the plist file though, a similar to thing to the include link I mentioned before:

                <key>PythonExecutable</key>
                <string>/Users/ao-osee/.virtualenvs/goob/bin/python</string>

I tried messing with PyRuntimeLocations immediately above PythonExecutable, but failed at that. Eventually I just went for brute force, created the /Users/ao-osee/.virtualenvs/goob/bin/ folder and then made a link named “python” to my python executable, then made the link executable. Bang, got to setup, and I’m printing out a Rocktopus this very instant!

EDIT: it isn’t necessary for the link to python to be executable. Permissions of 440 are nice and restrictive.

hemocyanin, thank you for the feedback! That gives us quite a bit more info to track down the problem. We should have a new build to test in the next day.

Cool – I’m glad it was useful. I’ve been using the new version all day and I love it so far. Those pesky UI issues that always bothered me seem to be gone. :slight_smile:

One issue remains for me – on long print jobs (more than 3 or 4 hours) the software sort of crashes. It finishes the job fine, but the program has to be force-quit after completion. This is true of the previous version too.

I’m fairly certain, but will check in the morning to be positive, that when you come back to a long print job and it is in that half-crashed state, that if you turn off the printer before doing anything to Cura, that you can then close the control window and then close the program normally.

hemocyanin, that has been a known problem for quite some time, even in Ultimaker’s upstream version. Here is the bug report for it https://code.alephobjects.com/T43 As you mention, printing is still possible, but it is annyoing to have to force close Cura afterwards. It has not been fixed yet. :frowning:

Verifying that behavior could help in solving the problem. Thanks for bringing that up.

hemocyanin, we’re still tracking down the exact cause and could use some more feedback. Did version 15.02.1-1.03 work for you without the changes you made to make 17.10 work?

The info.plist file in 15.02.1-1.03 also called for python 2.7.10. It also had that line showing the harcoded path of the virtualenv but from the previous build machine.

Side note first – turning off the machine on a half-crashed Cura had no effect. Maybe I imagined it.

TL:DR – I can type random words for PythonExecutable and Cura17 runs if I have the “/Users/ao-osee/.virtualenvs/goob/bin/python” link to “/usr/bin/python”. It seems the need for that python path exists elsewhere in the program.

As for the Python virtual environment, I never used 15 on my Mac, I did use 14 though.

Info.plist for Cura 14.09:

        <key>PyRuntimeLocations</key>
        <array>
                <string>@executable_path/../Frameworks/Python.framework/Versions/2.7/Python</string>
        </array>
        <key>PythonInfoDict</key>
        <dict>
                <key>PythonExecutable</key>
                <string>/Volumes/MacintoshHD/Users/graphmastur/.virtualenvs/cura2/bin/python</string>
                <key>PythonLongVersion</key>
                <string>2.7.8 (default, Nov 15 2014, 12:22:56) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)]</string>
        </dict>

Very interesting that a virtual environment for Python in Cura 14 was no issue. It always ran fine, UI issues aside.

I should mention that before I recreated the virtual environment path and a link to python for 17, I had tried just to identify the PythonExecutable as “/usr/bin/python” – which failed. I tested that again today to make sure I remembered right, and something interesting happened. So to be clear, this how I have Cura 17 Info.plist set:

PythonExecutable
/usr/bin/python

Cura loads and works if the link “/Users/ao-osee/.virtualenvs/goob/bin/python” exists on my filesystem, but fails if that link does not exist. That sort of suggests that the existence of this python link in that specific location is important somewhere else in the program and whatever I did the other day with Info.plist wasn’t really the root of it. In fact, I just changed the “/usr/bin/python” string to “autumnIsHere” – which I know is not an executable on my system, and Cura 17 still loads up fine with that python link in place (but instacrashes if I remove it).

Between the fact that Cura 14’s Info.plist contains similar virtual environment stings, and the irrelevance of whatever I type for PythonExecutable, the need for the “/Users/ao-osee/.virtualenvs/goob/bin/python” link to exist, must be related to something elsewhere in the program.

Last, probably not pertinent but just in case – my executable paths are:
/Library/Frameworks/Python.framework/Versions/2.7/bin: (this differs from Info.plist: PyRuntimeLocations in both 14 and 17, but 14 always worked – it’s one the things I mentioned trying to change in Info.plist in my previous post)
/usr/local/bin:
/usr/bin:
/bin:
/usr/sbin:
/sbin:
/opt/X11/bin

Sorry to jump into this thread but I’m also interested in getting cura 17 on the mac. I noticed a difference between 15.02 (which works) and the 17beta by comparing the file structures. In the beta, there is a file “Cura.app/Contents/MacOS/python” that simply links to “/Users/ao-osee/.virtualenvs/goob/bin/python” which would explain why hemocyanin got it to work by putting a python executable there.

In 15.02, there is a python binary at that location but I’m not sure which version because it doesn’t run from the command line.

I can get 17beta to run by changing the link to point to the system python framework (version 2.7):"/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python"

Hope this helps track down the issue, and I’m happy to dig around more if it is helpful.