hi larry, i think if you are sending emails to [email protected] from an email address that is different from your subscription email address, your email will be rejected by the list server.
best wishes, dan On Tue, Aug 28, 2012 at 3:11 PM, Tom Kuiper <[email protected]> wrote: > On 08/28/2012 01:30 PM, Larry D'Addario wrote: > >> I noticed your thread on this subject on the CASPER list. (Although I >> subscribe to the list, I'm unable to post to it for some reason that I have >> not yet figured out.) >> > That's strange. An e-mail to Mark Wagner may resolve that. Hopefully > he'll see this. > >> I have used both the pseudo-files under /proc and the katcp server to >> communicate with registers in the FPGA, and both work fine. I think the >> best approach depends a lot on whether you are wanting to change the >> low-level things interactively by typing commands, or whether you want to >> do it from within a program. I have done both. >> > I tend to begin using the interactive Python (ipython) command line. Then > as things are worked out I copy the commands into a Python program in an > editor. Even as I'm building the program I try things out or debug errors > using the ipython command line. Sometimes the command line is just plain > handy. For example, except that I was really busy, I should have done this > when I got your e-mail about CRAFT yesterday: > > In [1]: from Ephem import * > In [2]: p = Pulsar('J0332+5434') > In [3]: p.period > Out[3]: 714.51969972580105 > > and you might want to do this: > > In [4]: d = DSS(13) > In [5]: p.compute(d) > In [6]: print(p.a_ra, p.a_dec) > (3:32:59.39, 54:34:43.4) > In [7]: print(p.ra, p.dec) > (3:33:59.59, 54:37:04.5) > > Mind you, this is Python enhanced with my own modules but you get the idea. > >> For something that's fairly complicated, the CASPER people tend to write >> Python programs which work via the katcp server on the PPC. The same thing >> can be done in C; you don't need Python unless you want to re-use some >> existing code, but so far I've found the existing code too complex, >> convoluted, and undocumented to make it worth the bother. >> > I agree. I tried to find out how they actually write to registers and I > dug through layer after layer only to get to some 'request' method that I > could not locate. By the way, there is some documentation I generated > automatically and put on > http://dsnra.jpl.nasa.gov/**software/Python/python-**modules/corr/<http://dsnra.jpl.nasa.gov/software/Python/python-modules/corr/> > At the moment you can only get at it from within JPL because we closed > outside access, pending an investigation, after the website was hacked a > few days ago. > >> If you can do your control via katcp commands, then you can put a list of >> them in a file and execute the file like a script using my katcp >> interpreter. >> > To do that I need to run katcp on the ROACH host which is behind a > firewall (JPL's for now, FlightOps in the future). It can be done but is > clumsy. Glenn's solution is more elegant. Mine is primitive but has the > advantage of not depending on software (corr) someone else wrote. > >> To minimize network traffic, the file with the commands could be on the >> local host rather than on a remote machine; then the only thing that goes >> over the network is the file name. I also have a small program that allows >> you to run individual katcp commands but is far more user-friendly than >> trying to type those commands directly to the server over a telnet >> connection. >> > That's a front end to katcpComm, I guess. I'm not sure how I could grow > from that into a complex interactive graphical program, except very > painfully using the Motif library or something like that. There is a good > reason for languages like Python and Matlab. > > I have the feeling that the file length going to zero on a simple write is > unintended and been lurking in the borph code since no one ever tried such > a simple OS-level write. I'm guessing that the file pointer, which is > reset to zero before the write, is not advanced after the write. > > Cheers, > > Tom > >
