×
INDI Library v1.8.1 Released (09 Sep 2019)

Monthly maintenance release INDI v1.8.1

myFocuserPro or myFocuserPro2 and INDI

1 month 2 weeks ago
ajt68
Senior Boarder
Senior Boarder
Posts: 74
Karma: 1
More
myFocuserPro or myFocuserPro2 and INDI #44205
I have just generated a pull request for the isMoving issue.
The following user(s) said Thank You Acapulco Rolf

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
ajt68
Senior Boarder
Senior Boarder
Posts: 74
Karma: 1
More
myFocuserPro or myFocuserPro2 and INDI #44207
Like the auto focus results (this is my main motivation for writing this driver). The vide is real useful too.

When I connect using local server in development the MaxPos is read every connect, in fact it is one of the first proerties to be read. I need to get my head around how ekos is connecting differently. In the meantime can I ask you to start ekos, goto the focuser page then disconnect and reconnect, see if that populates it? I still think the ultimate protection should be in the focuser firmware though.

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago 1 month 2 weeks ago by Acapulco Rolf.
Acapulco Rolf
Senior Boarder
Senior Boarder
Posts: 41
Karma: 2
More
myFocuserPro or myFocuserPro2 and INDI #44210
Thanks Alan
I did the disconnect/reconnect test as you suggested

Some interesting outcomes

Video uploading now....

Should be uploaded and visible in about 50 minutes from now

I'll post the link shortly

Look out for the various "quirks":

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago 1 month 2 weeks ago by roberto.
roberto
Junior Boarder
Junior Boarder
Posts: 25
More
myFocuserPro or myFocuserPro2 and INDI #44225
Hi
I cant make changes in the firmware because it will affect the ASCOM app and the Windows app.
What happened from 284 to the next release of v288 was a common code base was developed that is now used across all platforms.
So changing that code breaks a lot of other things, not just myFocuserPro2.

290 is the best way to go. You can program the controller without removing anything. Simply save its settings using the Windows app, then reporgram with v290.
After that, update the Windows app, then use that to restore the controller settings.

Here is how MaxPos is used. The ASCOM standard and Windows apps uses a GET and possible a SET getmaxstep call when connecting to determine what is the maximum setting of the controller. On a SET any attempt to set it is checked. If the value being set is lower than that stored in the controller, then it is checked to see if it is lower than 1024 or the current focuser position. If it is lower than the focuser position then it is set to that. If focuser position is less than 1024 then maxstep is set to 1024.

ASCOM has no way of knowing what the maximum value might be. Only the user knows. The Windows app and ASCOM driver thus implement a MAXFOCUSERPOSITION value which the user can set so the software will not let them enter in a greater value than this for maxtsep.

Typically all focusers require a user to determine maxstep during setup and install and not set it to an invalid value. Once set it cannot be changed. ASCOM does not provide a mechanism to change it. myFocuserPro2 cheats a bit by providing a mechanism to change it during connection sequence.

I do not know enough about INDI.

myFocuserPro2 firmware expects any application to validate values before sending. Having said that it does error check values. In the case of maxstep the value is checked against a constant FOCUSERUPPERLIMIT which is arbitrarily set to 2000000000L. This value is NOT exposed through the interface (there is no way to retrieve this value).

Any attempt to set maxstep to a higher value on connection is handled. v291 (about to be released) looks a bit like
case 7: // set maxsteps
WorkString = receiveString.substring(2, receiveString.length() );
tmppos = WorkString.toInt();
tmppos = (tmppos >= FOCUSERUPPERLIMIT) ? FOCUSERUPPERLIMIT : tmppos;
tmppos = (tmppos < fcurrentposition) ? fcurrentposition : tmppos;
tmppos = (tmppos < FOCUSERLOWERLIMIT) ? FOCUSERLOWERLIMIT : tmppos;
myfocuser.maxstep = tmppos;
writenow = 1;
break;

So the firmware does check any request to set maxstep value.

On a read maxtep call ( :8# ) the focuser simply returns the current maxstep value (preceded by M and suffixed with # ).
case 8: // get maxStep
SendPacket('M' + String(myfocuser.maxstep) + '#');
break;

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago 1 month 2 weeks ago by Acapulco Rolf.
Acapulco Rolf
Senior Boarder
Senior Boarder
Posts: 41
Karma: 2
More
myFocuserPro or myFocuserPro2 and INDI #44235
@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




Attachments:

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago 1 month 2 weeks ago by Acapulco Rolf.
Acapulco Rolf
Senior Boarder
Senior Boarder
Posts: 41
Karma: 2
More
myFocuserPro or myFocuserPro2 and INDI #44305
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

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
roberto
Junior Boarder
Junior Boarder
Posts: 25
More
myFocuserPro or myFocuserPro2 and INDI #44316
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

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
Acapulco Rolf
Senior Boarder
Senior Boarder
Posts: 41
Karma: 2
More
myFocuserPro or myFocuserPro2 and INDI #44317
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....?

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
roberto
Junior Boarder
Junior Boarder
Posts: 25
More
myFocuserPro or myFocuserPro2 and INDI #44352
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)

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
ajt68
Senior Boarder
Senior Boarder
Posts: 74
Karma: 1
More
myFocuserPro or myFocuserPro2 and INDI #44363
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?
The following user(s) said Thank You knro

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
ChrisRowland
Gold Boarder
Gold Boarder
Posts: 219
Karma: 7
More
myFocuserPro or myFocuserPro2 and INDI #44365
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
The following user(s) said Thank You knro

Please Log in or Create an account to join the conversation.

1 month 2 weeks ago
knro
Administrator
Administrator
Posts: 7379
Karma: 51
myFocuserPro or myFocuserPro2 and INDI #44370

ajt68 wrote: 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?


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.

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info

Please Log in or Create an account to join the conversation.

Time to create page: 1.006 seconds