umagi

....

Changed to 16 steps for the Z by installing the jumper on JP3, and the "resonant" noise when the Z shaft moves up and down (homing and to Z=0) have basically gone. However, my Ulticontroller board has again failed, and again, it's the U3 chip that has blown with a very visible burnout hump on the chip. I really start to believe this Ulticontroller design is flawed big time!

Exactly what I needed to know. In the link you provided above, it seems that changing to 16 steps may reduce some of the Z axis noise, so I will give it a try. Some people in that post speak of resonance effects, and I believe my custom UM2 build may suffer from it as well, especially since it is even taller than the UM2 extended. My construction is build around an 20x20 aluminum extrusion frame and covered with 4mm composite alu panels. The Z max is 435mm now, and to stabilize the bed somewhat, I have attached flange bearings also below the bed. These bottom bearings also serve as support for the two bed support arms I have mounted as well below the bed. I hope the pictures of my (unfinished but yet functional build) will make this clear. To compensate for the weight of the supporting arms, I even cut away the same mass from the build plate. The weight of the build platform has thus increased only by the weight of the extra bearings. I hope that increasing the number of microsteps will alleviate some of the (resonance?) noise I am experiencing when the Z stage is moving down during homing, but possibly, the Z is just too high with respect to the various shaft diameters involved to avoid resonance. Maybe I need to find other ways to dampen those vibrations... Thanks tinkergnome!

Hi, On the Ultimaker 2 main board is a jumper JP3 "8/16 step". What does this do? If this sets the microstepping mode, why is there only 1 jumper and not one for each stepper motor? If it is used, does the open state (no jumper installed) mean 8 or 16? Thanks!

I surely will!

Labern, This is exactly what I needed! It helped me debug my build and I found two problems with it: 1. One of the Y motor cables was loose (bad connector crimp by myself), which explains the stuttering without rotating. 2. The Y limit switch was not working because again, a bad connector crimp by myself... Thanks a lot again for telling me about this tool!

Hmm... I used Pronterface for the first time right now... and it shows me that the Y stepper is the culprit. The X axis moves correctly, but the Y does not move, the motor just stutters. Apparently, it has to do with the wiring because when I interchange the X and Y motor connections, the Y moves correctly but the X fails this time. I check the cable of the Y stepper... and of course, a wire was loose due to my bad connector crimping skills... I'm also new at connector crimping you see. Now both X and Y move smoothly in Pronterface!

Hi, I just powered on my self-built UM2. Using the default firmware in the UM2 main board (v.2.1.4), I went to Maintenance -> Build Plate. The Z axis homes correctly, i.e. goes down, hits the limit switch, then backs up a little bit and goes down again slower to hit the limit switch again. But then, all hell breaks loose on the XY movement! Hellish stuttering noise during X movement which is not stopped by the limit switch (limit switch was tested to work), leaving me no other option than to switch off. Please have a look at the following video: I know I need to change some firmware settings for my machine. The X,Y dimensions are the same as UM2, the Z is longer. The XY motor pulleys have 16 GT2 teeth instead of the official UM2 20 teeth, so I need to change the steps per unit for these as well. But even with these wrong settings, I can't figure out why the XY make such noise. Any help will be greatly appreciated!

Hi Labern, Thanks, I will take a look at it!

Hi, This may be a stupid question, but I was wondering if someone has simple firmware for the UM2 for testing basic functionality such as: - If the limit switches are detected correctly - If the temperature sensors are working correctly - If the stepper motors are working correctly - If the LED and Fan PWMs are working correctly, etc... You guessed it, it's because I am in the process of building my own UM2 (a slightly taller version than the Extended) and I cannot use the UM2 default firmware for this, since it first goes through the calibration process, which must succeed before the menu becomes available. For example: The limit switch test would display a message like "X limit switch activated" every time the X limit switch is closed, etc.. This test also would include confirming that what the software means by X indeed corresponds with the X switch (i.e. that the X and Y switches are not exchanged) The stepper X, Y and Z motor tests would provide things like: If I turn the control knob left, then the motor turns in one direction, and when I turn the knob right, it turns in the other direction, with the speed being adjustable. This test would also indicate whether the motors turn in the correct direction (i.e. what the software thinks is the left direction for the X axis really makes the head turning to the left rather than to the right, etc...). For the PWM tests, idem: turning the knob left or right increases or decreases the PWM frequency, etc... Simple and basic tests to ensure everything is set, working, or detected correctly. I'm too new to 3D to write such firmware myself for the moment by looking at the UM2 firmware code, but I hope that I will be able to write such thing after some more study if none is available at the moment. Thanks!

Many thanks gr5! By further looking at the Recommended Operating conditions, it seems this is not really a big problem, since both VREF1 and VREF2 can operate between 0 and 5.5V it seems (with 7V being the absolute maximum) So things seem to be OK after all... I should have looked more closely to the datasheet info, but I guess I was too eager to find a solution to my problem... However, the Design Requirements table from the Typical Application section also says: So there, the max. for VREF1 is 4.4V... All this is pretty confusing after all. Let me just hope Cohen will be kind enough to enlighten me with his expertise and give some suggestions as to what could be wrong with my Ulticontroller board (or is it a main board problem too?) Thanks!

Hi nallath, I found posts about the issue before and tried the --disable-textures. But that doesn't work in the development version of Cura. Since I don't know how to pass that launch argument, I followed the same procedure as described in another post, i.e. modified the Windows shortcut to the Cura executable and added the --disable-textures switch there. Also note that I successfully built Cura using the Daid script, and that I don't have the crashes with that version. All the posts relating to this crash seem to be from people not using the development version of Cura, which I am referring to here. Well, I don't know. I spent my time setting up a development environment for PyQt (using Eclipse and its PyDev addin) in the hope of debugging the QML problem that apparently causes the crashes. Although I succeeded in running a simple example PyQt program, I still haven't figured out how to debug the Cura GUI in there... Maybe someone has a PyDev Eclipse project to do that already?

Hi, Trying to figure out why the PCA9306 chip on my Ulticontroller keeps blowing up, I checked the datasheet from Texas Instruments for it. I found the following: However, the Ultimaker schematic shows this: So in the UM2 schematic, VREF1 is at 5V whereas the range for VREF1 as per the datasheet is only between 1.2V and 3.3V... What the ... ?? Can any of the Ultimaker design engineers please help me out here?

Hi nallath, What I did was to open a normal Windows Command prompt window, and first set the following path: set PYTHONPATH=G:\dev\cura-build\build\inst\lib\python3.4\site-packages Then, I started: python G:\dev\cura-build\build\inst\bin\cura_app.py This starts Cura (developer version), with splash screen and all, including the crash after selecting the Printer. At the same time the following output was printed in the command window: Microsoft Windows [Version 6.1.7601]Copyright © 2009 Microsoft Corporation. All rights reserved.G:\dev\cura-build\build\inst\bin>python G:\dev\cura-build\build\inst\bin\cura_app.py2016-03-01 21:24:26,003 - INFO - Loaded plugin ConsoleLogger2016-03-01 21:24:26,043 - INFO - Loaded plugin CuraEngineBackend2016-03-01 21:24:26,043 - WARNING - Plugin ConsoleLogger was already loaded2016-03-01 21:24:26,073 - INFO - Loaded plugin 3MFWriter2016-03-01 21:24:26,083 - INFO - Loaded plugin OBJReader2016-03-01 21:24:26,093 - INFO - Loaded plugin OBJWriter2016-03-01 21:24:26,103 - INFO - Loaded plugin STLReader2016-03-01 21:24:26,113 - INFO - Loaded plugin STLWriter2016-03-01 21:24:26,133 - INFO - Loaded plugin FileLogger2016-03-01 21:24:26,153 - INFO - Loaded plugin LocalFileOutputDevice2016-03-01 21:24:26,173 - INFO - Loaded plugin CameraTool2016-03-01 21:24:26,183 - INFO - Loaded plugin MirrorTool2016-03-01 21:24:26,213 - INFO - Loaded plugin RotateTool2016-03-01 21:24:26,233 - INFO - Loaded plugin ScaleTool2016-03-01 21:24:26,253 - INFO - Loaded plugin SelectionTool2016-03-01 21:24:26,273 - INFO - Loaded plugin TranslateTool2016-03-01 21:24:26,333 - INFO - Checking for new version of cura2016-03-01 21:24:26,333 - INFO - Loaded plugin UpdateChecker2016-03-01 21:24:26,363 - INFO - Loaded plugin SimpleView2016-03-01 21:24:26,383 - INFO - Loaded plugin WireframeView2016-03-01 21:24:26,403 - INFO - Loaded plugin 3MFReader2016-03-01 21:24:26,423 - INFO - Loaded plugin AutoSave2016-03-01 21:24:26,443 - ERROR - Error loading plugin ChangeLogPlugin:2016-03-01 21:24:26,443 - ERROR - invalid literal for int() with base 10: '99-2'2016-03-01 21:24:26,443 - WARNING - Plugin CuraEngineBackend was already loaded2016-03-01 21:24:26,463 - INFO - Loaded plugin CuraProfileReader2016-03-01 21:24:26,483 - INFO - Loaded plugin CuraProfileWriter2016-03-01 21:24:26,513 - INFO - Loaded plugin GCodeProfileReader2016-03-01 21:24:26,533 - INFO - Loaded plugin GCodeWriter2016-03-01 21:24:26,563 - INFO - Loaded plugin ImageReader2016-03-01 21:24:26,583 - INFO - Loaded plugin LayerView2016-03-01 21:24:26,613 - INFO - Loaded plugin LegacyProfileReader2016-03-01 21:24:26,633 - INFO - Loaded plugin PerObjectSettingsTool2016-03-01 21:24:26,673 - INFO - Loaded plugin PostProcessingPlugin2016-03-01 21:24:26,703 - INFO - Loaded plugin RemovableDriveOutputDevice2016-03-01 21:24:26,733 - INFO - Loaded plugin SliceInfoPlugin2016-03-01 21:24:26,763 - INFO - Loaded plugin SolidView2016-03-01 21:24:26,813 - INFO - Loaded plugin USBPrinting2016-03-01 21:24:26,853 - INFO - Loaded plugin XRayView2016-03-01 21:24:26,933 - WARNING - Could not determine application version from string 2.0.99-2.1, not checking for updates2016-03-01 21:24:27,023 - DEBUG - Setting active view to SolidView2016-03-01 21:24:27,843 - DEBUG - Loaded theme G:\dev\cura-build\build\inst\share\cura\resources\themes\curaqml: TableViewSelection: index out of rangeqml: TableViewSelection: index out of rangefile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of null2016-03-01 21:24:28,606 - DEBUG - Initialized OpenGL subsystems.2016-03-01 21:24:28,607 - DEBUG - OpenGL Version: 4.5.13399 Compatibility Profile Context 15.200.1062.10042016-03-01 21:24:28,607 - DEBUG - OpenGL Vendor: ATI Technologies Inc.2016-03-01 21:24:28,608 - DEBUG - OpenGL Renderer: AMD Mobility Radeon HD 5000file:///G:/dev/cura-build/build/inst/share/cura/resources/qml/SidebarSimple.qml:249:22: Unable to assign [undefined] to boolQQmlContext: Cannot set context object on invalid context.QQmlComponent: Cannot create a component in an invalid context2016-03-01 21:24:36,756 - INFO - Started engine process: G:\dev\cura-build\build\inst\bin\CuraEngine.exe2016-03-01 21:24:36,926 - DEBUG - Backend connected on port 49674Requires a valid current OpenGL context.Texture has not been created The error should now be more debuggable, since we have a clear culprit here: qml: TableViewSelection: index out of rangeqml: TableViewSelection: index out of rangefile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of nullfile:///G:/dev/cura-build/build/inst/lib/qml/QtQuick/Controls/Menu.qml:149: TypeError: Cannot read property '__contentItem' of null2016-03-01 21:24:28,606 - DEBUG - Initialized OpenGL subsystems.2016-03-01 21:24:28,607 - DEBUG - OpenGL Version: 4.5.13399 Compatibility Profile Context 15.200.1062.10042016-03-01 21:24:28,607 - DEBUG - OpenGL Vendor: ATI Technologies Inc.2016-03-01 21:24:28,608 - DEBUG - OpenGL Renderer: AMD Mobility Radeon HD 5000file:///G:/dev/cura-build/build/inst/share/cura/resources/qml/SidebarSimple.qml:249:22: Unable to assign [undefined] to boolQQmlContext: Cannot set context object on invalid context.QQmlComponent: Cannot create a component in an invalid context2016-03-01 21:24:36,756 - INFO - Started engine process: G:\dev\cura-build\build\inst\bin\CuraEngine.exe2016-03-01 21:24:36,926 - DEBUG - Backend connected on port 49674Requires a valid current OpenGL context.Texture has not been created I'm just not sure yet as how to procede with this debugging now, since I know nothing about qml nor Qt.

Hi Nallath. EDIT: Sorry, you already mentioned to run the Python stuff from source... I didn't initially get what you meant by that... I'd suggest running the python stuff from source and copy the artifacts that you do need (eg; CuraEngine) How do I run the Cura python part from source in the cura-build build? Is it done by launching cura_app.py from the cura-build\build\Cura-prefix\src\Cura directory? Many thanks!

I don't think the supplier will be of any help. He's just a vendor. I was hoping to get some pointers from one of the Ultimaker hardware design engineers, or any other experienced electronics design engineer who is familiar with the Ultimaker schematics. But I know that's just wishful thinking... My PCBs are indeed from China, but are of high quality, and certainly look genuine enough to qualify as "real". I'm wondering where Ultimaker sources its PCBs?

Hi, My Ulticontroller v2.1 blew up due to what I thought was an ESD discharge when touching the knob. This fried the U3 chip on the PCB (the PCA9306 chip: Dual Bidirectional I2C Bus and SMBus Voltage-Level Translator) which I replaced myself. With the repair, things appeared to go well for a moment, but then the U3 chip started smoking... again. I start tot suspect that there must be another underlying problem to this and that the ESD I first got was just a symptom and not a cause. Does anyone know where I can can PCB debugging support for my self-built Ultimaker 2 ? What can cause this U3 chip to get smoked like that? Many thanks...

I started the build from scratch, using my newly gained experience from the above steps and deleted the cura-build/build directory. Note: It seems building under MSYS2 seems a little bit unstable? I got errors such as Too many open files, and another error relating to some truncated object file? In any case, after the new build, the Cura 2.0 exe starts:

I installed the newly built Cura package on a Windows 7 virtual machine (64bit, as my build host) but got the following error upon launching Cura (the installer works fine): Errors in 'Cura.exe'See logfile 'C:\Program Files (x86)\Cura 2.0\Cura.log' for details. That logfile shows: Error in sys.excepthook:Traceback (most recent call last): File "", line 2237, in _find_and_load File "", line 2226, in _find_and_load_unlocked File "", line 1191, in _load_unlocked File "", line 1161, in _load_backward_compatible File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\cura\CrashHandler.py", line 6, in File "", line 10, in File "", line 8, in __loadImportError: (DLL load failed: The specified module could not be found.) 'C:\\Program Files (x86)\\Cura 2.0\\PyQt5.QtCore.pyd'Original exception was:Traceback (most recent call last): File "cura_app.py", line 20, in File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\cura\CuraApplication.py", line 6, in File "G:\dev\cura-build\build\inst\lib\python3.4\site-packages\UM\Qt\QtApplication.py", line 9, in File "", line 10, in File "", line 8, in __loadImportError: (DLL load failed: The specified module could not be found.) 'C:\\Program Files (x86)\\Cura 2.0\\PyQt5.QtCore.pyd'

To solve the above error (not sure it is correct), I downloaded the Arduino master repository as zip file (about 82.3MByte, and about 326MByte unzipped. I did not clone the master, which is about 1.5GByte!) https://github.com/arduino/Arduino/archive/master.zip Then copy the unzipped Arduino-master folder (and rename it to arduino) to: cura-build/arduino Resuming the package build step, we get the following error after this: Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: - Install component: arduinoCPack: - Install component: curaCPack: - Install component: vcredistCMake Error at G:/dev/cura-build/build/cmake_install.cmake:35 (file): file INSTALL cannot find "G:/dev/cura-build/vcredist_x86.exe".CPack Error: Error when generating package: CuraMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1 As mentioned in the cura-build\CMakeLists.txt file, we need to get the distributable from: http://www.microsoft.com/en-us/download/details.aspx?id=26999 We downloaded the vcredist_x86.exe (because we have a 32bit build) and copied it to the cura-build directory. After this step: Success!!! Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: - Install component: arduinoCPack: - Install component: curaCPack: - Install component: vcredistCPack: Create packageCPack: - package: G:/dev/cura-build/build/Cura-2.0.99-2.1-win32.exe generated. Of course, I still need to check if this thing actually installs and runs...

Finally, I called "mingw32-make package" to build the Cura installer. mingw32-make package As expected, we get the following error, since we did not install NSIS: Run CPack packaging tool...CPack Error: Cannot find NSIS compiler makensis: likely it is not installed, or not in your PATHCPack Error: Could not read NSIS registry value. This is usually caused by NSIS not being installed. Please install NSIS from http://nsis.sourceforge.netCPack Error: Cannot initialize the generator NSISMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1 NSIS can be downloaded from: http://nsis.sourceforge.net/Main_Page As suggested in the README.md from the cura-build page, I downloaded version 3: The windows installer and sources can be downloaded from: http://prdownloads.sourceforge.net/nsis/nsis-3.0b3-setup.exe?download http://prdownloads.sourceforge.net/nsis/nsis-3.0b3-src.tar.bz2?download Resuming the build of the installer after installing NSIS 3, we get the following error: Run CPack packaging tool...CPack: Create package using NSISCPack: Install projectsCPack: - Run preinstall target for: cura-buildCPack: - Install project: cura-buildCPack: - Install component: arduinoCMake Error at G:/dev/cura-build/build/cmake_install.cmake:39 (file): file INSTALL cannot find "G:/dev/cura-build/arduino".CPack Error: Error when generating package: CuraMakefile:117: recipe for target 'package' failedmingw32-make: *** [package] Error 1 So it tries to find a package called arduino, which I don't seem to have (although Arduino 1.6.7 is installed on my system).

The build of target cura-binary-data goes smoothly, mainly because it just appears to download and copy the firmware binaries, it does not build them here (who does that?): Scanning dependencies of target cura-binary-data[ 93%] Creating directories for 'cura-binary-data'[ 94%] Performing download step (git clone) for 'cura-binary-data'Cloning into 'cura-binary-data'...Branch 2.1 set up to track remote branch 2.1 from origin.Switched to a new branch '2.1'[ 95%] No patch step for 'cura-binary-data'[ 96%] Performing update step for 'cura-binary-data'Current branch 2.1 is up to date.[ 97%] Performing configure step for 'cura-binary-data'-- The C compiler identification is GNU 5.3.0...-- Configuring done-- Generating done-- Build files have been written to: G:/dev/cura-build/build/cura-binary-data-prefix/src/cura-binary-data-build[ 98%] Performing build step for 'cura-binary-data'[ 99%] Performing install step for 'cura-binary-data'Install the project...-- Install configuration: ""-- Up-to-date: G:/dev/cura-build/build/inst/share/cura-- Up-to-date: G:/dev/cura-build/build/inst/share/cura/resources-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware/Attribution.txt-- Installing: G:/dev/cura-build/build/inst/share/cura/resources/firmware/MarlinUltimaker-115200-dual.hex...-- Installing: G:/dev/cura-build/build/inst/./arduino/dpinst64.exe[100%] Completed 'cura-binary-data'[100%] Built target cura-binary-data Then, finally, the build of the build_exe target starts ... and stops with the following error: Scanning dependencies of target build_exeRunning py2exeTraceback (most recent call last): File "setup_win32.py", line 5, in import py2exeImportError: No module named 'py2exe'CMakeFiles/build_exe.dir/build.make:57: recipe for target 'build_exe' failedmingw32-make[2]: *** [build_exe] Error 1CMakeFiles/Makefile2:588: recipe for target 'CMakeFiles/build_exe.dir/all' failedmingw32-make[1]: *** [CMakeFiles/build_exe.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2 I had to install the py2exe package. Make sure to install the latest version (0.9.2.2), otherwise you may get the following error during the build of the build_exe target: KeyError: 'six.moves' The Windows installer (choose win32 version, since we had to install the 32bit version of Python to build Cura) can be dowloaded here: https://pypi.python.org/packages/any/p/py2exe/py2exe-0.9.2.2.win32.exe#md5=f1684d39de2ed8287a0a36eb241f81e5 The source code can be downloaded here: https://pypi.python.org/packages/source/p/py2exe/py2exe-0.9.2.2.zip#md5=f7d7e3980a606b4ded4d98016759d557 Install it as usual using: python setup.py buildpython setup.py install Or better, install it using pip: pip install py2exe Finally, after installing the correct version of py2exe and resuming the build, the target builds to completion! Finally! Running py2exeRemoving previous distribution packagerunning py2exerunning build_scripts 27 missing Modules ------------------? FCNTL imported from serial.serialposix? Image imported from scipy.misc.pilutil? ImageFilter imported from scipy.misc.pilutil? PIL imported from scipy.misc.pilutil? System imported from serial.serialcli? TERMIOS imported from serial.serialposix? backports imported from setuptools.ssl_support? google.protobuf._use_fast_cpp_protos imported from google.protobuf.internal.api_implementation? google.protobuf.internal._api_implementation imported from google.protobuf.internal.api_implementation? matplotlib imported from scipy.spatial._plotutils? netbios imported from uuid? packaging imported from pkg_resources? readline imported from cmd, code, pdb? scikits imported from scipy.sparse.linalg.dsolve.linsolve? scipy.arange imported from scipy.sparse.linalg.isolve.minres? scipy.ones imported from scipy.sparse.linalg.isolve.minres? sets imported from numpy.distutils.command.build_ext, numpy.distutils.fcompiler, numpy.distutils.misc_util? setuptools_svn imported from setuptools.command.egg_info? urllib.pathname2url imported from setuptools.compat? urllib.splittag imported from setuptools.compat? urllib.url2pathname imported from setuptools.compat? win32api imported from distutils.msvccompiler? win32com imported from setuptools.sandbox? win32con imported from distutils.msvccompiler? win32pdh imported from numpy.testing.utils? win32wnet imported from uuid? wincertstore imported from setuptools.ssl_support 1 submodules that appear to be missing, but could also be global names in the parent package ---------------------------------------------------------------------------------------------? numpy.conj imported from scipy.linalg.decompBuilding 'dist\cura_app.exe'.Building shared code archive 'dist\library.zip'.Copy c:\windows\system32\python34.dll to dist...Copy G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\spatial\ckdtree.pyd to dist\scipy.spatial.ckdtree.pydCopy E:\DevTools\Python34\DLLs\pyexpat.pyd to dist\pyexpat.pydCopy DLL E:\DevTools\MinGW\bin\libgcc_s_dw2-1.dll to dist\...Copy DLL E:\DevTools\MinGW\bin\libquadmath-0.dll to dist\Copying Cura plugins.Copying resources.Coping Uranium QML.Copying Qt5 pluginsCopying QtQuick pluginsCopying Qt5 svg libraryCopy CuraEngine[100%] Built target build_exe I'm not sure what the above report of missing modules (27 + possibly 1) implies, but the build finishes. Let's wait until the next step (packaging) before claiming victory...

Resuming the SciPy build first gave another error: error: [Errno 24] Too many open files I just restarted MSYS2 and resumed the build (since ulimit was already set to unlimited, there is was no way to increase the memory for commands that way?) Resuming the build gave a final error for the Scipy build: running build_clibBuilding msvcr library: "E:\DevTools\Python34\libs\libmsvcr100.a" (from E:\jre1.8.0_60\bin\msvcr100.dll)objdump.exe: E:\jre1.8.0_60\bin\msvcr100.dll: File format not recognizedE:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg)E:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg)E:\DevTools\Python34\lib\distutils\dist.py:260: UserWarning: Unknown distribution option: 'setup_requires' warnings.warn(msg)E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:1505: UserWarning: Atlas (http://math-atlas.sourceforge.net/'>http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__)Running from scipy source directory.E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:594: UserWarning: Specified path E:\DevTools\Python34\include\include is invalid. warnings.warn('Specified path %s is invalid.' % d)E:\DevTools\Python34\lib\site-packages\numpy\distutils\system_info.py:1603: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__)Traceback (most recent call last): File "setup.py", line 253, in setup_package() File "setup.py", line 250, in setup_package setup(**metadata) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\core.py", line 169, in setup return old_setup(**new_attr) File "E:\DevTools\Python34\lib\distutils\core.py", line 148, in setup dist.run_commands() File "E:\DevTools\Python34\lib\distutils\dist.py", line 955, in run_commands self.run_command(cmd) File "E:\DevTools\Python34\lib\distutils\dist.py", line 974, in run_command cmd_obj.run() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\command\build.py", line 39, in run old_build.run(self) File "E:\DevTools\Python34\lib\distutils\command\build.py", line 126, in run self.run_command(cmd_name) File "E:\DevTools\Python34\lib\distutils\cmd.py", line 313, in run_command self.distribution.run_command(command) File "E:\DevTools\Python34\lib\distutils\dist.py", line 974, in run_command cmd_obj.run() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\command\build_clib.py", line 72, in run force=self.force) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\ccompiler.py", line 562, in new_compiler compiler = klass(None, dry_run, force) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 94, in __init__ msvcr_success = build_msvcr_library() File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 361, in build_msvcr_library generate_def(dll_file, def_file) File "E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py", line 278, in generate_def raise ValueError("Symbol table not found")ValueError: Symbol table not foundCMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[3]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Scipy.dir/all] Error 2CMakeFiles/Makefile2:488: recipe for target 'CMakeFiles/Scipy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/rule] Error 2Makefile:327: recipe for target 'Scipy' failedmingw32-make: *** [scipy] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build This is exactly the same error as I got during the build of Numpy, but this time, the file that throws the error is: E:\DevTools\Python34\lib\site-packages\numpy\distutils\mingw32ccompiler.py I just repeated the workaround described above for that error, and resumed the build. Finally, the Scipy build completed: creating G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\sparse\linalg\eigen\lobpcg\testscopying scipy\sparse\linalg\eigen\lobpcg\tests\test_lobpcg.py -> G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy\sparse\linalg\eigen\lobpcg\tests\running install_egg_infoWriting G:\dev\cura-build\build\inst\lib\python3.4\site-packages\scipy-0.16.1-py3.4.egg-inforunning install_clib[ 71%] Completed 'Scipy'[100%] Built target Scipy

To build the missing lapack/blas libraries I downloaded the sources from http://www.netlib.org/lapack/lapack.tgz (currently v3.6.0) EDIT: v3.6.0 has a bug that leads to undefined references, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810143 The errors are shown below as per the original posting. So get Lapack v3.5.0 instead: http://www.netlib.org/lapack/lapack-3.5.0.tgz END EDIT In the unzipped directory, I configured it as follows: mkdir buildcd buildcmake -G "MSYS Makefiles" .. Then I build it: $ mingw32-makeScanning dependencies of target blas[ 5%] Linking Fortran static library ../../lib/libblas.a[ 5%] Built target blasScanning dependencies of target lapack[ 59%] Built target lapackScanning dependencies of target tmglib...[ 93%] Built target xeigtstd...[100%] Built target xeigtstz Then, from G:\dev\lapack-3.6.0\build\lib, I copied the following files to my E:\DevTools\Python34\libs directory: cp G:/dev/lapack-3.6.0/build/lib/libblas.a E:/DevTools/Python34/libs/libblas.acp G:/dev/lapack-3.6.0/build/lib/liblapack.a E:/DevTools/Python34/libs/liblapack.acp G:/dev/lapack-3.6.0/build/lib/libtmglib.a E:/DevTools/Python34/libs/libtmglib.a Resuming the build then gave: [ 86%] Performing build step for 'Scipy'...lapack_info: FOUND: language = f77 libraries = ['lapack'] library_dirs = ['E:\\DevTools\\Python34\\libs']blas_info: FOUND: language = f77 libraries = ['blas'] library_dirs = ['E:\\DevTools\\Python34\\libs'] FOUND: language = f77 libraries = ['lapack', 'blas'] library_dirs = ['E:\\DevTools\\Python34\\libs'] define_macros = [('NO_ATLAS_INFO', 1)] EDIT: The following error occured when running the MSVC build of Scipy, which was the default. I needed to change it to a mingw32 build as shown further below this comment. And build continues until it hits the following error: Found executable E:\Microsoft Visual Studio 14.0\VC\BIN\link.exe Creating library build\temp.win32-3.4\Release\scipy\cluster\_vq.lib and object build\temp.win32-3.4\Release\scipy\cluster\_vq.expgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol _pthread_mutex_lock referenced in function _data_transfer_initgfortran.lib(unix.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_lockgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol _pthread_mutex_unlock referenced in function _data_transfer_initgfortran.lib(unix.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_unlockgfortran.lib(unix.o) : error LNK2019: unresolved external symbol __imp___iob referenced in function __gfortrani_flush_if_preconnectedmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2001: unresolved external symbol __imp___iobgfortran.lib(unix.o) : error LNK2019: unresolved external symbol _pthread_mutex_trylock referenced in function _flush_all_units_1gfortran.lib(unit.o) : error LNK2001: unresolved external symbol _pthread_mutex_trylockgfortran.lib(unit.o) : error LNK2019: unresolved external symbol _pthread_mutex_init referenced in function _insert_unitgfortran.lib(random.o) : error LNK2001: unresolved external symbol _pthread_mutex_initgfortran.lib(unit.o) : error LNK2019: unresolved external symbol _pthread_mutex_destroy referenced in function _get_external_unitgfortran.lib(write.o) : error LNK2019: unresolved external symbol _signbitq referenced in function _write_floatgfortran.lib(write.o) : error LNK2019: unresolved external symbol _finiteq referenced in function _write_floatgfortran.lib(write.o) : error LNK2019: unresolved external symbol _isnanq referenced in function _write_floatgfortran.lib(backtrace.o) : error LNK2019: unresolved external symbol __Unwind_GetIPInfo referenced in function _trace_functiongfortran.lib(backtrace.o) : error LNK2019: unresolved external symbol __Unwind_Backtrace referenced in function __gfortran_backtracemingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol __imp__MessageBoxW@16 referenced in function __wassertmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol __snwprintf referenced in function __wassertmingwex.lib(lib32_libmingwex_a-wassert.o) : error LNK2019: unresolved external symbol _fwprintf referenced in function __wassertmingwex.lib(lib32_libmingwex_a-mingw_pformat.o) : error LNK2019: unresolved external symbol __get_output_format referenced in function ___pformat_emit_efloatmingwex.lib(lib32_libmingwex_a-wcrtomb.o) : error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function _wcrtombmingwex.lib(lib32_libmingwex_a-mbrtowc.o) : error LNK2001: unresolved external symbol __imp____mb_cur_maxbuild\lib.win32-3.4\scipy\cluster\_vq.pyd : fatal error LNK1120: 16 unresolved externalserror: Command "E:\Microsoft Visual Studio 14.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:build\temp.win32-3.4\Release /LIBPATH:E:\DevTools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 /LIBPATH:E:\DevTools\MinGW\i686-w64-mingw32\lib /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:E:\DevTools\Python34\PCbuild /LIBPATH:build\temp.win32-3.4 /LIBPATH:E:\DevTools\Python34\libs /LIBPATH:E:\DevTools\Python34\PCbuild /LIBPATH:build\temp.win32-3.4 lapack.lib blas.lib gfortran.lib gcc.lib mingw32.lib mingwex.lib /EXPORTyInit__vq build\temp.win32-3.4\Release\scipy\cluster\_vq.obj /OUT:build\lib.win32-3.4\scipy\cluster\_vq.pyd /IMPLIB:build\temp.win32-3.4\Release\scipy\cluster\_vq.lib /MANIFESTFILE:build\temp.win32-3.4\Release\scipy\cluster\_vq.pyd.manifest" failed with exit status 1120CMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[2]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2 EDIT: The above clearly uses the VS2015 linker because the default Scipy build uses the default compiler on my system, VS2015. To change the Scipy build to mingw32 we need to change the toplevel CMakeLists.txt file again and add the --compiler=mingw32 option to the setup.py build command: if(BUILD_SCIPY) ExternalProject_Add(Scipy DEPENDS Python Numpy URL http://downloads.sourceforge.net/project/scipy/scipy/0.16.1/scipy-0.16.1.tar.gz CONFIGURE_COMMAND "" BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32 INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install} BUILD_IN_SOURCE 1 endif() Again, don't forget to rerun CMake after this! cmake -G "MSYS Makefiles" .. After deleting the cura-build\build\Scipy-prefix directory (to delete the previous MSVC build results), I restarted the build for mingw32: mingw32-make Scipy Of course, I did not get the same error as above, but another one: ompiling Fortran sourcesFortran f77 compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -O3 -funroll-loopsFortran f90 compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -fno-second-underscore -O3 -funroll-loopsFortran fix compiler: E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -Wall -g -fno-second-underscore -O3 -funroll-loop scompile options: '-DNO_ATLAS_INFO=1 -Ibuild\src.win32-3.4 -IG:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy\core\include -IE:\DevTools\P ython34\include -IE:\DevTools\Python34\include -c'gfortran.exe:f77: G:\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_g77_abi.fgfortran.exe:f77: G:\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_accelerate.fgfortran.exe:f77: build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.fE:\DevTools\MinGW\bin\gfortran.exe -Wall -g -Wall -g -shared build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack module.o build\temp.win32-3.4\Release\build\src.win32-3.4\fortranobject.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scip y\_build_utils\src\wrap_dummy_g77_abi.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src\wrap_dummy_acce lerate.o build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.o -LE:\DevTools\Python34\libs -LE:\Dev Tools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild -Lbuild\temp.win32-3.4 -llapack -lblas -lpython34 -lgfortran -o build\lib.win32-3.4\scipy\linalg\_flapack.pydbuild\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x7fbc): undefined reference to `sgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x8074): undefined reference to `dgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x812c): undefined reference to `cgegv_'build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapackmodule.o:_flapackmodule.c.data+0x81e4): undefined reference to `zgegv_'collect2.exe: error: ld returned 1 exit statuserror: Command "E:\DevTools\MinGW\bin\gfortran.exe -Wall -g -Wall -g -shared build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy \linalg\_flapackmodule.o build\temp.win32-3.4\Release\build\src.win32-3.4\fortranobject.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefi x\src\Scipy\scipy\_build_utils\src\wrap_dummy_g77_abi.o build\temp.win32-3.4\Release\dev\cura-build\build\Scipy-prefix\src\Scipy\scipy\_build_utils\src \wrap_dummy_accelerate.o build\temp.win32-3.4\Release\build\src.win32-3.4\build\src.win32-3.4\scipy\linalg\_flapack-f2pywrappers.o -LE:\DevTools\Python 34\libs -LE:\DevTools\MinGW\lib\gcc\i686-w64-mingw32\5.3.0 -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild -Lbuild\temp.win32-3.4 -llapack - lblas -lpython34 -lgfortran -o build\lib.win32-3.4\scipy\linalg\_flapack.pyd" failed with exit status 1CMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[3]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Scipy.dir/all] Error 2CMakeFiles/Makefile2:488: recipe for target 'CMakeFiles/Scipy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/rule] Error 2Makefile:327: recipe for target 'Scipy' failedmingw32-make: *** [scipy] Error 2 These errors are due to a bug in Lapack v3.6.0 as mentioned above, and do not occur when using v3.5.0. Build v3.5.0 and copy the generated library files to the Python Libs directory as described above.

EDIT: The following error is for a MSVC build of Numpy, which is the default on my system. I leave the info below for reference, but this error does not apply to mingw32 builds of Numpy. Another error happens then, see below. The build of the Numpy target failed with the following error: error: Unable to find vcvarsall.batCMakeFiles/Numpy.dir/build.make:113: recipe for target 'Numpy-prefix/src/Numpy-stamp/Numpy-build' failedmingw32-make[2]: *** [Numpy-prefix/src/Numpy-stamp/Numpy-build] Error 1CMakeFiles/Makefile2:218: recipe for target 'CMakeFiles/Numpy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Numpy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2 What is happening is that the installer is looking in your environmental variables for the Visual Studio 2010 tools, specifically (other versions of VS will not work) In Windows 7, Right click on My Computer -> Properties -> Advanced system settings -> Advanced -> Environmental Variables. In the System Variables, there should be a Variable called VS100COMNTOOLS that points to the Visual Studio 2010 Tools Directory. A workaround if you have a different version of Visual Studio (e.g. VS2015) is to create a new variable named VS100COMNTOOLS and to set its value to the same as the 2015's VS140COMNTOOLS variable, in my case: E:\Microsoft Visual Studio 14.0\Common7\Tools\ EDIT: The above error and solution were for an MSVC build of Numpy. Since I wanted a mingw32 build, I had to add the --compiler=mingw32 to the setup.build rule for Numpy in the toplevel cura-build\CMakeLists.txt file: if(BUILD_NUMPY) ExternalProject_Add(Numpy DEPENDS Python URL http://downloads.sourceforge.net/project/numpy/NumPy/1.9.2/numpy-1.9.2.tar.gz URL_MD5 a1ed53432dbcd256398898d35bc8e645 CONFIGURE_COMMAND "" BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32 INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install} BUILD_IN_SOURCE 1 endif() After this modification, don't forget to rerun CMake: cmake -G "MSYS Makefiles" .. As as alternative to adding the above build option in CMakeLists.txt you could add the following to file cura-build\build\Numpy-prefix\src\Numpy\numpy\distutils\distutils.cfg (create the file if it doesn't exist): [build]compiler=mingw32 Since we previously (wrongly) built it with MSVC, we must delete the cura-build/Numpy-prefix folder and relaunch the build for that target: rm -rf Numpy-prefixmingw32-make Numpy Then however resulted in the following build error: build_srcbuilding py_modules sourcesbuilding library "npymath" sourcesBuilding msvcr library: "E:\DevTools\Python34\libs\libmsvcr100.a" (from E:\jre1.8.0_60\bin\msvcr100.dll)objdump.exe: E:\jre1.8.0_60\bin\msvcr100.dll: File format not recognized...prefix\src\Numpy\numpy\distutils\mingw32ccompiler.py", line 278, in generate_def raise ValueError("Symbol table not found")ValueError: Symbol table not foundCMakeFiles/Numpy.dir/build.make:113: recipe for target 'Numpy-prefix/src/Numpy-stamp/Numpy-build' failedmingw32-make[3]: *** [Numpy-prefix/src/Numpy-stamp/Numpy-build] Error 1CMakeFiles/Makefile2:218: recipe for target 'CMakeFiles/Numpy.dir/all' failedmingw32-make[2]: *** [CMakeFiles/Numpy.dir/all] Error 2CMakeFiles/Makefile2:230: recipe for target 'CMakeFiles/Numpy.dir/rule' failedmingw32-make[1]: *** [CMakeFiles/Numpy.dir/rule] Error 2Makefile:236: recipe for target 'Numpy' failedmingw32-make: *** [Numpy] Error 2 The problem is that the numpy distutils is trying to read the symbol table using "objdump" from msvcr100.dll but it can't recognize the format. As a workaround, edit the following file where the above check is made: cura-build\build\Numpy-prefix\src\Numpy\numpy\distutils\mingw32ccompiler.py Comment out the following lines: # Check for custom msvc runtime library on Windows. Build if it doesn't exist. msvcr_success = build_msvcr_library() msvcr_dbg_success = build_msvcr_library(debug=True) if msvcr_success or msvcr_dbg_success: # add preprocessor statement for using customized msvcr lib self.define_macro('NPY_MINGW_USE_CUSTOM_MSVCR') Thus: # Check for custom msvc runtime library on Windows. Build if it doesn't exist. #msvcr_success = build_msvcr_library() #msvcr_dbg_success = build_msvcr_library(debug=True) #if msvcr_success or msvcr_dbg_success: # # add preprocessor statement for using customized msvcr lib # self.define_macro('NPY_MINGW_USE_CUSTOM_MSVCR') Resuming the build then successfully completed target NumPy: running install_egg_infoWriting G:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy-1.9.2-py3.4.egg-inforunning install_clibcopying build\temp.win32-3.4\npymath.lib -> G:\dev\cura-build\build\inst\lib\python3.4\site-packages\numpy\core\lib[ 74%] Completed 'Numpy'[ 78%] Built target Numpy EDIT: The PySerial build defaults also to MSVC on my system, so I needed to add the --compiler=mingw32 switch to the setup.py build command in cura-build\CMakeLists.txt, i.e.: if(BUILD_PYSERIAL) ExternalProject_Add(PySerial DEPENDS Python URL https://pypi.python.org/packages/source/p/pyserial/pyserial-2.7.tar.gz URL_MD5 794506184df83ef2290de0d18803dd11 CONFIGURE_COMMAND "" BUILD_COMMAND ${PYTHON_EXECUTABLE} setup.py build --compiler=mingw32 INSTALL_COMMAND ${PYTHON_EXECUTABLE} setup.py install ${python_install} BUILD_IN_SOURCE 1 )endif() The build of target PySerial works, but the following SciPy build fails with the following error: ... File "scipy\linalg\setup.py", line 20, in configuration raise NotFoundError('no lapack/blas resources found')numpy.distutils.system_info.NotFoundError: no lapack/blas resources foundCMakeFiles/Scipy.dir/build.make:114: recipe for target 'Scipy-prefix/src/Scipy-stamp/Scipy-build' failedmingw32-make[2]: *** [scipy-prefix/src/Scipy-stamp/Scipy-build] Error 1CMakeFiles/Makefile2:476: recipe for target 'CMakeFiles/Scipy.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Scipy.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build