umagi
-
Posts
63 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by umagi
-
-
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?
-
As to finding protobuf, did you install protobuf 3 beta 2? You can find it on https://github.com/google/protobuf/releases
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.
What do you mean by 2.1?
git clone -b 2.1 git@github.com:Ultimaker/cura.git...
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.
Python is an interpreted language. There is no need to compile it.
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.
-
Why do you want to build it in the first place? The building is to create a distributable.
I want to build it to educate myself and to possible mess around with the code later.
I don't ever seem to get the protobuf-python state. Have you updated all repo's to 2.1?
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:
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:
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.
Building Cura (dev version) with MinGW-w64 works, but Cura fails on launch.
in UltiMaker Cura
Posted · Edited by Guest
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...