tesscience / tessfpe Goto Github PK

See Table §5.2.1 in Kari's "14011" document

When changing operating parameters using the python tool, it outputs a listing which correctly shows the new values. However, if I immediately read the housekeeping, it shows the default values, as if the change was never made. This seems to be true of other parameters, too. I confirmed that no change is made in the hardware by measuring current in the trim heater dummy load after changing the current to 100 mA, or to 227 mA. This may be due to a very recent change, since yesterday we did observe current in the trim heater dummy load.

Need to change house_keeping conversion factors for the two signals called
driver_temperature and interface_temperature. The conversions should be the same as for the four channels called ccd[1:4]_board_temperature, since the signals also come from REF43 chips.

When load wrapper is used for the first time on tessgse3 using FPE2, it hangs. Output is shown below, using the --debug option. Note that the port number on the tftp command line (70) is different from what was successfully used before on this setup (69).

tessgse3.mit.edu% load_wrapper --FPE-number 2 --debug
FPE2> cam_control
cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_hsk
FPE2> cam_control
cam_control
cam_control
cam_control
cam_control
Timeout
FPE2> cam_control
cam_control = 0x00000004
cam_control
FPE2> cam_control = 0x00000004
camrst
FPE2> FPE Reset complete
cam_control = 1
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
camrst
FPE2> FPE Reset complete
cam_control = 1
FPE2> cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
cam_fpga_rst
FPE2> Resetting Cam FPGA
cam_control
Cam FPGA Reset done.
FPE2> cam_control
cam_control = 0x00000000
Running:
tftp <<EOF

mode binary
connect 192.168.100.1 70
put /usr/lib/python2.7/site-packages/tessfpe/dhu/MemFiles/FPE_Wrapper-6.2.3.bin bitmem2
EOF
cam_control
FPE2> cam_control = 0x00000000

CTRL-C at this point

FPE2> cam_control
cam_control = 0x00000000
cam_control
FPE2> cam_control = 0x00000000
Traceback (most recent call last):
File "/usr/bin/load_wrapper", line 45, in
dhu_reset=args.dhu_reset))
File "/usr/lib/python2.7/site-packages/tessfpe/dhu/fpe.py", line 138, in load_wrapper
self.upload_fpe_wrapper_bin(fpe_wrapper_binary)
File "/usr/lib/python2.7/site-packages/tessfpe/dhu/fpe.py", line 415, in upload_fpe_wrapper_bin
"bitmem" + str(self.fpe_number))
File "/usr/lib/python2.7/site-packages/tessfpe/dhu/fpe.py", line 197, in tftp_put
self.connection.wait_for_pattern(r'.*Load complete\n\r')
File "/usr/lib/python2.7/site-packages/tessfpe/dhu/fpesocketconnection.py", line 85, in wait_for_pattern
data = str(self.socket.recv(chars)).encode()
KeyboardInterrupt

There should be a tool for getting the Serial Number from an FPE board.

Please update testsuite.sh to default to 6.1t.5. The previous version (6.1t.4) has a bug in it which does not allow the LEDs to be turned off.

We should have nested includes

The tutorial should have a link to the FPGA design spec.

Using tessfpe version 6.2.6.
Running load_wrapper 6.2.3 --dhu-reset
then
upload_fpe_program /../UpAndRunning-draft-1.0.fpe
then
frames_running_status
gives the output Frames are running despite the fact that start_frames was never issued.

Using tessfpe 6.2.6 with ObsSim version 1.7d on tessgse2. Starting out with cam_fpga_rst and dhu_rst.

Load_wrapper 6.2.3 loads OK, but upload_fpe_program hangs. Using the --debug feature I see that the sequencer memory seems to be loading OK but the program times out after trying to tftp the program memory. It appears to be waiting for a pattern it never gets.

Very similar commands seem to work fine, however, on cosmos, caladan, and tessgse4, so it's also possible this is a configuration issue on tessgse2.

The latest FPGA binary is 6.2.4. Please update the tools so that load_wrapper 6.2.4 finds the file.

Currently, load_wrapper fails if it finds supply voltages out of range (unit_tests fails). Since some ObsSim units have -12V supplies, and some have -15V supplies, this will prevent load_wrapper from completing for some ObsSim setups.

It would be better if load_wrapper simply reported the -15V supply, but otherwise completed normally.

Currently scan_plots creates a set of 26 pdfs in the tmp/ directory, along with a summary PDF including all 26. It will be much more convenient if scan_plots outputs only the summary PDF, and puts it in the directory from which scan_plots is called.

From "make install_testsuite" in a virgin clone, something creates this and then "make venv" chokes on it.

It would be nice if the load_wrapper script did the following:

• expose a --force command so the user can force the FPE stack to install another FPGA binary
• take a file as its argument rather than a FPGA binary version

The attached file is a reference set of expected housekeeping values for the case where a stack of 3 boards is assembled and an RTD/Heater Dummy Load is connected. This was based on a stack consisting of a 6.2 Interface, a 6.1T Driver, and a 6.2 Video, at room temperature, with CCD connectors open.

Reference sets (to be created by EB ) will be identified as follows:
Set A: Interface only
Set B: Interface + Driver
Set C: Interface + Driver + Video, no dummy loads attached
Set D: Interface + Driver + Video, RTD/HTR dummy load attached
Set E: Interface + Driver + Video, 4 CCD Simulators and the RTD/HTR dummy load attached

HK_Reference_D.txt

We should be smarter about includes and comments