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

Re: [ASCOM] Meade Driver Creation Help

Expand Messages
  • Chris Rowland
    ... You are calling your driver through DriverAccess and that only implements the ITelescopeV3 properties and methods, it doesn t have your method so it fails.
    Message 1 of 9 , Apr 1 2:17 PM
    View Source
    • 0 Attachment
      On 01/04/2012 12:32, yodie.geo wrote:
      > Actually, scratch what I said about calling custom functions.
      >
      > Here is my problem.
      >
      > I create the following function in the driver.cs file.
      >
      > public string ROM
      > {
      > get
      > {
      > char[] charsToTrim = { '#', '+' };
      > string rom = CommandString(":GVN#", true);
      > rom = rom.TrimEnd(charsToTrim);
      > return rom;
      > }
      > }
      >
      > I place it in the ITelescopeV3 Members region.
      >
      > Then from my "TestFormApplication" I create an instance of the driver with:
      >
      > driver = new ASCOM.DriverAccess.Telescope(Properties.Settings.Default.DriverId);
      >
      > and I am able to call all my functions nicely with commands like:
      >
      > txtElevation.Text = driver.SiteElevation.ToString();
      >
      > However, the function ROM that I created can't be called. VS says that:
      >
      > 'ASCOM.DriverAccess.Telescope' does not contain a definition for 'ROM' and no extension method 'ROM' accepting a first argument of type 'ASCOM.DriverAccess.Telescope' could be found (are you missing a using directive or an assembly reference?)
      >
      > I am missing something I am sure . . .

      You are calling your driver through DriverAccess and that only
      implements the ITelescopeV3 properties and methods, it doesn't have your
      method so it fails. Your driver never gets the call.

      The SupportedActions/Action stuff is intended for this, so
      SupportedActions returns an ArrayList containing the string "ROM", then
      Action(string actionName,... contains code to identify your command and
      return the data, such as:

      switch(actionName)
      {
      case "ROM":
      char[] charsToTrim = { '#', '+' };
      string rom = CommandString(":GVN#", true);
      rom = rom.TrimEnd(charsToTrim);
      return rom;
      default:
      throw new ASCOM.ActionNotImplementedException(actionname);
      }

      Hope that makes sense.

      Bear in mind that no other application than yours will use this command,
      however it might be possible to come up with some more generic method
      name that other drivers could also implement, such as ControllerVersion.

      Chris

      >
      > Todd
      >
      >
      >
      >
      >
      >
      >
      > --- In ASCOM-Talk@yahoogroups.com, "Tim Long"<Tim@...> wrote:
      >>
      >> It may help to use a metaphor to understand the role of an ASCOM driver.
      >> They are similar in many ways to Windows Printer Drivers. The
      >> controlling program (be it Microsoft Word, or Notepad or whatever)
      >> wishes to print the letter "A", so it calls the drivers command for
      >> printing a text string and passes in "A". The driver is then responsible
      >> for implementing that request. How does it print an "A"? Well that
      >> depends on what type of printer it is. It may involve spinning a
      >> daisywheel to the correct position and then activating a striker
      >> solenoid, or it might involve firing lots of little needles against a
      >> ribbon while moving a head along the carriage, it might involve calling
      >> a PostScript routing to scale a vector font, or activating a laser beam
      >> to deposit a charge onto a photostatic drum.
      >>
      >> The controlling program knows nothing about the printer hardware. All it
      >> knows is that it has paper of a certain size available and it has asked
      >> for an "A" to be printed. The job of the printer driver is to do
      >> whatever is necessary to fulfil the application's request. The printer
      >> driver has hardware-specific knowledge, the high level application has
      >> no hardware knowledge.
      >>
      >> ASCOM drivers are similar. Applications know nothing about how
      >> telescopes work. The application asks to "Point at these coordinates"
      >> and it's the job of the ASCOM driver to do whatever is necessary to meet
      >> that request, by translating it to commands that the telescope
      >> understands. It's up to you - the driver writer - to provide that logic.
      >>
      >> When you say " I've tried adding custom methods to this section like
      >> public string GetROMVersion() . . . but it won't let me add it " - that
      >> makes no sense to me. What is "it" and how is "it" preventing you from
      >> adding your code?
      >>
      >> --Tim Long
      >>
      >> Regards,
      >> Tim Long
      >>
      >>
      >>> -----Original Message-----
      >>> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
      >>> Talk@yahoogroups.com] On Behalf Of yodie.geo
      >>> Sent: 27 March 2012 16:07
      >>> To: ASCOM-Talk@yahoogroups.com
      >>> Subject: [ASCOM] Meade Driver Creation Help
      >>>
      >>> So, I am having a bit of trouble wrapping my mind around the process
      >> for
      >>> writing an ASCOM driver file . . .
      >>>
      >>> I have created an app in C# (stand alone) that does everything I want
      >> to do
      >>> with controlling my scope. I have all the serial commands, I am
      >> managing
      >>> the COM port, sending the commands, receiving the responses and
      >>> populating the GUI with the returned values.
      >>>
      >>> Now, I want to incorporate it into ASCOM.
      >>>
      >>> I've been through the tutorials, and looked at a ton of example code.
      >>>
      >>> I've got a driver started for my RCX400 (basicaly the same as the
      >> LX200GPS/R
      >>> driver with a bunch of extra stuff) that allows me to pick my scope
      >> from the
      >>> chooser, connect to my scope, and with a Test Console Application, I
      >> have
      >>> verified that I am connected to my scope, and recieving data. I sent a
      >>> command to tell me the ROM version of my AutoStar, and it returned the
      >>> correct value.
      >>>
      >>> Good. It works, in that regard.
      >>>
      >>> What I don't understand is this ITelescopeV3 section. Here are my
      >> questions.
      >>>
      >>> Where can I find the settings for all of these things that are related
      >> to my
      >>> scope? Are these answers hard-coded? Do I place the serial command
      >> to
      >>> park the scope in the public void SetPark() function? One of the
      >>> example/tutorials said that I need to check the ASCOM standards for my
      >>> scope type, but I can't seem to find them. Or do they mean the list
      >> of serial
      >>> commands for my scope. That, I have. But things like, public bool
      >>> CanSetRightAscentionRate . . . do I hard code that to true if I have
      >> that
      >>> functionality?
      >>>
      >>> ANd then there are functions in there like the following:
      >>>
      >>> public void SlewToCoordinates(double rightAscension, double
      >>> declination)
      >>> {
      >>> targetDeclination = declination;
      >>> targetRightAscension = rightAscension;
      >>> SlewToTarget();
      >>> }
      >>>
      >>>
      >>> public void SlewToTarget()
      >>> {
      >>> rightAscension = targetRightAscension;
      >>> declination = targetDeclination;
      >>> }
      >>>
      >>> I understand both of these methods, but at what point is the command
      >> sent
      >>> to the telesopce to actually "MOVE". At some point, the scope needs
      >> the
      >>> correct serial command to move, but where is this done?
      >>>
      >>> Also, I've tried adding custom methods to this seciton like public
      >> string
      >>> GetROMVersion() . . . but it won't let me add it.
      >>>
      >>> Thanks for any help, and for not flaming me!
      >>> Todd
      >>>
      >>>
      >>>
      >>>
      >>> ------------------------------------
      >>>
      >>> For more information see http://ASCOM-Standards.org/.
      >>>
      >>> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
      >>> USED TO SUBSCRIBE(!) to:
      >>> ASCOM-Talk-unsubscribe@yahoogroups.com
      >>>
      >>> Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>
      >> --
      >> ExchangeDefender Message Security: Click below to verify authenticity
      >> http://www.exchangedefender.com/verify.asp?id=q2S2oBrv021354&from=tim@...
      >> Complete email hygiene and business continuity solution available from http://www.tigranetworks.co.uk
      >>
      >
      >
      >
      >
      > ------------------------------------
      >
      > For more information see http://ASCOM-Standards.org/.
      >
      > To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED TO SUBSCRIBE(!) to:
      > ASCOM-Talk-unsubscribe@yahoogroups.com
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Todd Wessendorf
      Chris, thanks for taking the time to explain this for me. This really clears things up. I am now able to call my custom functions. However, I am missing the
      Message 2 of 9 , Apr 4 7:30 AM
      View Source
      • 0 Attachment
        Chris, thanks for taking the time to explain this for me.  This really clears things up.

        I am now able to call my custom functions.

        However, I am missing the need/purpose of the SupportedActions function.

        I am populating text fields using . . .

        txtRomVersion.Text = driver.Action("ROM", ":GVN#");

        to set the value of a text field, but not sure where the SupportActions list comes into play .  . ..

        Todd

        On Sun, Apr 1, 2012 at 5:17 PM, Chris Rowland <chris_group_mail@...> wrote:


        You are calling your driver through DriverAccess and that only
        implements the ITelescopeV3 properties and methods, it doesn't have your
        method so it fails. Your driver never gets the call.

        The SupportedActions/Action stuff is intended for this, so
        SupportedActions returns an ArrayList containing the string "ROM", then
        Action(string actionName,... contains code to identify your command and
        return the data, such as:

        switch(actionName)
        {
          case "ROM":
            char[] charsToTrim = { '#', '+' };
            string rom = CommandString(":GVN#", true);
            rom = rom.TrimEnd(charsToTrim);
            return rom;
          default:
            throw new ASCOM.ActionNotImplementedException(actionname);
        }

        Hope that makes sense.

        Bear in mind that no other application than yours will use this command,
        however it might be possible to come up with some more generic method
        name that other drivers could also implement, such as ControllerVersion.

        Chris

      • Chris
        ... This is described in the driver interface documentation; it gives the user a list of the actions that are supported. I ve implemented it as: ArrayList
        Message 3 of 9 , Apr 4 1:55 PM
        View Source
        • 0 Attachment
          --- In ASCOM-Talk@yahoogroups.com, Todd Wessendorf <todd.wessendorf@...> wrote:
          >
          > Chris, thanks for taking the time to explain this for me. This really
          > clears things up.
          >
          > I am now able to call my custom functions.
          >
          > However, I am missing the need/purpose of the SupportedActions function.

          This is described in the driver interface documentation; it gives the user a list of the actions that are supported.

          I've implemented it as:
          ArrayList actions = new ArrayList( new String[]{ "Dome:SlewContinuously", "Dome:Heading", "Dome:CompassVolts" } );

          public System.Collections.ArrayList SupportedActions
          {
          get { return actions; }
          }

          then the application has something like:

          if (device.SupportedActions.Contains("Dome:Heading"))
          txtHeading.text = driver.Action("Dome:Heading");

          It stops a crash if the driver doesn't support the action.

          Chris

          >
          > I am populating text fields using . . .
          >
          > txtRomVersion.Text = driver.Action("ROM", ":GVN#");
          >
          > to set the value of a text field, but not sure where the SupportActions
          > list comes into play . . ..
          >
          > Todd
          >
          > On Sun, Apr 1, 2012 at 5:17 PM, Chris Rowland <
          > chris_group_mail@...> wrote:
          >
          > >
          > >
          > > You are calling your driver through DriverAccess and that only
          > > implements the ITelescopeV3 properties and methods, it doesn't have your
          > > method so it fails. Your driver never gets the call.
          > >
          > > The SupportedActions/Action stuff is intended for this, so
          > > SupportedActions returns an ArrayList containing the string "ROM", then
          > > Action(string actionName,... contains code to identify your command and
          > > return the data, such as:
          > >
          > > switch(actionName)
          > > {
          > > case "ROM":
          > > char[] charsToTrim = { '#', '+' };
          > > string rom = CommandString(":GVN#", true);
          > > rom = rom.TrimEnd(charsToTrim);
          > > return rom;
          > > default:
          > > throw new ASCOM.ActionNotImplementedException(actionname);
          > > }
          > >
          > > Hope that makes sense.
          > >
          > > Bear in mind that no other application than yours will use this command,
          > > however it might be possible to come up with some more generic method
          > > name that other drivers could also implement, such as ControllerVersion.
          > >
          > > Chris
          > >
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.