synthetos
Homing on U,V or W axis is not possible
Now after I have spent the whole day wiring up everything I ran across a show stopper bug :-(
I have x,y,z as usual, a rotary axis (a) and an additional linear axis (u).
They are mapped to the motors as follows: m1 - x m2 - y m3 - z m4 - u m5 - a
All axes are configured and moving properly when moved with g0 or g1.
using the g28.2 command I can home all axes except the additional linear axis u (and also v and w won't work):
g28.2 u0
g2core[mm] ok>
Homing error - Bad or no axis(es) specified
Machine state: Stop
Oh, that definitely sounds like a bug. That one shouldn't be too hard to fix though, and I've actually done stuff with the homing code before.
If you're ok to wait until tomorrow (I'm desperately in need of sleep atm), I should have had a chance to figure out and fix the problem.
I know this bug. I'll handle it. I'll have to follow up with more info later.
No need to lose sleep over it, I can't continue to work on my machine for the next seven days anyways, the most important thing is to know that it can be fixed, so I don't have to worry about my choice of motion controller.
I very much like the idea of being able to use g2core, its actually a perfect fit for my project, there are not many open source alternatives that offer such flexibility, I wonder why it is not massively more popular among the maker scene. With that many axes I can potentially control almost any machine I might ever happen to build in the future and once I have invested time in understanding its configuration and implementing the protocol on the PC side then I will certainly continue using it, even for smaller machines instead of grbl.
Ok, so this will be fixed more accurately in a new version in edge-preview (it's mixed up with other homing changes where we support multi-motor on the same axis homing to square up an axis, but that's a longer discussion), so for now, here's where this issue exists:
https://github.com/synthetos/g2/blob/72e49fb33de2951bc4547a1417af348bf8d03514/g2core/cycle_homing.cpp#L442-L581
It's not the most succinct code, but it's clear what it does, so there's that at least.
The HOMING_AXES part is defined here:
https://github.com/synthetos/g2/blob/c8223c5e0743a5dd7a9b28a273e2ab917f752530/g2core/g2core.h#L68
It should be wrapped in an ifndef like (or with) AXES but currently it's not.
In any case, that if statement tree in cycle_homing should (but doesn't) have else if (axis == AXIS_Y) for axes A, B, and C, as well as U, V, and W (you may want to check for AXES == 9), then I believe it will work.
I don't know if anyone has tested homing U, V, and W, or at least they didn't report back AFAIK, so I'm excited to hear how it goes.
I forgot to mention, the g2core.h ifdefs rely on the hardware overriding values. For example, in the board-specific hardware.h AXES is defined:
https://github.com/synthetos/g2/blob/423c83f233f1ff414521b9f66170e530d95ad14c/g2core/board/ArduinoDue/hardware.h#L64
That's also the file where MOTORS is defined, but you also have to define structures for each motor in board_stepper.h and board_stepper.cpp, for example:
https://github.com/synthetos/g2/blob/404106b75e95a3a12c981d2e1ff42ad626c3e015/g2core/board/ArduinoDue/board_stepper.h#L35-L97
and
https://github.com/synthetos/g2/blob/404106b75e95a3a12c981d2e1ff42ad626c3e015/g2core/board/ArduinoDue/board_stepper.cpp#L33-L97
How about rewriting the above function like this?
static int8_t _get_next_axis(int8_t axis) {
const int8_t homing_order[9] = {AXIS_Z, AXIS_X, AXIS_Y, AXIS_U, AXIS_V, AXIS_W, AXIS_A, AXIS_B, AXIS_C};
if (axis == -1) {
// search the first axis in the order whose flag is set
for (int i=0; i<9; i++) {
if (hm.axis_flags[homing_order[i]]) {
return homing_order[i];
}
}
return -2; // no existing axis flag was set
} else {
// search the next axis in the order whose flag is set
for (int i=0; i<9; i++) {
if (axis == homing_order[i]) {
for (int j=i+1; j<9; j++) {
if (hm.axis_flags[homing_order[j]]) {
return homing_order[j];
}
}
return -1; // no more axes, we are done
}
}
return -1; // called with non-existing axis, should never happen (but compiler insists on some return value)
}
}
I am currently testing it, it seems to work as before, but the U axis now makes a rapid g0 move if I try to home it, the error message is gone (very strange, must further check my axis and motor configurations, something seems wrong still)
It moves with U_FEEDRATE_MAX until it hits the limit switch, then the motor stops and the machine is frozen, homing sequence is stuck at this point and never ends, needs reset.
Ouch. Sounds like that function might not be returning correctly. :frowning:
Hmmm, since you seem to be ok with C, do you have a hardware debugger handy? eg a Segger J-Link or similar
Asking because those are really helpful for debugging stuff like this. eg setting breakpoints in the firmware, stepping through functions, etc, to figure out what's wrong. We have things pretty well set up for people using MS Code + that Segger J-Link, if that's useful. :smile:
The function above seems to return correctly, if I do for example g28.2 x0 z0 u0 it will correctly home z, then x, then start moving u (but with the wrong velocity) and then it is stuck.
I initially suspected a typo or copy-paste error where it is setting up the configuration arrays but it seems its internal structures know the configuration for this axis correctly:
$u
[uam] u axis mode 1 [standard]
[uvm] u velocity maximum 4000 mm/min
[ufr] u feedrate maximum 4000 mm/min
[utn] u travel minimum 0.000 mm
[utm] u travel maximum 300.000 mm
[ujm] u jerk maximum 5000 mm/min^3 * 1 million
[ujh] u jerk homing 10000 mm/min^3 * 1 million
[uhi] u homing input 4 [input 1-N or 0 to disable homing this axis]
[uhd] u homing direction 0 [0=search-to-negative, 1=search-to-positive]
[usv] u search velocity 200 mm/min
[ulv] u latch velocity 20.00 mm/min
[ulb] u latch backoff 4.000 mm
[uzb] u zero backoff 2.000 mm
g2core[mm] ok>
It should begin searching with 200mm/min but starts moving toward the limit switch with 4000mm/min, then stops and freezes.
I have a J-Link but no IDE that is set up for Atmel/Arduino and also not the connectors/adapters to plug it into the arduino, I am normally only working with chinese GD32 controllers and for these I have configured Eclipse with GNU-ARM-Plugin and J-Link. I have never used J-Link with vscode (although I am using vscode as my text editor for everything outside of eclipse)
But this problem should be reproducible for any of you who has already set up a working debug environment, even if you don't have 4 axis: Just map any of your existing motors to the U-Axis, configure its limit switch for U also and then try to home U.
This is the output (in text mode) when I am trying to home U
g28.2 u0
g2core[mm] ok>
A position: -13.737 mm
Feed rate: 200.000 mm/min
Velocity: 4000.000 mm/min
Coordinate system: G53 - machine coordinate system
Distance mode: G91 - incremental distance mode
Motion mode: G1 - linear feed
Machine state: Homing
A position: -30.432 mm
A position: -47.128 mm
A position: -63.823 mm
A position: -80.519 mm
A position: -97.214 mm
A position: -113.910 mm
A position: -130.606 mm
A position: -147.301 mm
A position: -163.997 mm
A position: -180.692 mm
A position: -197.388 mm
A position: -214.084 mm
A position: -230.779 mm
A position: -247.475 mm
A position: -264.170 mm
A position: -279.566 mm
Note that it is also reporting the positions with the wrong axis name. And it correctly says "Feedrate 200mm/min" but then accelerates to 4000mm/min
@giseburt Do you have time to look into this in the near future, or should I have a go at it?
And my motor configuration for motor 4 seems to be ok also, for testing purposes I have temporarily remapped this motor along with the corresponding limit switch to axis Y and on this axis I can home it just fine, so my limit switch is working and connected, motor polarity and everything else seems ok for this motor.
And I am still on the edge branch btw.
This is because I have made my own branch based on edge with my own changes to be able to later merge updates from edge, I am not sure if I can just rebase this to edge-preview without breaking too many things here, so I am a bit hesitant towards switching branches now. I still hope it has a simple fix that can be applied to edge.
It is always moving with maximum feedrate 4000, even when I use G1
g1 u100 f100
g2core[mm] ok>
Line number: 0
X position: 0.000 mm
Y position: 0.000 mm
Z position: 0.000 mm
A position: 12.490 mm
B position: 0.000 mm
C position: 0.000 mm
� position: 0.000 deg
position: 0.000 deg
Feed rate: 100.000 mm/min
Velocity: 4000.000 mm/min
Units: G21 - millimeter mode
Coordinate system: G54 - coordinate system 1
Distance mode: G90 - absolute distance mode
Arc Distance mode: G91.1 - incremental distance mode (default mode)
Feed rate mode: G94 - units-per-minute mode (i.e. feedrate mode)
Motion mode: G1 - linear feed
Machine state: Run
A position: 29.172 mm
A position: 45.854 mm
A position: 62.537 mm
A position: 79.219 mm
A position: 95.902 mm
Velocity: 3999.793 mm/min
A position: 100.000 mm
Velocity: 0.000 mm/min
Machine state: Stop
So maybe the error is not in the homing code, there must be something broken elsewhere with this axis.
@prof7bit I'll take a look at this in a bit. Need to get sleep first, so it'll be after that. :smile:
@prof7bit What branch are you on?
Edge has a few missing parts for the UVW to work. In particular, I believe this one is getting you:
https://github.com/synthetos/g2/blob/72e49fb33de2951bc4547a1417af348bf8d03514/g2core/plan_line.cpp#L642
Vs edge-preview where it's corrected:
https://github.com/synthetos/g2/blob/b3e0e9eb374a0a560e1aece1a0e082f2f78af56d/g2core/plan_line.cpp#L563-L567
ok, the feed_time fix now makes it run with the correct velocity, it will accept the specified feedrate in G1, but it is still not working correctly. It is still freezing when trying to home the axis.
Can somebody please confirm that the edge-preview branch does indeed work with UVW-axes and these axes can be homed before I start porting my settings and all the stuff over to edge-preview?
@prof7bit I've been working on getting my development system up to scratch. It's now connected up to a small 4-axis test bed, and hardware breakpointing (using edge-preview, though not on a Due) is technically functional. :smile:
I still need to work through some issues before it's really "ok" to develop on though. :frowning:
Should be ok to look into the UVW axes sometime today or tomorrow, unless someone else is able to jump in earlier. :smile:
I'm getting compile errors with the edge-preview branch:
$ make BOARD=gShield
...
In file included from ./settings.h:54:0,
from ./board/ArduinoDue/hardware.h:33,
from g2core.h:62,
from spindle.cpp:28:
./settings/settings_default.h:89:37: error: 'SPINDLE_ACTIVE_HIGH' was not declared in this scope
#define SPINDLE_ENABLE_POLARITY SPINDLE_ACTIVE_HIGH // {spep: 0=active low, 1=active high
^
spindle.cpp:483:79: note: in expansion of macro 'SPINDLE_ENABLE_POLARITY'
{ "sp","spep", _iip, 0, sp_print_spep, sp_get_spep, sp_set_spep, nullptr, SPINDLE_ENABLE_POLARITY },
^~~~~~~~~~~~~~~~~~~~~~~
./settings/settings_default.h:89:37: note: suggested alternative: 'IO_ACTIVE_HIGH'
#define SPINDLE_ENABLE_POLARITY SPINDLE_ACTIVE_HIGH // {spep: 0=active low, 1=active high
^
spindle.cpp:483:79: note: in expansion of macro 'SPINDLE_ENABLE_POLARITY'
{ "sp","spep", _iip, 0, sp_print_spep, sp_get_spep, sp_set_spep, nullptr, SPINDLE_ENABLE_POLARITY },
^~~~~~~~~~~~~~~~~~~~~~~
make: *** [../Motate/MotateProject/motate/Motate.mk:538: build/gShield/./spindle.o] Fehler 1
(will try to fix the missing defines manually for now)
getting even more errors about missing defines and defines that have been moved into other files after fixing this one, the preview branch does not seem to be meant for the arduino due board at this time yet.
Seems I really need a fix for the edge branch until edge-preview is ready to be used.
I suggest removing any mention of 9 axis and UVW from the wiki at this time.
For the SPINDLE_ACTIVE_HIGH compilation error, the simple 1 line patch here should fix it: https://github.com/synthetos/g2/pull/483
Would you be ok to cut-n-paste here the follow on errors you're getting with it?
Hmmm, as a rough idea, maybe try grabbing the branch I've been doing stuff in here?
https://github.com/justinclift/g2/tree/justin-edge-preview-studiomill-v2
I'm using a different (non-Due) board though, so it might not be all that much better (not sure). :innocent:
edge-preview branch:
After fixing the spindle polarity I get this:
board/ArduinoDue/0_hardware.cpp:44:2: warning: #warning SPINDLE_ENABLE_OUTPUT_NUMBER is defaulted to 4! [-Wcpp]
#warning SPINDLE_ENABLE_OUTPUT_NUMBER is defaulted to 4!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:45:2: warning: #warning SPINDLE_ENABLE_OUTPUT_NUMBER should be defined in settings or a board file! [-Wcpp]
#warning SPINDLE_ENABLE_OUTPUT_NUMBER should be defined in settings or a board file!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:50:2: warning: #warning SPINDLE_DIRECTION_OUTPUT_NUMBER is defaulted to 5! [-Wcpp]
#warning SPINDLE_DIRECTION_OUTPUT_NUMBER is defaulted to 5!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:51:2: warning: #warning SPINDLE_DIRECTION_OUTPUT_NUMBER should be defined in settings or a board file! [-Wcpp]
#warning SPINDLE_DIRECTION_OUTPUT_NUMBER should be defined in settings or a board file!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:56:2: warning: #warning SPINDLE_PWM_NUMBER is defaulted to 6! [-Wcpp]
#warning SPINDLE_PWM_NUMBER is defaulted to 6!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:57:2: warning: #warning SPINDLE_PWM_NUMBER should be defined in settings or a board file! [-Wcpp]
#warning SPINDLE_PWM_NUMBER should be defined in settings or a board file!
^~~~~~~
board/ArduinoDue/0_hardware.cpp:69:108: error: 'SPINDLE_SPEED_CHANGE_PER_MS' was not declared in this scope
ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
^~~~~~~~~~~~~~~~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:69:108: note: suggested alternative: 'SPINDLE_SPEED_MAX'
ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
^~~~~~~~~~~~~~~~~~~~~~~~~~~
SPINDLE_SPEED_MAX
board/ArduinoDue/0_hardware.cpp:69:135: error: no matching function for call to 'ESCSpindle::ESCSpindle(<brace-enclosed initializer list>)'
ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
^
In file included from board/ArduinoDue/0_hardware.cpp:68:0:
device/esc_spindle/esc_spindle.h:234:1: note: candidate: ESCSpindle::ESCSpindle(uint8_t, uint8_t, uint8_t, float)
ESCSpindle::ESCSpindle(const uint8_t pwm_pin_number, const uint8_t enable_pin_number,
^~~~~~~~~~
device/esc_spindle/esc_spindle.h:234:1: note: conversion of argument 4 would be ill-formed:
In file included from board/ArduinoDue/0_hardware.cpp:68:0:
device/esc_spindle/esc_spindle.h:52:7: note: candidate: ESCSpindle::ESCSpindle(const ESCSpindle&)
class ESCSpindle : public ToolHead {
^~~~~~~~~~
device/esc_spindle/esc_spindle.h:52:7: note: candidate expects 1 argument, 4 provided
device/esc_spindle/esc_spindle.h:52:7: note: candidate: ESCSpindle::ESCSpindle(ESCSpindle&&)
device/esc_spindle/esc_spindle.h:52:7: note: candidate expects 1 argument, 4 provided
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_pulse_duration(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:243:5: error: 'laser_tool' was not declared in this scope
laser_tool.set_pulse_duration_us(nv->valuetype == TYPE_FLOAT ? nv->value_flt : nv->value_int);
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:243:5: note: suggested alternative: 'cm_get_tool'
laser_tool.set_pulse_duration_us(nv->valuetype == TYPE_FLOAT ? nv->value_flt : nv->value_int);
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_pulse_duration(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:248:21: error: 'laser_tool' was not declared in this scope
nv->value_int = laser_tool.get_pulse_duration_us();
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:248:21: note: suggested alternative: 'cm_get_tool'
nv->value_int = laser_tool.get_pulse_duration_us();
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_min_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:254:21: error: 'laser_tool' was not declared in this scope
nv->value_flt = laser_tool.get_min_s();
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:254:21: note: suggested alternative: 'cm_get_tool'
nv->value_flt = laser_tool.get_min_s();
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_min_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:259:5: error: 'laser_tool' was not declared in this scope
laser_tool.set_min_s(nv->value_flt);
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:259:5: note: suggested alternative: 'cm_get_tool'
laser_tool.set_min_s(nv->value_flt);
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_max_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:264:21: error: 'laser_tool' was not declared in this scope
nv->value_flt = laser_tool.get_max_s();
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:264:21: note: suggested alternative: 'cm_get_tool'
nv->value_flt = laser_tool.get_max_s();
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_max_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:269:5: error: 'laser_tool' was not declared in this scope
laser_tool.set_max_s(nv->value_flt);
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:269:5: note: suggested alternative: 'cm_get_tool'
laser_tool.set_max_s(nv->value_flt);
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_min_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:274:21: error: 'laser_tool' was not declared in this scope
nv->value_flt = laser_tool.get_min_ppm();
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:274:21: note: suggested alternative: 'cm_get_tool'
nv->value_flt = laser_tool.get_min_ppm();
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_min_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:279:5: error: 'laser_tool' was not declared in this scope
laser_tool.set_min_ppm(nv->value_flt);
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:279:5: note: suggested alternative: 'cm_get_tool'
laser_tool.set_min_ppm(nv->value_flt);
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_max_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:284:21: error: 'laser_tool' was not declared in this scope
nv->value_flt = laser_tool.get_max_ppm();
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:284:21: note: suggested alternative: 'cm_get_tool'
nv->value_flt = laser_tool.get_max_ppm();
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_max_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:289:5: error: 'laser_tool' was not declared in this scope
laser_tool.set_max_ppm(nv->value_flt);
^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:289:5: note: suggested alternative: 'cm_get_tool'
laser_tool.set_max_ppm(nv->value_flt);
^~~~~~~~~~
cm_get_tool
board/ArduinoDue/0_hardware.cpp: At global scope:
board/ArduinoDue/0_hardware.cpp:294:95: error: 'LASER_PULSE_DURATION' was not declared in this scope
{ "th2","th2pd", _iip, 0, tx_print_nul, get_pulse_duration, set_pulse_duration, nullptr, LASER_PULSE_DURATION },
^~~~~~~~~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:295:78: error: 'LASER_MIN_S' was not declared in this scope
{ "th2","th2mns", _fip, 0, tx_print_nul, get_min_s, set_min_s, nullptr, LASER_MIN_S },
^~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:296:78: error: 'LASER_MAX_S' was not declared in this scope
{ "th2","th2mxs", _fip, 0, tx_print_nul, get_max_s, set_max_s, nullptr, LASER_MAX_S },
^~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:296:78: note: suggested alternative: '__SHRT_MAX__'
{ "th2","th2mxs", _fip, 0, tx_print_nul, get_max_s, set_max_s, nullptr, LASER_MAX_S },
^~~~~~~~~~~
__SHRT_MAX__
board/ArduinoDue/0_hardware.cpp:297:82: error: 'LASER_MIN_PPM' was not declared in this scope
{ "th2","th2mnp", _fip, 0, tx_print_nul, get_min_ppm, set_min_ppm, nullptr, LASER_MIN_PPM },
^~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:298:82: error: 'LASER_MAX_PPM' was not declared in this scope
{ "th2","th2mxp", _fip, 0, tx_print_nul, get_max_ppm, set_max_ppm, nullptr, LASER_MAX_PPM },
^~~~~~~~~~~~~
make: *** [../Motate/MotateProject/motate/Motate.mk:538: build/gShield/./board/ArduinoDue/0_hardware.o] Fehler 1
edge branch questions:
It is crashing or freezing when the limit switch is hit
- How/where is the limit switch evaluated during a move, where is this, is it an interrupt, is it polled?
- Can I instrument the code to output debugging info on the serial connection, which function would I need to call?
- Is there a document that outlines how the control flow is organized and architected, what is controlling what, which interrupts, which state machines, how do the different threads/interrupts communicate (queues? shared memory?), how the pulses are generated, etc?
edge-preview:
I have now applied the following quick hacks/changes to get rid of all compile errors and it compiles now:
diff --git a/g2core/board/ArduinoDue/0_hardware.cpp b/g2core/board/ArduinoDue/0_hardware.cpp
index a3443cba..6721c79d 100644
--- a/g2core/board/ArduinoDue/0_hardware.cpp
+++ b/g2core/board/ArduinoDue/0_hardware.cpp
@@ -236,7 +236,7 @@ stat_t hw_flash(nvObj_t *nv)
constexpr cfgSubtableFromStaticArray sys_config_3{};
const configSubtable * const getSysConfig_3() { return &sys_config_3; }
-#else
+#elif HAS_LASER
stat_t set_pulse_duration(nvObj_t *nv)
{
@@ -301,6 +301,11 @@ constexpr cfgItem_t sys_config_items_3[] = {
constexpr cfgSubtableFromStaticArray sys_config_3{sys_config_items_3};
const configSubtable * const getSysConfig_3() { return &sys_config_3; }
+#else
+
+constexpr cfgSubtableFromStaticArray sys_config_3{};
+const configSubtable * const getSysConfig_3() { return &sys_config_3; }
+
#endif
/***********************************************************************************
diff --git a/g2core/board/ArduinoDue/board_gpio.cpp b/g2core/board/ArduinoDue/board_gpio.cpp
index b43baca3..66dd5fb9 100644
--- a/g2core/board/ArduinoDue/board_gpio.cpp
+++ b/g2core/board/ArduinoDue/board_gpio.cpp
@@ -112,6 +112,7 @@ const int16_t ain_sample_freq = 2;
int16_t ain_sample_counter = ain_sample_freq;
Motate::SysTickEvent ain_tick_event{
[] {
+ /*
if (!--ain_sample_counter) {
ai1.startSampling();
ai2.startSampling();
@@ -124,6 +125,7 @@ Motate::SysTickEvent ain_tick_event{
ain_sample_counter = ain_sample_freq;
}
+ */
},
nullptr
};
diff --git a/g2core/settings/settings_default.h b/g2core/settings/settings_default.h
index 013a3588..0ce901d1 100644
--- a/g2core/settings/settings_default.h
+++ b/g2core/settings/settings_default.h
@@ -86,7 +86,7 @@
#endif
#ifndef SPINDLE_ENABLE_POLARITY
-#define SPINDLE_ENABLE_POLARITY SPINDLE_ACTIVE_HIGH // {spep: 0=active low, 1=active high
+#define SPINDLE_ENABLE_POLARITY 1 // {spep: 0=active low, 1=active high
#endif
#ifndef SPINDLE_DIR_POLARITY
@@ -138,6 +138,10 @@
#define COOLANT_MIST_POLARITY 1 // {comp: 0=active low, 1=active high
#endif
+#ifndef SPINDLE_SPEED_CHANGE_PER_MS
+#define SPINDLE_SPEED_CHANGE_PER_MS 1
+#endif
+
#ifndef COOLANT_FLOOD_POLARITY
#define COOLANT_FLOOD_POLARITY 1 // {cofp: 0=active low, 1=active high
#endif
I hope I did not break anything. Now I need some time to re-apply my settings (regarding the missing motors and get_next_axis function) to see whether this will work.
Sounds like you're making solid progress. :smile:
Sorry I haven't been able to help more yet. :frowning:
I have the edge-preview branch compiled and running with my own settings and the same bug is still there. When I try to home the U-axis it stops and freezes as soon as it hits the limit switch.
Here are the changes I made:
- applied the diff I posted in my previous post to make it compile for BOARD=gShield
- uncommented the 2 missing motors in board/ArduinoDue/board_stepper.cpp and .h and changed MOTORS to enable all 6 motors
- replaced the _get_next_axis() function with my version from above (here: https://github.com/synthetos/g2/issues/482#issuecomment-716430048) to enable homing on all axis
- applied my own settings (motor steps, speeds, axis and switch assignment)
Everything is behaving as before with the edge branch, including the messed up axis names on the console output:
g0 u 42
g2core[mm] ok>
Line number: 0
X position: 0.000 mm
Y position: 0.000 mm
Z position: 0.000 mm
A position: 27.811 mm
B position: 0.000 mm
C position: 0.000 mm
▒ position: 0.000 deg
Feed rate: 0.000 mm/min
Velocity: 11184.437 mm/min
Units: G21 - millimeter mode
Coordinate system: G54 - coordinate system 1
Distance mode: G90 - absolute distance mode
Arc Distance mode: G91.1 - incremental distance mode (default mode)
Feed rate mode: G94 - units-per-minute mode (i.e. feedrate mode)
Motion mode: G0 - linear traverse
Machine state: Run
A position: 42.000 mm
Velocity: 0.000 mm/min
Machine state: Stop
$pos
X position: 0.000 mm
Y position: 0.000 mm
Z position: 0.000 mm
A position: 42.000 mm
B position: 0.000 mm
C position: 0.000 mm
� position: 0.000 deg
g2core[mm] ok>
where it is reporting the U-axis as A and the A-axis position is not reported at all. (But this can be discussed in a separate bug report, iirc in json mode it was reporting the positions correctly, so this is not a priority right now, I am only using text mode currently while I am interacting with it manually in a serial terminal).
iirc in json mode it was reporting the positions correctly
Oh, that's interesting. I was under the impression it shouldn't be possible for those to be different, but I guess this is another case of theory != reality. :wink:
In json mode it is reporting all axes correctly. So this won't affect me later in my application, its only cosmetic while I am still using it in text mode:
$ej 1
{"r":{"ej":1},"f":[1,0,6]}
g0 a23 u42
{"r":{},"f":[1,0,11]}
{"sr":{"posu":21.76362,"posa":11.91817,"vel":13130.17,"momo":0,"stat":5}}
{"sr":{"posu":42,"posa":23,"vel":0,"stat":3}}
$pos
{"r":{"pos":{"x":0,"y":0,"z":0,"u":42,"v":0,"w":0,"a":23,"b":0,"c":0}},"f":[1,0,5]}
$ej 0
[ej] enable json mode 0 [0=text,1=JSON,2=auto]
g2core[mm] ok>
$pos
X position: 0.000 mm
Y position: 0.000 mm
Z position: 0.000 mm
A position: 42.000 mm
B position: 0.000 mm
C position: 0.000 mm
position: 0.000 deg
� position: 0.000 deg
g2core[mm] ok>
I'm going to make a different bug report for this later or tomorrow to not distract attention from the main problem.
Has anybody of you made any progress regarding the homing problem? I don't know enough about the architecture of this code to have the slightest idea where to even begin to look for the reason of the freeze, so I need your help!