Loading ...
Sorry, an error occurred while loading the content.

ASCOM romote control?

Expand Messages
  • hamed_ascom
    Hi, How can we use ASCOM for remote control of astronomical devices? Suppose that you have written an ASCOM code in VBScript or JavaScript. These languages are
    Message 1 of 3 , Apr 4, 2005
    • 0 Attachment
      Hi,
      How can we use ASCOM for remote control of astronomical devices?
      Suppose that you have written an ASCOM code in VBScript or JavaScript.
      These languages are usually used for client side programming. How used
      them for "Server side" programming? Is there any solution other
      than "DCOM" for calling a ASCOM script remotely?

      Thanks in advance
    • Bob Denny
      Hamed -- Your question is vast --- remotely controlling instruments is complex, and requires more than just drivers. DCOM is not recommended by Microsoft -
      Message 2 of 3 , Apr 13, 2005
      • 0 Attachment
        Hamed --

        Your question is "vast" --- remotely controlling instruments is complex,
        and requires more than just drivers. DCOM is not recommended by Microsoft -
        it was a bad ides. They now recommend you turn DCOM off in your Windows
        system if at all possible.

        Plus, remoting individual instruments, mounts, etc. is not the most robust
        way to provide remote imaging. What if yo lose the net connection in the
        middle of a run? Better to provide web pages that let you specify what
        images to take and where, and let an autonomous system at the observatory
        do the work, internet or not. At least tnat is MY opinion.

        Remoting object calls is generally done using Simple Object Access
        Protocol, and extension of HTTP and XML. There are many many places on the
        net that describe SOAP, etc.

        What sort of "server" are you envisioning?

        -- Bob
      • hamed_ascom
        Dear Bob Thanks for your answer. I am sorry for answering late. During the last month I was really busy and besides that no one answered to my question for
        Message 3 of 3 , May 6, 2005
        • 0 Attachment
          Dear Bob

          Thanks for your answer. I am sorry for answering late. During the
          last month I was really busy and besides that no one answered to my
          question for about 3 weeks ( this disappointed me a little because
          it seemed that I had asked a silly question ļ )

          I know that remote observation is really complex and besides
          programming, many other things should be considered. (I have studied
          the article named "Remote Observatory Handbook" form homedome.com,
          It is a nice article), but "remote control" is really attractive for
          me. Although the real-time control is more complex and may be more
          error-prone, but the sense of "real-time control" excite me a lot.

          I think that "automated observation" is an "open-loop" control. If
          you make a mistake in your script, it can not be fixed at run time.
          What happens if the weather is semi cloudy? In real-time control,
          the human can slew the telescope to an object not covered by clouds,
          scripts can not do that. ("Artificial Intelligence" and "Machine
          Vision" are improving rapidly; In the future we may have "smart
          scripts"!)

          In real-time control you may lose the net connection, but if you
          use "fault tolerance" techniques (for example doubling the
          communication line) and prevent connection failures, the "close-
          loop" control let you to fix some errors remotely and let you adapt
          your system to the environment faster. For example if some thing is
          going wrong with your instruments (as an example CCD camera wires
          are twisting around the telescope) you can immediately stop the
          system. Of course in real-time control, the limited bandwidth of the
          network is it self a problem. Besides that TCP/IP protocol, which is
          the most widespread protocol, does not guarantee the quality of
          service and problems like congestion and long delays may happen.

          In the future I will buy ACP and use its great capabilities (I have
          recently spend 7000$ for buying telescope and its accessories and I
          should save about 2000$ more for buying this nice software), so know
          I prefer to write my own client/server program via ASCOM.

          I'm studding about COM, SOAP, Remote Scripting, etc but I'm still at
          the beginning of my way ļ

          At the moment, I'm not sure about the server but I think I will use
          IIS4 and windows 2000 server.

          Sorry for this long letter. Wish to hear from you soon.

          Best regards;
          Hamed



          --- In ASCOM-Talk@yahoogroups.com, Bob Denny <rdenny@d...> wrote:
          > Hamed --
          >
          > Your question is "vast" --- remotely controlling instruments is
          complex,
          > and requires more than just drivers. DCOM is not recommended by
          Microsoft -
          > it was a bad ides. They now recommend you turn DCOM off in your
          Windows
          > system if at all possible.
          >
          > Plus, remoting individual instruments, mounts, etc. is not the
          most robust
          > way to provide remote imaging. What if yo lose the net connection
          in the
          > middle of a run? Better to provide web pages that let you specify
          what
          > images to take and where, and let an autonomous system at the
          observatory
          > do the work, internet or not. At least tnat is MY opinion.
          >
          > Remoting object calls is generally done using Simple Object Access
          > Protocol, and extension of HTTP and XML. There are many many
          places on the
          > net that describe SOAP, etc.
          >
          > What sort of "server" are you envisioning?
          >
          > -- Bob
        Your message has been successfully submitted and would be delivered to recipients shortly.