umagi

As a temporary workaround, we replaced the VERSION string by a litteral string, i.e. gcode.writeComment("Generated with Cura_SteamEngine " VERSION); by: gcode.writeComment("Generated with Cura_SteamEngine " "2.0.99-2.1"); I needed to do this in the following two files: G:\dev\cura-build\build\CuraEngine-prefix\src\CuraEngine\src\FffGcodeWriter.cppG:\dev\cura-build\build\CuraEngine-prefix\src\CuraEngine\src\Wireframe2gcode.cpp After this, CuraEngine proceeds to build to completion! [ 31%] Linking CXX static library lib_CuraEngine.a[ 95%] Built target _CuraEngine[ 97%] Building CXX object CMakeFiles/CuraEngine.dir/src/main.cpp.obj[100%] Linking CXX executable CuraEngine.exe[100%] Built target CuraEngine[ 89%] Performing install step for 'CuraEngine'[ 4%] Built target clipper[ 95%] Built target _CuraEngine[100%] Built target CuraEngineInstall the project...-- Install configuration: "Release"-- Installing: G:/dev/cura-build/build/inst/bin/CuraEngine.exe[ 93%] Completed 'CuraEngine'[100%] Built target CuraEngineumagi@HOME-PC MSYS /g/dev/cura-build/build Up to the next error in the Cura build...

I managed to proceed with the build of: https://github.com/Ultimaker/cura-build Which automatically checks out branch 2.1 I am at the stage where it starts to build the CuraEngine (I got the all the required dependencies to build, after some tweaks). For the build, I still used MinGW-w64+MSYS2, but this time with CMake generator "MSYS Makefiles" instead of "MinGW Makefiles". Things seem to go smoother this way, as I don't get the annoying error anymore then: For MinGW make to work correctly sh.exe must NOT be in your path. Run cmake from a shell that does not have sh.exe in your PATH. Some say that using MSYS Makefiles make things run slower, but I don't really care for the moment, as long as things get done. Among the tweaks I had to use was to replace the ./configure part in the Qt build with ./configure.bat to work around the following error: The build script does not currently recognize all platforms supported by Qt. Rerun this script with a -platform option listed to set the system/compiler combination you use. First, I ran the configure.bat script manually, which works fine. Then, to avoid the above error whenever I rerun make, I edited the following script: %cura-build%/build/CMakeFiles/Qt.dir/build.make And replaced ./configure by ./configure.bat at the correct location: Qt-prefix/src/Qt-stamp/Qt-configure: Qt-prefix/src/Qt-stamp/Qt-patch@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=/G/dev/cura-build/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_7) "Performing configure step for 'Qt'"cd /G/dev/cura-build/build/Qt-prefix/src/Qt && ./configure.bat -release -prefix G:/dev/cura-build/build/inst -archdatadir G:/dev/cura-build/build/inst/lib -datadir G:/dev/cura-build/build/inst/share -opensource -confirm-license -nomake examples -nomake tests -no-cups -skip qtconnectivity -skip qtdoc -skip qtenginio -skip qtlocation -skip qtmultimedia -skip qtquick1 -skip qtscript -skip qtsensors -skip qtwebchannel -skip qtwebengine -skip qtwebkit -skip qtwebsockets -skip qtandroidextras -skip qtactiveqt -skip qttools -skip qtxmlpatterns -skip qt3d -skip qtcanvas3d -skip qtserialport -skip qtwayland -skip qtwebkit-examples -opengl desktopcd /G/dev/cura-build/build/Qt-prefix/src/Qt && /E/DevTools/CMake/bin/cmake.exe -E touch G:/dev/cura-build/build/Qt-prefix/src/Qt-stamp/Qt-configure Another tweak was to perform the installation part of Sip manually, to work around this strange error: [ 35%] Performing install step for 'Sip'/usr/bin/sh: -c: line 1: syntax error: unexpected end of fileMakefile:39: recipe for target 'install' failedmingw32-make[4]: *** [install] Error 1Makefile:7: recipe for target 'install' failedmingw32-make[3]: *** [install] Error 2CMakeFiles/Sip.dir/build.make:73: recipe for target 'Sip-prefix/src/Sip-stamp/Sip-install' failedmingw32-make[2]: *** [sip-prefix/src/Sip-stamp/Sip-install] Error 2CMakeFiles/Makefile2:513: recipe for target 'CMakeFiles/Sip.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Sip.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2 The workaround I tried was by first having a dry run (i.e. with the -n Make switch for the install target) of the Makefile: G:\dev\cura-build\build\Sip-prefix\src\Sip\Makefile Performing the dry run mingw32-make install -n in the Sip directory above shows which files are to be copied where. Then, I replaced the build rules for the install target in the above Makefile by direct cp commands: cp G:/dev/cura-build/build/Sip-prefix/src/Sip/sipgen/sip.exe G:/dev/cura-build/build/inst/bin/sip.execp G:/dev/cura-build/build/Sip-prefix/src/Sip/siplib/sip.pyd G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sip.pydstrip G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sip.pydcp G:/dev/cura-build/build/Sip-prefix/src/Sip/siplib/sip.h G:/dev/cura-build/build/inst/include/sip.hcp sipconfig.py G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sipconfig.pycp G:/dev/cura-build/build/Sip-prefix/src/Sip/sipdistutils.py G:/dev/cura-build/build/inst/lib/python3.4/site-packages/sipdistutils.py I know, not very pretty at all, but since I don't know much about build systems like this one, and since it works, I don't really care for now. Finally, I got to the CuraEngine build, which unfortunately fails too with a rather strange version format error: Scanning dependencies of target _CuraEngine[ 6%] Building CXX object CMakeFiles/_CuraEngine.dir/src/bridge.cpp.obj[ 8%] Building CXX object CMakeFiles/_CuraEngine.dir/src/comb.cpp.obj[ 10%] Building CXX object CMakeFiles/_CuraEngine.dir/src/commandSocket.cpp.obj[ 12%] Building CXX object CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj:0:9: error: too many decimal points in numberG:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp:225:59: note: in expansion of macro 'VERSION' gcode.writeComment("Generated with Cura_SteamEngine " VERSION); ^G:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp: In member function 'void cura::FffGcodeWriter::processStartingCode(cura::SliceDataStorage&'::0:9: error: expected ')' before numeric constantG:/dev/cura-build/build/CuraEngine-prefix/src/CuraEngine/src/FffGcodeWriter.cpp:225:59: note: in expansion of macro 'VERSION' gcode.writeComment("Generated with Cura_SteamEngine " VERSION); ^CMakeFiles/_CuraEngine.dir/build.make:146: recipe for target 'CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj' failedmingw32-make[5]: *** [CMakeFiles/_CuraEngine.dir/src/FffGcodeWriter.cpp.obj] Error 1CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/_CuraEngine.dir/all' failedmingw32-make[4]: *** [CMakeFiles/_CuraEngine.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make[3]: *** [all] Error 2CMakeFiles/CuraEngine.dir/build.make:111: recipe for target 'CuraEngine-prefix/src/CuraEngine-stamp/CuraEngine-build' failedmingw32-make[2]: *** [CuraEngine-prefix/src/CuraEngine-stamp/CuraEngine-build] Error 2CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/CuraEngine.dir/all' failedmingw32-make[1]: *** [CMakeFiles/CuraEngine.dir/all] Error 2Makefile:149: recipe for target 'all' failedmingw32-make: *** [all] Error 2 The Make dry run shows that VERSION is expanded to 2.0.99-2.1, as set in the top-level cura-build/CMakeLists.txt file, and is passed as -DVERSION=\"2.0.99-2.1\" at the command line of g++. So the quotes are escaped correctly. I'm stuck with this error for the moment, so if anyone has an idea of what's going on, please let me know! Thanks!

OOPS.. this message was posted twice? No way to delete it myself it seems, so I just left this. Deleting all text does not work...

The next step now... building the Cura Engine... Unfortunately, this does not seem to be possible using the MSVC compilers because of this error: g:\dev\cura-b2.1\curaengine\src\utils/gettime.h(: fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directoryNMAKE : fatal error U1077: 'E:\MICROS~1.0\VC\bin\amd64\cl.exe' : return code '0x2'Stop. Since MSVC does not have a sys/time.h header. I tried to replace the source code by time.h instead, but this gives a bunch of other errors... I tried to compile it with MinGW instead, but then I get errors relating to the fact that I should probably also build the other dependencies (libArcus and protobuf) using MinGW instead of MSVC?

I built protobuf and then made cmake point to the .lib file and the include directory: (Note that I am using NMake now in a VS2015 x64 Native Tools Command Prompt window, since it seems to work better than with MinGW-w64?) cmake -G "NMake Makefiles" -DPROTOBUF_INCLUDE_DIR="E:\DevTools\protobuf\include" -DPROTOBUF_LIBRARY="E:\DevTools\protobuf\lib\libprotobuf.lib" .. After also downloading and compiling SIP, the build of libArcus finally succeeds after changing some incompatible settings in CMakeLists.txt of libArcus: libprotobuf.lib(structurally_valid.cc.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease'doesn't match value 'MTd_StaticDebug' in sipArcuspart0.cpp.obj I got a similiar error about static/dynamic is because protobuf was built as a static library, while libArcus by default builds as a dynamic one, and needed to edit libArcus' toplevel CMakeLists.txt file and change the following settings: option(BUILD_STATIC "Build as a static library" ON)...option(MSVC_STATIC_RUNTIME "Link the MSVC runtime statically" ON) The actual error above was because protobuf was CMake-configured with DCMAKE_BUILD_TYPE=Release, so I needed to use it for libArcus too. cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DPROTOBUF_INCLUDE_DIR="E:\DevTools\protobuf\include" -DPROTOBUF_LIBRARY="E:\DevTools\protobuf\lib\libprotobuf.lib" .. So the libArcus part compiles and installs correctly now. The previous linking error: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit status was because I installed the 64bit version of python 3.4.4. Replacing it by the 32bit version eliminated that error.

The SIP build succeeds using VS2015's nmake: G:\dev\cura-b2.1\sip-4.17>nmakeMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. cd sipgen "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"Microsoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -Fo @C:\Users\umagi\AppData\Local\Temp\nmD4EE.tmpmain.ctransform.cgencode.cextracts.cexport.cheap.cparser.clexer.cGenerating Code... link /NOLOGO /DYNAMICBASE /NXCOMPAT /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:sip.exe.manifest /SUBSYSTEM:CONSOLE /OUT:sip.exe @C:\Users\umagi\AppData\Local\Temp\nmEA82.tmp mt -nologo -manifest sip.exe.manifest -outputresource:sip.exe;1 cd siplib "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"Microsoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -IE:\DevTools\Python34\include -Fo @C:\Users\umagi\AppData\Local\Temp\nmEB3C.tmpsiplib.capiversions.cdescriptors.cqtlib.cthreads.cobjmap.cvoidptr.carray.cGenerating Code... cl -c -nologo -Zm200 -Zc:wchar_t- -FS -Zc:strictStrings -D_HAS_EXCEPTIONS=0 -O2 -MD -W0 -DNDEBUG -DUNICODE -DWIN32 -I. -IE:\DevTools\Python34\include -Fo @C:\Users\umagi\AppData\Local\Temp\nmEF81.tmpbool.cpp link /NOLOGO /DYNAMICBASE /NXCOMPAT /DLL /MANIFEST /MANIFESTFILE:sip.pyd.manifest /SUBSYSTEM:CONSOLE /INCREMENTAL:NO/OUT:sip.pyd @C:\Users\umagi\AppData\Local\Temp\nmEFEF.tmp Creating library sip.lib and object sip.exp mt -nologo -manifest sip.pyd.manifest -outputresource:sip.pyd;2G:\dev\cura-b2.1\sip-4.17>nmake installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. cd sipgen "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. copy /y sip.exe E:\DevTools\Python34\sip.exe 1 file(s) copied. cd siplib "E:\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" installMicrosoft ® Program Maintenance Utility Version 14.00.23026.0Copyright © Microsoft Corporation. All rights reserved. copy /y sip.pyd E:\DevTools\Python34\Lib\site-packages\sip.pyd 1 file(s) copied. copy /y G:\dev\cura-b2.1\sip-4.17\siplib\sip.h E:\DevTools\Python34\include\sip.h 1 file(s) copied. copy /y sipconfig.py E:\DevTools\Python34\Lib\site-packages\sipconfig.py 1 file(s) copied. copy /y G:\dev\cura-b2.1\sip-4.17\sipdistutils.py E:\DevTools\Python34\Lib\site-packages\sipdistutils.py 1 file(s) copied.G:\dev\cura-b2.1\sip-4.17> With SIP now installed, I resume the Arctus configuration stage, which fails again because it cannot find PROTOBUF: umagi@HOME-PC MINGW64 /G/dev/cura-b2.1/libArcus/build (2.1)$ cmake -G "MinGW Makefiles" ..-- Could NOT find PROTOBUF (missing: PROTOBUF_LIBRARY PROTOBUF_INCLUDE_DIR)-- Found SIP version: 4.17CMake Error: The following variables are used in this project, but they are set to NOTFOUND.Please set them or make sure they are set and tested correctly in the CMake files:G:/dev/cura-b2.1/libArcus/PROTOBUF_INCLUDE_DIR used as include directory in directory G:/dev/cura-b2.1/libArcusPROTOBUF_LIBRARY (ADVANCED) linked by target "Arcus" in directory G:/dev/cura-b2.1/libArcus-- Configuring incomplete, errors occurred!See also "G:/dev/cura-b2.1/libArcus/build/CMakeFiles/CMakeOutput.log".

Hi Nallath, Thanks for your help. I appreciate it. Got it... branch 2.1 But... when making libArcus: Traceback (most recent call last): File "G:/dev/cura-b2.1/libArcus/cmake/FindSIP.py", line 8, in import sipconfigImportError: No module named 'sipconfig'CMake Error at cmake/FindSIP.cmake:58 (MESSAGE): Could not find SIPCall Stack (most recent call first): CMakeLists.txt:22 (find_package) So I tried to dowload and install SIP from here: https://riverbankcomputing.com/software/sip/download Then in the sip-4.17 directory, I ran: python configure.py --platform win32-g++This is SIP 4.17 for Python 3.4.4 on win32.The SIP code generator will be installed in E:\DevTools\Python34.The sip module will be installed in E:\DevTools\Python34\Lib\site-packages.The sip.h header file will be installed in E:\DevTools\Python34\include.The default directory to install .sip files in is E:\DevTools\Python34\sip.Creating siplib\sip.h...Creating siplib\siplib.c...Creating siplib\siplib.sbf...Creating sipconfig.py...Creating top level Makefile...Creating sip code generator Makefile...Creating sip module Makefile... Then: mingw32-makemingw32-make[1]: Entering directory 'G:/dev/cura-b2.1/sip-4.17/sipgen'mingw32-make[1]: Nothing to be done for 'all'.mingw32-make[1]: Leaving directory 'G:/dev/cura-b2.1/sip-4.17/sipgen'mingw32-make[1]: Entering directory 'G:/dev/cura-b2.1/sip-4.17/siplib'gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o siplib.o siplib.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o apiversions.o apiversions.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o descriptors.o descriptors.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o qtlib.o qtlib.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o threads.o threads.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o objmap.o objmap.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o voidptr.o voidptr.cgcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o array.o array.cg++ -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -IE:\DevTools\Python34\include -o bool.o bool.cppg++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -shared -Wl,-subsystem,console -Wl,-s -o sip.pyd siplib.o apiversions.o descriptors.o qtlib.o threads.o objmap.o voidptr.o array.o bool.o -LE:\DevTools\Python34\libs -lpython34E:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statusMakefile:36: recipe for target 'sip.pyd' failedmingw32-make[1]: *** [sip.pyd] Error 1mingw32-make[1]: Leaving directory 'G:/dev/cura-b2.1/sip-4.17/siplib'Makefile:3: recipe for target 'all' failedmingw32-make: *** [all] Error 2 So, I basically get the same error as I first reported in this thread. Why does everyone keep telling this? For instance, is the CuraEngine written in Python? I thought it was written in C++ and therefore needs to be compiled.

I want to build it to educate myself and to possible mess around with the code later. What do you mean by 2.1? I just use the git cloning procedure: git clone git@github.com:Ultimaker/cura-build.git This should give me the master repository and therefore the latest Cura version?

EDIT: This post first started out of my initial frustration of not succeeding in building Cura's developer's version in Windows using MingGW-w64 and MSYS2, and trying to get some help. It evolved into a rather long monologue that documents my step-by-step build of the Cura package, the problems I encountered and the sometimes uggly workarounds I used. The final lesson from all this is that building Cura in Windows 7 with MinGW-w64 and MSYS2 works! Hopefully, my post will be of some help to others... EDIT2: After installing the freshly built installer package on a Windows 7 Virtual machine... I get an error. So not all is well yet... For the error see my latest entries in this thread below. EDIT3: Although the Cura package and installer build to completion, launching the Cura (developer's version) program fails with the error at the end of this thread. EDIT4: To have a working Cura build, I just used the daid script (the one that creates the official Cura releases, it seems) from: https://github.com/daid/Cura After a few tweaks, the Daid script worked for my installation using the latests MinGW-w64+MSYS2 and the installer package builder NSIS3 except for the build of CuraEngine.exe, which must be compiled from scratch. But I already built it using the cura-build (developer's version) script. Just copying that one and using the rest of the Daid script seems to work. Cura installs and runs correctly as far as I can see. I still need to figure out why the dev version of Cura crashes after launch though. Hi I have been utterly wasting my time trying to build Cura in Windows 7 (64bit) using the instructions from https://github.com/Ultimaker/cura-build and also from: https://github.com/daid/Cura Both to no avail. I have installed: CMake 3.4.3 MinGW-w64 from https://sourceforge.net/projects/mingw-w64/ msys2 from https://sourceforge.net/projects/msys2/files/latest/download' PyQt5-5.5.1: PyQt5-5.5.1-gpl-Py3.4-Qt5.5.1-x64.exe Python 3.4.4 numpy-1.10.2-win32-superpack-python3.4.exe I did the following in MSYS2 (and also tried in Git Bash): git clone git@github.com:Ultimaker/cura-build.gitmkdir buildcd build../env_win64.batcmake -G "MinGW Makefiles" ..mingw32-make I also tried with env_win32.bat, and also once tried with cmake .. to generate the default generator, which in my case is Visual Studio 14.0 - from VS2015 and tried to build the solution in VS2015. All these trials did not work either... The build of the Protobuf target succeeds, but then I hit a snag witth the following error: [ 5%] Completed 'Protobuf'[ 7%] Built target Protobuf[ 7%] Built target Python[ 7%] Performing update step for 'Protobuf-python'Current branch master is up to date.[ 8%] Performing copy-libproto step for 'Protobuf-python'[ 9%] No configure step for 'Protobuf-python'[ 10%] Performing build step for 'Protobuf-python'running buildrunning build_pyrunning build_extbuilding 'google.protobuf.pyext._message' extensionE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_containers.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_database.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_pool.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\extension_dict.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\map_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\message.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_composite_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_scalar_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o -Wno-write-strings -Wno-invalid-offsetofwriting build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.defE:\DevTools\MinGW\bin\g++.exe -shared -s build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.def -L../src/.libs -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild\amd64 -lprotobuf -lpython34 -lmsvcr100 -o build\lib.win-amd64-3.4\google\protobuf\pyext\_message.pydE:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build The error is thus: E:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2 Does anyone have an idea about this error or more detailed info about a working build procedure with detailed configuration info and correct (i.e. compatible) versions for the various dependencies to use? Thanks from a very frustrated Cura beginner...

Hi John, I tested the UM2 in a location with bad flooring, and regularly get ESD discharges when touching the door knob. I mentioned this problem to the persons in charge there and they will consider installing some grounded mat or something. In any case, I should probably wear a grounding wrist wrap, and drink more water...

Deleted as duplicate of previous post.

Hi, I have built my own UM2 with aluminum extrusion profiles as frame and some minor modifications to make it slightly taller than the UM2 extended. The aluminum extrusion frame is covered with composite aluminum panels ("dibond-like"). The control knob is a solid one made of anodized aluminum (see image below). I used a switched power supply 24V/10A with AC ground connected to the aluminum frame. For the testing however, I used the output of a stabilized lab power supply (so that I could also see the actual current drawn) but I did not connect the ground of that supply to my UM2 frame during the test. When touching the control knob on the Ulticontroller v2.1, an electrostatic discharge (ESD) occured which took out the controller: the display and knob leds went out and I could smell that something had fried. Inspection of the PCB showed that chip U3 on the PCB (the PCA9306 chip: Dual Bidirectional I2C Bus and SMBus Voltage-Level Translator) was fried: the package shows a hump on the top (see image below) I will try to replace that component, hoping that the damage was limited to that one alone and did not propagate to other parts of the circuitry, especially the main board. But how can I effectively protect my UM2 against such ESD damage in the future? Was the choice of using an aluminum knob a bad one since it provided a discharge path into the circuitry? Thanks for sharing your insights on this!

Hi, I have built my own UM2 Extended (made it even higher + some small modifications for more rigid heated bed platform, see pictures) and am now in the process of compiling the UM2 Extended firmware (from the official git repository, UM2 branch). I have first tried with the default UM2 extended firmware included in the latest Cura version (Cura 15.04.4) and compared it with the .hex file built using the latest Arduino IDE (v1.6.7) on Windows. Cura binary: Cura_15.04.4\resources\firmware\MarlinUltimaker2extended.hex Source for Arduino build: https://github.com/Ultimaker/Ultimaker2Marlin When comparing both .hex version using a hex file comparator, it is obvious that both files are very very different. My question is therefore this: How is the default UM2 extended firmware included in Cura built? Why are the two images so different? Are they any extra libraries included in the Cura image? Different optimization? Different compiler? I have many questions upcoming concerning the debug process of my self-built UM2, which boots but does not seem to home properly, and hope to get some help from experienced people here^^. Many thanks for your help.