NightHammer1000
commented
6 years ago Only happens when
define XY_DIAG_AC [Value]
define XY_DIAG_BD [Value]
define XY_SIDE_AD [Value]
is set.
Closed NightHammer1000 closed 6 years ago
NightHammer1000
commented
6 years ago Only happens when
is set.
Bob-the-Kuhn
commented
6 years ago Confirmed. When SKEW_CORRECTION is uncommented and and XY_SKEW_FACTOR 0.0 is commented out uou get the following error message.
Marlin\src\HAL\HAL_LPC1768\../../inc/Conditionals_post.h:1037:32: error: call to non-constexpr function 'double tan(double)'
That's a new type of error to me. I'll see what it takes to fix it.
NightHammer1000
commented
6 years ago Change constexpr to const at Line 1041, 1053 and 1062 in Conditinals_post.h fixes the Problem. Looks like the toolchain used for the MKS SBASE cant handle constexpr.
Bob-the-Kuhn
commented
6 years ago The error I now get is:
Marlin\src\module/planner.h:237:49: error: the value of 'XY_SKEW_FACTOR' is not usable in a constant expression
This is all new to me. As I read a few articles, the standard C11 math functions are not constexpr and everything in the routine has to be constexpr. I'm wondering if we need a different math library.
Bob-the-Kuhn
commented
6 years ago If I switch to a 2560 the compile errors go away.
Bob-the-Kuhn
commented
6 years ago If I switch to DUE and disable the scara.cpp module then the problem goes away.
Bob-the-Kuhn
commented
6 years ago This is beyond my expertise.
The three processors use different math.h libraries. I tried just replacing the LPC1768 one with the DUE one but the compile error didn't change.
Due "C:\Users\bobku.platformio\packages\toolchain-gccarmnoneeabi@1.40804.0\arm-none-eabi\include"
LPC1768 "C:\Users\bobku.platformio\packages\toolchain-gccarmnoneeabi\arm-none-eabi\include"
2560 "C:\Users\bobku.platformio\packages\toolchain-atmelavr\avr\include"
ejtagle
commented
6 years ago @Bob-the-Kuhn : The problem is that a 'constexpr' must be an expression whose value MUST be computed at compile time. GCC does not always compute trigonometric functions at compile time, even if their arguments are constants.
You can try the -ffast-math gcc flag. The reason why GCC does NOT compute trigonometric functions at compile time, is that the value of those functions can change based on the floating point processor rounding mode.
GCC documentation warns about that (no compile time evaluation of trig functions if rounding mode can´t be deterrmined)
My suggestion is just to
1) try the -ffast-math flag
2) or evaluate the constant manually and place the value there instead of trusting the compiler
3) or do not use constexpr for that
Bob-the-Kuhn
commented
6 years ago @ejtagle - any idea why DUE compiles without problems and the LPC1768 doesn't?
computed at compile time
That means the run time math libraries don't enter into the consideration.
ejtagle
commented
6 years ago GCC version @Bob-the-Kuhn ... If you update the toolchain to a newer version, it should work
ejtagle
commented
6 years ago gcc -v should give you the version. I am sure DUE is newer than the one used by LPC. But installing a generic ARM toolchain should work
thinkyhead
commented
6 years ago evaluate the constant manually and place the value there instead of trusting the compiler
It's better if we can let the compiler or runtime library compute these, rather than ask users to get out their scientific calculators. If it becomes a total blocker, I suppose we can provide a skew calculator on the website. We need to do a basic one anyway at some point.
Meanwhile, if this is needed because GCC is determined to be stingy, we can calculate the skew factors at compile-time for any toolchains (or platforms) where this issue is known to exist. We'd just do it in planner.h in the Planner constructor.
I wonder if there's a compiler-defined macro we can check for this feature…?
ejtagle
commented
6 years ago it is a compiler version "bug" . You can certainly check gcc version
thinkyhead
commented
6 years ago What GCC version should we check for? Last time we had a check (for C++11) it looked like this...
#if __cplusplus < 201103L
. . .
#endifThat ensures at least c++11 features are available. But does not ensure a bug free GCC
The proper macros for this are GNUC // major GNUC_MINOR // minor GNUC_PATCHLEVEL // patch
(https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html)
The problem you see is just a GCC that is newer than 2011, but too old to properly propagate constexprs. The PlatformIO does show the problem. I bet the LPC toolchain is the oldest one...
p3p
commented
6 years ago I bet the LPC toolchain is the oldest one...
The lpc1768 plaform in platformio uses the newest toolchain-gccarmnoneeabi package available (gcc version 7.2.1 20170904 (release)) whereas the DUE platform uses (gcc version 4.8.4 20140725 (release)) built with the same configuration, so it is unlikely to be related to bugs or version, to be honest I wasn't aware C++11 allowed constexpr maths functions yet on any (standard)version, I know there was discussion regarding it and how to get around the floating point representation being unknown, but even min/max are not constexpr until c++14..
ejtagle
commented
6 years ago @p3p You are right in the sense there is no official support for math constexprs. In fact, the evaluation of a trig function at compile time just works by accident sometimes (probably depends even on the compilation of GCC itself)
The following page explaing the problems of float optimization, and why GCC does not do them by default: https://gcc.gnu.org/wiki/FloatingPointMath
And the following one https://gcc.gnu.org/gcc-4.3/changes.html , Take a close look at the following paragraph:
General Optimizer Improvements
The GCC middle-end has been integrated with the MPFR library. This allows GCC to evaluate and
replace at compile-time calls to built-in math functions having constant arguments with their
mathematically equivalent results.
In making use of MPFR, GCC can generate correct results regardless of the math library
implementation or floating point precision of the host platform.
This also allows GCC to generate identical results regardless of whether one compiles in native
or cross-compile configurations to a particular target. The following built-in functions take
advantage ofthis new capability: acos, acosh, asin, asinh, atan2, atan, atanh, cbrt, cos, cosh,
drem,erf, erfc, exp10, exp2, exp, expm1, fdim, fma, fmax, fmin, gamma_r, hypot, j0, j1, jn,
lgamma_r, log10, log1p,log2, log, pow10, pow, remainder, remquo, sin, sincos, sinh, tan, tanh,
tgamma, y0, y1 and yn. The float and long double variants of these functions (e.g. sinf and sinl)
are also handled. The sqrt and cabs functions with constant arguments were already optimized
in prior GCC releases. Now they also use MPFR.So i guess something is wrong with the LPC toolchain, or that the above optimization has been removed from the following versions of GCC
As it turns out, seems the GCC toolchain can be built without the MPFR library, and if that is the case, then no compile time optimizations of math functions will be done. Maybe that could be the problem of the LPC toolchain ?
p3p
commented
6 years ago @ejtagle MPFR is in the configuration for both versions (DUE and LPC) but other than that I don't know enough about it to say why its not doing what it should be
ejtagle
commented
6 years ago @p3p: I did some tests:
My "testsuite" is the following piece of code:
enum myenum {
constvalue = int(sin(2.23*100)),
value2 = 1
};
constexpr myenum n = constvalue;
void setup() { pinMode(13, OUTPUT); }
void loop() {
if ((millis() & 1) != 0) {
digitalWrite(13, (constvalue & 1) != 0);
} else {
digitalWrite(13, (constvalue & 2) != 0);
}
}I suppose we all agree that enum values MUST BE evaluated at compile time, otherwise there is no way for the compiler to know what to do. If the compiler is unable to calculate the value of the enum label constvalue, it just can´t compile the code.
So i tested 3 compilers, and in all of them worked
Using built-in specs.
COLLECT_GCC=C:\Users\ejtagle\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++
COLLECT_LTO_WRAPPER=c:/users/ejtagle/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/7.2.1/lto-wrapper.exe
Target: arm-none-eabi
Configured with: /tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/src/gcc/configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw --libexecdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/lib --infodir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-mingw-wildcard --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/install-mingw/arm-none-eabi --with-libiconv-prefix=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-gmp=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-mpfr=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-mpc=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-isl=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-libelf=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-633_20171130_1512067137/build-mingw/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2017-q4-major' --with-multilib-list=rmprofile
Thread model: single
gcc version 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] (GNU Tools for Arm Embedded Processors 7-2017-q4-major)Using built-in specs.
COLLECT_GCC=C:\Users\ejtagle\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=c:/users/ejtagle/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/lto-wrapper.exe
Target: arm-none-eabi
Configured with: /home/build/work/GCC-4-8-build/src/gcc/configure --build=i686-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/home/build/work/GCC-4-8-build/install-mingw --libexecdir=/home/build/work/GCC-4-8-build/install-mingw/lib --infodir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/home/build/work/GCC-4-8-build/install-mingw/arm-none-eabi --with-libiconv-prefix=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-gmp=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-mpfr=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-mpc=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-isl=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-cloog=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-libelf=/home/build/work/GCC-4-8-build/build-mingw/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322] (GNU Tools for ARM Embedded Processors)Using built-in specs.
Reading specs from c:/users/ejtagle/appdata/local/arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/../lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=C:\Users\ejtagle\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\4.9.2-atmel3.5.4-arduino2/bin/avr-g++
COLLECT_LTO_WRAPPER=c:/users/ejtagle/appdata/local/arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/../libexec/gcc/avr/4.9.2/lto-wrapper.exe
Target: avr
Configured with: ../gcc/configure --enable-fixed-point --enable-languages=c,c++ --prefix=/c/jenkins/workspace/avr-gcc/label/winxp-32-mingw/objdir --enable-long-long --disable-nls --disable-checking --disable-libssp --disable-libada --disable-shared --enable-lto --with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 4.9.2 (GCC)The 7.2.1 GCC is a fresh download from the official ARM site https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
Just replace the LPC toolchain with this one, and it should work (to be honest, i always prefer original releases compared to rebundles of them - They tend to work better)
And to be fair, i had already had some troubles with the 4.8.3 version or the GCC ARM compiler (internal errors! ... That is why i always try to go with the latest official build of it
ejtagle
commented
6 years ago BTW: You can force the compile time evaluation of an expression by abusing of templates, but only if the result is an integer:
template<int v> struct ConstExpr { enum { value = v; }; };
#define COMPILE_TIME_EVAL( v ) ConstExpr< (int)(v)>::valueIf you need a float evaluation, this wont work,
p3p
commented
6 years ago okay, I can work around it, (not yet explain) -fsingle-precision-constant build flag.. double sin(double) is not constexpr for some reason, not that we should be using doubles anyway, I'l look into it more in a bit
ejtagle
commented
6 years ago yes, a float number constant is double by default, unless postfixed by f
10.5 => double 10.5f => float
But, on ARM doubles -should- be converted to floats. As that is not the rule for all archs, then i would not be surprised if some optimizations do not work as intended...
p3p
commented
6 years ago But, on ARM doubles -should- be converted to floats
Not sure what you mean, ARM has the double type and it is 64bits, AVR does not (double and float are 32bit), but I agree something is not working as expected the double version of sin should still work as constexpr.
p3p
commented
6 years ago I think specifying -fsingle-precision-constant is probably a good idea even without this issue, Marlin does not need double precision and because they are the same thing on AVR no care is taken to specify the correct constant type.
ejtagle
commented
6 years ago Even for ARM Cortex with the FPU, that is a good idea. doubles are only handled in CortexM7 (assuming it has an FPU)
Yes, Marlin only needs single precision float
p3p
commented
6 years ago Indeed the FPU only handles floats on the Cortex M4 (etc) and double maths is silently handled by the MCU, on the M3 it's just throwing cycles away, I'l add -fsingle-precision-constant to the lpc176x build.
thinkyhead
commented
6 years ago The LPC toolchain in my PlatformIO install is version 3.1.0 and doesn't exhibit this issue.
Lacking any automated way to check for compile-time evaluation, it sounds like a hidden option to use runtime-calculation for the skew factors would be useful.
p3p
commented
6 years ago I had left -ffreestanding enabled, this disables builtins, which disables some compile time evaluations so I think this is resolved now, and even better I know why it happened, It also explains a previous issue with builtins not being available in the LPC176x platform.
Roxy-3D
commented
6 years ago Even for ARM Cortex with the FPU, that is a good idea. doubles are only handled in CortexM7 (assuming it has an FPU)
One place double's make sense is in the interrupt service routines on the 32-bit platforms. The reason is the floating point processor registers are not saved on entry to the ISR. So, by declaring things double, everything is done in software. If a floating point number really needs to be done within an ISR... Make sure it is done as a double!
thinkyhead
commented
6 years ago Actually, on many of these chips, the FPU is disabled for interrupts, so software math is used in those cases.
p3p
commented
6 years ago @Roxy-3D Cortex MCU FPUs have a feature called lazy stacking, that is configurable in various modes, it will save the state registers automatically on interrupt if the FPU has been used and only if the FPU is used within that interrupt, so after configuration you can pretty much forget you are using the FPU and everything works as expected. RTOSs have to be configured with this in mind though.
ejtagle
commented
6 years ago @Roxy-3D , @p3p @thinkyhead ... Just stop fighting ... 👍 ... It is always a bad idea to use floating point in ISR, so better avoid it! Reasons:
thinkyhead
commented
6 years ago Software emulation is SLOOOW...
…and water is wet.
p3p
commented
6 years ago …and water is wet.
well everything has exceptions :wink:
Just stop fighting ...
The more advanced the processor the less predictable it is.. its just something you have to live with and understand so issues can be mitigated, being why I explained to Roxy how the Cortex FPU registers can be saved, If you need to use the FPU in an ISR, and know about lazy stacking, you know on the first FLOP you will have extra latency, if a specific control register is set, otherwise you will not.
thinkyhead
commented
6 years ago If you need to use the FPU in an ISR
But again, remember that for some (if not most) MCUs this is simply verboten.
thinkyhead
commented
6 years ago There has long been a plan on the back-burner to shift everything to fixed-point maths. It wouldn't be trivial, but it might be worth the attempt. We have a lot of room to sacrifice bits for the fractional part.
p3p
commented
6 years ago But again, remember that for some (if not most) MCUs this is simply verboten.
Indeed its all very MCU specific, which is why I keep prefixing FPU with Cortex and even then I'm probably wrong for all cases.
thinkyhead
commented
6 years ago Apparently the M4 allows it, with the aforementioned state save and restore.
ghost
commented
5 years ago HI all, I am a complete nob, and the thread above reads like Hebrew to me, but I believe I am having this compile error with the latest Marlin 2.0 Bugfix version. Would somebody be able to help me figure out what the problem is? I have been at trying to get this to work for over 12 hours now!
Thank you!
Executing task in folder Marlin-bugfix-2.0.x: C:\Users\XXXXXXX.platformio\penv\Scripts\platformio.exe run < Processing LPC1768 (platform: https://github.com/p3p/pio-nxplpc-arduino-lpc176x/archive/master.zip; board: nxp_lpc1768; framework: arduino)
Verbose mode can be enabled via
-v, --verboseoption CONFIGURATION: https://docs.platformio.org/page/boards/nxplpc-arduino-lpc176x/nxp_lpc1768.html PLATFORM: NXP Arduino LPC176x > NXP LPC1768 HARDWARE: LPC1768 100MHz 31.80KB RAM (464KB Flash) DEBUG: CURRENT(cmsis-dap) ON-BOARD(cmsis-dap) EXTERNAL(blackmagic, jlink) Converting Marlin.ino Library Dependency Finder -> http://bit.ly/configure-pio-ldf LDF MODES: FINDER(off) COMPATIBILITY(strict) Collected 12 compatible libraries Scanning dependencies... Dependency Graph |--1.0.0 |-- 1.0.0 |-- 0.4 |-- 0.3.5 |-- 1.1.8
Unable to find destination disk (Autodetect Error) Please select it in platformio.ini using the upload_port keyword (https://docs.platformio.org/en/latest/projectconf/section_env_upload.html) or copy the firmware (.pioenvs/LPC1768/firmware.bin) manually to the appropriate disk
Compiling .pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\DebugMonitor_LPC1768.cpp.o In file included from Marlin\src\HAL\HAL_LPC1768../../core/../inc/MarlinConfigPre.h:35, from Marlin\src\HAL\HAL_LPC1768../../core/serial.h:24, from Marlin\src\HAL\HAL_LPC1768\DebugMonitor_LPC1768.cpp:26: Marlin\src\HAL\HAL_LPC1768../../core/../inc/../../Configuration.h:1152:4: error: #endif without #if
^~~~~ Marlin\src\HAL\HAL_LPC1768../../core/../inc/../../Configuration.h:1153:2: error: #endif without #if
^~~~~ Compiling .pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL.cpp.o Compiling .pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL_spi.cpp.o Compiling .pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL_timers.cpp.o In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfigPre.h:35, from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:28, from Marlin\src\HAL\HAL_LPC1768\HAL.cpp:25: Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1152:4: error: #endif without #if
^~~~~ Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1153:2: error: #endif without #if
^~~~~ In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfigPre.h:35, from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:28, from Marlin\src\HAL\HAL_LPC1768\HAL_spi.cpp:51: Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1152:4: error: #endif without #if
^~~~~ Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1153:2: error: #endif without #if
^~~~~ In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfigPre.h:35, from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:28, from Marlin\src\HAL\HAL_LPC1768\HAL_timers.cpp:31: Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1152:4: error: #endif without #if
^~~~~ Marlin\src\HAL\HAL_LPC1768../../inc/../../Configuration.h:1153:2: error: #endif without #if
^~~~~ In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:41, from Marlin\src\HAL\HAL_LPC1768\HAL.cpp:25: Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:988:60: error: static assertion failed: X_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(X_PROBE_OFFSET_FROM_EXTRUDER)) == float(X_PROBE_OFFSET_FROM_EXTRUDER), "X_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:989:60: error: static assertion failed: Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(Y_PROBE_OFFSET_FROM_EXTRUDER)) == float(Y_PROBE_OFFSET_FROM_EXTRUDER), "Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); [.pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\DebugMonitor_LPC1768.cpp.o] Error 1 In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:41, from Marlin\src\HAL\HAL_LPC1768\HAL_timers.cpp:31: Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:988:60: error: static assertion failed: X_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(X_PROBE_OFFSET_FROM_EXTRUDER)) == float(X_PROBE_OFFSET_FROM_EXTRUDER), "X_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:989:60: error: static assertion failed: Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(Y_PROBE_OFFSET_FROM_EXTRUDER)) == float(Y_PROBE_OFFSET_FROM_EXTRUDER), "Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); In file included from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:41, from Marlin\src\HAL\HAL_LPC1768\HAL_spi.cpp:51: Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:988:60: error: static assertion failed: X_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(X_PROBE_OFFSET_FROM_EXTRUDER)) == float(X_PROBE_OFFSET_FROM_EXTRUDER), "X_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); Marlin\src\HAL\HAL_LPC1768../../inc/SanityCheck.h:989:60: error: static assertion failed: Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer! static_assert(FLOOR(float(Y_PROBE_OFFSET_FROM_EXTRUDER)) == float(Y_PROBE_OFFSET_FROM_EXTRUDER), "Y_PROBE_OFFSET_FROM_EXTRUDER must be an integer!"); [.pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL.cpp.o] Error 1 [.pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL_timers.cpp.o] Error 1 [.pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\HAL_spi.cpp.o] Error 1 =============================================================================================== [ERROR] Took 2.65 seconds ===============================================================================================
======================================================================================================= [SUMMARY] ======================================================================================================= Environment megaatmega2560 [SKIP] Environment megaatmega1280 [SKIP] Environment at90usb1286_cdc [SKIP] Environment at90usb1286_dfu [SKIP] Environment DUE [SKIP] Environment DUE_USB [SKIP] Environment DUE_debug [SKIP] Environment LPC1768 [ERROR] Environment LPC1769 [SKIP] Environment melzi [SKIP] Environment melzi_optiboot [SKIP] Environment rambo [SKIP] Environment sanguino_atmega644p [SKIP] Environment sanguino_atmega1284p [SKIP] Environment STM32F1 [SKIP] Environment STM32F4 [SKIP] Environment ARMED [SKIP] Environment mks_robin [SKIP] Environment black_stm32f407ve [SKIP] Environment teensy35 [SKIP] Environment malyanm200 [SKIP] Environment esp32 [SKIP] Environment fysetc_f6_13 [SKIP] Environment linux_native [SKIP] =============================================================================================== [ERROR] Took 2.68 seconds ===============================================================================================
github-actions[bot]
commented
4 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Description
Marlin 2.0 not compiling with SKEW_CORRECTION enabled on MKS SBASE.
Steps to Reproduce
Additional Information
Build Log:
Error Log
``` Verbose mode can be enabled via `-v, --verbose` option PLATFORM: NXP LPC > NXP mbed LPC1768 SYSTEM: LPC1768 100MHz 64KB RAM (512KB Flash) DEBUG: CURRENT(cmsis-dap) ON-BOARD(cmsis-dap) EXTERNAL(blackmagic, jlink) Library Dependency Finder -> http://bit.ly/configure-pio-ldf LDF MODES: FINDER(off) COMPATIBILITY(light) Collected 12 compatible libraries Scanning dependencies... Dependency Graph |--