1. Stefan B Avatar Stefan B
  2. nina
  3. NINA
  4. Issues

1.11.49: Cannot connect ASCOM Focuser (Baader SteelGo II)

Issue #786 resolved
Ruediger created an issue

Hi,

NINA cannot connect to focuser Baader SteelGo II. Other tools can connect (e.g. APT or ASCOM Device Hub).
Current workaround: Connect via ASCOM Device Hub.

Log attached.

Cheers
Rüdiger

‌

Comments (18)

  1. Dale Ghent

    Nothing telling in the logs other than the driver seemingly disconnecting itself. Can you look under the Documents\ASCOM\<date> for a possible log file from the Baader ASCOM driver itself?

  2. Stefan B repo owner

    Most likely the focuser does not immediately indicate true for connection state after setting it and Nina will think it lost connection.i will add more logs to indicate this.

  3. Ruediger reporter

    @Dale: Unfortunately there is no log.
    @Stefan: That's true. The driver needs also in native control SW upto 10 (sometimes more) seconds to connect. As soon as there a connect try, it starts a background process which serves as mid-tear. This takes some time to start. Also there are lot of parameters of the controller to query internally. So it is not quickly answering an connect try.
    Maybe this could be solved by simply raise the time-out threshold.

  4. Stefan B repo owner

    This is an interesting problem and depends on how the ASCOM specs expect this to work. We had a similar discussion about a similar problem in regards to Dome Shutter Status that wasn’t directly updated after a call to OpenShutter()

    According to the guys at ASCOM the status had to be updated immediately, otherwise it was considered a driver issue. In my opinion the same principle applies here. When we set “Connected” to true, and there is no error on the call, having the device return “false” afterwards is unexpected.
    See here: https://ascomtalk.groups.io/g/Developer/topic/dome_shutterstate_timing/80764828?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80764828 and https://ascom-standards.org/Developer/Principles.htm

    If you don’t agree, I can open a discussion on the ASCOM board to clarify what the correct behavior is and if this should be handled by NINA or by the Driver.

  5. Ruediger reporter

    Hi Stefan, my opinion is not relevant, since I have to live with driver I have. I doubt the developer will change it. And not in near future at all.

    Interesting is, that the ASCOM Device Hub has no issue at all. Since it follows (or better should) the ASCOM standards it is quite strange. Either they do no follow their own standards, or it is another issue.

  6. Ruediger reporter

    Hi Stefan,
    I have contacted the SW creator via Baader. There wont be any change in response time, due to architectural concepts. They are starting a service, watchdogs, stateless messaging queues and much more, This is a completely sophisticated framework which will always require some time to start.

    I have rechecked in latest nightly 053. Via Hub ok, but directly it throws instantly an error.

    ‌

    2021-03-05T11:00:14.3500|DEBUG|AscomFocuserProvider.cs|GetFocuser|28|Absolute ASCOM Focuser detected ASCOM.SteelDriveII.Focuser
    2021-03-05T11:00:29.3877|INFO|FocuserVM.cs|Disconnect|332|Disconnected Focuser
    2021-03-05T11:00:34.7896|DEBUG|AscomFocuserProvider.cs|GetFocuser|28|Absolute ASCOM Focuser detected ASCOM.SteelDriveII.Focuser
    2021-03-05T11:00:34.7985|DEBUG|AscomDevice.cs|Connected|115|SteelDrive II - Try SET Connected to True
    2021-03-05T11:00:34.8095|ERROR|AscomDevice.cs|Connected|95|SteelDrive II should be connected=True but reports to be connected=False
    2021-03-05T11:00:34.8145|DEBUG|AscomDevice.cs|Connected|115|SteelDrive II - Try SET Connected to False
    2021-03-05T11:01:33.6257|INFO|FocuserVM.cs|Disconnect|332|Disconnected Focuser

    2021-03-05T11:01:36.3859|DEBUG|AscomFocuserProvider.cs|GetFocuser|28|Absolute ASCOM Focuser detected ASCOM.DeviceHub.Focuser
    2021-03-05T11:01:36.3909|DEBUG|AscomDevice.cs|Connected|115|Device Hub Focuser - Try SET Connected to True
    2021-03-05T11:01:36.4129|INFO|FocuserVM.cs|ChooseFocuser|238|Successfully connected Focuser. Id: ASCOM.DeviceHub.Focuser Name: Device Hub Focuser Driver Version: 6.5
    2021-03-05T11:05:18.6489|DEBUG|AscomDevice.cs|Connected|115|Device Hub Focuser - Try SET Connected to False

  7. Dale Ghent

    My opinion on this is the drivers’s Connect property must block until it is finished connecting to the hardware and then set itself to true. The ASCOM spec does not specify that there must be a period of time allowed for a driver to reflect the client’s wishes. The setting of the Connect property to true must end in either that happening, or an exception. There is no allowance for a period of ambiguity between requesting that the hardware be connected and reflecting that it is.

  8. Ruediger reporter

    Hi Dale,

    I will forward your reply to the SW producer.

    The only thing that makes me wondering is why the ASCOM Hub has no problem at all. 🤔

    Cheers Rüdiger

  9. Dale Ghent

    Devicehub does have a 10 second wait for the Connect setting to reflect its wishes:

    https://github.com/ASCOMInitiative/ASCOMDeviceHub/blob/e779c3d5af305ebc25c9dba076b3b7053c64d17c/DeviceHub/DeviceManagers/FocuserManagerAccess.cs#L148

    However this is a special dispensation on its part. At the end of the day, the ASCOM specification itself prescribes no requirement on the client for this type of wait period when setting theConnected property. This means that a driver author should never rely on a mechanism being present that is not advised or specified by the specification. The setting of the driver’s Connected property should therefore block and finish with either the setting of the requested value (true or false) or emit an appropriate exception if it is unable to complete the request. The ASCOM focuser class documentation is here:

    https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Focuser.htm

    I would like to note that this is the first driver of any sort (focuser, telescope, etc.) that we have encountered that demands this peculiar requirement of a wait period.

  10. Stefan B repo owner

    The best way to clarify this, will be through the ASCOM mailing list. I will post a new topic there and check what the driver has to do in this case and if this is correct or incorrect behavior.

  12. Ruediger reporter

    Hi Stefan, Hi Dale,
    the latest Nightly (and also the version before) can successfully connect to the Focuser. I think this issue is solved.

    So close it. Thanks for your help!

    Cheers
    Rüdiger

    ‌

    ‌

  15. Ruediger reporter

    Hi Stefan,

    got a feedback from my Baader contact and they are interested what has been changed, because they want to forward the information to the SW developer in order to fix the issue also on the driver side. Can you give any hint which I could forward or please post here - they are reading this issue here also.

    Thx!
    Rüdiger

    ‌

  16. Stefan B repo owner

    Well I too am surprised that it is working now, as the only thing that I have changed is to unify the connection code for all ascom devices to follow one code path. The overall connection logic should still be the same.

  17. Ruediger reporter

    That’s really strange. I have just re-tested and it works. Not only showing “connected” but also the commands are executed from the motor as expected.

  19. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
resolved
Component
User Interface
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!