...
# | Title | User Story | Importance | Notes | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
| As a developer I want a new DEVIL204 control so that I can put it into the new DEVIL204DEVIL704 |
| |||||||||||||
| 2 | DEVIL204-Global write to memcached
| As a developer I want GGODSta.vi and GGODDyn.vi have the "append" and "write" cases ENABLED so that I can validate real memcached write operations. | Must Have |
| ||||||||||||
| 3 | DEVIL204-Update DBFiles
| As a developer I want updated versionof DEVILs' DBFiles so that I can use them for loading data. | Must Have |
| ||||||||||||
| 4 | DEVIL204-Program data loading
| As a developer I want valid orbit values (that is equal to legacy Apple data) so that I can use the same UI. | Must Have | |||||||||||||
| 5 | DEVIL204-Optimize bundleORB VIs | As a developer I want a fast ORB dataset recontruction so that I can obtain a real time orbit acquisition. | Important |
| ||||||||||||
| 6 | DEVIL204-Database
| As a developer I want all the data available in the new program global variables so that I can develop the acquisition code. | Must Have | |||||||||||||
| 7 | DEVIL204-HWMaskArray
| Fix the HW mask | Must Have | |||||||||||||
| 8 | Comparison of Orbits through proxy and 704 | |||||||||||||||
| 9 | To be discussed with Angelo Stella | Must Have | The method to update the offset configuration file (now resident on the Linux AFP server) has been discussed with Angelo. He said that he has checked with Paolo how to edit it. | |||||||||||||
| To be discussed with Paolo | Must Have | Alive, SysReset, OrbitProxy, Solaris window and subVI, system wide conseguences?
| ||||||||||||||
DONE | Reintroduced the "persistent error" that is an error that repeats continuously for 6 times (~ 1 second). |
...
| Code Block | ||
|---|---|---|
| ||
[GOD_Parameters] maxErrors=25 |
...
GGODConnection.vi
The purpose of this global is to keep all program data in one place, but a reorganization in the final version is strongly recommended. At the present moment some fields
| Warning |
|---|
Even though the use of LV globals with values saved as default is deprecated, this global has been introduced to speed up the porting of the code from legacy Apple DEVIL to Linux VM. Some fields of the global contain constant values (saved as defaults), others are calculated and written at HWInit. |
...
A reorganization of data in a next version is strongly recommended. |
Data type | Name | Type | Description |
|---|---|---|---|
Data type | Name | Type | Description |
| abc | DEVIL | constant | [ 364, 365 ,366, 367 ] (see fig. 1-a, 1-b) |
| abc | element | constant | [ ORBRAK63, ORBRAK71, ORBRAK70, ORBRAK66 ] |
| abc | controllerIP | constant | [ 192.168.192.91, 192.168.192.92, 192.168.192.93, 192.168.192.94 ] The sequence is sorted according to the direction of the beam for the electronic mode: clockwise, starting from rack 063 (DEVIL364) |
| U32 | vme handle | Written at startup by the initHWGOD.vi | |
| U32 | DEVILBaseAddress | constant | 0xE0000000 for all 4 DEVILs |
| U32 | DEVILBufferOffset | constant | 0x200000 (2 MB) for all 4 DEVILs |
| abc | HCIDynDescriptor | constant | It varies depending on the DEVIL36X.DBDyn content In order to fill the ORBHCIDyn cluster with data read from the SIS3153 interface, we read "HCIDynNumOfLongwords" longwords starting from "HCIDynOffset. Data are then passed to the VI |
| U32 | HCIDynOffset | constant | Position of the dynamic fork in the DEVIL memory. It varies depending on the lenght of other data written before in memory |
| U32 | HCIDynNumOfLongwords | constant | The 4 HCIDyn have different length but we use a safe value to fetch any of them without missing any piece of data. The value is set to 64 longwords. |
| abc | HCIStaDescriptor | constant | It varies depending on the DEVIL36X.DBSta content In order to fill the ORBHCISta cluster with data read from the SIS3153 interface, we read "HCIStaNumOfLongwords" longwords starting from "HCIStaOffset. Data are then passed to the VI |
| U32 | HCIStaOffset | constant | Position of the static fork in the DEVIL memory. It varies depending on the lenght of other data written before in memory. |
| U32 | HCIStaNumOfLongwords | constant | The 4 HCISta have different length but we use a safe value to fetch any of them without missing any piece of data. The value is set to 240 longwords. |
| Boolean | ctrlInitDone | variable | Indicates if the Control has been initialized. This flag is set to false by the openGOD VI and to true by the control after the initialization. |
| Boolean | doSleep | variable | Not used at this moment (01/03/2022) |
...
This VI reads and returns the last data acquired from the 4 DEVILs. It doesn't perform any data reordering or padding (see "Details" paragraph below). The X and Y arrays have 32 components , such as the number of channels of the multiplexer connected to the DVM.
...
| Each one of the 4 DEVILs has a circular buffer of 1927 lines named "sockets". Write operations of the four circular buffers are synchronized via a common stobe strobe so that the four write pointers are always alligned. At each strobe, each DEVIL stores a "socket" composed as:
DBL ACQNum [0, 1926]; The socket header is written twice: at the beginning of the socket (before part X) and again in the middle of the socket (before part Y) the content of the two headers being the same; this is due to historical reasons and – although it is a waste of memory space – it was left in order not to compromise the functioning of other pieces of code that access the same memory area.
[DBL] 32 values of the BPM X signals from the Bergoz modules read from that DEVIL;
[DBL] 32 values of the BPM Y signals from the Bergoz modules read from that DEVIL. The 32 components in part X and Y are ordered according to the cabling and do not necessarily follow the sequence of the BPMs along the vacuum chamber. Moreover the 32 values refer to both e- and e+ rings for which the BPMs sequence is obviously different. As a consequence, part X and Y must be considered as raw containers and their content must be further processed in order to reconstruct the real orbit. |
...
This VI is a functional global that stores, holds and returns the last X and Y parts acquired from the 4 DEVILs (as they come out from the readDEVILSocket VI). The X and Y arrays have 32 components, such as the number of channels of the multiplexer connected to the DVM. This VI doesn't perform any data reordering or padding. Data are not queued: each write operation with the same DEVILIndex overwrites the previous one.
...