- User Since
- Mar 7 2017, 12:47 PM (102 w, 4 d)
Mar 5 2018
Jan 3 2018
I can't duplicate this on Windows 10 with the latest updates. Can we close this ticket and handle it as a support issue?
Dec 21 2017
Dec 15 2017
I can confirm seeing this happen on my OS X 10.11.6 system. This seems to be a known issue with unsigned apps. I see if happen with another app on my system as well. A workaround is to disable the firewall, but obviously not everyone wants to do that. We'll see if we can find a better solution or workaround.
Dec 12 2017
Dec 11 2017
We are not seeing this issue on any of the Windows 7, Windows 8, Windows 10, MacOS or Linux computers that we test on here.
The code uses the Qt framework and doesn't interact directly with the desktop environment.
There must be something different about your setup.
What theme are you using? Did you move the taskbar to a location other than the default bottom of the screen?
Does it make a difference whether the Cura window is maximized?
Are you using multiple monitors?
What type of video hardware do you have? We have seen issues due to OpenGL drivers.
Dec 1 2017
@Yahuba Note: By default on Mac it will not launch a second instance of an application. You need to follow these steps:
Nov 30 2017
Is this the "Pre-heat" button to the right of the Hotend temperature? Try in the 2.6.55 build. It looks like it is working again in that build.
I've updated it to remove the Google link.
Nov 29 2017
I found a way to do an automated conversion that works quite well. Take a look at this page:
I can't access that site. Is it available outside your network?
Nov 28 2017
We have run the app on Mac OS High Sierra and are not seeing any crashes.
Can you provide more details? If there is a crash log, please paste the details in here.
There should be a log file under your home directory in Library/Application Support/cura-lulzbot/2.6/cura-lulzbot.log
Or run it from Terminal (/Applications/cura-lulzbot.app/Contents/MacOS/cura-lulzbot) and send us the output.
Nov 27 2017
Alexei's Linux command will remove the Cura 1 settings too. Mine will not.
Is it possible some users might still want to keep their cura 1 settings?
Below are steps to remove the cached settings for previously installed versions of cura-lulzbot 2.x
I believe instructions were given to people in the past, but I wasn't involved so I'm not sure if the instructions were the same as these.
I can provide screen shots and/or more detailed steps if needed.
Yes, they are the same paths.
I can see a couple of different options for how we could do this:
On Windows the profiles are stored in:
Nov 14 2017
I'm now seeing Gradual Infill in the latest 2.6.46 build.
Nov 13 2017
FYI: That should be Mac OS 10.13.1, not 10.31.1.
Nov 3 2017
FYI: We have updated our internal test procedure.
Oct 24 2017
We spent significant time investigating this and trying signed binaries and were not able to suppress the install warning. According to our Mac expert, signing a binary will still generate a warning about it coming from the Internet and the user needs to confirm to run it. This is causing it to only launch the second time. There is no way around the warning unless the app is released to the Apple store. It will only happen the first time you run a given version.
@alexei Can you review the proposed change and check it in?
Oct 21 2017
Under Linux it is getting an error which calls an exception. The fix that works for me is to add an import of subprocess. I don't know why that is needed, since it is imported earlier, but it fixes the issue for me.
Without there is an error about an unset variable.
This patch should fix it:
Oct 20 2017
Yahuba report that the system is now going to sleep on Debian.
I just tried the latest 2.6.41 build on Debian and during printing the debug output shows:
Oct 19 2017
@Yahuba Please test it on Mac. It is working for me in today's 2.6.40 build. Note that the screen blank can still activate, but the system should not go into sleep mode during printing. I set the computer sleep time to a short value in order to test it.
Oct 17 2017
The cache files are all stored on a per user basis. When the application is being installed it is being run as root or adminstrator. We don't know, in general, what users on the machine would want their cache files removed.
We still have the original issue that clicking on a model and hitting <Delete> does not delete it, but now it is more obvious why because you can see that the translate tool has focus.
On Mac you can delete it with Control-H and this also shows up in the menus.
This is probably the best we can do for now. Maybe a future Cura version will come up with a better solution.
The code to call MacOS library functions is quite fragile and can break depending on the MacOS version. I have a simpler approach that calls the external program "caffeinate" to turn off the idle sleep.
See the attached updated file and patch.
Oct 16 2017
Oct 13 2017
I can confirm that this also happens for me.
There is code in Cura2 to prevent the Mac from going into sleep mode during printing, but it is not working (it throws an exception).
It looks like the code was taken with a few changes from Cura 1. It is working in Cura 1.
I don't believe it ever worked on Cura 2.
The code is in Uranium/UM/Qt/QtApplication.py
Oct 12 2017
If we reduce the modal window size in the theme, we can make it fit smaller screens (it adds scroll bars if needed). Changing model_window_minimum in resources/themes/lulzbot/theme.json to use the same size as the Ultimaker theme seemed to work well for me. I changed this one line:
Oct 11 2017
The changes b-morgan suggest look reasonable. Attached are screenshots on Windows and Linux.
I've attached a patch. @efilenko If this looks good to you, please apply the changes.
FYI: To see this UI, in the Print Setup pane, select Custom, and then scroll down.
This is what I see on Debian Stretch 9.2 with the default desktop.
I can't duplicate the problem you see - clicking on a file will select it. It might only be an issue on Debian Jessie.
This is for a LulzBot Mini. It might be different for a TAZ.
It doesn't seem to be finding a printer on any serial port.
Is this a known good printer and computer, i.e. that works from another OS like Debian or Windows?
Are you a member of the Linux group "dialout"?
Oct 6 2017
Good news! With the latest 2.6.38 build (date stamped 2017-10-06 12:11), I was able to perform a complete print on a Mac.
@Yahuba Also see the articles that Alexei referred to. One possibility for the problems on Debian is that you aren't added to the necessary Linux groups.
@efilenko I'm still seeing the problem on Mac with this change. I can also still duplicate it on Linux even with this change.
I am still not able to print, and see some errors related to objc:
Oct 2 2017
@efilenko In the screenshot, there is text that says "00h 00min 0.00 m / ~ 0 g".
It is very hard to read against the light colors in the print bed.
Can you tell me where that text color is set so we can experiment with using a darker color?
@efilenko Can you tell me where in those files is sets the color of the text over the bed plate area?
@Elena If you can tell me where in the code the color for this text is set, I'd like to take a look at it and then see if I can recommend a different color to use.
Sep 29 2017
@efilenko Can you identify where in the theme or code it sets this text color, so we can experiment with some different options?
It looks like this code stops the computer from sleeping during printing, which was a bug that was reported in the past. It is only done on the Mac platform. We should try to include PyObjc so that this feature will work.
@kaleb The file open dialog is a standard part of Qt, and depending on the platform it may use native dialogs.
We can't realistically fix this without writing a whole new custom file open dialog, and it then won't look native on some platforms.
You're on Debian - can you post a screen shot of the file open dialog? It may actually be using the Gnome file open dialogs on that platform.
You may need to wait for a 2.6.35 Mac build before you can verify it. Skip the "rm -rf ~/Library/Application\ Support/cura2_lulzbot" step in the procedure when you test it so that it sees the version has changed since the last time it was run.
Try using a recent build. It looks more visible to me, but it may be dependent on your monitor.
The units are in the tooltip, so how about making the text just " Flow Temperature Graph".
It is still not working. See my earlier comments - it seems to be related to the "Move" UX getting the event and I can cause it to happen on Linux as well if I enter a value in the Move dialog.
I looked further into this. The changelog is only shown if you have run Cura 2 before and the previous version was older than the one you are currently running. Since we normally clean all the previous settings when we test, the changelog is not going to be shown. To test this feature, you could install and run an older version of Cura 2. Then install and run a newer one without removing the settings.
Sep 28 2017
@Yahuba See if you can find a cura2_lulzbot.log file and paste the contents here.
It is typically in a location like
After manually fixing T1192, I am able to connect to a printer and send move commands, etc.
But printing does not work. I think the cause is a missing Python module. I see this in the logging output:
It looks like this will work now, but we can't test it until T1192 is fixed.
The cause of this issue is that this file is missing from the Mac OS install:
I am seeing this too.
I am seeing the version in 2.6.34. Make sure you use the 2.6.34 build from today, I think there was an earlier build that was also 2.6.34.
I noticed a typo in the code:
It should be StandardKey.Backspace
Sep 27 2017
The fix is not working on Mac.
It looks like maybe the Move UX is taking the event.
If I select another toolbar icon like Scale, Rotate, or Mirror then the Delete key does work.
But when I click on the object to select it, and Move gets selected, Delete stops working again.
Sep 26 2017
Now that T1170 is fixed, in build 2.6.33 under Windows 10 I can no longer reproduce this problem any more. Cura prompted me to upgrade the firmware.
Sep 19 2017
@Baldwin Can you check if this still occurs with recent builds, and if so, provide the steps you followed and your hardware and software platform details?
Sep 18 2017
It looks like this change was due to T1157, and is now working as intended. It should only ask to upgrade the firmware if the toolhead has actually changed.
I will update the test procedure to reflect this.
In my testing on Ubuntu, this was working up to and including version 2.6.24 and started failing (no toolhead dialog appearing) in 2.6.25.
@Yahuba Yes, please close this one.
Sep 15 2017
@Yahuba I think this is now fixed in our test procedure by removing any previous settings. Can you confirm if it now appears.
We suspect that the root cause for this is the same as T1170, so let's see if that fix addresses it.
See T1085. I believe this is the same issue.
Sep 13 2017
I can confirm that this is fixed for me in build 2.6.29.
I can confirm that it is no longer crashing on exit with version 2.6.28. Ubuntu Linux 17.04.
This is fixed for me in build 2.6.28. @Yahuba Can you confirm and then close the bug?
Sep 12 2017
I can confirm seeing this too. It seems to be a new issue that was not in earlier builds.
I am on Ubuntu 17.04 which currently uses libssl.so.1.0.0.
Here is part of the problem report I see:
I can confirm seeing this as well. It didn't happen in earlier builds.
@Yahuba Can you paste the details text from the Problem Report here?
@efilenko I can confirm that mm/s are the right units. This should be a simple change to make.
Sep 11 2017
@efilenko The suggested fix is not working for me. See more details in the email I sent.
@ Yahuba Please upgrade your firmware as per T1160 and then see how reproducible this is. I think this can be made a low priority. I have to go to a lot of effort, clicking on the move buttons many times, to cause it to occur now.
Can we clarify what is needed here?
Sep 8 2017
Just to clarify: It looks like the Python serial module is missing from the MacOS install. As far as I can tell it was never included and no MacOS Cura 2 builds have ever been able to communicate with a printer.
Part of the logging output reports:
ImportError: No module named 'serial.tools'
Note that bug T1160 is a different issue but can mask this one.
@efilenko Can you look at this one? I can only reproduce this on Windows. Maybe we need a longer timeout or more retries. If you have some proposed fixes or patches with additional debug code, I can test them for you if needed.
Sep 7 2017
Upgrading the firmware to 188.8.131.52 solved the issue.
I'll upgrade my firmware and retest.
FIRMWARE_NAME:Marlin 184.108.40.206 (Aleph Objects Inc.'s Phabricator) SOURCE_CODE_URL:https://code.alephobjects.com/diffusion/MARLIN PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot Mini EXTRUDER_COUNT:1 UUID:351487b6-ca9a-4c1a-8765-d668b1da6585
I've been able to reproduce it on two Windows computers. I see this in the log file: