When doing flips how much time does SGP give the driver to report it’s slewing? my driver might have some ms timing issues with this. Below is from a client log and I can’t tell if it’s 1100 ms or 100 ms. If it’s real short would it me possible to delay this a few ms more? I don’t remember if ascom says how quick to report this but a few ms more would be great and I don’t think it would hurt other drivers.
[03/01/20 01:32:10.333][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: Waiting until pier side changes…
[03/01/20 01:32:11.335][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: Side of pier changed, waiting for scope to report it’s done slewing…
Looks as if the driver is broken. IsSlewing shouldn’t report that the slew has finished until it has finished. If the hardware takes time for the slew to start this should be handled in the driver.
IsSlewing shouldn’t report that the slew has finished until it has finished
was talking about the starting time.
If the hardware takes time for the slew to start this should be handled in the driver.
I was looking to know how quick it was checking. When the slew request comes in I do a few checks first before initialing the slew. Possible the call isn’t give me any time at all to do the checks?
Not sure I understand. A slew command followed immediately by an IsSlewing check should return true. The only reason not to from the driver’s perspective would be when the slew command failed and the driver threw an exception or possibly if the mount was already at the correct position.
The time between a successful return of a slew command and a call to IsSlewing returnng true could be zero.
The log fragment you posted doesn’t show the commands to the mount so it isn’t possible to see exactly what commands are being sent to the mount and what the replies are. The mount driver log could be helpful as it would give the order of commands from the driver’s perspective.
I think SGP is calling the SlewToCoordinatesAsync and I’m simply not setting the Slewing flag fast enough because I do checks to see if it’s already slewing, stopped, parked, etc… So I could possible delay the return but was curious if SGP had any delays before checking if the slew started. NINA has a 1 second delay before checking and then waits out the flip to finish. From the log below I was trying to see if SGP has something similar, but there isn’t enough info to tell.
Tonight I’ll make some details logs from my driver to see all calls.
I think what Chris is telling you is that before SlewToCoordinatesAsync returns from the driver the slewing flag should already be set. That will preclude any possible timing issue. Whether or not the mount has actually started to move is immaterial. If during your checks you find that the slew can’t be started then you can clear the flag. Even though it is an async operation, the flag must be set before returning even if the mount has not started to move.
Yup, but SGP using SlewToCoordinatesAsync was just a guess on my part as there are other ways to do the same and I didn’t think ascom says that the flag should be set before it returns. Could be, I just didn’t see it listed. Anyway was just trying to find out how SGP works so I’ll just do some logs and figure it out. thanks.
The only time we use the Async variant is when there is a manual slew to a target. All other times we use the blocking variant and wait for it to return (at least in the telescope thread…SGP still does other things while that is happening). We typically expect that SlewToCoordinates will block (as there is an Async method if you don’t want that blocking behavior). However if it does not block we check IsSlewing immediately after the Slew returns and will block until that is false.
We try not to use delays unless absolutely necessary, that just adds time where it shouldn’t be needed. Basically we expect either SlewToCoordinates to block or IsSlewing to be true immediately when SlewToCoordinates exits if the scope is going to invoke a slew.
After comparing my log this may be a bit more complicated than I thought… Can one of you open the SGP log I posted in an earlier message and tell me what happened? It looks like the SOP didn’t change but it reports SOP as West at the top and later it changes to East but the error and says it didn’t change?
Best I can tell is that it reported East and then we asked it again and it reported West.
int pierSideStart = (int)tel.SideOfPier;
... pier flip code
if (pierSideStart == (int)tel.SideOfPier){
Logger.debugln("ASCOM Telescope: Failed to flip because starting pier side and ending pier side are the same!");
}
Guess I dont understand as I see ‘ASCOM Telescope: Pier side is West’ listed first then a ‘Setting Pier East’ and about a second later says ASCOM Telescope: Pier side is East.
So it checks for slewing after it setting SOP. When false it checks SOP again for the validation?
What I’m guessing happens, based on the very close timestamps:
SGP sets pier side to East
SGP asks for pier side and Driver says “East”
SGP asks if the mount is slewing…it says “No”
SGP assume pier flip has completed based on East and “Not Slewing”
SGP checks to make sure mount is on the expected side
Driver says mount is on West side
SGP Fails Pier Flip
Based on all that I assume:
1 - Meridian flip did not happen
2 - Driver incorrectly reports pier side of East when it is actually on the West (probably cached in the driver?)
3 - Driver eventually asks hardware what pier side it is on (maybe as part of an update loop?) and driver reports West.
Seems like pier side is getting cached in the driver. Might also be a good idea to run the driver through Conform.
Did find out the user was using the new ascom device hub so that may have added to the problem.
1 - actually the flip did complete but SGP failed long before it completed.
2 - no caching as each request is calculated based on position.
The driver passes Conform in N and S Hemi configurations
I’m back to thinking SGP picked up no slewing and then checked SOP again and because of the short timestamp SOP hadn’t changed yet.
oh well, thanks for at least trying to help me.
–Rob
As Jared says, from the SGP perspective there is a very short slew and the pier side has not changed. All that SGP has to go on is what commands it sends to the driver and what the response is.
This could be because the slew was commanded before the driver was at the position where a slew caused a flip. In that case a correct slew would take very little time, the mount would barely move and the pier side would remain the same.
Or it could be that the driver was asked to do a synchronous slew but returned early, before the slew had completed. SGP asks for the pier side, and because the mount has barely moved, the pier side has not changed. So while your mount is moving to the other pier side SGP thinks it hasn’t moved. All sorts of undesiranble behaviour could result.
We can’t tell which of these is the case because we can’t see what is happening. You should be able to look at what is actually happening. Does the mount do a pile flip at the time when SGP thinks it hasn’t?
The mount logs (NOT the SGP logs) should show what the mount thinks is going on and the times in these logs can be correlated with the times in the SGP logs.
Jared says that the slews are synchronous, this means that it is up to the driver to manage checking when the slew finishes. It is not up to anyone else but the driver author to ensure this.
Do I understand that this is your driver? Written by you? That gives you a huge advantage as you don’t need to convince anyone else of this problem to get it fixed in the driver.
Do I understand that this is your driver? Written by you?
Yes, this in my driver
Or it could be that the driver was asked to do a synchronous
Don’t know and that’s why I asked in the first place. I figured from the SGP log someone could tell me what calls SGP was making for the flip and the criteria used to fail. Now, from my logs, my driver is now being to do is a set_PierSide. I still can’t tell why it failed, maybe SGP is checking for the SOP to change, maybe is waiting on Slewing to change to false, Maybe it’s doing both, don’t know as I see calls for both. I know what the driver and mount is doing but that really doesn’t matter. What matters is what made SGP fail so I can fix it. The SGP log makes it look like it first check was for the SOP to change then it waits for the Slewing to stop, but this doesn’t seem to be the case. Now, it seems to checks for the slewing to stop and then is checks SOP to see if it changed, I still don’t know. I’m guessing SGP ran the set_PierSide and immediately starts checking the Slewing flag. When it turns false it checks SOP and saw it didn’t change and failed on that. I can see all the incoming calls but not sure which ones are SGP specific.
Because the flip takes time NINA put in a small delay before starting to check the Slewing flag to give the driver time to report the correct slewing state on a flip. This may not be appropriate for all slews. ascom doesn’t really define this very well, so drivers could report slewing when the actual hardware starts slewing, not when a call returns. It’s a bit subjective so some leeway maybe appropriate.
I don’t have the appropriate logs from the user to know for sure if this is what happened at the time. I’ve been conducting my own tests at home and the SGP flip works every time. I’ve been comparing SGP logs to the SGP log the user gave me and there just isn’t enough info there to know why it failed. Now the user also said they used the ascon device hub, which add another layer into things. I haven’t loaded the device hub yet, but was planning on checking it out. Maybe there some timing issue with it.
It should be easy to find out what is happening by looking at the logs that your driver provides.
If your user refuses to provide the logs that you need to sort this out then I think the best thing is to close their support ticket until they do. You should not be expected to guess. Guessing leads to incorrect fixes. It wastes your time. In this case Jared’s and my time as well.
I’ve had a lot of experience in debugging this sort of thing remotely, both for ASCOM and my day job. The impression I get is that some users (and service engineers) seem to think that the idea is to provide the bare minimum of information. On some occasions not even the type of equipment. It looks as if you weren’t told about the ascom hub. I don’t expect that would make a difference though.
All I think you can do is tell your user to provide logs from your driver showing you what is happening. There’s nothing more that can be done.
I always check out what might be potential problems no matter what the user says. I didn’t think it was a waste of time just asking how something works, dev to dev, but okay. Anyways, sorry for wasting your time and I’ll think twice before asking again.
I don’t personally see this as a waste of time. But it can be difficult to troubleshoot issues with limited information.
It seems like removing the device hub out of the equation should be a first step for the user. There is generally not a need for a hub and they typically just add issues and complication. Especially if this is something he can easily reproduce and you can’t. Other than that maybe firmware/driver versions…but I assume you’ve already gone that route.