Feature request: adjust lock position or sticky lock position in the API

[gnthibault]

From the documentation I see that it should be possible to force to change the position of a star (when selected) so that it is moved up to a specific coordinates on the sensor.

Unfortunately, from the API documentation, and some tests, I didn't managed to find how to force a previsously selected star (with find_star) to go onto a specific position on the sensor. This feature is particularly useful in slit-spectroscopy workflow. I would summarize the feature request as follow:

• add a sticky_lock_position that would make the current lock position sticky, even in case of calibration
• add a adjust_lock_position, with an x,y parameters so that one can change

[bwdev01]

Have you done this:

Bruce

From: gnthibault @.> Sent: Thursday, December 22, 2022 12:26 PM To: OpenPHDGuiding/phd2 @.> Cc: Subscribed @.***> Subject: [OpenPHDGuiding/phd2] Feature request: adjust lock position or sticky lock position in the API (Issue #1020)

From the documentation https://openphdguiding.org/man-dev/Tools.htm#:~:text=the%20bookmark%20location.-,Lock%20Positions,off%20by%20a%20few%20pixels. I see that it should be possible to force to change the position of a star (when selected) so that it is moved up to a specific coordinates on the sensor.

Unfortunately, from the API documentation https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring#available-methods , and some tests, I didn't managed to find how to force a previsously selected star (with find_star) to go onto a specific position on the sensor. This feature is particularly useful in slit-spectroscopy workflow. I would summarize the feature request as follow:

• add a sticky_lock_position that would make the current lock position sticky, even in case of calibration
• add a adjust_lock_position, with an x,y parameters so that one can change

— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1020 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV6MBA3F2SGUHJUDQWTWOS2OFANCNFSM6AAAAAATHC4CGA . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ADDHSV2MRNJRLT7GCNG4CM3WOS2OFA5CNFSM6AAAAAATHC4CGCWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFT2PHZ4.gif Message ID: @. @.> >

[gnthibault]

Sorry I don't understand your message.

[bwdev01]

My message showed a screen-shot of the documentation for the set_lock_position method. So my question is: 1) Did you know about it, 2) Did you try using it, and 3) Do you have some reason to think it doesn’t work.

From: gnthibault @.> Sent: Thursday, December 22, 2022 1:11 PM To: OpenPHDGuiding/phd2 @.> Cc: bwdev01 @.>; Comment @.> Subject: Re: [OpenPHDGuiding/phd2] Feature request: adjust lock position or sticky lock position in the API (Issue #1020)

Sorry I don't understand your message.

— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1020#issuecomment-1363343957 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV6PO32PKGC4NMHHIXDWOS7VZANCNFSM6AAAAAATHC4CGA . You are receiving this because you commented. https://github.com/notifications/beacon/ADDHSV4L5BZLUKZOADY7XO3WOS7VZA5CNFSM6AAAAAATHC4CGCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSRIL5FK.gif Message ID: @. @.> >

[d33psky]

(the screenshot did not show up for me either, not in mail nor on github)

[bwdev01]

Ok try this.

set_lock_position | X: float, Y: float, EXACT: boolean (optional, default = true) | integer (0) -- | -- | --

[gnthibault]

yes sorry I forgot to add this in the initial problem description, I did quite some tests with set_position_lock . The behaviour is the following: set_position_lock (almost) immediately returns with the required LockPositionSet event, it does not change the position of the previously slected star whatsoever, no mount movement is initiated at all.

Upon launching guide afterwards, phd2 selects another star (which generates another LockPositionSet), so I really think the feature is not available from the API.

[bwdev01]

Ok, sorry, this looks like a bug wherein the freshly set lock-point is almost immediately over-written. I can reproduce it easily enough so I should be able to deal with it soon. The intended behavior is that the change in lock-point will behave like a dither, which is essentially all a dither is. Doing a ‘start-guide’ will select a new star set unless there is already one in use.

Bruce

From: gnthibault @.> Sent: Friday, December 23, 2022 12:51 AM To: OpenPHDGuiding/phd2 @.> Cc: bwdev01 @.>; Comment @.> Subject: Re: [OpenPHDGuiding/phd2] Feature request: adjust lock position or sticky lock position in the API (Issue #1020)

yes sorry I forgot to add this in the initial problem description, I did quite some tests with set_position_lock . The behaviour is the following: set_position_lock (almost) immediately returns with the required LockPositionSet event, it does not change the position of the previously slected star whatsoever, no mount movement is initiated at all.

Upon launching guide afterwards, phd2 selects another star (which generates another LockPositionSet), so I really think the feature is not available from the API.

— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1020#issuecomment-1363746202 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV5XH6B5TUVJVWTPZ73WOVRXRANCNFSM6AAAAAATHC4CGA . You are receiving this because you commented. https://github.com/notifications/beacon/ADDHSV3BQYCPRL33YEQBBFLWOVRXRA5CNFSM6AAAAAATHC4CGCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSRJEOZU.gif Message ID: @. @.> >

[gnthibault]

Ok, sorry, this looks like a bug wherein the freshly set lock-point is almost immediately over-written. I can reproduce it easily enough so I should be able to deal with it soon. The intended behavior is that the change in lock-point will behave like a dither, which is essentially all a dither is. Doing a ‘start-guide’ will select a new star set unless there is already one in use.

Exactly ! I would expect ideally the set_lock_position to perform a "dither" in the pixel space that would bring the current selected star onto the position passed in parameter in the set_lock_position. It would be absolutely awesome if you could bring that feature up, I am ready to test this. Thanks a lot for your help

Just for your to know, I am using the following workflow in my current test (from here):

g.launch_server()
g.connect_server()
g.connect_profile()
g.set_exposure(1.0)
g.loop()
print("About to start star selection")
ret = g.find_star(x=0, y=0, width=1000, height=1000)
print(f"Return from find_star is {ret}")
# If successful, there should be a lock position set
ret = g.get_lock_position()
print(f"Get lock position now returns {ret}")
print("About to set lock position")
g.set_lock_position(320.0, 350.0)
print("Lock position set
# If successful, there should be a lock position set
ret = g.get_lock_position()
print(f"Get lock position now returns {ret}")
g.guide(recalibrate=False)
print(f"Guiding is now steady, about to check lock position")
ret = g.get_lock_position()
print(f"Get lock position now returns {ret}")

g.disconnect_profile()
g.disconnect_server()
g.terminate_server()

My phd2 client class is here, it is not ready to be used as a standalone, but there's not too much work either to remove the external dependencies, let me know if you are interested.

[bwdev01]

Ok, I looked into this and I don’t think there’s a problem after all. The “secret sauce” is that you must set the “Exact” parameter to true! If you leave it set to false (the default), it behaves like “lock on the star nearest to this position”. That’s useful if you have an app that’s trying to choose a guide star for some reason rather than a fixed sensor position. But if there’s no star at that exact position, the next “star-find” of the closest one will reset the lock point. With “Exact” set to true, it means “set the lock point here and move the guide star to this position” – just like a dither. Here’s an excerpt from the log file showing the desired behavior:

14:59:23.289 00.002 7684 evsrv: cli 0D73BE08 request: {"method":"set_lock_position","params":[358,185,true],"id":1}

14:59:23.289 00.000 7684 setting lock position to (358.00, 185.00)

14:59:23.291 00.002 7684 Mount: notify guiding dithered (3.8, 3.6)

Give that a shot, I’ll bet it works…

Bruce

From: gnthibault @.> Sent: Friday, December 23, 2022 2:54 PM To: OpenPHDGuiding/phd2 @.> Cc: bwdev01 @.>; Comment @.> Subject: Re: [OpenPHDGuiding/phd2] Feature request: adjust lock position or sticky lock position in the API (Issue #1020)

Ok, sorry, this looks like a bug wherein the freshly set lock-point is almost immediately over-written. I can reproduce it easily enough so I should be able to deal with it soon. The intended behavior is that the change in lock-point will behave like a dither, which is essentially all a dither is. Doing a ‘start-guide’ will select a new star set unless there is already one in use.

Exactly ! I would expect ideally the set_lock_position to perform a "dither" in the pixel space that would bring the current selected star onto the position passed in parameter in the set_lock_position. It would be absolutely awesome if you could bring that feature up, I am ready to test this. Thanks a lot for your help

— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1020#issuecomment-1364373286 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV7ZJPJ7OMRXRHGYIT3WOYUSJANCNFSM6AAAAAATHC4CGA . You are receiving this because you commented. https://github.com/notifications/beacon/ADDHSV2RMTZJNRIL7SCE3KTWOYUSJA5CNFSM6AAAAAATHC4CGCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSRKKXSM.gif Message ID: @. @.> >

[gnthibault]

Ok thank you very much @bwdev01 for actively providing support. I think I was missing a few elements of understanding with regard to how PHD2 is working. Apparently while simply being in looping state, set_lock_position was immediately returning, not doing much, even if star was selected before (through the use of find_star)

However, when in state guiding, the set_lock_position indeed triggers a mount move towards the new target, which is great. I haven't however, really understand if there was a specific event associated with the lock position being reached, I would have expected a SettleDone event, that would have been great.

However, I found a simple workaround, by simply monitoring guidestep events, and waiting for RADistanceRaw" and DECDistanceRaw to be as close as expected. Just a side note, I notive there was a small issue in the documentation: https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring#guidestep DecDistanceRaw should be DECDistanceRaw DecDistanceGuide should be DECDistanceGuide

[agalasso]

@gnthibault thanks for letting us know about the error in the documentation. I made the correction, but the wiki is actually editable by anyone with a github account so feel free to make any additional corrections yourself!

[gnthibault]

Sure thing, I will continue develop my python software, but there is a high chance that I split the Phd2 client into its own python module at some point.

I will ask my friend who is expert in spectroscopy in order for me to better understand the workflow, and potentially consider help developing new features if needed (I will most probably ask for support to develop here) Will close the FR, thank you veruly much again for the support