RayS wrote:
>I've begun a Python module to provide a complete interface to the Meade
>LX200 command set:
>http://rjs.org/Python/LX200.py
>and would like input from potential users or people interested in
>developing it further.
>
>
<snip>
Hello,
I know nothing about telescopes and spending most of my time
trying to avoid dog s**t so I don;t look up much. However I do control
machines for a living so here is some pointers.
>The code I have online is a very alpha start - it contains all of the
>command set, parsed from
>http://www.meade.com/support/LX200CommandSet.pdf
>reg-exp'd into methods, but few methods are actually complete yet.
>My thinking is to have it useful for Python command line testing, as well
>as GUI programs.
>
>History: after searching for such a thing, I had found only:
>http://72.14.203.104/search?q=cache:hOgO7H_MUeYJ:phl3pc02.phytch.dur.ac.uk/~jrl/source/source_code.html+lx200.py&hl=en&gl=us&ct=clnk&cd=1
>from University of Durham, but the code is not available...
>and
>http://cvs.sourceforge.net/viewcvs.py/projgalileo/lx200/lx200.py?rev=1.4
>from the Galileo project, but which only has a subset and is aimed at their
>needs, mostly. Some of the Galileo code looks useful, and so I might want
>to make use of at least some of the methodology, even if only to get their
>interest as well.
>
>Current input I would most like is on module structure and Pythonic-ness:
>-Only one class, or two?
>I was considering splitting the commands into two classes: Telescope and
>Library, as either could be used without the other for a scope session. (If
>you have large libraries on your PC, you do not need the LX one - or if you
>don't, or have a PDA, then just doing a Library lookup alone might be useful.)
>If you were to "import LX200", how would you expect it to work?
>
>
I would actually split into more than two, the split into model and
library, it can't harm and you would be the expert on that. However I
would also split out the serial communications so you can simply send
commands and receive information back without worrying to the vagarities
of serial comms. That way if the manufacturers switch to a different
communication protocol you can easily swap this out. In addition the
seperate class will allow you to deal with the responses and commands
coming back from the scope in an extensible fashion, for exmaple making
the code asynchronous in the future and maybe thread safe.
In addition, looking at the number of methods you have for the scope, I
would split even further or you are going to have a _massive_ class.
Can you split it into a tiered structure, complicated commands that do a
lot down to simple ones. If not then try to split out different scope
functionality to seperate classes with a core module holding them together.
>-Should I have module methods, as I do? (Galileo uses some static methods)
>
>
Personally I hate module methods but that is a matter of taste. The
best thing I can add here is that if anything changes (or may in the
future) state then keep it in the class as an instance method.
>-What constants might be useful to define?
>
>
All of the commands in a dictionary
States the machine is in : disconnected, connected, idle, busy, error
>-When should the com port be opened/tested? (I have it on init...)
>
>
Here is one clear piece of advice, never ever open a serial port on the
constructor (or any kind of stateful thing that takes a long time and
may fail). Give the user the option to open the port themselves. That
way I can make my instance and then open it at my own leisure. On the
same vein, give the user an explicit close method.
>-What about the class names?
>
>
fine
>It is already ~1200 lines code and comments, even without most of the
>commands actually useful yet, and so I'd like to get a good form started
>before getting too far along.
>
>Is anyone here interested in using such a module, or willing to critique?
>
>
here's a coupla things
When you are reading from the serial port, if I remember correctly
read blocks, when checking to see if characters are available use
inWaiting. I see you are running synchronously so use a loop with
sleeps in it to allow a timeout and throw an esxception if it times out.
This may be a personal thing but don;t use 0..n for the serial port
names - no-one expects it and it confuises the issue, use COM1,
/dev/tty1, etc. What is the first serial port on a Mac OSX for example?
It is good you are throwing your own exceptions, however have
different exceptions for the command being badly formatted and for a
command that got sent but failed. Otherwise I have no way of working
out what the error is without parsng the error message.
The bits that send the communication, wrap these in a try/catch,
rethrow Serial exceptions them as an IO exception and throw it from the
method that is called e.g. auto_align
State at the top your code is not safe for multi-threaded operation
and you bear no responsibility if the code smashed their scope up!
However as I stated, I wouldn't wanna use it - sorry!
>Thanks,
>Ray
>arr-ayy-why-ess at blue-cove.com
>
>
>
One final thing, above is simply a list of tips, if you are doing this
for a hobby and it is not expected to run 24/7 handling expensive
materials then use the above comments as you feel, IMHO this si the
correct way to do things but that's just me.
If you really want to get the operation correct then start with the
serial communication, get a bit of paper and think what could ever
possibly go wrong with the communication. Then design your serial
communication for that. Here's a few communciations thigns to worry about:
Requested port on computer does not exist
Requested port on computer is broken and cannot send data
Command gets sent to scope, however some noise occurs in the line and
the scope receives data but not what you sent
as above but vice versa
Cheers,
Neil
--
Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany
Tel : +49 (0)351 4173 154
e-mail : [EMAIL PROTECTED]
Cenix Website : http://www.cenix-bioscience.com
--
http://mail.python.org/mailman/listinfo/python-list
