Problem: how to home at hold state (by config file or programmatically) #1226
Comments
|
The only way with the current code is to first issue $X to go from home state to idle state, then issue $H |
|
no, it's not home state, it's hold state (on feed_hold_pin) actually i can reset the state to idle by pressing Ctrl+X, and then run static void protocol_do_origin() {
if (state_is(State::Homing) || state_is(State::Cycle) || state_is(State::Jog) || state_is(State::ConfigAlarm)) {
log_warn("Ignore home event at state " << (uint8_t)sys.state);
return;
}
// [bug] press home btn when paused
if (!state_is(State::Idle) && !state_is(State::Alarm)) {
log_warn("Reset before homing at state " << (uint8_t)sys.state);
protocol_do_rt_reset();
// why it doesn't do homing after ?
}
// works fine at `Idle` state
log_info("Do homing by pin at state " << (uint8_t)sys.state);
static char cmd[] = "$Home";
settings_execute_line(cmd, allChannels, WebUI::AuthenticationLevel::LEVEL_ADMIN);
}
|
|
Sorry, there were lots of mistakes in my post above. I just woke up and haven't had my coffee yet. I meant to say ctrl-x to get from hold to idle. The reason your code doesn't work is probably related to the timing of the event processing. protocol_do_rt_reset() ends by sending restartEvent to be executed later. Your code is running as an event handler, so the event dispatch cannot run until your code returns. One way to fix it might be to use the event system instead of trying to run the event handlers directly. Instead of calling protocol_do_rt_reset(), call protocol_send_event(&rtResetEvent) , Also create a event that does the homing step and send it. Then the event handler will run all the steps in sequence. |
|
Oh, wish you a good day, Mr. Bradley . |
|
I am not guaranteeing that my proposed approach will work without problems. What you are trying to do is complicated because of the historical design of the Grbl state machine. The problem is the use of reset to exit from Hold state. Grbl uses reset to do several things that have conflicting requirements:
Reset is a very "heavyweight" operation that reinitialized many variables - perhaps too many for some uses. I have often wanted to fix this problem, but the chances of breaking something is very high. |
|
It's ok, any suggestion will be appreciated. |
|
It do homing (state=home) but goes the wrong directions (all three axes wrong), Any idea? new code: static void protocol_do_home() {
log_info("Handle home event at state " << (uint8_t)sys.state);
static char cmd[] = "$Home";
settings_execute_line(cmd, allChannels, WebUI::AuthenticationLevel::LEVEL_ADMIN);
}
static NoArgEvent homeEvent { protocol_do_home };
static void protocol_do_origin() {
if (state_is(State::Homing) || state_is(State::Cycle) || state_is(State::Jog) || state_is(State::ConfigAlarm)) {
log_warn("Ignore home event at state " << (uint8_t)sys.state);
return;
}
// [bug] press home btn when paused
if (!state_is(State::Idle) && !state_is(State::Alarm)) {
log_warn("Reset before homing at state " << (uint8_t)sys.state);
protocol_send_event(&rtResetEvent);
// why it goes wrong direction when homing ?
}
// works fine at `Idle` state
log_info("Do homing by pin at state " << (uint8_t)sys.state);
protocol_send_event(&homeEvent);
}
NoArgEvent originPinEvent { protocol_do_origin };
NoArgEvent pausePinEvent { protocol_do_pause };logs: |
|
If you send $message/level=debug you will see more details of the homing process |
|
It's still the timing. But it stuck at do {
protocol_execute_realtime();
} while (state_is(State::Homing)); // It stuck in this loop
It never get to 'Idle' after homed xyz: new code with delay: static void protocol_do_home();
static NoArgEvent homeEvent { protocol_do_home };
static int64_t homeEventStart = 0;
static void protocol_do_home() {
// wait at least 100ms, or it will home at the wrong direction.
if (millis() - homeEventStart < 200) {
protocol_send_event(&homeEvent);
return;
}
log_info("Handle home event at state " << (uint8_t)sys.state);
static char cmd[] = "$Home";
settings_execute_line(cmd, allChannels, WebUI::AuthenticationLevel::LEVEL_ADMIN);
log_info("Homed, state=" << (uint8_t)sys.state); // never get here when homing at hold state
}
static void protocol_do_origin() {
if (state_is(State::Homing) || state_is(State::Cycle) || state_is(State::Jog) || state_is(State::ConfigAlarm)) {
log_warn("Ignore home event at state " << (uint8_t)sys.state);
return;
}
if (!state_is(State::Idle) && !state_is(State::Alarm)) {
log_warn("Reset before homing at state " << (uint8_t)sys.state);
protocol_send_event(&rtResetEvent);
homeEventStart = millis();
protocol_send_event(&homeEvent);
return;
}
// log_info("Do homing by pin at state " << (uint8_t)sys.state);
protocol_do_home();
}
NoArgEvent originPinEvent { protocol_do_origin }; |
|
I managed to fix it by creating another task with the same priority. |
|
You could probably do the same thing with a freertos timer. They use much less RAM than a task. There is an example in Motors/Servo.cpp |
|
OK |
FluidNC version
release v3.7.17
Wiki Search Terms
Homing at Hold state
Controller Board
not listed but quite simple: (and the problem is irrelevant with hardware)
G01 X275 Y275 Z0 f3000andG01 X0 Y0 Z80 f3000]each hardware part is tested basically.
and pin usage:
Machine Description
irrelevant ....
something like bambu lab a1 mini
Input Circuits
No response
Configuration file
Startup Messages
User Interface Software
FluidTerm
What happened?
my goal
do homing when a button is pressed at idle or hold state.
(homing at idle or alarm state is tested fine.)
what i did
what i expected
state changed: hold -> home
do homing
what happended instead
the state changed: hold -> idle, and nothing else.
GCode File
the file 1.nc in sd card:
Other Information
i look at wiki for a long time but can't find what i want.
i can do
Ctrl+Xand then run cmd$Homeat console, but how can i do it programmatically?i change some source code to add 2 new pin
z_pause_pinandz_origin_pin.the
z_pause_pinworks fine (pause when state=idle, resume when state=hold).the handler of
z_origin_pinis:The text was updated successfully, but these errors were encountered: