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