ChrisM-S
commented
7 years ago There seem to be three or four layers related to "intelligent" third-party applications which we may write some code for and we run as part of Ibex. As with "settings", it would be useful to identify generic paths where this sort of code lives. I don't know if it might be in support modules, but I'm sort of hoping "LabVIEWModules" would naturally find a place in the same tree as the others. I've tried to group them below by example.
The reason this matters is that each storage "class" will be handled differently, the link to the VHDs with different storage types can be done at any folder level but obviously fewer links make the structure easier to maintain.
| Platform (installed+system code) | Our Code (common, loaded with IBEX) R/O | Settings R/W+git (inst specific) | Valuable produced or recorded data |
|---|---|---|---|
| Installed with OS platform | Installed with IBEX install | Initialized/saved/recovered on per instrument basis | Moved and archived |
| No backup (platform kept) | No backup | backup per inst | backup as cache (per inst) until archived |
| ----- | ------ | ----- | ----- |
| LabVIEW | Ibex VIs | .ini files | diagnostics logs |
| Python | Ibex Python code | config settings files | ??? |
| MySQL | SQL scripts | recorded settings (my.ini) | experiment parameter logs |
| Java | Ibex Java code | Java Client/Server settings | ??? |
| ICP | standard IBEX GENIE python scripts | Tables | saved Nexus files |
| NI DAQ | NiDAQ tasks | configuration files | saved data files |
Currently Ibex uses a few pieces of LabView Modules, but this is outside of our change control and mixes read-only executables with read-write instrument settings. As a (self-aggrandising) system architect I would like a standalone version of LabView modules for Ibex that contains no instrument-specific information.