July 2001 J. D. Monnier VxWorks/OT Documentation ------------------------ Contents A. File Locations of up-to-date code: WORKSPACE: IOTAMC_2001June B. Brief comments about certain vxworks modules. C. How to start the vxworks from scratch (also misc utilities). D. How to start the OT and run the script E. Other things: XDisplays and IDL interface to shared memory Appendix: JDM's version of the OT programmer's manual -------------------------------------------------------- A. The most up-to-date version of the VxWorks code lies in the ~iota/iotamc subdirectory. I've made a new WORKSPACE which is meant to be a record of the development as of the June/July 2001 run. I've copied the IOTAMC workspace as IOTAMC_2001June workspace and this will be the NEW up-to-date workspace with the best distribution. The appropriate file to load from tornado is: ~iotamc/vxworks/IOTAMC_2001June.wsp *******IMPORTANT NOTE********* I just figured out that the new workspace I created overwrites the project files, since I kept the same project directories. Hence, be aware than changes to the IOTAMC_2001June and IOTAMC projects interact with each other. We need to come up with a good way of archiving directories. When I am done with my 'cleaning up' I will copy the iotamc directory into the ~iota/Backups directory. ****************************** All the CfA code resides in iotamc/vxworks, while Amherst has put some vxworks code in other places like iotamc/lmt/mc/c++. I've tried to put copies of all the relevant .cpp and .h files in iotamc/vxworks so as to have a clean distribution. However, there still may be some code existing in other places, such as ~iota/mc. One way to look would be call up the Workspace "IOTA_Clean_2001April" which points to the file locations of all code as of April 2001. Current Subdirectories/Projects in ~iota/iotamc/vxworks: axis Galil Controller -- SD/telescope Axes cbcom CBCOM power modules csphere Celestial Sphere Calculations daq Data Acquisition by PICNIC camera and ADC board delay Short delay line routines gps_clock Routines for reading and syncing gps clock libs Many misc library routines longdelay Long Delay line routines star_tracker Star tracker routines, including routines for the first analog output (Matrix AO) board. telescope Telescope-related routines. As I said -- much of the guts of the Amherst vxworks code actually resides in ~iota/iotamc/lmt/mc/c++: For object/class definitions (*IMPORTANT*) ~iota/iotamc/lmt/mc/conf: For machine-generated .h files ~iota/iotamc/lmt/mc/xml: XML files for shared memory definitions --------------------------------------- B. Comments of some modules DAQ: ---- All relevant files (src/include) are contained in /daq or /star_tracker. [Except for the mv2400.h which is reference for interrupt-related macros which are machine-board specific and will not change.] Current Status: This version is based on Brewers and Pedretti modification of the April2001 version. I have attempted to document the changes and to update some features, such as new file format, use of adc converter, use of piezos There are still many problems here. One is that there is an inconsistency in the way scans and quadrants are dealt with. For scans, a series of num_scans are taken by invoking the command CMD_SCAN, after which the DAQ_Scheduler stops and rests in IOTADAQ_REST. During these scans one can request a frame be moved into shared memory lastscan using iotadaq_data->data_request =1. Also, one can choose to savedata by choosing savedata = 1 [no error checking here so please don't change savedata in the middle of scan. However! for the CMD_QUAD, the DAQ_Scheduler just sits in the CMD_QUAD loop forever reading quadrants at maximum rate. If one says data_request = 1, then the next frame will be save to the lastquadrant in shmem. The only way to stop this is to issue the command CMD_REST or CMD_SCAN which will dump it out of the loop. One could make this parallel to CMD_SCAN by adding a num_quads keyword and implementing savedata keyword. Note: in order to implement changes in the altera setup of the quad readout (integration time, size, etc.) one has to CMD_REST, then CMD_QUAD again. Important changes needed to be done: for DAQ -------------------------------------------- The header information is very incomplete; one might say completely incomplete. I have a latex/ps document on this subject at cfa-www.harvard.edu/~jmonnier/DAQ. The new current version partially uses the new adc_record_vector shmem keyword for determining which adc channels to record each scan (these are saved as ~iota/Data/*.adc) in ASCII. However, when creating the better header, one will need to save other ADC channels (ADC_RECORD_ONCE). Also, One will want to record other variables every scan, and I can't think of a general way to do this. I think a special purpose routine like the ADCbuffer will need to be written to make sure all the relevant variables we want are stored. This will likely mean defining global pointers to many of the shmem objects that exist. There should a SIMULATE mode, in shmem, which tells the DAQ to use a simulator to instead of waiting for hardware interrupts. I'm not sure how to simulate a hardware interrupt in software, but there probably is a way. Also, I personally have not tested the latest work on Piezo scanning, both the so-called 'Classical' and 'Fiber' modes. The interface with IDL is buggy and incomplete (see notes in section E). However, all the important pieces are in place and EP has put in a lot of flexibility and control into the altera control registers and setup parameters which can be utilized by an IDL interface DAQ system. Star_Tracker ------------ All relevant files are found in /star_tracker and /cbcom. I removed the det_FPGA object from the code and all references to this object. -------------------------------------------------------- C. How to start up the Vxworks code from scratch Login as iota on iota17. Start tornado: % launch & Click on Project button and start the workspace /home/iota/iotamc/vxworks/IOTAMC_2001June Download the following modules in the following order to the following cpus: cpu0 cpu1 cpu2 ------------------------------------------- gps_clock star_tracker DAQ cbcom libs csphere axis delay telescope Now open up windsh for all the cpus and run the following programs: cpu0 cpu1 cpu2 --------------------------------------- cbcom_start spawn_ccd spawn_daq gps_start spawn_shutter csphere_start delay_start telescope_start axis_start ** MISC UTILITIES ** When the above procedures are followed there are a few interesting programs that can be run from the windsh. If you download the following modules into the cpu, you can then invoke the following commands. cbcom: windsh> cbcom_start %% Same as above to start the cbcom server windsh> flip_c %% This will flip in the star aqu. camera, flip-in mirror, and motor power to show you the telescope image in monitor C using cbcom modules (make sure they are pluggedin) flip_a %% same for Tel A, but cbcom modules are not currently physically in place flip_b %% save for Tel B -- modules not in place. star_tracker: windsh> spawn_ccd windsh> spawn_shutters windsh> open_a or close_a %% open /close shutter A open_b or close_b %% open /close shutter B open_c or close_c %% etc DAQ: windsh> adc_record This program will ask you a series of questions to allow you to read out the ADconverter on any set of channels you want, with "arbitrary" time delay between sampling, and for arbitrarily long. It will print results to the screen and to a file of your choosing in ASCII. The units are in Volts. The program seems to work pretty well at 10 ms sample delay with nothing else running on the VME. I've noticed that at 1 ms time delay there are large, up to 0.5 sec, delays; but the performance at high speeds has not been tested thoroughly. ------------------------------ D. How to start the OT and run the initial observing script After completing step C above to start all the necessary vxworks programs. 1) open two xterms 2) in both, go to % cd ~iota/iotamc 3) in both, % source SOURCEME 4) in both, % cd lmt/mc 5) in one, % ./c++/startFSM 6) in the other, % mc jni Now wait a long time, and the OT will come up -- currently this mostly requires having all the cpu0 and cpu1 programs functioning, including the startracker. We must make a new version of the OT which can function w/o everything working. 7) Now go the File pull-down and open the script called: /home/iota/iotamc/lmt/mc/otscript This will setup the N15, S15, C0 coords including the current estimate for the proper magic constant/beamcombiner offsets/internal delay matrix for a beam combiner in the neutral lab frame. Also will setup the current pointing models for the telescope and turn on all the telescopes and delay lines. One just has to hit the reset button on the anorad cage for the green light to come on (red lights to go off) on the central station box. -------------------------------------------------- E. XDisplays/IDL interface The Startracker and Quadrant display are in the ~iota/XDisplays directory. The Startracker_Display program works well. The Quadrant program hasn't been used lately and (at the very least) will need to be recompiled to work under Solaris 2.8. The reason the Quadrant program hasn't been used much is because IDL can now interface to the shared memory. One can find the example of the customDAQ.script program, used to adjust and align the integrated optic with the PICNIC array. See ~iota/Idlstuff/PICNIC. The examples in vxcom.cpp will show how to read and write shared memory variables. And the customDAQ.script will show you how to use IDL. One important point is that idl must be invoked with "idl -32" to run in 32bit mode, or the call_external function will not work. Also, I have added a few libraries to the default IDL path iota, such as the Astrolib and the Freudenreich (for robust statistics) libraries. These libraries could be put in a public location but currently reside (along with a few others) in ~jmonnier/Idlstuff. ** Current situation with EP 's altera code + vxcom.cpp. I tried to come up with a good versions, new and stable versions of the DAQ_Scheduler, *rbf, vxcom.cpp (for idl shared memory) and even quad.script/customDAQ.script/oldscan.pro for running the show. However, things are a bit of a mess still due to lack of time. Ettore has his own stuff going on which is (nearly) up-to-date with my versions. The stuff that I have that works together can be found in: ~iota/iotamc/vxworks/daq (of course) ~iota/iotamc/vxworks/daq/rbf ~iota/Idlstuff/EP_Scan/customDAQ.script [for Quadrant display] /oldscan6.script [for scanning and displaying 6pix] /oldscan.script [for scanning and displaying 1pix] /vxcom.cpp (vxcom.so) ~iota/Idlstuff/PICNIC/not completely up to date with shmem exchange. ** This code shmem interface changes very rapidly by EP and so it is not possible to make a completely stable version yet. Once the camera is fully functioning we will stabilize this ** ------- Appendix This is not really an OT programmers manual, but is meant to document what pete told me about writing OT code. I hope that this can be expanded properly by those who know a lot more than me and put on the web for us to reference. To recompile the OT from scratch (to run xml scripts, generate C++ code, and compile the executables): a. goto ~iota/iotamc % source SOURCME b. % make help % offers help % make src % make cc % make jni % make java There are also command here like 'make rm' and 'make clean' but not sure when to use these (at the beginning presumably). What is in each directory of lmt/mc: [as far as I know]: c++: Contains a lot Vxworks code (from Amherst). I think these are located here because they use the machine-generated *.h files in conf: conf: This looks to be all machine-generated code based on the xml: files. These define the shared memory structures and shared memory objects with get/set method for reading and writing variables. These .h files for the shmem structure BETTER match the shmem structure definitions in the vxworks counterparts. [like it doesn't for gps_clock]. control:No idea depends:No idea doc: No idea images/gif: icons for OT include: No idea mie No idea novas No idea plot: Little stand-alone plot monitors in java. scripts: No idea sim No idea uiswing.. No idea uitty No idea uixml This is where the xml defining the OT monitors, etc. are located xml This is where all the shared memory objects are defined. These must be consistent with the shared memory as defined by the Vxworks.