@Alan

Just FYI

Did a quick test of the focuser with your PR from yesterday (MyFP2 indilib driver version 0.2)
It seems to have done the job to resolve the <em>"isMoving issue"</em>

No longer seeing any errors thrown for that issue in the ekos/kstars message window

Thanks

Hi Alan

I ran v0.2 of the MyFP2 indi driver through the debugger

See below for a steer:



I wrote additional logging statements into the driver code to aid seeing what's going on via the ekos log window
It appears that when the indilib driver reads the focuser "Max Position" value at startup, a zero value is picked up


When connected to the Windows MyFP2 client, the focuser "Max Position" value is correctly picked up

Is get maxsteps the first command issued to the controller after a connection is made?
my guess is that it is occuring too quickly and not giving the controller enough time to start up.
I would suggest inserting a 1s delay between connecting and sending any commands to the controller.

Windows and ASCOM drivers/apps I insert a 3s delay after connecting and a 100ms delay between each request

OK, I believe the issue is here:

In reading the focuser "Max Position", the indi driver uses the following which always returns zero:
(sendCommand(":08#", res) == false)

It should be:
if (sendCommand(":8#", res) == false)

@Alan, @Rob, what do you think....?

perhaps
All commands send to myFocuserPro2 must be two digits long, so cannot shorten to 8 instead of 08 though

if (sendCommand(":8#", res) == false)

would be

if (sendCommand(":08#", res) == false)

Roberto, I agree in principle that the sent command should be in the format #xx: where xx = leading zero 2 numeric (00-99), but rather than go back to change any that are not, just use this going forward.

I see you have modified the MaxPosition request back to #08:, unfortunately KNRO has submitted a change to #8:, without checking version of firmware (it would now be broke for 280, which wasted a bit of my time trying to understand why I was no longer reading the MaxPosition!)

Leave your change as is (#08:) in 291, and I will upgrade my focuser to 291, and retest, and fix any issue I see. I will then make the base firmware check equal to or greater than 291.

So to be clear:
KNRO to revert the :8# change back to :08# ;
Roberto, leave 291 as is (possibly point me at inputs or outputs they may have changed since 280?) ;
I will update to 291, test and fix ;


Does this seem acceptable?

Would it be worth being generous about what is accepted?

Take the string sent, remove the leading ':' and the trailing '#' and parse what is left as a decimal integer.
It could accept :8#, :08#, :008# and so on.
That way the code can be agnostic about the version of the code on the other side.

Chris

Ok sorry I thought that was the actual fix to communicate with the firmware. Please agree on a solution and we'll take it from there.

I have updated my focuser firmware to the latest 291, and set the Indi focuser driver to only work with 291 or greater.

I have made sure isMoving and Max position behave as expected.
I have implemented Reverse Motion, and removed option tab Reverse Direction (to use standard functions).

I am about to push these changes (this will also revert KNRO earlier change).

So I have hit this problem, I have no idea what todo?!

alan@alan-kubuntu:~/indi$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 8 and 11 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified: drivers/focuser/myfocuserpro2.cpp
modified: drivers/focuser/myfocuserpro2.h

alan@alan-kubuntu:~/indi$ git commit -m "Update myFocuserPro2 to work with firmware 291 or greater"
[master 3874b71] Update myFocuserPro2 to work with firmware 291 or greater
2 files changed, 22 insertions(+), 31 deletions(-)
alan@alan-kubuntu:~/indi$ git pull
Auto-merging drivers/focuser/myfocuserpro2.cpp
CONFLICT (content): Merge conflict in drivers/focuser/myfocuserpro2.cpp
Automatic merge failed; fix conflicts and then commit the result.
alan@alan-kubuntu:~/indi$


How do I resolve this?

I also fixed other issues in a prior commit, so this is why it complains. Just edit the file and manually fix the conflicts. or if you can create a PR then I'll resolve the conflicts myself.

As stated many times before, I have never worked in git as a developer, and I am by no means a linux guru, so your previous comment really doesn't help me get any closer to a solution. My biggest concern is that I will loose my changes, by not really understanding what is going on, I also understand you are a very busy man, and don't have time to answer these sort of requests. Unfortunately I too am busy, and can't commit the time to learning git at this moment in time. Maybe we need a developer git help forum? I guess my problem was I didn't do a "git fetch" before starting my edits at lunch time?

After a bit of googling, I think I am back to some sort of synchronisation. You said "if I can create a PR....", I believe I already had, with a commit from myself, then one from you and now another from me just now. I manually opened the problem file with "nano" (horrible text editor) and then checked line by line looking for merge messages (there must be a better way of doing this?)

Anyway, I have done a commit. and my end says it is up to date, so I assume somehow I have muddled through and pushed my changes?