ERROR: Cannot initiate dither while guide is in progress CODE:1
Harry Zampetoulas
bw_msgboard
Hi Harry. These are caused by implementation problems in NINA. In the cases where the error occurs, NINA has requested an operation that may take a long time and requires settling – for example ‘start guiding’ or ‘dither’. In one case, the ‘start guiding’ required a calibration. But NINA isn’t monitoring the PHD2 settling activity correctly – or at all – and then tries to initiate a dither operation before the original settling has completed. This is something they will have to address, it isn’t a problem when the automation app is working correctly. That said, these are “soft” errors – PHD2 keeps guiding but the requested dither operation wasn’t done.
Good luck,
Bruce
--
You received this message because you are subscribed to the Google Groups
"Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/be8c084a-4afe-4e08-a56b-284bf9165c62n%40googlegroups.com.
Jay Sanchez
Unfortunately, I posted the same question on the NINA Discord forum just last week and was treated horribly by one of the moderators. Beware, they get pretty defensive on the forum -- which is unfortunate because it's a great app. Please post if you get this solved. Thanks!
bw_msgboard
Hi Jay. I think I explained the reason. This wasn’t guess-work, the PHD2 debug log file shows the problem pretty clearly. But perhaps you can find some workaround in NINA to avoid the problem.
Bruce
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/4c54b2ef-32e7-4754-aa79-f43779ea3b55n%40googlegroups.com.
Jay Sanchez
Brian Valente
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/4c54b2ef-32e7-4754-aa79-f43779ea3b55n%40googlegroups.com.
Jim Waters
Jim Waters
bw_msgboard
I think they are mistaken for the reasons I’ve explained. The problem is not seen in any other imaging/automation software we’re aware of, notably SGP, but numerous others. If the NINA developers are having problems handling PHD2 settling events and keeping things in synch, they can contact us on this forum and we will try to help.
Bruce.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/6248a12f-dbd1-4342-b81f-e2312c0e1aeen%40googlegroups.com.
Jim Waters
Bruce Waddington
Jim Waters
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/EMWTXmQdiak/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b2c053c9-81a6-4772-9699-add868568f16n%40googlegroups.com.
shlomi...@gmail.com
1. Looking for dither in the source, I found the following dither function, which sends the dither command immediately when it determines that phd2 is connected
Jim Waters
Shlomi Vaknin
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d90f88e3-b5f7-4eba-a2cf-1edc325d6ba2n%40googlegroups.com.
bw_msgboard
Hi Shlomi. There are reference implementations (with source code) for a PHD2 client app here:
https://github.com/agalasso/phd2client
Bruce
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CANyzh%3Dj5uJ2vdihOBUrpHysgSyi4%2Bh0%2B6ZEvVU7XwMUBYmPtug%40mail.gmail.com.
Dale Ghent
Hi Bruce, I'm one of the contributors. Thanks for taking a look at this.
I think the confusion stems from it not being clear in the Event API docs[1] that a SettledDone state is a prerequisite for initiating a dither. A lot is explained how the Settle object is used to ascertain when a guide or dither op has run through to its full completion, but not this apparently crucial aspect related to just getting it off the ground. I just took another look at the docs and, in the context of dithering, settling is talked about only in terms of after its initiation. Given that, one can make the assumption that the dither request would just be queued and executed at the next available opportunity without and further consideration from the client.
Given the lack of knowing this requirement and that this error being noticed is a relatively recent phenomena that happens to some more than others (or not at all), we were disposed to believe that something in PHD2, either by code or by setting, was amiss. The docs should definitely be updated to reflect this requirement so no one steps on this in the future.
We'll look at putting in a check for SettleDone before kicking off a dither. Are there any other operations that have the same requirement?
[1] https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring
> On Feb 8, 2021, at 23:25, Bruce Waddington <bw_m...@earthlink.net> wrote:
>
> I'd like to clarify our thinking on this. No one wants to see this devolve into a battle between warring development groups with the end-users trapped in the middle. It makes more sense to work through the available data constructively and find a solution. I think the PHD2 debug log file provides a pretty clear view of what's going on and I would be happy to go over that with the NINA developers. We don't expect other developers to know the ins-and-outs of what's in our log files.
>
> Bruce
>
> On Monday, February 8, 2021 at 7:50:12 PM UTC-8 Jim Waters wrote:
> Harry, JS9 ...etc - Bug this as 'Critical' in the Discord forum. That way they need to pay attention to the issue.
>
> On Monday, February 8, 2021 at 8:38:37 PM UTC-7 bw_m...@earthlink.net wrote:
> I think they are mistaken for the reasons I’ve explained. The problem is not seen in any other imaging/automation software we’re aware of, notably SGP, but numerous others. If the NINA developers are having problems handling PHD2 settling events and keeping things in synch, they can contact us on this forum and we will try to help.
>
>
>
> Bruce.
>
>
>
> Sent: Monday, February 08, 2021 7:31 PM
> To: Open PHD Guiding
> Subject: Re: [open-phd-guiding] ERROR: Cannot initiate dither while guide is in progress CODE:1
>
>
>
> The core developers told me it was a PHD2 problem.
>
> On Monday, February 8, 2021 at 8:24:34 PM UTC-7 Jim Waters wrote:
>
> I have had this same error several times.
>
> On Monday, February 8, 2021 at 4:30:03 PM UTC-7 bval...@gmail.com wrote:
>
> Hi Jay
>
>
>
> >>>I posted the same question on the NINA Discord forum just last week and was treated horribly by one of the moderators. Beware, they get pretty defensive on the forum -- which is unfortunate because it's a great app. Please post if you get this solved. Thanks!
>
>
>
> I'm sorry to hear this news, it's unfortunate that is their reaction, but it wouldnt be the first time I have heard this.
>
>
>
> NINA is constantly being updated, and in the past when things like this have come up, NINA's first reaction seems to always point at PHD, but in later NINA releases somehow it gets solved.
>
>
>
> It hasn't been an issue in the past, and PHD has been unchanged for quite some time related to dithering and API messaging
>
>
>
>
>
> I'd say just keep on this with them and if you can show your data, hopefully they will address it
>
>
>
>
>
>
>
> On Mon, Feb 8, 2021 at 1:25 PM Jay Sanchez <js9...@gmail.com> wrote:
>
> I too get this error in NINA (code 1) -- and can't seem to track down the reason. It happens when PHD2 is guiding and NINA starts a sequence and, also when guiding is started by NINA during a sequence. Makes no sense.
>
> Unfortunately, I posted the same question on the NINA Discord forum just last week and was treated horribly by one of the moderators. Beware, they get pretty defensive on the forum -- which is unfortunate because it's a great app. Please post if you get this solved. Thanks!
>
> On Saturday, February 6, 2021 at 11:12:01 AM UTC-5 bw_m...@earthlink.net wrote:
>
> Hi Harry. These are caused by implementation problems in NINA. In the cases where the error occurs, NINA has requested an operation that may take a long time and requires settling – for example ‘start guiding’ or ‘dither’. In one case, the ‘start guiding’ required a calibration. But NINA isn’t monitoring the PHD2 settling activity correctly – or at all – and then tries to initiate a dither operation before the original settling has completed. This is something they will have to address, it isn’t a problem when the automation app is working correctly. That said, these are “soft” errors – PHD2 keeps guiding but the requested dither operation wasn’t done.
>
>
>
> Good luck,
>
> Bruce
>
>
>
Shlomi Vaknin
1. Looking at the example phd client, we follow until the dither example
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/D44A121516B34FD2A42BCC6C6F3B5A1F%40HomeDesktop.
bw_msgboard
model says that when the client initiates an operation that will result in
settling activity, it should then monitor the settling events and react
accordingly. The settling might time out, it might complete successfully,
the star might be lost, etc. - the imaging app would want to know. That
normally means you keep the socket connection to PHD2 open while you get
those events. AFAIK, that's how all the other imaging apps work with PHD2.
If you're initiating dithers and StartGuiding commands but aren't paying
attention to the settling events, how do you know when to start the next
main camera exposure? So it strikes me as a little weird to think of
SettleDone as being a pre-condition to doing another dither operation - it
really is something you should be reacting to in real-time as a result of
the previous operation. All of this applies to StartGuiding as well,
anything that will result in settling activity.
I think it might be helpful for you to look at the reference implementations
that Andy did to see how all this is normally done.
That said, I'm not opposed to updating the documentation.
Bruce
This is something they will have to address, it isn't a problem when the
>
>
>
>
>
> --
>
> Brian
>
>
>
>
>
>
>
> Brian Valente
>
> portfolio brianvalentephotography.com
>
> --
> You received this message because you are subscribed to the Google Groups
"Open PHD Guiding" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to open-phd-guidi...@googlegroups.com.
>
> To view this discussion on the web visit
https://groups.google.com/d/msgid/open-phd-guiding/6248a12f-dbd1-4342-b81f-e
2312c0e1aeen%40googlegroups.com.
>
>
> You received this message because you are subscribed to the Google Groups
"Open PHD Guiding" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to open-phd-guidi...@googlegroups.com.
> To view this discussion on the web visit
dd868568f16n%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the
https://groups.google.com/d/topic/open-phd-guiding/EMWTXmQdiak/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
https://groups.google.com/d/msgid/open-phd-guiding/07F5B2EB-6A79-43E6-A963-5
B295BDECD05%40elemental.org.
bw_msgboard
Take a look at my earlier response to Dale. I think it makes more sense for the app to monitor the settling events in real-time, block new camera exposures and dithers until the SettleDone is received, analyze the associated conditions such as a timeout, and react appropriately. If this is done, the next camera exposure won’t be started prematurely and there really won’t be any reason a second dither or start-guiding command would be issued. PHD2 is running a state machine here and it seems like the imaging app would be doing the same thing. In that case, there’s no reason to think of ‘SettleDone’ as a pre-condition – it’s an event, not an externally reported state in PHD2.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CANyzh%3Dgg2BeHW2GnGm4kgf5kdxa07KCw%3Dc3v6RxNtFoJhniXXw%40mail.gmail.com.
Shlomi Vaknin
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/A70D73478F964D4189B34664F31BDC58%40HomeDesktop.
bw_msgboard
No, it’s not feasible for us to try to document the internals of PHD2, we have a hard enough time with end-user documentation and support. There generally isn’t a need to know and if someone is just curious, they should study the source code.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CANyzh%3DjHC_c9ijEwcszQfwTj%3D-6qBiO%2B5OECucEQ6zV0uttOSA%40mail.gmail.com.
Shlomi Vaknin
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/0883DC379BC8489E86C1C62EC53B8251%40HomeDesktop.
bw_msgboard
We don’t demand that anyone has to know about the state machines – there are many of them. We’ve documented the server interface and we’ve provided reference code for how to use it. If those aren’t clear, we will try to improve on them as time permits. Or better yet, you can. If you’ve become fixated on the state machine behind the event-server interface, that is implemented in phdcontrol.cpp.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CANyzh%3Dg23ocmRqCCd0cDqs4cq-_A%2BV_vGKqKnNP-_fYconRmdQ%40mail.gmail.com.
Shlomi Vaknin
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5012DC3C22F54AB790E45927249A3B69%40HomeDesktop.
Dale Ghent
Hi Bruce,
I think the issue here is that this is a case of us taking the Event API documentation the wiki at face value and implementing our client to the extent that it spells things out. The very good insight provided by you (thank you!) in this thread has filled in the critical missing gaps that we need to fix things, but this info should really, really, *really* be in that API document. In this post-mortem, I would like to point out 2 places where we tripped up and can be improved:
* The current description of the Settle parameter states[1]:
"The SETTLE parameter is used by the guide and dither commands to specify when PHD2 should consider guiding to be stable enough for imaging."
The "...for imaging" part is key there, as it implies that we ought to wait for such operations to complete SettleDone be signaled before resumption of imaging, which we already do. While the need for that is clear and very self-evident, the need for SettleDone to have occurred for other commands, such as dither, to even be issued successfully is -not-. It can't even be implied because this opening sentence in the description of Settle comes across as explicit in its intended use.
* The error message that people have been getting due to a dither being ordered when the state is not settled does not indicate the true cause of the errored state. In fact, it appears to point at something unrelated, and in a contradicting way:
"ERROR: Cannot initiate dither while guide is in progress"
It's clear now that the API documentation should elucidate much more about these behaviors and expectations than it currently does. We came at this as app developers external to PHD2 who lack the carnal knowledge about the API that you do. So from our point of view, there is kind of an expectation that if there is documentation for an API, it's more or less complete or at the very least clearly spells out any expectations and limits around its use. To know what you told us would not only require a developer to read the API doc, but to also mine through years of mailing list threads and connect any remaining dots by reading copious amounts of source code. Sure, questions could have been asked, but one can't ask about what one don't even know about. Andy's client reference code is great and I really appreciate that it's there now, but I must point out that a link to his personal repo, where it resides, was put into the wiki only just last year, well after the PHD2 client code went into NINA.
I'd like to help fill in the missing info in the API documentation but I fear that, even after this discussion, I would still be unprepared to describe it fully and accurately.
[1] https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring#settle-parameter
Stefan B
Dither is already waiting for the SettleDone event. However it looks like the start of guiding was not, as I was under the impression that PHD2 only switches to the guiding app state when it is settled. I will add a fix to this to Wait for Settling prior to commanding a guide or dither command as well as waiting for settling after those commands were sent. Hopefully this will prevent any of the issues that are described by the OP
bw_msgboard
and see what we can do to improve the documentation and provide a less
generic error message if the problem arises.
Let us know if you run into additional problems.
Cheers,
F9B8B495397%40elemental.org.
bw_msgboard
Hi guys. Just to tie this off, there’s a pretty easy way to use the PHD2 debug log file to see the traffic between your app and PHD2. You just do a text-search for ‘evsrv’ and you’ll get a nice history of what happened during the session. Here’s a partial example:
01:25:10.586 635.081 6972 evsrv: cli 0688D0C8 connect
01:25:10.586 00.000 6972 evsrv: cli 0688D0C8 request: {"method":"guide","params":[{"pixels":1,"time":10,"timeout":40},false],"id":3}
01:25:10.596 00.000 6972 evsrv: cli 0688D0C8 response: {"jsonrpc":"2.0","result":0,"id":3}
01:25:25.629 00.270 6972 evsrv: cli 0688CD08 request: {"method":"get_pixel_scale","id":1}
01:25:25.629 00.000 6972 evsrv: cli 0688CD08 response: {"jsonrpc":"2.0","result":1.04744,"id":1}
01:25:28.940 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612859128.940,"Host":"ANZA-DOME","Inst":1,"Distance":0.52,"Time":0.0,"SettleTime":10.0,"StarLocked":true}
01:25:32.060 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612859132.060,"Host":"ANZA-DOME","Inst":1,"Distance":0.47,"Time":3.1,"SettleTime":10.0,"StarLocked":true}
01:25:34.861 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612859134.861,"Host":"ANZA-DOME","Inst":1,"Distance":0.45,"Time":5.9,"SettleTime":10.0,"StarLocked":true}
01:25:37.351 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612859137.351,"Host":"ANZA-DOME","Inst":1,"Distance":0.47,"Time":8.4,"SettleTime":10.0,"StarLocked":true}
01:25:39.912 00.000 6972 evsrv: {"Event":"SettleDone","Timestamp":1612859139.912,"Host":"ANZA-DOME","Inst":1,"Status":0,"TotalFrames":5,"DroppedFrames":0}
01:25:41.912 02.000 6972 evsrv: cli 0688D0C8 disconnect
01:56:08.875 00.030 6972 evsrv: cli 0688D528 connect
01:56:08.885 00.000 6972 evsrv: cli 0688D528 request: {"method":"dither","params":[6,false,{"pixels":1,"time":10,"timeout":40}],"id":2}
01:56:08.895 00.000 6972 evsrv: cli 0688D528 response: {"jsonrpc":"2.0","result":0,"id":2}
01:56:11.346 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612860971.346,"Host":"ANZA-DOME","Inst":1,"Distance":2.75,"Time":0.0,"SettleTime":10.0,"StarLocked":true}
01:56:14.407 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612860974.407,"Host":"ANZA-DOME","Inst":1,"Distance":0.18,"Time":0.0,"SettleTime":10.0,"StarLocked":true}
01:56:16.947 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612860976.947,"Host":"ANZA-DOME","Inst":1,"Distance":0.23,"Time":2.5,"SettleTime":10.0,"StarLocked":true}
01:56:19.488 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612860979.488,"Host":"ANZA-DOME","Inst":1,"Distance":0.26,"Time":5.1,"SettleTime":10.0,"StarLocked":true}
01:56:22.038 00.000 6972 evsrv: {"Event":"Settling","Timestamp":1612860982.038,"Host":"ANZA-DOME","Inst":1,"Distance":0.33,"Time":7.6,"SettleTime":10.0,"StarLocked":true}
01:56:24.588 00.000 6972 evsrv: {"Event":"SettleDone","Timestamp":1612860984.588,"Host":"ANZA-DOME","Inst":1,"Status":0,"TotalFrames":6,"DroppedFrames":0}
01:56:26.589 01.931 6972 evsrv: cli 0688D528 disconnect
02:06:38.182 00.030 6972 evsrv: cli 0688D528 connect
02:06:38.192 00.000 6972 evsrv: cli 0688D528 request: {"method":"stop_capture","id":"4"}
02:06:38.192 00.000 6972 evsrv: cli 0688D528 response: {"jsonrpc":"2.0","result":0,"id":"4"}
02:06:38.192 00.000 6972 evsrv: cli 0688D528 disconnect
02:09:46.591 187.859 6972 evsrv: cli 0688D528 connect
This happens to show a sequence of start guiding, then a dither about 30 minutes later, then a disconnect at the end of the image sequence.
This might make it easier for you to support your users if they get tangled up with dithering and settling – our experience is that many users are confused by how this works.
Bruce
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/8bd95ad4-635e-48a9-a873-fd723500ad10n%40googlegroups.com.