Rewrite code base in Python

[edaniszewski]

I might eventually get around to doing this. I think I commit a Python directory a while ago.

Problems with this include:

• not knowing the mechanics (read as mathematical/logic decisions) currently implemented
• not having a radiotelescope and rotator readily available to play with.

[edaniszewski]

Might be useful: http://rhodesmill.org/pyephem/

[acencini]

a possible path for this is to encapsulate the stuff that needs to be highly optimized (e.g. the serious math) in C, but wrap the rest in Python. this is sort of what Python is "for" and will speed development.

this may already be in progress, but i was thinking about this and think it might make sense to tease apart the mundane stuff (including the controller control) which would be easier in Python, while maintaining performance by modularizing the C stuff.

for the controller stuff, it may help to create a module built on pyserial to handle the serial communications.

[edaniszewski]

:+1:

playing around with this could be a fun way of getting my hands dirty with pyserial

[edaniszewski]

13744e66baf275ca12bfc3538b3d10c303c4e020

took a crack at converting the serial Rot2Prog controller into Python. I know now what all the magic numbers mean. Source documentation credit: http://ryeng.name/blog/3

Still need to figure out how to test this. Probably through some kind of serial emulator. @acencini ?

[acencini]

i think you should have @thedarklard help test it with the controller

otherwise, you'd need to know intimately how the rotator controller works

that said, if it's pretty simple, yes an emulator would work - you can use the socat tool to create a "fake" serial device that you can run in a separate process or thread that listens for incoming requests, and returns some result based on that request - in effect, emulating some of the controller's firmware. you could have the responses be what's "expected" (either statically, or based on some algorithm/state), or use a canned response file, or a random or programmatic generator - the former, obviously being the easiest.

nice work

On Jul 2, 2015, at 9:31 PM, Erick Daniszewski notifications@github.com wrote:

13744e6 https://github.com/BenningtonCS/Telescope-2014/commit/13744e66baf275ca12bfc3538b3d10c303c4e020 took a crack at converting the serial Rot2Prog controller into Python. I know now what all the magic numbers mean. Source documentation credit: http://ryeng.name/blog/3 http://ryeng.name/blog/3 Still need to figure out how to test this. Probably through some kind of serial emulator. @acencini https://github.com/acencini ?

— Reply to this email directly or view it on GitHub https://github.com/BenningtonCS/Telescope-2014/issues/110#issuecomment-118207839.

[theDarkLard]

I'd love to help test it! @edanisweski did you push your code to github? Are there any install things I should know about?

On Jul 2, 2015, at 9:34 PM, Andrew Cencini notifications@github.com wrote:

i think you should have @thedarklard help test it with the controller

otherwise, you'd need to know intimately how the rotator controller works

that said, if it's pretty simple, yes an emulator would work - you can use the socat tool to create a "fake" serial device that you can run in a separate process or thread that listens for incoming requests, and returns some result based on that request - in effect, emulating some of the controller's firmware. you could have the responses be what's "expected" (either statically, or based on some algorithm/state), or use a canned response file, or a random or programmatic generator - the former, obviously being the easiest.

nice work

On Jul 2, 2015, at 9:31 PM, Erick Daniszewski notifications@github.com wrote:

13744e6 https://github.com/BenningtonCS/Telescope-2014/commit/13744e66baf275ca12bfc3538b3d10c303c4e020 took a crack at converting the serial Rot2Prog controller into Python. I know now what all the magic numbers mean. Source documentation credit: http://ryeng.name/blog/3 http://ryeng.name/blog/3 Still need to figure out how to test this. Probably through some kind of serial emulator. @acencini https://github.com/acencini ?

― Reply to this email directly or view it on GitHub https://github.com/BenningtonCS/Telescope-2014/issues/110#issuecomment-118207839.

― Reply to this email directly or view it on GitHub.

[edaniszewski]

@theDarkLard I pushed the code I wrote to the dev branch, but all I wrote was the controller class, no actual code to instantiate and run it. I could put together a test file which would try to connect over /dev/ttyUSB0 and then execute a few commands. Really there are only 3 commands the controller supports: set, status, and stop, which is explained in link in my previous comment as well as the comments in the controller class.

I'll let you know when I have a decent-looking test checked in, then you could just run it at your leisure.

[edaniszewski]

@theDarkLard

https://github.com/BenningtonCS/Telescope-2014/tree/dev/src/python/serial_controller

the test code is in the 'test' folder. You need the entire 'serial_controller' directory to run the test (could either clone the branch, or download the branch as a zip )

then, cd into the test folder, and

$ python test_rot2prog.py

which should then generate a log file, rot2prog_test.log in the test directory. It would be helpful to see the log file, dunno if its best to just email it to me, or copy its contents in a comment... we'll pass that bridge when we get there. it would be best to email it to me, since I dont know how GitHub would display whatever ascii characters may exist in the log output.

[edaniszewski]

@theDarkLard

I realized that running the test I commit earlier (if successful) would move the telescope out of position, so you would have to realign it, which Im sure is a pain in the butt, so I just pushed an additional bit to the test code which will try and set it back to the position it was in before the tests began (again, assuming that the things works).

Just thought I'd let ya know!

[edaniszewski]

oh, also @theDarkLard @hcrowl with the commit mentioned in the previous comment ( 1229553713779bcdede17be5f8067237003653f6 ) I added a stub for the command file parsing. I'm trying to keep backwards compatibility to some extent (e.g. command files for the MIT srtn version should still be able to be parsed correctly), but there is also nothing wrong with adding more to it. I dont know if you use command files enough to have an opinion on them, but are there any things that you think would be nice to have added? (e.g. I know that to execute a wait command, you would need to have something like :40, but we could add a 'wait' keyword to make it clearer, e.g. : wait 40)