Sorry for this blizzard of email on Buster's topic...

There's also a script in the ASCOM exchange (WebForm.js) that demonstrates
getting orbital elements for multiple numeric or designated objects from the
MPC. This script is VERY detailed, and includes an event handler that shows
you the progress of the connection. It synthesizes the data from an HTTP form
and feeds it to the unsuspecting MPC server, and gleans the orbital elements
from the HTTP response. This one is written in JScript, which for me at lease
is MUCH better at generating web form-encoded data and for chopping up the
results. Perhaps you can modify WebForm.js to suit your needs...

   -- Bob

Buster --

Er, here's the tiny script from the ASCOM script exchange:

----
dim web, buf
set web = CreateObject("InetCtls.Inet")
web.RequestTimeout = 360
buf = web.OpenURL("http://astron.berkeley.edu/~bait/weather/weatherd.dat")
WScript.Echo buf
----

Save in a file x.vbs. Double click this or run it in a command window

   cscript x.vbs

To run it in ACP's scripting console, wrap it in a Sub Main() and use ACP's
console (click the main() button to start) output method:

----
Sub Main()
  dim web, buf
  set web = CreateObject("InetCtls.Inet")
  web.RequestTimeout = 360
  buf = web.OpenURL("http://astron.berkeley.edu/~bait/weather/weatherd.dat")
  Console.PrintLine buf
End Sub
----

Needless to say, you'll have to do something more intelligent with the
contents of buf, which is the web page data (or whatever) that your URL
returns. After you futz with trying to extract data from HTML meant for
rendering for human viewing in a browser, you'll be closer to the reasons for
XML... :-)))

   -- Bob

Buster --

> Can someone point me to a good (preferably online) source of
> info on the Microsoft Internet Transfer [Control]?

The controls are not part of the language (thank heavens!!).

Splice this together in your browser for "the" reference info:

     http://msdn.microsoft.com/library/devprods/vs6/vbasic/
         vbcon98/vbconusinginternettransfercontrol.htm

I got this by going to http://msdn.microsoft.com/ and clicking the "Search
MSDN" link in the top-bar. This takes you to

     http://search.microsoft.com/us/dev/default.asp

which is a great thing to bookmark. Now click "Show Scope" and check only
"MSDN Library" for reference info. Check "Knowledge Base" for additional
articles full of useful info about the quirks (and there are planty) of the
ITC. Watch it, some of the KB articles are OLD and the problems they relate to
are fixed. I suggest you get Internet Exploder 5.5SP1. which carries a bunch
of useful operating system bugfixes in it.

Also, there is a tiny sample script on the ASCOM Script Exchange at

     http://ascom-standards.org/Exchange/scripts/GetWebData.vbs

which shows how to get stuff off a web server.

Please share your results with the rest of us, Buster. It's a cool idea to use
the MPC as a "server" in an automated fashion. So many cool things to try, so
little time...

   -- Bob

I have deleted that message from the archive.

--- In ASCOM-Talk@egroups.com, "Steven S Tuma" <stuma@i...> wrote:
> Notice, the code I just posted has the password to my FTP server in it.
> Please do not take advantage of this.
>
> Thanks

Notice, the code I just posted has the password to my FTP server in it.
Please do not take advantage of this.

Thanks

Steve

-------------------------------------------
If you like Deepsky 2000, please let other
people know.  Word of mouth advertising is
the primary means I use.

Steven S Tuma
Author, Deepsky 2000 Astronomy Software
http://www.deepsky2000.com
-------------------------------------------


-----Original Message-----
From: Buster Sikes [mailto:h2oape@...]
Sent: Tuesday, December 05, 2000 8:51 PM
To: ASCOM-Talk@egroups.com
Subject: [ASCOM] INET reference?


Hi all,

Can someone point me to a good (preferably online) source of info on the
Microsoft Internet Transfer Controls? I have some VBScript info but can't
find
anything in them about this.

I'd like to be able to extract data off the MPC website to build observing
lists
to feed the scope, but am an absolute beginner at this stuff.

Thanks.

--
--
Buster Sikes
|-----------------------------------|
   h2oape@...
   http://pw2.netcom.com/~h2oape/robointro.html
   http://pweb.netcom.com/~h2oape/home.html
|-----------------------------------|



To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com

Attached is a VB6 application using the Internet Transfer Control that I use
in Deepsky 2000.  The code is real basic and should show you how you can use
the control.

Steve

-------------------------------------------
If you like Deepsky 2000, please let other
people know.  Word of mouth advertising is
the primary means I use.

Steven S Tuma
Author, Deepsky 2000 Astronomy Software
http://www.deepsky2000.com
-------------------------------------------


-----Original Message-----
From: Buster Sikes [mailto:h2oape@...]
Sent: Tuesday, December 05, 2000 8:51 PM
To: ASCOM-Talk@egroups.com
Subject: [ASCOM] INET reference?


Hi all,

Can someone point me to a good (preferably online) source of info on the
Microsoft Internet Transfer Controls? I have some VBScript info but can't
find
anything in them about this.

I'd like to be able to extract data off the MPC website to build observing
lists
to feed the scope, but am an absolute beginner at this stuff.

Thanks.

--
--
Buster Sikes
|-----------------------------------|
   h2oape@...
   http://pw2.netcom.com/~h2oape/robointro.html
   http://pweb.netcom.com/~h2oape/home.html
|-----------------------------------|



To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com






[Non-text portions of this message have been removed]

Hi all,

Can someone point me to a good (preferably online) source of info on the
Microsoft Internet Transfer Controls? I have some VBScript info but can't find
anything in them about this.

I'd like to be able to extract data off the MPC website to build observing lists
to feed the scope, but am an absolute beginner at this stuff.

Thanks.

--
--
Buster Sikes
|-----------------------------------|
   h2oape@...
   http://pw2.netcom.com/~h2oape/robointro.html
   http://pweb.netcom.com/~h2oape/home.html
|-----------------------------------|

Certainly Robert.

I've been involved with software for the last 20 years, the
last two main tasks in date were a good part of the design
of the BeOS operating system, I am now director of engineering
at phone.com (openwave) managing the firmware for wireless phones.


I used ccd's for the last 10 years, designed the prototypes of
the AO-7 for SBIG and wrote large pieces of code to control my
different ccd cameras from both DOS and BeOS.

I have some specific interests in AO, drift-scan imaging and general
ccd interface.

I own at ST-8, an ST-V and an FLI TK1024 camera.

I am not a Windows fan... my heart is more toward BeOS or UNIX like
OS, so I will probably push back any Windows specific interface
specifications.

-- benoit


>From: Robert Schwebel <robert@...>
>Reply-To: robert@...
>To: benoit_schillings@...
>Subject: Re: ccdlib subscription request
>Date: Fri, 1 Dec 2000 06:48:43 +0100 (CET)
>
>On 30 Nov 2000, eGroups Notification wrote:
> > A user with the following email address would like to subscribe
> > to the ccdlib group:
> >
> >   benoit_schillings@...
>
>Please tell me some words about yourself and your interest in this group.
>
>Bye,
>Robert
>--
>  +----------------------------------------------------------------------+
>  I Dipl.-Ing. Robert Schwebel, Luedemannstrasse 25, 24114 Kiel, Germany I
>  I Phone +49-431-6794138 Fax +49-431-6794139 email: robert@...  I
>  +----------------------------------------------------------------------+
>

________________________________________________________________________________\
_____
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

-- benoit

--- In ASCOM-Talk@egroups.com, Jeff Medkeff <medkeff@m...> wrote:

> ...occasionally I won't get ActiveX objects properly made,
> for whatever reason, and a 'second try' does the job.

I use Delphi as my primary platform, and I related to Bob when I was
first playing with PinPoint that I had a case (which I still haven't
isolated to my satisfaction) in which FindImageStars would fail, but
would succeed on a second call.

My workaround was a try..exception block with the equivalent of the
following:

PP.FindImageStars;
if NOT PP.ImageStarsReady then
   PP.FindImageStars;

I've set it aside as a peculiarity of Delphi, since the equivalent
code (without the repeated call to FindImageStars) in JScript works
flawlessly.

But then again, I admit to being a tyro at this stuff..

TWE

Here at 701 we've got a big problem, and I want ASCOM folks' input on my
solution to it.

I've just sent 124 observations to the Minor Planet Center, the bulk of
which come from the last two nights. We're using eight to ten minute
robotically auto-guided exposures (thanks for exposing these methods,
Doug!) all night and going awfully faint. We're finding a *lot* of rocks
out there, definitely more than one per image. About half of them are
coming up unidentified in the MPC Checker, so management of all these
observations is getting a bit tricky. To give you an idea of our potential
volume, last October we made 4,642 measurements (I was testing a script
called "swamp" and it works as you would expect from the name).

I'm in the process of designing an observation management system, since I
haven't heard of anyone else developing what I want. I'd like the whole
system to run in VBScript, if it can (and I think it can). If it can't,
I've got Visual Basic 5 which I think I can struggle through to get the job
done. (I am not a developer.)

What I'd like my management system to do by way of minimum functionality is:

1) Open a text file of "last night's" measurements and ID them with the MPC
Checker (using the INET controls here). The reporting lines and the ID's
would be stored in a table that correlated our temporary designations with
MPC's preliminary and numbered designations.

2) Stuff all the ID'ed objects into a "report" table, which means that
these get reported to MPC the next time we send in a report.

3) Stuff all the not-ID'ed objects - that is, potential discoveries and
high-residual known stuff - into a "second night" table. This table would
be used to set up "tonight's" target list.

4) Calculate Vaisala solutions for all the objects in the "second nights"
table, and see if any two temporary designations are the same object. This
can be done with the INET control to hit the MPC new object ephemeris
generator, and a bit of evaluation code of my own. Objects that match up
are 'cleared' and moved over into the "report" table.

5) Of course, after n days, any observation would be cleared from the
"second nights" table, on account of recovery being hopeless. So if we
still think that thing was an asteroid as opposed to Noise-O-Rama, we might
as well send that observation in for the one-night-stand file where it can
be used for eventual linking.

6) Process MPC's 'designations' emails to set some flags in these tables.
Objects MPC identified will be flagged as identified. Anything that doesn't
come back with an ID is moved over into the "second nights" file on account
of apparently needing a second night in the MPC's opinion. Anything that
comes back as our discovery get's flagged with such an indication.

7) "Our discovery" flags are used to place the object into the observation
queue at appropriate intervals so as to better nail down the orbit (e.g.,
four or five days after the second night, then again one month later, then
three months later, or whatever).

8) Generate a target list with positions (from the Vaisala engine, I guess)
for "tonight." This target list would supplement our regularly scheduled
observing program.

This is a description of the minimum needed here. I can use Excel or Access
with a VBScript to get this job done (I am almost certain), and I've got
some definite coding ideas about how to implement some of these things.
There is room for expansion - for example, the script could calculate mean
scatter in our photometry, or handle other statistics. What I'm looking for
is any conceptual or design advice before I actually start coding this.

As usual, I'll make my eventual script or application available for free
via the ASCOM website.

BTW, I'm *not* posting this on MPML, on account of Gareth possibly not
liking it if he hears that I want to hit his webpages with a script. QT.


--
Jeff Medkeff
Hereford, Arizona

Jim Vail wrote:

> These things seem to sometimes have a mind of their own, but what a great
> way to run a set of programs.

Heh heh heh... I agree on the last. And as far as the first part goes... it
should NOT be that way. We're all getting our feet wet right now, and despite
the technology being very heavily used throughout the Windows world, it's
still really squirrily and complex internally. We're learning how to tame the
beast. I am confident the behavior will be more deterministic as we get better.

The ASCOM quality guidelines were/are a huge step towards taming the beast.
It's not nearly enough to "do COM" as such, there's MUCH MORE to exposing
stable scriptable objects.

    -- Bob

Jeff,

Thanks for the suggestions.  I like your idea of waiting for a temperture,
rather than just waiting, while the camera cools.  I'll try throwing in one
of your "doubble whammy" startups, just for the heck of it.  I'm also adding
a warning to make sure the camera is manually shut down before the script
starts it.

These things seem to sometimes have a mind of their own, but what a great
way to run a set of programs.

Jim



> -----Original Message-----
> From: Jeff Medkeff [mailto:medkeff@...]
> Sent: Thursday, November 23, 2000 9:43 PM
> To: ASCOM-Talk@egroups.com
> Subject: [ASCOM-Talk] Jim's Question
>
>
>
>
> Hello folks,
>
> I'm very glad to see this list developing. I never really used the
> conference but an e-mail list I can handle.
>
> I noticed Jim Vail was asking about some issues with camera cooling and
> starting up Maxim before the script or allowing the script to start it....
> I have a few comments about this based on our experiences out here:
>
> I've gone through several dev platforms, which means I've run my Acquire
> script on several different computers. I don't have any answers,
> but I will
> say that I've noticed wonky behaviour from all of my ASCOM
> programs (and in
> fact with every kind of ActiveX control that I use) when the system
> registry gets filled up with junk from programs that have been
> uninstalled,
> but which didn't uninstall gracefully. This "should" have no effect, but
> I've noticed that hosing things down with Norton's or Microsoft's registry
> cleaners correlates to getting nice, predictable, stable behavior from the
> software components. I'm not positing a cause-effect relationship, just
> commenting that this is how the Dome Gnome causes us trouble out here.
>
> I recently found that my observing partner starts our Acquire script
> without Maxim running. I have always started Maxim (but not opened the CCD
> control window) before starting the script. We have reliable operation
> either way except when I tinker with something and break it. I know I have
> no answers here, but perhaps this information will jog something loose; in
> any case hose down the registry if you aren't scared to do so. Also, I'd
> advise running a minimal configuration on your science-acquisition
> computer: its a real-time robotic controller you know.
>
> Also, if you are using some derivative of Bob's AcquireImages script, I
> might suggest altering your code to do something like this (in suitably
> vague meta-scripting code):
>
>
>  If not cam.CreateObject ...
>    If not cam.CreateObject ...
>       ' Now barf with an error here
>    End if
>  End if
>  ' If we land here we've created the object so things are OK
>
> I've noticed that occasionally I won't get ActiveX objects properly made,
> for whatever reason, and a 'second try' does the job. (This is not limited
> to ASCOM objects, in fact other controls are far more prone to
> needing this
> kind of treatment for whatever reason.)
>
> Also, I don't like the idea of building in an n minute wait for
> your camera
> to cool. I'm using something like:
>
> Do While cam.Temperature > camTargetTemp
>   Util.WaitForMilliseconds 1000
>   Log "Present camera temperature is " & Round (cam.Temperature, 1) & "
> degrees C."
> ...
>
> This way we only wait for how long it actually takes to get the
> camera down
> to an acceptable temperature. Out here, we run the camera cooler 100%
> during the whole observing session, so we set camTargetTemp to a different
> value than what we set the cooler to. If you are looking for the camera to
> settle down between two temperatures, you can do "Do while cam.Temperature
> > x and < y ...." Don't forget to initialize a timeout variable to exit
> this loop so that if the camera just won't cool, the script won't hang out
> forever waiting for it.
>
> If your errors are coming when you set the camera cooler, you can use a
> strategy similar to the above:
>
> On Error Resume Next
> cam.CoolerOn = True
> If Not cam.CoolerOn
>  'try again? Destroy cam object and start over? you decide.
> End if
> On Error Goto 0
>
> And likewise:
>
> On Error Resume Next
> cam.TemperatureSetPoint = cameraTemp
> If not cam.TemperatureSetPoint = cameraTemp
>  'try again? Destroy cam object and start over? you decide.
> End if
> On Error Goto 0
>
> I do recommend that you use On Error Resume Next *very carefully.* Be
> especially cautious if you call another subroutine or function while
> between "On Error Resume Next" and "On Error Goto 0." I don't know exactly
> where you are getting your error or what the error actually is, so that's
> why I'm providing a couple different scenarios here.
>
>
> --
> Jeff Medkeff
> Hereford, Arizona
>
>
>
> To unsubscribe from this group, send an email to:
> ASCOM-Talk-unsubscribe@egroups.com
>
>
>

Hello folks,

I'm very glad to see this list developing. I never really used the
conference but an e-mail list I can handle.

I noticed Jim Vail was asking about some issues with camera cooling and
starting up Maxim before the script or allowing the script to start it....
I have a few comments about this based on our experiences out here:

I've gone through several dev platforms, which means I've run my Acquire
script on several different computers. I don't have any answers, but I will
say that I've noticed wonky behaviour from all of my ASCOM programs (and in
fact with every kind of ActiveX control that I use) when the system
registry gets filled up with junk from programs that have been uninstalled,
but which didn't uninstall gracefully. This "should" have no effect, but
I've noticed that hosing things down with Norton's or Microsoft's registry
cleaners correlates to getting nice, predictable, stable behavior from the
software components. I'm not positing a cause-effect relationship, just
commenting that this is how the Dome Gnome causes us trouble out here.

I recently found that my observing partner starts our Acquire script
without Maxim running. I have always started Maxim (but not opened the CCD
control window) before starting the script. We have reliable operation
either way except when I tinker with something and break it. I know I have
no answers here, but perhaps this information will jog something loose; in
any case hose down the registry if you aren't scared to do so. Also, I'd
advise running a minimal configuration on your science-acquisition
computer: its a real-time robotic controller you know.

Also, if you are using some derivative of Bob's AcquireImages script, I
might suggest altering your code to do something like this (in suitably
vague meta-scripting code):


  If not cam.CreateObject ...
    If not cam.CreateObject ...
       ' Now barf with an error here
    End if
  End if
  ' If we land here we've created the object so things are OK

I've noticed that occasionally I won't get ActiveX objects properly made,
for whatever reason, and a 'second try' does the job. (This is not limited
to ASCOM objects, in fact other controls are far more prone to needing this
kind of treatment for whatever reason.)

Also, I don't like the idea of building in an n minute wait for your camera
to cool. I'm using something like:

Do While cam.Temperature > camTargetTemp
   Util.WaitForMilliseconds 1000
   Log "Present camera temperature is " & Round (cam.Temperature, 1) & "
degrees C."
...

This way we only wait for how long it actually takes to get the camera down
to an acceptable temperature. Out here, we run the camera cooler 100%
during the whole observing session, so we set camTargetTemp to a different
value than what we set the cooler to. If you are looking for the camera to
settle down between two temperatures, you can do "Do while cam.Temperature
> x and < y ...." Don't forget to initialize a timeout variable to exit
this loop so that if the camera just won't cool, the script won't hang out
forever waiting for it.

If your errors are coming when you set the camera cooler, you can use a
strategy similar to the above:

On Error Resume Next
cam.CoolerOn = True
If Not cam.CoolerOn
  'try again? Destroy cam object and start over? you decide.
End if
On Error Goto 0

And likewise:

On Error Resume Next
cam.TemperatureSetPoint = cameraTemp
If not cam.TemperatureSetPoint = cameraTemp
  'try again? Destroy cam object and start over? you decide.
End if
On Error Goto 0

I do recommend that you use On Error Resume Next *very carefully.* Be
especially cautious if you call another subroutine or function while
between "On Error Resume Next" and "On Error Goto 0." I don't know exactly
where you are getting your error or what the error actually is, so that's
why I'm providing a couple different scenarios here.


--
Jeff Medkeff
Hereford, Arizona

Bob Denny wrote:
>
> (1) Some property indicating whether the focuser is capable of temperature
> compensation, some way to turn this on and off, and some way to read out the
> compensation value and/or the detected temperature. I know the Optec unit
> can't do this, but some day one might (assuming the designer decides to spend
> $30.00 instead of $1.95 for the CPU :-)))))

I was thinking of this.  Actually, the Optec TCF-S CAN read out the current
temperature.

> (2) A speed setting

I think I'd leave that to the Setup dialog box.

> (3) An interval setting (for/if pulsed operation)

Likewise.

> (4) Possibility of setting StepSize if the focuser has something like a
> coarse/fine capability. This is in a sense equivalent to (2) so they may be
> mutually exclusive.

That is tricky because there will be a limited set of values which will be
acceptable to the unit.  Maybe a simple fast/slow switch?

> (5) In a simple focuser, should there be a provision for pulsed operation?
> Personally, I think a software latch operating across a COM boundary is scary.
> An alternative to In/OutButton might be a Move() method with a direction and
> an amount (which would be clicks for an absolute positioner and time for a
> simple motor type). The focus controller might be very much closer to the
> hardware, and thus in a much safer position to turning on and off the stepper
> or motor.

Well, the Absolute mode anticipates that someone might want to build a pulsing
system.  However, I suppose we could specify that they HAVE to build it this way
and get rid of the InButton/OutButton controls.

> Thinking more in the large ... it would be great if the interface were
> consistent enough so that the client script didn't have to do a bunch of
> discovery before deciding how to manage the focuser. But that's probably a
> pipe dream. I think you're right on for exposing the characteristics of the
> device so that the client can make decisions.-

That would require that all focusers attempt absolute positioning, I think.  I
KNOW that some focusers aren't anywhere near good enough for this.

> Clarification --
>
> The IsMoving description says that "New commands cannot be issued while the
> focuser is moving." Does this include querying the Position property? How
> about other "static" properties such as StepSize?

You can access the readonly properties, but depending on the focuser they may
not update until the end of travel.  For example, the TCF-S doesn't give
position feedback until it gets to the end of the commanded motion.

Doug

--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

Some thoughts for addition/modification --

(1) Some property indicating whether the focuser is capable of temperature
compensation, some way to turn this on and off, and some way to read out the
compensation value and/or the detected temperature. I know the Optec unit
can't do this, but some day one might (assuming the designer decides to spend
$30.00 instead of $1.95 for the CPU :-)))))

(2) A speed setting

(3) An interval setting (for/if pulsed operation)

(4) Possibility of setting StepSize if the focuser has something like a
coarse/fine capability. This is in a sense equivalent to (2) so they may be
mutually exclusive.

(5) In a simple focuser, should there be a provision for pulsed operation?
Personally, I think a software latch operating across a COM boundary is scary.
An alternative to In/OutButton might be a Move() method with a direction and
an amount (which would be clicks for an absolute positioner and time for a
simple motor type). The focus controller might be very much closer to the
hardware, and thus in a much safer position to turning on and off the stepper
or motor.

Thinking more in the large ... it would be great if the interface were
consistent enough so that the client script didn't have to do a bunch of
discovery before deciding how to manage the focuser. But that's probably a
pipe dream. I think you're right on for exposing the characteristics of the
device so that the client can make decisions.-

Clarification --

The IsMoving description says that "New commands cannot be issued while the
focuser is moving." Does this include querying the Position property? How
about other "static" properties such as StepSize?

    -- Bob

Hi,

Bob thought that dumping word-wrapped IDL into my e-mail was too hard to read!
Here's a condensed version:


Properties
----------

Link         Read/Write       Set true to connect link to focuser, false
                               to shut down link

Absolute     Readonly         returns True if the focuser control is
                               capable of absolute positioning.  If not,
                               only the InButton and OutButton functions work

StepSize     Readonly         reports the step size in microns

MaxStep      Readonly         returns the maximum step range when
                               operating in Absolute mode.  The step range
                               of the focuser will be from 0 to MaxStep.

IsMoving     Readonly         returns true if the focuser is moving,
                               false if not.  New commands cannot be
                               issued while the focuser is moving.

Position     Readonly         returns the current position of the focuser

InButton     Read/Write       When set true, focuser begins moving inward.
                               Distance moved is either dependant on the
                               duration (e.g. simple DC motor focuser) or
                               a fixed distance (absolute positioning
                               focuser).  When set false, focuser stops
                               moving.  Intended for user "pushbutton"
                               controls.

OutButton    Read/Write       When set true, focuser begins moving outward.
                               Distance moved is either dependant on the
                               duration (e.g. simple DC motor focuser) or
                               a fixed distance (absolute positioning
                               focuser).  When set false, focuser stops
                               moving.  Intended for user "pushbutton"
                               controls.


Methods
-------

SetupDialog  No parameters    Brings up the setup dialog box; used to
                               set up any required settings, eg. COM Port.

Move         long Position    Commands the focuser to move to an absolute
                               position.  Only available if Absolute is true.


Discussion
----------

Basically, the object supports two kinds of focusers:  absolute position units
like the Optec TCF-S and RoboFocus, and simple on/off DC motor focusers.  The
absolute position units are preferred since they have repeatable positioning.
Focuser component authors may try to simulate an absolute positioning focuser
using the DC motor focuser, but I suspect the results may be less than
satisfactory.

If the programmer wants to support optional features such as built-in backlash
compensation, any controls for these features should be in the setup dialog box.

I'm also thinking of adding a switch to turn on automatic temperature tracking
mode, if supported.  Any other ideas for additional features would be most
welcome.

Doug


--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

> Why don't we come up with an ASCOM standard for focuser control?
I've already
> got an ASCOM-compliant focuser control working for the Optec TCF-S,
and I'm
> > Any opinions out there???
>
> --
> Doug George

Doug,

I have one of the Optec temp units.  Is it possible to also control
the focuser in software by having Pinpoint do some sort of
calculations on stars in images and then adjust the focus when
commanded to?

Just a thought.
Tim.

***********************************************************
THE PUCKETT OBSERVATORY
P.O. Box 818
Ellijay, Ga. 30540 USA

Voice: 706- 636-1166
Fax: 706- 636-1167
Email: tpuckett@...

MPC # 752
Web: http://www.cometwatch.com

**********************************************************

Doug,

I have a Meade 416XT.

To expand on the situation..., if I manually start MaxIm and cool the
camera, and leave everything running, then start the script (which is a
takeoff on Bob's AcquireImages script), the CCD control panel comes up, the
cooler power is 0, the CCD temp start rising, cooler power comes on, and the
temp finally start falling.  In the meantime, an error message pops up with
"Could not initialize the Camera at (the line "If not cam.LinkEnabled
Then").  The second time I tried, it made it past that, but I got the error
"Failed to start the exposure at (the line "If Not cam.Expose ...").

I tried Bob's way of doing things, with manually starting MaxIm, cooling,
then shutting down, but hitting NO to "Turn Cooler Off?".  When I start the
script, the CCD control panel still comes up with cooler power 0, the camera
begins warming, the cooler power comes on, and it eventually cools back
down.  The only difference, is that the camera goes ahead and makes the
image just fine.

I can get around this by having a two minute wait time for the camera to
cool back down after the script starts.  According to Bob's reply, this
sounds like a problem unique to me, so if you have any thoughts on it, just
reply off the list to jimvail@... .

Thanks,

Jim

> -----Original Message-----
> From: Douglas B. George [mailto:dgeorge@...]
> Sent: Tuesday, November 21, 2000 11:53 AM
> To: ASCOM-Talk@egroups.com
> Subject: Re: [ASCOM-Talk] Hi
>
>
> jimvail@... wrote:
> >
> > I hope this group is a bit more active than the last ASCOM group.
> >
> > To start things (between the four of us :) ),I'll throw out a
> > question.  When I start a script that calls for MaxIm DL, and I've
> > already started Maxim to cool and focus my camera, I get very erratic
> > results.  Sometimes the script runs fine, others, it results in an
> > error.  If I shut Maxim down before starting the script, and let the
> > script start MaxIm, everything is fine.  Obviously, the latter is what
> > I now do, but I'm wondering why I have to.  THE Sky doesn't work this
> > way.  I don't have to have the script start a new instance of The Sky
> > when the script starts.  Does anyone know if there is an
> > initialization process that I should be performing, or if there's any
> > other around this?
>
> Hmmmm... I've not seen that problem.  What model of camera are you using?
>
> Doug
>
> --
> Doug George
>
> =============================================================
>      Diffraction Limited                Cyanogen Division
>      Industrial Products                Astronomy Products
> http://www.diffractionlimited.com     http://www.cyanogen.com
>  dgeorge@...        dgeorge@...
>     Phone:  (613) 225-9852            Sales:  (613) 225-2732
>      Fax:  (613) 225-9688              Fax:  (613) 225-9688
> =============================================================
>
>
> To unsubscribe from this group, send an email to:
> ASCOM-Talk-unsubscribe@egroups.com
>
>
>

Jim Vail wrote:

> [...], I notice that you DO shut down the camera before starting the
> script.

Maybe in an old script :-(, but the AcquireImagesFlex.vbs script that ships
with Pinpoint 2.0 SP1 has a user option for camera shutdown. And during
startup it does this:

          cam.CoolerOn = True
          cam.TemperatureSetpoint = cameraTemp

So I do turn on the cooler during script startup. The cameraTemp value comes
from the user config area.

    -- Bob

Hi,

Why don't we come up with an ASCOM standard for focuser control?  I've already
got an ASCOM-compliant focuser control working for the Optec TCF-S, and I'm
working on a similar one for the RoboFocus.

The driver supports both absolute positioning-capable focusers and the more
conventional
"press a button" style focusers.  The absolute functions can be simulated on a
conventional focuser using pulses if the programmer so desires.

My interface was written in ATL so I've just copied in the IDL with some
comments.


[propget, id(1), helpstring("Step size in microns")] HRESULT StepSize([out,
retval] float *pVal);

- reports the step size in microns


[id(2), helpstring("Display the setup dialog box")] HRESULT SetupDialog();

- brings up a dialog box for setup purposes (for this particular focuser, it
lets you set the COM port)


[propget, id(3), helpstring("Maximum step position")] HRESULT MaxStep([out,
retval] long *pVal);

- When operating in Absolute mode, the position range is from 0 to MaxStep


[propget, id(4), helpstring("True if focuser is currently moving")] HRESULT
IsMoving([out, retval] BOOL *pVal);

- Returns true if the focuser is in motion due to a Move command


[id(5), helpstring("Move the focuser to an absolute position")] HRESULT
Move(long Position);

- Commands the focuser to move to an absolute position


[propget, id(6), helpstring("Current focuser position")] HRESULT Position([out,
retval] long *pVal);

- Returns the current focuser position


[propput, id(7), helpstring("Move focuser in manually")] HRESULT InButton([in]
BOOL newVal);
[propget, id(7), helpstring("Manual button state")] HRESULT InButton([out,
retval] BOOL *pVal);

- Manual operation; calling this starts the focus motor running in.  (note: some
focusers will move in a predetermined amount)


[propget, id(8), helpstring("Move focuser out manually")] HRESULT
OutButton([out, retval] BOOL *pVal);
[propput, id(8), helpstring("Manual button state")] HRESULT OutButton([in] BOOL
newVal);

- Manual operation; calling this starts the focus motor running out.  (note:
some focusers will move out a predetermined amount)


[propget, id(9), helpstring("Set true to start link to focuser, false to shut
down")] HRESULT Link([out, retval] BOOL *pVal);
[propput, id(9), helpstring("Set true to start link to focuser, false to shut
down")] HRESULT Link([in] BOOL newVal);

- start/terminate link

[propget, id(10), helpstring("True if the focuser control is capable of absolute
positioning")] HRESULT Absolute([out, retval] BOOL *pVal);

- Returns True if the focuser control is capable of absolute positioning.  If
not, only the InButton and OutButton functions work


I'm also thinking of adding a switch to turn on automatic temperature tracking
mode, if supported.

Any opinions out there???

--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

Thanks,

Sorry for being so stupid, I am downloading now!

Steve

-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday, November 21, 2000 2:14 PM
To: ASCOM-Talk@egroups.com
Subject: Re: [ASCOM-Talk] Welcome!


Steven S Tuma wrote:

> Where is the SDK download link?  What scopes are supported?
> [...]
> -----Original Message-----
  > [...]

> Meanwhile, have a look at the ASCOM INitiative web site at
>
>    http://ascom-standards.org/
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                   |
      click here, all will be revealed



To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com

Steven S Tuma wrote:

> Where is the SDK download link?  What scopes are supported?
> [...]
> -----Original Message-----
  > [...]

> Meanwhile, have a look at the ASCOM INitiative web site at
>
>    http://ascom-standards.org/
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                   |
      click here, all will be revealed

Bob Denny wrote:
>
> Gosh, before I could post my first message, 4 people joined and Jim Vail
> posted a message. I hope this is an indication of better success than the old
> Conference Center! I was pleasantly surprised at the features and ease of
> setup for this eGroups list. You might take a look at the home page for
> ASCOM-Talk just to see the features you have available.

The conference center was a problem because you had to go out of your way to use
it, and it was very, very slow.  I think this will work much better.

Doug

--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

Bob,

Well, this has already paid off.  You're doing exactly what I wanted to do,
but didn't know I could.  I assumed that when you shut down the camera, you
HAD to turn off the cooler.  I even built in a "cooling down" period in the
script, because MaxIm always restarted at zero cooling power and needed a
couple of minutes to stabilize.

However, I notice that you DO shut down the camera before starting the
script.  That's what I was doing by shutting down MaxIm completely.  I
assume then, that shutting down the camera before starting the script IS
required.  I'll try this out this afternoon.  Thanks.

BTW, how is the new version of ACP coming?

Jim Vail

> -----Original Message-----
> From: rdenny@... [mailto:rdenny@...]
> Sent: Tuesday, November 21, 2000 11:37 AM
> To: ASCOM-Talk@egroups.com
> Subject: [ASCOM-Talk] Re: Hi
>
>
> Jim --
>
> Doug George is much better qualified than I, but I'll take a crack at
> it...
>
> I've noticed the opposite. I seem to have consistent and reliable
> operation if I start MaxIm and manually open the CCD control panel.
> Then I start the camera and cooler. Finally, I do a shutdown on the
> camera <b>without turning off the cooler</b>. My scripts don't turn
> off the cooler either. By doing this you avoid temperature cycling the
> camera, which can mess up the chip in some (older? cheap?) cameras.
>
> Once the camera is cooled, I can start a script. When the script
> creates its instance of MaxIm.CCDCamera, the CCD control panel
> appears. After this, things seem to run just great. I know that Tim
> Puckett, for example, starts scripts that take hundreds of images, and
> I believe he uses the same steps to get started.
>
>  -- Bob
>
> --- In ASCOM-Talk@egroups.com, jimvail@p... wrote:
> > Does anyone know if there is [a MaxIm DL scripting]
> > initialization process that I should be performing?
>
>
>
> To unsubscribe from this group, send an email to:
> ASCOM-Talk-unsubscribe@egroups.com
>
>
>

Where is the SDK download link?  What scopes are supported?

Thanks

Steve

-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday, November 21, 2000 1:54 PM
To: ASCOM-Talk List
Subject: [ASCOM-Talk] Welcome!


Gosh, before I could post my first message, 4 people joined and Jim Vail
posted a message. I hope this is an indication of better success than the
old
Conference Center! I was pleasantly surprised at the features and ease of
setup for this eGroups list. You might take a look at the home page for
ASCOM-Talk just to see the features you have available.

I'll pay the money to have the advertising removed from the bottom of the
messages. It supposedly takes a few weeks (??) but it will eventually
happen.

Meanwhile, have a look at the ASCOM INitiative web site at

    http://ascom-standards.org/

The first release of the Telescope Driver SDK is available for download. It
contains VB6 sources and runnable binaries for 5 implemented Telescope
drivers
(including a nifty scope simulator), a VB6 template project for implementing
your own Telescope driver, and the ASCOM spec in HTML Help format.

The installer will update your system to the latest VB6 support components,
and install the Windows Script 5.5 engines and Windows Script Host. It will
NOT back rev anything, so don't worry :-)

Let's hope things will get into high gear from here on out. Watch for
additional announcements regarding ASCOM telescope support in products.

Meanwhile, let's talk!

    -- Bob




To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com

Gosh, before I could post my first message, 4 people joined and Jim Vail
posted a message. I hope this is an indication of better success than the old
Conference Center! I was pleasantly surprised at the features and ease of
setup for this eGroups list. You might take a look at the home page for
ASCOM-Talk just to see the features you have available.

I'll pay the money to have the advertising removed from the bottom of the
messages. It supposedly takes a few weeks (??) but it will eventually happen.

Meanwhile, have a look at the ASCOM INitiative web site at

    http://ascom-standards.org/

The first release of the Telescope Driver SDK is available for download. It
contains VB6 sources and runnable binaries for 5 implemented Telescope drivers
(including a nifty scope simulator), a VB6 template project for implementing
your own Telescope driver, and the ASCOM spec in HTML Help format.

The installer will update your system to the latest VB6 support components,
and install the Windows Script 5.5 engines and Windows Script Host. It will
NOT back rev anything, so don't worry :-)

Let's hope things will get into high gear from here on out. Watch for
additional announcements regarding ASCOM telescope support in products.

Meanwhile, let's talk!

    -- Bob

jimvail@... wrote:
>
> I hope this group is a bit more active than the last ASCOM group.
>
> To start things (between the four of us :) ),I'll throw out a
> question.  When I start a script that calls for MaxIm DL, and I've
> already started Maxim to cool and focus my camera, I get very erratic
> results.  Sometimes the script runs fine, others, it results in an
> error.  If I shut Maxim down before starting the script, and let the
> script start MaxIm, everything is fine.  Obviously, the latter is what
> I now do, but I'm wondering why I have to.  THE Sky doesn't work this
> way.  I don't have to have the script start a new instance of The Sky
> when the script starts.  Does anyone know if there is an
> initialization process that I should be performing, or if there's any
> other around this?

Hmmmm... I've not seen that problem.  What model of camera are you using?

Doug

--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

Jim --

Doug George is much better qualified than I, but I'll take a crack at
it...

I've noticed the opposite. I seem to have consistent and reliable
operation if I start MaxIm and manually open the CCD control panel.
Then I start the camera and cooler. Finally, I do a shutdown on the
camera <b>without turning off the cooler</b>. My scripts don't turn
off the cooler either. By doing this you avoid temperature cycling the
camera, which can mess up the chip in some (older? cheap?) cameras.

Once the camera is cooled, I can start a script. When the script
creates its instance of MaxIm.CCDCamera, the CCD control panel
appears. After this, things seem to run just great. I know that Tim
Puckett, for example, starts scripts that take hundreds of images, and
I believe he uses the same steps to get started.

  -- Bob

--- In ASCOM-Talk@egroups.com, jimvail@p... wrote:
> Does anyone know if there is [a MaxIm DL scripting]
> initialization process that I should be performing?

I hope this group is a bit more active than the last ASCOM group.

To start things (between the four of us :) ),I'll throw out a
question.  When I start a script that calls for MaxIm DL, and I've
already started Maxim to cool and focus my camera, I get very erratic
results.  Sometimes the script runs fine, others, it results in an
error.  If I shut Maxim down before starting the script, and let the
script start MaxIm, everything is fine.  Obviously, the latter is what
I now do, but I'm wondering why I have to.  THE Sky doesn't work this
way.  I don't have to have the script start a new instance of The Sky
when the script starts.  Does anyone know if there is an
initialization process that I should be performing, or if there's any
other around this?

Jim Vail