Cura: Some platforms renders missing with numpy-stl

Created on 3 May 2017  路  30Comments  路  Source: Ultimaker/Cura

Application Version: 2.5.0
Platform: Linux Fedora 25
Qt: 5.7.1
PyQt: 5.7.4
Display Driver: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)

Steps to Reproduce:
Install numpy-stl.
Add printer Kossel Mini (or Prusa i3 Mk2 or maybe others, but not all). Observe the platform.
Uninstall numpy-stl and repeat.

Actual Results:
With numpy-stl:
kossel2

2017-05-03 17:54:28,564 - WARNING - cura.Settings.ExtruderManager.getMachineExtruders [404]: Tried to get the extruder trains for machine Kossel Mini, which doesn't exist.
2017-05-03 17:54:28,564 - WARNING - cura.Settings.ExtruderManager.getMachineExtruders [404]: Tried to get the extruder trains for machine Kossel Mini, which doesn't exist.
2017-05-03 17:54:28,599 - ERROR - UM.Logger.logException [74]: Exception: Job <UM.Scene.Platform._LoadPlatformJob object at 0x7f5727f01320> caused an exception
2017-05-03 17:54:28,607 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-03 17:54:28,609 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 71, in load
2017-05-03 17:54:28,610 - ERROR - UM.Logger.logException [78]:     fh, header, speedups=speedups)
2017-05-03 17:54:28,610 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 214, in _load_ascii
2017-05-03 17:54:28,610 - ERROR - UM.Logger.logException [78]:     return _speedups.ascii_read(fh, header)
2017-05-03 17:54:28,610 - ERROR - UM.Logger.logException [78]:   File "stl/_speedups.pyx", line 129, in stl._speedups.ascii_read (stl/_speedups.c:2752)
2017-05-03 17:54:28,611 - ERROR - UM.Logger.logException [78]: RuntimeError: (0, "Can't read vertex (4:b'vertex 59.3699 -83.2773 -42.8')")
2017-05-03 17:54:28,611 - ERROR - UM.Logger.logException [78]: 
2017-05-03 17:54:28,611 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-03 17:54:28,611 - ERROR - UM.Logger.logException [78]: 
2017-05-03 17:54:28,611 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-03 17:54:28,612 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/JobQueue.py", line 122, in run
2017-05-03 17:54:28,612 - ERROR - UM.Logger.logException [78]:     job.run()
2017-05-03 17:54:28,612 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/Scene/Platform.py", line 120, in run
2017-05-03 17:54:28,613 - ERROR - UM.Logger.logException [78]:     self.setResult(reader.read(self._file_name))
2017-05-03 17:54:28,613 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 40, in read
2017-05-03 17:54:28,613 - ERROR - UM.Logger.logException [78]:     self._loadWithNumpySTL(file_name, mesh_builder)
2017-05-03 17:54:28,613 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 71, in _loadWithNumpySTL
2017-05-03 17:54:28,614 - ERROR - UM.Logger.logException [78]:     loaded_data = stl.mesh.Mesh.from_file(file_name)
2017-05-03 17:54:28,614 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 318, in from_file
2017-05-03 17:54:28,614 - ERROR - UM.Logger.logException [78]:     fh, mode=mode, speedups=speedups)
2017-05-03 17:54:28,614 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 87, in load
2017-05-03 17:54:28,615 - ERROR - UM.Logger.logException [78]:     name, data = cls._load_binary(fh, header, check_size=True)
2017-05-03 17:54:28,615 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 104, in _load_binary
2017-05-03 17:54:28,615 - ERROR - UM.Logger.logException [78]:     count, MAX_COUNT)
2017-05-03 17:54:28,615 - ERROR - UM.Logger.logException [78]: AssertionError: File too large, got 841888568 triangles which exceeds the maximum of 10000000
2017-05-03 17:54:28,964 - DEBUG - UM.Qt.Bindings.Theme.load [126]: Loading theme file: /usr/share/cura/resources/themes/cura/theme.json
2017-05-03 17:54:29,032 - DEBUG - UM.Qt.Bindings.Theme.load [186]: Loaded theme /usr/share/cura/resources/themes/cura
QObject::connect: Parentheses expected, signal MainWindow::
QObject::connect: Parentheses expected, signal MainWindow::
QObject::connect: Parentheses expected, signal MainWindow::
qml: TableViewSelection: index out of range
qml: TableViewSelection: index out of range
2017-05-03 17:54:29,397 - DEBUG - UM3NetworkPrinting.DiscoverUM3Action._createAdditionalComponentsView [134]: Creating additional ui components for UM3.
2017-05-03 17:54:29,436 - DEBUG - UM.Mesh.MeshData.calculateNormalsFromIndexedVertices [433]: Calculating normals took 0.0022058486938476562 seconds
2017-05-03 17:54:29,447 - CRITICAL - cura.CrashHandler.show [36]: An uncaught exception has occurred!
2017-05-03 17:54:29,448 - CRITICAL - cura.CrashHandler.show [39]: Traceback (most recent call last):
2017-05-03 17:54:29,448 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/cura/CuraApplication.py", line 653, in event
2017-05-03 17:54:29,448 - CRITICAL - cura.CrashHandler.show [39]:     return super().event(event)
2017-05-03 17:54:29,449 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Qt/QtApplication.py", line 216, in event
2017-05-03 17:54:29,449 - CRITICAL - cura.CrashHandler.show [39]:     event._function_event.call()
2017-05-03 17:54:29,449 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Event.py", line 187, in call
2017-05-03 17:54:29,449 - CRITICAL - cura.CrashHandler.show [39]:     self._function(*self._args, **self._kwargs)
2017-05-03 17:54:29,449 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Signal.py", line 305, in __performEmit
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]:     func(dest, *args, **kwargs)
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Scene/Platform.py", line 96, in _onPlatformLoaded
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]:     if not job.getResult():
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Job.py", line 52, in getResult
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]:     return self._result
2017-05-03 17:54:29,450 - CRITICAL - cura.CrashHandler.show [39]: AttributeError: '_LoadPlatformJob' object has no attribute '_result'
2017-05-03 17:54:29,473 - DEBUG - UM.Mesh.MeshData.calculateNormalsFromIndexedVertices [433]: Calculating normals took 0.0021462440490722656 seconds
2017-05-03 17:54:29,494 - DEBUG - UM.Mesh.MeshData.calculateNormalsFromIndexedVertices [433]: Calculating normals took 0.0032470226287841797 seconds
2017-05-03 17:54:29,511 - DEBUG - UM.Mesh.MeshData.calculateNormalsFromIndexedVertices [433]: Calculating normals took 0.002132892608642578 seconds

Without numpy-stl:

kossel1

Expected results:
Show the platform in both cases.

cc @WoLpH

Bug
Source
picture hroncok

All 30 comments

I fear this might be related to https://github.com/WoLpH/numpy-stl/issues/52
Would you be able to test it without speedups enabled? (easy fix, rename /usr/lib64/python3.5/site-packages/stl/_speedups.pyx to something else)

WoLpH picture WoLpH on 3 May 2017

Renaming /usr/lib64/python3.5/site-packages/stl/_speedups.cpython-35m-x86_64-linux-gnu.so away indeed workarounds the problem.

hroncok picture hroncok on 3 May 2017

Note that I cannot reproduce WoLpH/numpy-stl#52 as described there.

hroncok picture hroncok on 3 May 2017

Hmm, that's interesting. For the time being I'll just push out a new release capturing the error and falling back to the non-speedups version. I still have no idea what's causing it but it's widespread enough for a quick workaround as fallback.

WoLpH picture WoLpH on 3 May 2017
👍1

Give version 2.2.2 a try :)
It's on PyPI now: https://pypi.python.org/pypi/numpy-stl

WoLpH picture WoLpH on 3 May 2017

I'm afraid it didn't help:

2017-05-03 22:58:39,580 - ERROR - UM.Logger.logException [74]: Exception: Job <UM.Scene.Platform._LoadPlatformJob object at 0x7f899718c4a8> caused an exception
2017-05-03 22:58:39,585 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-03 22:58:39,586 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 215, in _load_ascii
2017-05-03 22:58:39,588 - ERROR - UM.Logger.logException [78]:     return _speedups.ascii_read(fh, header)
2017-05-03 22:58:39,589 - ERROR - UM.Logger.logException [78]:   File "stl/_speedups.pyx", line 129, in stl._speedups.ascii_read (stl/_speedups.c:2752)
2017-05-03 22:58:39,589 - ERROR - UM.Logger.logException [78]: RuntimeError: (0, "Can't read vertex (4:b'vertex 59.3699 -83.2773 -42.8')")
2017-05-03 22:58:39,592 - ERROR - UM.Logger.logException [78]: 
2017-05-03 22:58:39,592 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-03 22:58:39,592 - ERROR - UM.Logger.logException [78]: 
2017-05-03 22:58:39,593 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-03 22:58:39,593 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 71, in load
2017-05-03 22:58:39,593 - ERROR - UM.Logger.logException [78]:     fh, header, speedups=speedups)
2017-05-03 22:58:39,593 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 219, in _load_ascii
2017-05-03 22:58:39,594 - ERROR - UM.Logger.logException [78]:     return cls._load_ascii(fh, header, speedups=False)
2017-05-03 22:58:39,594 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 223, in _load_ascii
2017-05-03 22:58:39,594 - ERROR - UM.Logger.logException [78]:     return name, numpy.fromiter(iterator, dtype=cls.dtype)
2017-05-03 22:58:39,594 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 199, in _ascii_reader
2017-05-03 22:58:39,594 - ERROR - UM.Logger.logException [78]:     v0 = get('vertex')
2017-05-03 22:58:39,595 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 171, in get
2017-05-03 22:58:39,595 - ERROR - UM.Logger.logException [78]:     'Incorrect value %r' % line)
2017-05-03 22:58:39,595 - ERROR - UM.Logger.logException [78]: RuntimeError: (False, "Incorrect value b'vertex 59.3699 -      vertex -59.3699 -83.2773 -38'")
2017-05-03 22:58:39,596 - ERROR - UM.Logger.logException [78]: 
2017-05-03 22:58:39,596 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-03 22:58:39,596 - ERROR - UM.Logger.logException [78]: 
2017-05-03 22:58:39,596 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-03 22:58:39,597 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/JobQueue.py", line 122, in run
2017-05-03 22:58:39,597 - ERROR - UM.Logger.logException [78]:     job.run()
2017-05-03 22:58:39,598 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/Scene/Platform.py", line 120, in run
2017-05-03 22:58:39,598 - ERROR - UM.Logger.logException [78]:     self.setResult(reader.read(self._file_name))
2017-05-03 22:58:39,598 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 40, in read
2017-05-03 22:58:39,598 - ERROR - UM.Logger.logException [78]:     self._loadWithNumpySTL(file_name, mesh_builder)
2017-05-03 22:58:39,599 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 71, in _loadWithNumpySTL
2017-05-03 22:58:39,599 - ERROR - UM.Logger.logException [78]:     loaded_data = stl.mesh.Mesh.from_file(file_name)
2017-05-03 22:58:39,599 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 328, in from_file
2017-05-03 22:58:39,599 - ERROR - UM.Logger.logException [78]:     fh, mode=mode, speedups=speedups)
2017-05-03 22:58:39,600 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 87, in load
2017-05-03 22:58:39,600 - ERROR - UM.Logger.logException [78]:     name, data = cls._load_binary(fh, header, check_size=True)
2017-05-03 22:58:39,600 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 104, in _load_binary
2017-05-03 22:58:39,601 - ERROR - UM.Logger.logException [78]:     count, MAX_COUNT)
2017-05-03 22:58:39,601 - ERROR - UM.Logger.logException [78]: AssertionError: File too large, got 841888568 triangles which exceeds the maximum of 10000000

The cls._load_ascii(fh, header, speedups=False) raises as well :(

hroncok picture hroncok on 3 May 2017

That's probably due to seeking, it appears to be reading broken stl data now which means it's skipping a bit internally... I guess the workaround is not as easy as I had hoped :(

For the time being simply disabling speedups completely might be the best solution.

WoLpH picture WoLpH on 3 May 2017

And for the time being we should fix Kossel's STL file? Could that help?

Ghostkeeper picture Ghostkeeper on 5 May 2017

I've re-saved the Kossel platform. That also made it a lot smaller since it's now binary. See https://github.com/Ultimaker/Cura/commit/ce3b0d9fe488bba225a3d2723726c12daf23cf39

Ghostkeeper picture Ghostkeeper on 5 May 2017

That indeed workarounds the problem for Kossel Mini, but still valid for Prusa i3 Mk2:

2017-05-05 14:50:01,979 - ERROR - UM.Logger.logException [74]: Exception: Job <UM.Scene.Platform._LoadPlatformJob object at 0x7fb37904ff60> caused an exception
2017-05-05 14:50:02,015 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-05 14:50:02,020 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 215, in _load_ascii
2017-05-05 14:50:02,021 - ERROR - UM.Logger.logException [78]:     return _speedups.ascii_read(fh, header)
2017-05-05 14:50:02,023 - ERROR - UM.Logger.logException [78]:   File "stl/_speedups.pyx", line 120, in stl._speedups.ascii_read (stl/_speedups.c:2641)
2017-05-05 14:50:02,024 - ERROR - UM.Logger.logException [78]: RuntimeError: (1, "Can't read normals (2:b'facet normal -0.737716 0.675111 0')")
2017-05-05 14:50:02,024 - ERROR - UM.Logger.logException [78]: 
2017-05-05 14:50:02,025 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-05 14:50:02,025 - ERROR - UM.Logger.logException [78]: 
2017-05-05 14:50:02,026 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-05 14:50:02,027 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 71, in load
2017-05-05 14:50:02,028 - ERROR - UM.Logger.logException [78]:     fh, header, speedups=speedups)
2017-05-05 14:50:02,048 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 219, in _load_ascii
2017-05-05 14:50:02,063 - ERROR - UM.Logger.logException [78]:     return cls._load_ascii(fh, header, speedups=False)
2017-05-05 14:50:02,064 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 223, in _load_ascii
2017-05-05 14:50:02,066 - ERROR - UM.Logger.logException [78]:     return name, numpy.fromiter(iterator, dtype=cls.dtype)
2017-05-05 14:50:02,068 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 197, in _ascii_reader
2017-05-05 14:50:02,068 - ERROR - UM.Logger.logException [78]:     normals = get('facet normal')
2017-05-05 14:50:02,069 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 165, in get
2017-05-05 14:50:02,069 - ERROR - UM.Logger.logException [78]:     prefix))
2017-05-05 14:50:02,069 - ERROR - UM.Logger.logException [78]: RuntimeError: (False, "b'fartex -99.977 112.453 -11' should start with b'facet normal'")
2017-05-05 14:50:02,070 - ERROR - UM.Logger.logException [78]: 
2017-05-05 14:50:02,070 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-05 14:50:02,070 - ERROR - UM.Logger.logException [78]: 
2017-05-05 14:50:02,071 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-05 14:50:02,073 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/JobQueue.py", line 122, in run
2017-05-05 14:50:02,078 - ERROR - UM.Logger.logException [78]:     job.run()
2017-05-05 14:50:02,078 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/Scene/Platform.py", line 120, in run
2017-05-05 14:50:02,079 - ERROR - UM.Logger.logException [78]:     self.setResult(reader.read(self._file_name))
2017-05-05 14:50:02,079 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 40, in read
2017-05-05 14:50:02,080 - ERROR - UM.Logger.logException [78]:     self._loadWithNumpySTL(file_name, mesh_builder)
2017-05-05 14:50:02,080 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 71, in _loadWithNumpySTL
2017-05-05 14:50:02,084 - ERROR - UM.Logger.logException [78]:     loaded_data = stl.mesh.Mesh.from_file(file_name)
2017-05-05 14:50:02,084 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 328, in from_file
2017-05-05 14:50:02,085 - ERROR - UM.Logger.logException [78]:     fh, mode=mode, speedups=speedups)
2017-05-05 14:50:02,085 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 87, in load
2017-05-05 14:50:02,089 - ERROR - UM.Logger.logException [78]:     name, data = cls._load_binary(fh, header, check_size=True)
2017-05-05 14:50:02,090 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 104, in _load_binary
2017-05-05 14:50:02,091 - ERROR - UM.Logger.logException [78]:     count, MAX_COUNT)
2017-05-05 14:50:02,092 - ERROR - UM.Logger.logException [78]: AssertionError: File too large, got 2019914866 triangles which exceeds the maximum of 10000000
2017-05-05 14:50:02,148 - CRITICAL - cura.CrashHandler.show [36]: An uncaught exception has occurred!
2017-05-05 14:50:02,151 - CRITICAL - cura.CrashHandler.show [39]: Traceback (most recent call last):
2017-05-05 14:50:02,151 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/cura/CuraApplication.py", line 653, in event
2017-05-05 14:50:02,151 - CRITICAL - cura.CrashHandler.show [39]:     return super().event(event)
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Qt/QtApplication.py", line 216, in event
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:     event._function_event.call()
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Event.py", line 187, in call
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:     self._function(*self._args, **self._kwargs)
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Signal.py", line 305, in __performEmit
2017-05-05 14:50:02,152 - CRITICAL - cura.CrashHandler.show [39]:     func(dest, *args, **kwargs)
2017-05-05 14:50:02,153 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Scene/Platform.py", line 96, in _onPlatformLoaded
2017-05-05 14:50:02,153 - CRITICAL - cura.CrashHandler.show [39]:     if not job.getResult():
2017-05-05 14:50:02,153 - CRITICAL - cura.CrashHandler.show [39]:   File "/usr/lib/python3.5/site-packages/UM/Job.py", line 52, in getResult
2017-05-05 14:50:02,153 - CRITICAL - cura.CrashHandler.show [39]:     return self._result
2017-05-05 14:50:02,153 - CRITICAL - cura.CrashHandler.show [39]: AttributeError: '_LoadPlatformJob' object has no attribute '_result'
hroncok picture hroncok on 5 May 2017

Strange. I have numpy-stl but I'm not getting these errors.
I've now converted the Prusa i3 platform to binary STL as well: https://github.com/Ultimaker/Cura/commit/bd276a4d7007833f43ae6dc6899ba92117f14991. Let me know if you know of any more platforms.

Ghostkeeper picture Ghostkeeper on 5 May 2017

Platforms visible:

  • Kossel Mini (after your update)
  • Prusa i3 (Mk2) (after your update)
  • Ultimaker 2
  • Ultimaker 2 Extended
  • Ultimaker 2 Go
  • Ultimaker Original (also Dual Extruder and +)
  • Hello BEE Prusa
  • BQ (all)
  • Cartesio
  • German RepRap Neo
  • JellyBOX
  • Mankati Fullscale XT Plus
  • Printerbot Play
  • Printerbot Simple
  • RigidBot(Big)
  • Vertex K8400

Platforms not visible affected by this issue:

  • Folger Tech FT-5 (FT-5_build_plate.stl)
  • Kossel Pro (kossel_pro_build_platform.stl)
  • Mendel90 (mendel90_platform.stl)
  • Printerbot Simple Metal Extended (printrbot_simple_metal_upgrade.stl)
  • Prusa i3 xl (prusai3_xl_platform.stl)

Cannot test due to #1547:

  • Ultimaker 3
  • Ultimaker 3 Extended
  • Ultimaker 2+
  • Ultimaker 2 Extended+

Segfaults immediately after adding:

  • Innovo INVERTOR

Cannot find in Add Printer dialog:

  • 3DMaker Starter (makerstarter_platform.stl)

That should be everything that has a mesh in /usr/share/cura/resources/meshes/.

hroncok picture hroncok on 5 May 2017

You just named every ASCII STL file we have. I have a strong suspicion that the STL reader is broken on that rather than the files.

Ghostkeeper picture Ghostkeeper on 10 May 2017

It definitely seems to.

hroncok picture hroncok on 10 May 2017

The ascii STL reader with speedups enabled is broken for some platforms... unfortunately it's not reproducible everywhere and I'm still having problems reproducing :(

WoLpH picture WoLpH on 10 May 2017

Note that i cannot reproduce this outside fo Cura either.

hroncok picture hroncok on 10 May 2017

We have actually disabled numpy-stl loading on Linux due to issues with loading Ascii STL. I always put that down to build issues but I guess if others are affected it is not necessarily related to build issues.

@WoLpH If you want, I can see if I can give you an AppImage of Cura that exhibits the problem to see if that helps debugging.

awhiemstra picture awhiemstra on 10 May 2017

@awhiemstra that would help a lot, it's quite hard to debug right now.

For the time being I've released a version that should work around the issue (v2.2.3, should be on pypi soon)

@Ghostkeeper using binary stl files is indeed an option, it's only the ascii reader with speedups that is broken. Without speedups or when using the binary reader you should have no issues

WoLpH picture WoLpH on 10 May 2017
🎉1

I confirm that 2.2.3 indeed workarounds the problem.

hroncok picture hroncok on 10 May 2017

@Ghostkeeper using binary stl files is indeed an option, it's only the ascii reader with speedups that is broken. Without speedups or when using the binary reader you should have no issues

Using binary STL will fix the symptom (not visible platform). But this can happen when actually loading an ASCII STL for printing as well.

2017-05-10 12:45:49,687 - ERROR - UM.Logger.logException [74]: Exception: Exception occurred while loading file /usr/share/cura/resources/meshes/FT-5_build_plate.stl
2017-05-10 12:45:49,690 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-10 12:45:49,690 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 71, in load
2017-05-10 12:45:49,692 - ERROR - UM.Logger.logException [78]:     fh, header, speedups=speedups)
2017-05-10 12:45:49,692 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 214, in _load_ascii
2017-05-10 12:45:49,692 - ERROR - UM.Logger.logException [78]:     return _speedups.ascii_read(fh, header)
2017-05-10 12:45:49,693 - ERROR - UM.Logger.logException [78]:   File "stl/_speedups.pyx", line 120, in stl._speedups.ascii_read (stl/_speedups.c:2641)
2017-05-10 12:45:49,693 - ERROR - UM.Logger.logException [78]: RuntimeError: (0, "Can't read normals (2:b'facet normal 0.3826834323650663 -0.9238795325112966 6.119335945344355e-16\\r')")
2017-05-10 12:45:49,693 - ERROR - UM.Logger.logException [78]: 
2017-05-10 12:45:49,693 - ERROR - UM.Logger.logException [78]: During handling of the above exception, another exception occurred:
2017-05-10 12:45:49,693 - ERROR - UM.Logger.logException [78]: 
2017-05-10 12:45:49,694 - ERROR - UM.Logger.logException [78]: Traceback (most recent call last):
2017-05-10 12:45:49,694 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/FileHandler/ReadFileJob.py", line 61, in run
2017-05-10 12:45:49,694 - ERROR - UM.Logger.logException [78]:     self.setResult(self._handler.readerRead(reader, self._filename))
2017-05-10 12:45:49,694 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/python3.5/site-packages/UM/Mesh/MeshFileHandler.py", line 28, in readerRead
2017-05-10 12:45:49,694 - ERROR - UM.Logger.logException [78]:     results = reader.read(file_name)
2017-05-10 12:45:49,695 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 40, in read
2017-05-10 12:45:49,695 - ERROR - UM.Logger.logException [78]:     self._loadWithNumpySTL(file_name, mesh_builder)
2017-05-10 12:45:49,695 - ERROR - UM.Logger.logException [78]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 71, in _loadWithNumpySTL
2017-05-10 12:45:49,695 - ERROR - UM.Logger.logException [78]:     loaded_data = stl.mesh.Mesh.from_file(file_name)
2017-05-10 12:45:49,696 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 318, in from_file
2017-05-10 12:45:49,696 - ERROR - UM.Logger.logException [78]:     fh, mode=mode, speedups=speedups)
2017-05-10 12:45:49,696 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 87, in load
2017-05-10 12:45:49,697 - ERROR - UM.Logger.logException [78]:     name, data = cls._load_binary(fh, header, check_size=True)
2017-05-10 12:45:49,697 - ERROR - UM.Logger.logException [78]:   File "/usr/lib64/python3.5/site-packages/stl/stl.py", line 104, in _load_binary
2017-05-10 12:45:49,697 - ERROR - UM.Logger.logException [78]:     count, MAX_COUNT)
2017-05-10 12:45:49,697 - ERROR - UM.Logger.logException [78]: AssertionError: File too large, got 892547897 triangles which exceeds the maximum of 10000000
hroncok picture hroncok on 10 May 2017

Yeah I've converted all our platform files now (also makes the installation smaller) but of course the STLs that users load are not converted.

Ghostkeeper picture Ghostkeeper on 10 May 2017

Just shy of 900 million polygons. Wow.

fieldOfView picture fieldOfView on 10 May 2017

Using binary STL will fix the symptom (not visible platform). But this can happen when actually loading an ASCII STL for printing as well.

Very true unfortunately :(
Generally I would recommend using the binary format anyhow since it's less prone to errors (ascii stl is not that well standardized) and about as fast as you can get.

WoLpH picture WoLpH on 10 May 2017

Note that I wanted to create a reproducing environment by installing Fedora 25 to a virtual machine, but I couldn't reproduce it :(

hroncok picture hroncok on 10 May 2017

Just stating the obvious here but you didn't accidently try with v2.2.3?

But it might be a very specific combination of software and builds.
I've tried several linux machines and osx and I haven't been able to reproduce it so far :(

WoLpH picture WoLpH on 10 May 2017

Just stating the obvious here but you didn't accidently try with v2.2.3?

I've triple checked that. No, I've tried with 2.2.2, 2.2.1, 2.1.0.

hroncok picture hroncok on 10 May 2017

Closing it as no-one seems to be able to reproduce it.

nallath picture nallath on 27 Jul 2017

I think the problem may have been a bug in another library which has been resolved upstream... which is good, yet frustrating ;)

I'll close the bug from my side as well, hoping it won't rear its head again.

WoLpH picture WoLpH on 27 Jul 2017

If it does, feel free to give another shout. I'm just clearing up our old issues :)

nallath picture nallath on 27 Jul 2017

No-one is reproducing it since I converted all platforms to binary STL...

The problem should still exist since our build system still uses Numpy-STL v1.9.0. They are at 2.3.2 now, so we should update.

(Edit: I've put a ticket in to update this.)

Ghostkeeper picture Ghostkeeper on 10 Aug 2017
Was this page helpful?
0 / 5 - 0 ratings

Related issues

mubarak111nsu picture mubarak111nsu  路  3Comments
StanislavJochman picture StanislavJochman  路  3Comments
mnswamp1 picture mnswamp1  路  3Comments
jellewie picture jellewie  路  3Comments
Nemernemer picture Nemernemer  路  3Comments