This pull request contains several non-insignificant changes:
1) The python scripts now have an environment variable aware behaviour and have been moved to gemdaq-testing/setup/scripts/python
2) Due to compatibility with some uhal libraries (as far as I could tell) the address table files have moved from data to gemdaq-testing/setup/etc/addresstables
3) Two new environment variables are now necessary GEM_ADDRESS_TABLE_PATH and GEM_PYTHON_PATH, and they are set in gemdaq-testing/setup/paths.sh
4) The HW interfaces have been modified fairly drastically, which removed some functionality, and modified the constructors a bit. This move is in advance of removing other functionality from the public part of the interface
4b) GEMGLIBSupervisorWeb and gemHwMonitorWeb have been modified to account for this; GEMTBUtils and friends have just had some lines commented out, meaning there will probably be runtime issues which I'll try to sort out in a future pull request
5) GEMSupervisor is the future of GEMGLIBSupervisorWeb and has a basic structure. GLIBManager properly uses the GEMFSM. AMC13Manager is generic and just displays the html status page at the moment. OptoHybridManager is a clone of GLIBManager, VFAT2Manager has not yet been migrated.
Future steps will be to make GEMSupervisor "supervise" the manager applications, and link in the hwMonitor in a clean way. GEMDataParker will move to be similar to the manager applications, in that it will be supervised by GEMSupervisor, and have an FSM for controlling the state transitions. It also needs to possibly receive SOAP messages with some information, e.g., header parameters for scan routines.
I have two local branches, one for future V2 firmware functionality and one for the supervised applications development, both branched from this point.
This pull request contains several non-insignificant changes: 1) The python scripts now have an environment variable aware behaviour and have been moved to gemdaq-testing/setup/scripts/python 2) Due to compatibility with some uhal libraries (as far as I could tell) the address table files have moved from data to gemdaq-testing/setup/etc/addresstables 3) Two new environment variables are now necessary GEM_ADDRESS_TABLE_PATH and GEM_PYTHON_PATH, and they are set in gemdaq-testing/setup/paths.sh 4) The HW interfaces have been modified fairly drastically, which removed some functionality, and modified the constructors a bit. This move is in advance of removing other functionality from the public part of the interface 4b) GEMGLIBSupervisorWeb and gemHwMonitorWeb have been modified to account for this; GEMTBUtils and friends have just had some lines commented out, meaning there will probably be runtime issues which I'll try to sort out in a future pull request 5) GEMSupervisor is the future of GEMGLIBSupervisorWeb and has a basic structure. GLIBManager properly uses the GEMFSM. AMC13Manager is generic and just displays the html status page at the moment. OptoHybridManager is a clone of GLIBManager, VFAT2Manager has not yet been migrated.
Future steps will be to make GEMSupervisor "supervise" the manager applications, and link in the hwMonitor in a clean way. GEMDataParker will move to be similar to the manager applications, in that it will be supervised by GEMSupervisor, and have an FSM for controlling the state transitions. It also needs to possibly receive SOAP messages with some information, e.g., header parameters for scan routines.
I have two local branches, one for future V2 firmware functionality and one for the supervised applications development, both branched from this point.