Cura 14.12.1 not saving gcode on Ubuntu

[Algomorph]

System: Ubuntu 14.10 Cura: 14.12.1 from here: https://software.ultimaker.com/ Python: 2.7 Numpy: 1.9.1 Power: 1.4 PyOpenGL: 3.1.0 Pyserial: 2.7

Trace: Listening for engine communications on 49674 Exception in thread Thread-4: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 763, in run self.__target(_self.args, *_self.__kwargs) File "/usr/share/cura/Cura/gui/sceneView.py", line 318, in _saveGCode gcode = self._engine.getResult().getGCode() AttributeError: 'NoneType' object has no attribute 'getGCode'

Closing down Shader was not properly released! Shader was not properly released! Shader was not properly released! VBO was not properly released! VBO was not properly released!

Now, I would try to track down what the issue is, but so far I can't even build the .deb from the 14.12-hotfix branch, I get other errors when I try to do that. I can contribute some minor debugging effort if you would like me to, I code in Python as well.

[Algomorph]

Update: I was able to resolve issues with the .deb package. I'll be looking into the source shortly. Update: problem seems to be related only to scenes with multiple objects (i.e. multiple separate geometries in a single .stl). So far debugging revealed that the "runEngine" function in sliceEngine.py returns after hitting "if objMin is None:" on line 321/322.

At this point, since I see a potential work-around (exporting the model into separate .stl files, loading them one-by-one), I'm going to try that. Let me know if you need further help with debugging or want me to send a test file.

[daid]

Note that this could be a numpy problem, as I got a few odd reports a while back which we traced back to a bad numpy release. So first make sure all external packages are updated.

[Algomorph]

The Numpy 1.9.1 I mention above is the latest.

[Algomorph]

I don't have time to see if the work-around works just yet, but I'll keep you posted on that.

[nallath]

With python2 on ubuntu I have 1.8.2 (and don't have this problem). The python3 on my system uses 1.9.1. Some of the numpy version gave weird errors, which decreased when upgrading (but they are still there)

[Algomorph]

@nallath, the reason you don't have this problem is most likely that you aren't trying to use that kind of model file. Here's what I discovered. To my utter amazement, the software seems to be computing a convex hull for each model's base as you load it, and then uses this convex hull to determine how the pieces can be arranged on the buildplate. This poses a big problem in my case, so this is also a design issue. It's easy to explain if I can show you.

Here's the image of the model that causes the problem:

In this case, the brackets are arranged in an STL file with no overlap. I can see no physical limitations of the printer that would prevent this from being printed.

However, because of the strange convex-hull rule the program imposes, when I imported brackets piece-by-piece, I was only able to arrange a few like this (note that I'm missing a lot here, such a waste of space and print time):

I don't know if it's a limitation of the Cura Engine or of the Cura gui python wrapper, but it seems like a pretty serious limitation there.

P.S. direct link to problematic STL: http://algomorph.com/storage/DK2_Test_Bracket_Set_01.stl

P.P.S. It just dawned on me that it's possible I can actually pull through with the single-STL-file method if I pack the brackets closer together (i.e. leaving a thicker border around them to the edge of the build plate). Maybe that's the check that it fails.

[Algomorph]

I win!

However, I'm hesitant to close this, as we have identified two issues: 1) There is no immediate feedback to let the user know if his mesh fits within the bounds, which led me to believe this was a bug. (1A) - a text message whilst trying to export a model that "doesn't fit" would be helpful. (1B) - As you can see from the first illustration above, all pieces are on the buildplate, none overlap, and none touch the corners, so either there's an issue with processing them or the bounds of the build space aren't properly displayed.

2) The convex-hull approach in Cura to packing doesn't really work out, as you can see from illustrations 2 & 3. In other words, Cura should allow me to pack the brackets as in illustration 3, since the CuraEngine doesn't seem to think that is a problem.

I don't know how critical these are, I guess we can put these on the docket for the next release.

[nallath]

The reason for the convex hull is historic, we used to have AABB (axis aligned bounding boxes), so the convex hull was already a significant step up. If I recall correctly, it also has something to do with printing all at once or one at the time, as in the first case your method works, but in the second it can give problems.

[Algomorph]

@nallath , thanks for your input. Do you mean to say that printing the mesh in the third illustration may yield problems? What kind of problems are we talking here?

[nallath]

If your printing one at the time it wil first print the full object before going to the next it's possible to knoc over prints with your head. But a change not so long ago forces the print to all at once when one of the prints has a height above a certain level.

[Algomorph]

With all the objects stuck so hard to the buildplate that they require actually some force to get off, I don't think knocking over the prints can be a problem here. Besides, these brackets have such shapes that it's virtually impossible to knock any of them over. The print is going fine so far, I'll post the result later. In any case, I don't see a clear reason to stick to the convex-hull limitation, we should have an option for something better. I'll think about what algorithms can be used for this in my spare time.

[Algomorph]

The print-out is just fine.

@nallath: So, do I understand correctly: the "knocking over" problem was fixed recently with this change you're speaking off?

[frankvdh]

I'll reinforce that Algomorph's comment "There is no immediate feedback to let the user know if his mesh fits within the bounds" is a problem. As a new user, this confused me enormously. I think I've now figured that if the model is yellow, it's OK. If it's grey, then it's invalid.

But there's a second bug which added to my confusion; If you go to the File menu and choose "Save GCode..." on an invalid (grey) model, Cura will save the previous model's GCode with the current model's filename. :(

[Algomorph]

Should I close this and submit this elsewhere as a feature request (and, if so, where), or is this still considered a "bug"? It's technically just a major usability issue, but, in a sense, Cura behaves "as intended."

[BagelOrb]

@frankvdh you should create a separate issue for that, the saving-gcode-under-wrong-filename-problem has nothing to do with this problem. Please open a new issue.

[Feuermurmel]

It seems I'm running into a similar issue. The model below fails to slice because it is too big but this makes the command line interface crash with a similar error:

$ /.../Cura.app//Contents/MacOS/Cura --slice --ini /.../stuff/profile.ini --output /.../src/foo.gcode /.../src/foo.stl
load preferences from /.../Library/Application Support/Cura/15.04/preferences.ini
Failed to listen on port: 49674
Listening for engine communications on 49675
Traceback (most recent call last):
  File "/.../Cura.app/Contents/Resources/__boot__.py", line 316, in <module>
    _run()
  File "/.../Cura.app/Contents/Resources/__boot__.py", line 311, in _run
    exec(compile(source, path, 'exec'), globals(), globals())
  File "/.../Cura.app/Contents/Resources/cura.py", line 89, in <module>
    main()
  File "/.../Cura.app/Contents/Resources/cura.py", line 75, in main
    gcode = engine.getResult().getGCode()
AttributeError: 'NoneType' object has no attribute 'getGCode'
2016-01-18 20:56:34.722 Cura[30505:507] Cura Error