First thanks to Robert for all he developped (SQM, focuser, and so one) This is awesome !!
I used to work with the 304 version of MyFP2ESP32 with DRV8825 since few monthes with only the web services and servers and also an irremote when wanting to move manually (for visual use it is sometime convenient to not touch the scope ). This was working flawlessly (after having done the correction indicated here https://sourceforge.net/p/myfocuserpro2-esp32/discussion/general/thread/d91dcaabb8/#8454/3ea5 ) and the movement was smooth and without problems.
Decided to switch to the new rev recently to test it out and have found an issue with the irremote part:
Let say the focuser start at position 5000 on boot (this is an example)
Then want to move to pos 5010. I then push on the key mapped to OUT10.
If i get the position within the FP2 application i get 5010 displayed, which looks fine
However pushing again OUT10 on the remote then again get position the numbers stay at 5010.
I need to push another button to get the numbers change, but they do not change the way they should.
for example pushing OUT1 move the display to...5001 (instead of 5011) as if the position was not actualised
I have activated the debug server
Here is a copy of the debug window when doing the following sequence starting from an initial position of 5000
//
OUT10
OUT10 -> nothing update on the debug window
OUT1
OUT10
go State_InitMove
to 5010
State_InitMove
INITMOVE d=Out, steps=10
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
<<<<here i="" pushed="" out10="" again="" but="" nothing="" happened="">>>>
go State_InitMove
to 5001
State_InitMove
INITMOVE d=in, steps=9
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
go State_InitMove
to 5010
State_InitMove
INITMOVE d=Out, steps=9
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
//
As you can see it looks like the current position is not updated correctly
first move is 10 step out which is correct
second move doesn't occurs
third move should be 1 step out, but is..9 step in
then fourth move is 9 step out...</here>
Actually since my motorboard was not connected, i don't know if the motor is moving correctly and that the issue is only with the information display (but the debug server show the claculated increment/decrement for the stepper movement, so i assume th e motor will move as indicated in the debug
Also, when waiting enough time (for the information to be written ) then things works the way they should.
Any help welcome
Regards
Joël
Last edit: Collet 2024-07-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is Arduino 1.8.19 and the esp core version is 2.0.11 as recommended
And i tried also with 2 differents boards the ESP32WEMOSR3 as well as the small ESP32WEMOS D1 MINI, but both had the same behaviour.
To my understanding of the debug messages it seems to be related with the flag end_move_flag setted at 0 in the case State_EndMove:
but i may be wrong since i have not a full vision of the code (but it looks like in the irremte case, that the fposition value is never updated, except when time is ok for saving configuration, every 60s if my memory is good)
REgards
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reading your last post i am thinking about the issue i encountered
I have currently installed on my PC the legacy IDE 1.8.19 and the 2.3.2 version as well (both in separated directory, accounts..)
Both are also with esp core 2.0.11 and arduino esp32 in 2.0.11 as well.
I am doubtfull that having the two ide can be the source of the issue, but i can try to install only the 1.8.19 ide on an old PC to check if things behave differently.
all this under W10 if it matters.
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as expected, no changes, still the same behaviour with a fresh install
I tried to understand why the irremote "command" was behaving differently than the command from the tcp ip server, and i think i got the answer for the issue.
Actually when doing a N step move (command 64 ) with tcpip server ftargetposition is calculated from the driverboard values (line 837 in the tcpipserver.cpp
long pos = WorkString.toInt() + driverboard->getposition();
hence the move is always based on the latest position of the driverboard values, updated "real time". Additionally the flag ismoving is setted to 1 (which is not necessary to me since it is handled in the statemachine, but that's not the issue there)
While in the irremote code the ftargetposition is calculated from the ControllerData values (line 174 irremote.cpp
newpos = ControllerData->get_fposition() + adjpos; that is the latest position updated in the ControllerData, which occurs only when the "saving timer" triggers the save operation).
The logical things is probably to calculate the new position from the ftargetposition as for the pushbutton/joystick or from the driverboard position (as for the tcpip commands, which is i think the most logical of the two ideas)
Regards
Joël
Last edit: Collet 2024-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Robert
I also exhibit this issue and have tried core version 2.0.16 with the same results, the IR Test sketch just reports a constant stream of garbage in the terminal screen (I presume thats how it works?)
if I use the latest core version 3.0.2 I get a compile error tasktimer.h:196:23: error: too many arguments to function 'void timerAttachInterrupt(hw_timer_t, void ()())'
196 | timerAttachInterrupt(task_timer, &task_100MillisecondTimer, true);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did post a message about the recent core updates. I am still coding on 2.0.16 and advised everyone to stay on 2.0.16 till expressif solve the mirriad issues associated with it (espnow, httpupdate, many core routines had their interfaces changed, interrupts, irrremote etc). This happened because the IDF from Expressif changed to v4, then to v5 and because the core is built on the IDF, and had to use the same interfaces to talk to IDF, boom, it killed a lot of projects out there. There is even more bad news converning interrupt handling/conventions that is coming (or already here)
This also affects the mySQM+ project.
Once the main issues are resolved by the coding team responsible, 2.0.16 is the only core that is supported.
Regards
Robert
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2.0.16 core is working the same, no changes in the results.
Yes,but long time ago, and not on the curent version of the code , only to validate that the remote was working ok. But tbh i do not see the point there, since this test do not change any values (only printing the messages of which button was pressed).
Actually one point to mention : i was expecting (due the presence of the irremote->resume call) that keeping the button pressed (for example the +1 buttton) would have a "continuous" effect (that is the focuser keeping moving by +1 as long as the button is pressed, but that do not "work". you have to "click" one at a time..,.
Regards
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is Arduino 1.8.19 and the esp core version is 2.0.11 as recommended
And i tried also with 2 differents boards the ESP32WEMOSR3 as well as the small ESP32WEMOS D1 MINI, but both had the same behaviour.
To my understanding of the debug messages it seems to be related with the flag end_move_flag setted at 0 in the case State_EndMove:
but i may be wrong since i have not a full vision of the code (but it looks like in the irremte case, that the fposition value is never updated, except when time is ok for saving configuration, every 60s if my memory is good)
Think i solved this issue by moving
if (ControllerData->SaveConfiguration(driverboard->getposition(), DirOfTravel)) {
debug_server_println(FPSTR("config saved"));
}
out of the if (t_mux ==1) test in the State_Idle case.
Actually this was the case in the 304 revision, so i hope this is the right correction, though i do not know why it was moved into the t_mux test
Regards
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is in the ino file, firmware 311-02, in the state machine , case State_Idle
the if (t_mux==1) is at line 1743, into the else block (focuser not moving) tmux being made equal to endmoveflag in the mutex section just before (line 1741)
the if(ControllerData ) is at line 1745 .
Initially in the 304 version the If(COntrollerData) was placed before (line 1483) the if (t_mux==1) test (line 1504)
My understanding is that the call to ControllerData->SaveConfiguration is mandatory to update the value of fposition with the position after move(since fposition is used to calculate the target position in the irremote.cpp ), and that this call do not occur right after move int the 311 firmware (since endmove flag is set to 0 at the end of move as you can see in the debug log in my first post)
Moving this test out of the if tmux block do the job, but is not probably the correct solution regarding the architecture of the state machine, and maybe a call to set_fposition would be better ?
Joël
Last edit: Collet 2024-06-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took some time to dig into the code.
To me there is not much solutions to deal with this update position thing.
Either there is another flag (hence maybe mutex) to deal only with the updating position right after a move is completed, but this looks really overkill to me.
Or we rely on what we already have in the state machine to update the position (and maybe the direction) when needed.
My understanding of the state machine is that, In idle state , either there will be a move to do (ftargetposition !=driverboard positiion) or the move just finished (or did not occured for "a while").
Hence in this part of the code dealing with move finished/not moving (rigth after line 1734)
adding a call to ControllerData->set_fposition (and set_focuserdirection) will fix the problem, without interfering with the case of idling long enough to save the configuration into spiffs.
but i did not checked if this is completely correct (especially for configuration saving after the timeout)
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An explanation.
This is disabled. Think about this for a moment. I hold down +500 for a few seconds. actually maybe even 1s. If I had enabled the repeat code, then the read button could have occured maybe 5 or more occassions due to the speed of the ESP32, meaning +500 x5 = a move now of 2500 - there is no way to back out at present - so the code is written so that you press but then waits on a release before triggering the focuser to move. Much safer...
myFP2 has two good features: I am thinking of porting these to myFP2ESP32
1. Jog control has free range jogging (jog stops when the jog bar is released, but jogs continually when job bar is dragged left or right using a mouse. Pg 124
2. Key Mapping table used with tablet or joystick, pg135-137. I can use a small Bluetooth keyboard, then map key combinations to key presses (ALT + specific key) to actions (such as Halt, +50, -100 etc, like UP arrow for move in and DN arrow for move out) Pretty cool stuff,
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as i understand, the tcpip server is currently rewritted, which is explaining it was not working with either the app or the ascom driver ?
May i suggest the following code for the irremote, which is "moderating" the fact that the reading speed of the button is too fast? the value of 5 here is pretty ok for a button holded around 1s. May we wish to have it longer, just increase the threshold.. maybe a bit "rough" method, but works correctly ,except maybe for the largest move (+100 ?).
Not perfect but it is close to what "i want", between "comfort" and "safe"
if (irrecv->decode(&results)) {
int adjpos = 0;
static long lastcode;
static long memocode;
static int count = 0;
if (results.value == KEY_REPEAT) {
if (count==0)
{
memocode=lastcode;
// lastcode=0;
}
lastcode=KEY_REPEAT;
count++;
if (count>5) {
count=0;
lastcode=memocode;
}
results.value = lastcode; // repeat last code
} else {
lastcode = results.value;
count=0;
}
Hi Robert,
by the way, this idea can even be slightly refined to allow only some keys ( keys +/- 1 and +/-10 for example) to be repeated by adding a test on lastcode value .
something like
if ((count==0) && (lastcode==IR_IN1 || lastcode == IR_OUT1))
Joël
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ive looked at this for myFP2 for the KepMap and buttons.
Using a repeat key is not necessary. because the code as you can see only moves the focuser by x steps IF ismoving is false; meaning any keypress which finds ismoving true will be ignored.
Here is how it works in myFP2
A key or button is held down
Each loop() checks the keymap or button
Each loop(0 iterates at about 4ms
So key/button is checked about 4ms apart
A user holds down a key
The loop iteration checks key, checks ismoving, which is false, works out move and target, then sets ismoving true and the move starts
Next loop iteration
Finds key, checks ismoving which is now TRUE, so ignores this keypress
keys iterating while ismoving = true
Finally when move is completed, ismoving is set to false
Next loop iteration
Find key pressed, checks ismoving which is false, works out move and target, then sets ismoving true and the move starts
For the ESP32
Buttons handled by driver_board.cpp in void DRIVER_BOARD::update_pushbuttons(void)
If a button is reported as Logic 1, then it means the button is held DOWN
So it works same as way as for myFP2
Joysticks also operate the same way but on a pin configured as analog. A nuetral not moved (joystick is in the middle) is no steps.
When the joystick position is left or right of middle then a move is generated.
The code here could use the joystick position to also select the amount of move, typcially using a map code to map the value to something like -1..-500 steps, for In and +1..+500 for out.
We have center as
JZEROPOINT 1837
We have threshhold as
#define JTHRESHOLD 300
We have max as
#define JMAXVALUE 4095
and min value as
#define JMINVALUE 0
that means for In range it is
JZEROPOINT - JTHRESHOLD = 1837 - 300 = 1537
so the in range is
0 .. 1637
and the out range is
2137 .. 4095
meaning 0..1637 mapped to -500 .. -1
and 2137..4095 mapped to +500 .. +1
In map would look like
// map(value, fromLow, fromHigh, toLow, toHigh)
stepstomove = map(joyval, 0, 1637, -1, -500);
and for move out would be
stepstomove = map(joyval, 2137, 4095, +1, +500);
regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Robert, all
First thanks to Robert for all he developped (SQM, focuser, and so one) This is awesome !!
I used to work with the 304 version of MyFP2ESP32 with DRV8825 since few monthes with only the web services and servers and also an irremote when wanting to move manually (for visual use it is sometime convenient to not touch the scope ). This was working flawlessly (after having done the correction indicated here https://sourceforge.net/p/myfocuserpro2-esp32/discussion/general/thread/d91dcaabb8/#8454/3ea5 ) and the movement was smooth and without problems.
Decided to switch to the new rev recently to test it out and have found an issue with the irremote part:
Let say the focuser start at position 5000 on boot (this is an example)
Then want to move to pos 5010. I then push on the key mapped to OUT10.
If i get the position within the FP2 application i get 5010 displayed, which looks fine
However pushing again OUT10 on the remote then again get position the numbers stay at 5010.
I need to push another button to get the numbers change, but they do not change the way they should.
for example pushing OUT1 move the display to...5001 (instead of 5011) as if the position was not actualised
I have activated the debug server
Here is a copy of the debug window when doing the following sequence starting from an initial position of 5000
//
OUT10
OUT10 -> nothing update on the debug window
OUT1
OUT10
go State_InitMove
to 5010
State_InitMove
INITMOVE d=Out, steps=10
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
<<<<here i="" pushed="" out10="" again="" but="" nothing="" happened="">>>>
go State_InitMove
to 5001
State_InitMove
INITMOVE d=in, steps=9
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
go State_InitMove
to 5010
State_InitMove
INITMOVE d=Out, steps=9
MSDELAY=4000
State_InitMove GO State_Moving
State_Moving timerSemaphore true: move done
DRVBRD end_move
State_EndMove: end_move_flag =0
//
As you can see it looks like the current position is not updated correctly
first move is 10 step out which is correct
second move doesn't occurs
third move should be 1 step out, but is..9 step in
then fourth move is 9 step out...</here>
Actually since my motorboard was not connected, i don't know if the motor is moving correctly and that the issue is only with the information display (but the debug server show the claculated increment/decrement for the stepper movement, so i assume th e motor will move as indicated in the debug
Also, when waiting enough time (for the information to be written ) then things works the way they should.
Any help welcome
Regards
Joël
Last edit: Collet 2024-07-21
Hi
Could you please let me know the following
Arduino IDE version (should be 1.8.19)
ESP32 Core version ?
Regards
Robert
Hi Robert,
it is Arduino 1.8.19 and the esp core version is 2.0.11 as recommended
And i tried also with 2 differents boards the ESP32WEMOSR3 as well as the small ESP32WEMOS D1 MINI, but both had the same behaviour.
To my understanding of the debug messages it seems to be related with the flag end_move_flag setted at 0 in the case State_EndMove:
but i may be wrong since i have not a full vision of the code (but it looks like in the irremte case, that the fposition value is never updated, except when time is ok for saving configuration, every 60s if my memory is good)
REgards
Joël
Reading your last post i am thinking about the issue i encountered
I have currently installed on my PC the legacy IDE 1.8.19 and the 2.3.2 version as well (both in separated directory, accounts..)
Both are also with esp core 2.0.11 and arduino esp32 in 2.0.11 as well.
I am doubtfull that having the two ide can be the source of the issue, but i can try to install only the 1.8.19 ide on an old PC to check if things behave differently.
all this under W10 if it matters.
Joël
Hi Robert
as expected, no changes, still the same behaviour with a fresh install
I tried to understand why the irremote "command" was behaving differently than the command from the tcp ip server, and i think i got the answer for the issue.
Actually when doing a N step move (command 64 ) with tcpip server ftargetposition is calculated from the driverboard values (line 837 in the tcpipserver.cpp
long pos = WorkString.toInt() + driverboard->getposition();
hence the move is always based on the latest position of the driverboard values, updated "real time". Additionally the flag ismoving is setted to 1 (which is not necessary to me since it is handled in the statemachine, but that's not the issue there)
While in the irremote code the ftargetposition is calculated from the ControllerData values (line 174 irremote.cpp
newpos = ControllerData->get_fposition() + adjpos; that is the latest position updated in the ControllerData, which occurs only when the "saving timer" triggers the save operation).
The logical things is probably to calculate the new position from the ftargetposition as for the pushbutton/joystick or from the driverboard position (as for the tcpip commands, which is i think the most logical of the two ideas)
Regards
Joël
Last edit: Collet 2024-07-07
We are currently using 2.0.16 for the Arduino ESP32 core,
Have you tried the esp32 test for IR ion the tests folder?
irremote in the folder "Test Examples/irremote/irremote.ino
Hi Robert
I also exhibit this issue and have tried core version 2.0.16 with the same results, the IR Test sketch just reports a constant stream of garbage in the terminal screen (I presume thats how it works?)
if I use the latest core version 3.0.2 I get a compile error tasktimer.h:196:23: error: too many arguments to function 'void timerAttachInterrupt(hw_timer_t, void ()())'
196 | timerAttachInterrupt(task_timer, &task_100MillisecondTimer, true);
Dave
I did post a message about the recent core updates. I am still coding on 2.0.16 and advised everyone to stay on 2.0.16 till expressif solve the mirriad issues associated with it (espnow, httpupdate, many core routines had their interfaces changed, interrupts, irrremote etc). This happened because the IDF from Expressif changed to v4, then to v5 and because the core is built on the IDF, and had to use the same interfaces to talk to IDF, boom, it killed a lot of projects out there. There is even more bad news converning interrupt handling/conventions that is coming (or already here)
This also affects the mySQM+ project.
Once the main issues are resolved by the coding team responsible, 2.0.16 is the only core that is supported.
Regards
Robert
Hi Robert
2.0.16 core is working the same, no changes in the results.
Yes,but long time ago, and not on the curent version of the code , only to validate that the remote was working ok. But tbh i do not see the point there, since this test do not change any values (only printing the messages of which button was pressed).
Actually one point to mention : i was expecting (due the presence of the irremote->resume call) that keeping the button pressed (for example the +1 buttton) would have a "continuous" effect (that is the focuser keeping moving by +1 as long as the button is pressed, but that do not "work". you have to "click" one at a time..,.
Regards
Joël
Hi Robert,
it is Arduino 1.8.19 and the esp core version is 2.0.11 as recommended
And i tried also with 2 differents boards the ESP32WEMOSR3 as well as the small ESP32WEMOS D1 MINI, but both had the same behaviour.
To my understanding of the debug messages it seems to be related with the flag end_move_flag setted at 0 in the case State_EndMove:
but i may be wrong since i have not a full vision of the code (but it looks like in the irremte case, that the fposition value is never updated, except when time is ok for saving configuration, every 60s if my memory is good)
REgards
Joël
Last edit: Collet 2024-07-21
Hello
Think i solved this issue by moving
if (ControllerData->SaveConfiguration(driverboard->getposition(), DirOfTravel)) {
debug_server_println(FPSTR("config saved"));
}
out of the if (t_mux ==1) test in the State_Idle case.
Actually this was the case in the 304 revision, so i hope this is the right correction, though i do not know why it was moved into the t_mux test
Regards
Joël
Joel could you tell me where this line is and in which file please?
Hi Dave
Sorry for the small delay in my answer,
it is in the ino file, firmware 311-02, in the state machine , case State_Idle
the if (t_mux==1) is at line 1743, into the else block (focuser not moving) tmux being made equal to endmoveflag in the mutex section just before (line 1741)
the if(ControllerData ) is at line 1745 .
Initially in the 304 version the If(COntrollerData) was placed before (line 1483) the if (t_mux==1) test (line 1504)
My understanding is that the call to ControllerData->SaveConfiguration is mandatory to update the value of fposition with the position after move(since fposition is used to calculate the target position in the irremote.cpp ), and that this call do not occur right after move int the 311 firmware (since endmove flag is set to 0 at the end of move as you can see in the debug log in my first post)
Moving this test out of the if tmux block do the job, but is not probably the correct solution regarding the architecture of the state machine, and maybe a call to set_fposition would be better ?
Joël
Last edit: Collet 2024-06-11
Yes, I found the issue.
I am working on next release probably 313x
I am dealing with Joels issue for infra red now,.
Robert
Hi Robert
Thank you for this work.
If i can help (eg to test), please don't hesitate
Hi again
I took some time to dig into the code.
To me there is not much solutions to deal with this update position thing.
Either there is another flag (hence maybe mutex) to deal only with the updating position right after a move is completed, but this looks really overkill to me.
Or we rely on what we already have in the state machine to update the position (and maybe the direction) when needed.
My understanding of the state machine is that, In idle state , either there will be a move to do (ftargetposition !=driverboard positiion) or the move just finished (or did not occured for "a while").
Hence in this part of the code dealing with move finished/not moving (rigth after line 1734)
adding a call to ControllerData->set_fposition (and set_focuserdirection) will fix the problem, without interfering with the case of idling long enough to save the configuration into spiffs.
but i did not checked if this is completely correct (especially for configuration saving after the timeout)
Joël
The Coil Power Issue
The IRRemote Issue
These have been recoded and currently under test, and have both been migrated into the next release (v313)
regards
Robert
Hi Robert
Thanks. I can do some test if you need before release.
Regards
Joël
testing continues but the fixes are ok
An explanation.
This is disabled. Think about this for a moment. I hold down +500 for a few seconds. actually maybe even 1s. If I had enabled the repeat code, then the read button could have occured maybe 5 or more occassions due to the speed of the ESP32, meaning +500 x5 = a move now of 2500 - there is no way to back out at present - so the code is written so that you press but then waits on a release before triggering the focuser to move. Much safer...
myFP2 has two good features: I am thinking of porting these to myFP2ESP32
1. Jog control has free range jogging (jog stops when the jog bar is released, but jogs continually when job bar is dragged left or right using a mouse. Pg 124
2. Key Mapping table used with tablet or joystick, pg135-137. I can use a small Bluetooth keyboard, then map key combinations to key presses (ALT + specific key) to actions (such as Halt, +50, -100 etc, like UP arrow for move in and DN arrow for move out) Pretty cool stuff,
Regards
Robert
Thanks Robert for the update.
Yes fixes are ok.
As far as i understand, the tcpip server is currently rewritted, which is explaining it was not working with either the app or the ascom driver ?
May i suggest the following code for the irremote, which is "moderating" the fact that the reading speed of the button is too fast? the value of 5 here is pretty ok for a button holded around 1s. May we wish to have it longer, just increase the threshold.. maybe a bit "rough" method, but works correctly ,except maybe for the largest move (+100 ?).
Not perfect but it is close to what "i want", between "comfort" and "safe"
if (irrecv->decode(&results)) {
int adjpos = 0;
static long lastcode;
static long memocode;
static int count = 0;
if (results.value == KEY_REPEAT) {
if (count==0)
{
memocode=lastcode;
// lastcode=0;
}
lastcode=KEY_REPEAT;
count++;
if (count>5) {
count=0;
lastcode=memocode;
}
results.value = lastcode; // repeat last code
} else {
lastcode = results.value;
count=0;
}
Joël
Last edit: Collet 2024-07-21
Hi Robert,
by the way, this idea can even be slightly refined to allow only some keys ( keys +/- 1 and +/-10 for example) to be repeated by adding a test on lastcode value .
something like
if ((count==0) && (lastcode==IR_IN1 || lastcode == IR_OUT1))
Joël
Ive looked at this for myFP2 for the KepMap and buttons.
Using a repeat key is not necessary. because the code as you can see only moves the focuser by x steps IF ismoving is false; meaning any keypress which finds ismoving true will be ignored.
Here is how it works in myFP2
A key or button is held down
Each loop() checks the keymap or button
Each loop(0 iterates at about 4ms
So key/button is checked about 4ms apart
A user holds down a key
The loop iteration checks key, checks ismoving, which is false, works out move and target, then sets ismoving true and the move starts
Next loop iteration
Finds key, checks ismoving which is now TRUE, so ignores this keypress
keys iterating while ismoving = true
Finally when move is completed, ismoving is set to false
Next loop iteration
Find key pressed, checks ismoving which is false, works out move and target, then sets ismoving true and the move starts
For the ESP32
Buttons handled by driver_board.cpp in void DRIVER_BOARD::update_pushbuttons(void)
If a button is reported as Logic 1, then it means the button is held DOWN
So it works same as way as for myFP2
Joysticks also operate the same way but on a pin configured as analog. A nuetral not moved (joystick is in the middle) is no steps.
When the joystick position is left or right of middle then a move is generated.
The code here could use the joystick position to also select the amount of move, typcially using a map code to map the value to something like -1..-500 steps, for In and +1..+500 for out.
that means for In range it is
JZEROPOINT - JTHRESHOLD = 1837 - 300 = 1537
so the in range is
0 .. 1637
and the out range is
2137 .. 4095
meaning 0..1637 mapped to -500 .. -1
and 2137..4095 mapped to +500 .. +1
In map would look like
// map(value, fromLow, fromHigh, toLow, toHigh)
stepstomove = map(joyval, 0, 1637, -1, -500);
and for move out would be
stepstomove = map(joyval, 2137, 4095, +1, +500);
regards
Robert