Homing on U,V or W axis is not possible #482
Comments
|
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. |
|
Ahhh. In that case, it's definitely yours. 😄 |
|
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: Lines 442 to 581 in 72e49fb It's not the most succinct code, but it's clear what it does, so there's that at least. The Line 68 in c8223c5 It should be wrapped in an In any case, that if statement tree in 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 g2/g2core/board/ArduinoDue/hardware.h Line 64 in 423c83f That's also the file where g2/g2core/board/ArduinoDue/board_stepper.h Lines 35 to 97 in 404106b and g2/g2core/board/ArduinoDue/board_stepper.cpp Lines 33 to 97 in 404106b |
|
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. 😦 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. 😄 |
|
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: 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 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 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. 😄 |
|
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 I still need to work through some issues before it's really "ok" to develop on though. 😦 Should be ok to look into the UVW axes sometime today or tomorrow, unless someone else is able to jump in earlier. 😄 |
|
I'm getting compile errors with the edge-preview branch: (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 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). 😇 |
|
edge-preview branch: After fixing the spindle polarity I get this: |
|
edge branch questions: It is crashing or freezing when the limit switch is hit
|
|
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. 😄 Sorry I haven't been able to help more yet. 😦 |
|
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:
Everything is behaving as before with the edge branch, including the messed up axis names on the console output: 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). |
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. 😉 |
|
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: 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! |
|
Ahhh, sorry. I have all the equipment needed here for doing stuff, but have been taking a few weeks out to have a bit of a break from most IT stuff in general. eg recover from burn-out 😦 |
|
So can we then conclude that g2core is abandoned and no longer actively developed? The wiki should mention it! |
|
Has someone of you even reproduced this error or does it home the U axis on all your builds and I am the only one having problems with the U axis? |
|
I have begun instrumenting the code to do some rudimentary printf debugging, I have calls like this But when I try to home the U axis it prints this: When it hits the limit switch it correctly ends the move and calls _motion_end_callback() which in turn clears the waiting_for_motion_end flag but then it (what?) won't ever call into the state machine ever again. Whatever is responsible for polling the state machine just stops. Where do I proceed from here? What is calling the state machine and how would I debug this, given that I cannot connect a debugger and am restricted to this kind of printf-debuging? |
|
I have also inserted a rpt_exception at the beginning of cm_homing_cycle_callback(), this will flood my console with hundreds of lines (so I removed it again) but it clearly shows that the call to _motion_end_callback() is the very last call ever, after that it stops. The yellow LED is still slowly blinking. The position report "A position: 0.076 mm" is also arriving after the call to _motion_end_callback() but I have no idea who is producing these outputs, whether this happens later the same interrupt or somewhere else. How do I proceed from here? |
|
I found the reason: The attached patch will fix both: the probing and the homing problems for U,V,W, Please merge. diff --git a/g2core/cycle_probing.cpp b/g2core/cycle_probing.cpp
index 3f3db80f..f8ab9423 100644
--- a/g2core/cycle_probing.cpp
+++ b/g2core/cycle_probing.cpp
@@ -138,6 +138,7 @@ uint8_t cm_straight_probe(float target[], bool flags[], bool trip_sense, bool al
// error if no axes specified
if (!(flags[AXIS_X] | flags[AXIS_Y] | flags[AXIS_Z] |
+ flags[AXIS_U] | flags[AXIS_V] | flags[AXIS_W] |
flags[AXIS_A] | flags[AXIS_B] | flags[AXIS_C])) {
return(cm_alarm(STAT_AXIS_IS_MISSING, "Axis is missing"));
}
diff --git a/g2core/util.cpp b/g2core/util.cpp
index 61f4c4b0..952bb0fe 100644
--- a/g2core/util.cpp
+++ b/g2core/util.cpp
@@ -76,6 +76,9 @@ float get_axis_vector_length(const float a[], const float b[])
return (sqrt(square(a[AXIS_X] - b[AXIS_X]) +
square(a[AXIS_Y] - b[AXIS_Y]) +
square(a[AXIS_Z] - b[AXIS_Z]) +
+ square(a[AXIS_U] - b[AXIS_U]) +
+ square(a[AXIS_V] - b[AXIS_V]) +
+ square(a[AXIS_W] - b[AXIS_W]) +
square(a[AXIS_A] - b[AXIS_A]) +
square(a[AXIS_B] - b[AXIS_B]) +
square(a[AXIS_C] - b[AXIS_C])));
|
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):
The text was updated successfully, but these errors were encountered: