| Page properties | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| ||||||||||||||||||||||||||||||||||||||||||||
|
Goals
- improve the stability of the DAFNE orbit acquisition system;
- replace the phisical DEVIL204 with a virtual machine;
- get rid of the 4 LEXTEL couples by employing the SIS3153 VME Ethernet controllers.
Overall strategy
- develop and debug the new DEVIL204 along with the regular run of the legacy system;
due to safety reasons, the development of the new DEVIL204 takes place on the virtual machine vldantedev038 that temporarily mounts a copy of the dcs_lv12/source_linux actual directory.
Any VIs and data files created/modified/removed concern the directories:/u2/dcs/source_linux/0_classes/GOD/
/u2/dcs/source_linux/devils/DISARMED/DEVIL204-NEW/
/u2/dcs/source_linux/lib/lv-vme-chaos-driver/Any derogation from this assumption will be highlighted.
Repository
- .
Repository
| Type | Link / Path | Note |
|---|---|---|
git | https://baltig.infn.it/lnf-da-control/lv-dcs-new204 | New DEVIL 204 LabVIEW project ( |
| Type | Link / Path | Note |
git | https://baltig.infn.it/lnf-da-control/lv-dcs-new204 | New DEVIL 204 LabVIEW project (for standard "vldantedev" machines) The only file included in the git repo is GOD.lvproj (no VIs are included in the git repo at this moment.) |
...
| . |
Links
AFP Management (Old Devil Filesystem)
Hardware description
| Type | Description |
|---|---|
| Processor | Standard DANTE virtual machine vldantedevxxx |
| VME controllers | Nr. 4 VME controller SIS3153 USB-0 USB3.0-VME Interface with 1 Gbps SFP Tranceiver |
| VME hardware | Standard Apple DEVILs (364-5-6-7), HP DVM+MUX |
| Hardware | Bergotz modules for BPM signal acquisition |
Programming languages
| Language | Required Add ons/Plugins/Extensions/Libraries |
|---|---|
| LabVIEW 12.0.1f5 (32-bit) | liblv2vmechaos.lvlib (for SIS3153 usage) |
...
GODCtrl – warnings and fixes
# | 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
| 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. | Must HaveImportant |
| |||||||||||||||||||
| 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 | 8 | DEVIL204-HWMaskArray| Jira | | ||||||||||||||||||||
| showSummary | false | server | As a developer I want the DEVIL204 DBSta and DBDyn in the real working directory so that the DCS can find them where espected. | Must Have |
| HWMaskArray
| Fix the HW mask | Must Have |
Al momento la difficoltà maggiore è quella di riottenere una tabella di ordinamento tramite i VIs:
precompileORB.vi
precompileORB_IR.vi
I suddetti VIs sono stati modificati per quanto riguarda il recupero degli indirizzi ma ci sono degli errori.
Command warnings and fixes
| 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). |
GODCmd – warnings and fixes
# | Title | User Story | Importance | Notes | |||||
|---|---|---|---|---|---|---|---|---|---|
| 1 |
|
#
Title
User Story
Importance
Notes
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
As a developer I want a new DEVIL204 command so that I can put it into the new DEVIL204
DEVIL204-system commands
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
ONLN, BYPS, EMSK, PUTT
- ONLN [ON | OFF]
- BYPS [ON | OFF]
- EMSK <integer number>
- PUTT HCI,<flattened string>
|
CALC [OFF | AVR <n> | VAR <n>]
where n ≥ 2
| Warning |
|---|
This command should be redefined because now the average is calculated along with the RMS (variance). |
where what can be: MSKE+, MSKE-, MSKI1, MSKI2
File ".../0_classes/GOD/configuration/<file name>.lst"
Path: /u2/dcs/source_linux/0_classes/GOD/configuration/
| Code Block | ||
|---|---|---|
| ||
Name azimuth[m] allHOffset[mm] allVOffset[mm] IROffset [mm] refOrbH[m] refOrbV[mm] rotationAngle IP1/IP2 azimuth [m] |
GGODSta.vi / DEVIL204.DBSta
This global is initialized with data from the DBSta file. The DBSta file contains dummy data (all zeros) and is only used to correctly dimension the arrays.
The filling of the global with actual data is done via the GODStartup.vi program using the file:
| Code Block |
|---|
/u2/dcs/source_linux/0_classes/GOD/configuration/<file name>.lst |
| Code Block | ||
|---|---|---|
| ||
%GOD
#GOD**001
@HCI(S) [(I32),(DBL),DU32,DU32,DU32,DU32,DU32,DU32,HI32,HI32,HI32,HI32,HI32,HI32,HI32,HI32,HI32:4,HI32:64,HI32:64,DU16:4,DU16:4,DU16:4,DU16:4,(DBL):64,DBL:64,DBL:64,DBL:64,(DBL):64,DBL:64,DBL:64,DBL:64,(DBL):64,(DBL):64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64] |
GGODDyn.vi / DEVIL204.DBDyn
This global is initialized with data from the DBDyn file. The DBSta file contains almost only dummy data and is mainly used to correctly dimension the arrays.
The filling of the global with actual data is done via the GODStartup.vi program using:
- the content of the dynamic fork of the ORB element of DEVIL364 (the master of the 4 DEVILs)
- the value of a string hard coded into the DEVIL204 control program.
| As a developer I want a new DEVIL204 command so that I can put it into the new DEVIL204 | Must Have | ||||||||||||||
| 2 | DEVIL204-system commands
| ONLN, BYPS, EMSK, PUTT | Must Have |
| ||||||||||||
| 3 | DEVIL204-GOD class commands
| CALC, SETT, LOAD | Must Have |
|
...
File ".../0_classes/GOD/configuration/<file name>.lst"
Path: /u2/dcs/source_linux/0_classes/GOD/configuration/
| Code Block | ||
|---|---|---|
| ||
Name azimuth[m] allHOffset[mm] allVOffset[mm] IROffset [mm] refOrbH[m] refOrbV[mm] rotationAngle IP1/IP2 azimuth [m] |
GGODSta.vi / DEVIL704.DBSta
This global is initialized with data from the DBSta file. The DBSta file contains dummy data (all zeros) and is only used to correctly dimension the arrays.
The filling of the global with actual data is done via the GODStartup.vi program using the file:
| Code Block |
|---|
/u2/dcs/source_linux/0_classes/GOD/configuration/<file name>.lst |
| Code Block | ||
|---|---|---|
| ||
%GOD
#GOD**002
@HCI(S) [(I32),(DBL),DU32,DU32,DU32,DU32,DU32,DU32,HI32,HI32,HI32,HI32,HI32,HI32,HI32,HI32,HI32:4,HI32:64,HI32:64,DU16:4,DU16:4,DU16:4,DU16:4,(DBL):64,DBL:64,DBL:64,DBL:64,(DBL):64,DBL:64,DBL:64,DBL:64,(DBL):64,(DBL):64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64,DBL:64] |
...
GGODDyn.vi / DEVIL704.DBDyn
This global is initialized with data from the DBDyn file. The DBSta file contains almost only dummy data and is mainly used to correctly dimension the arrays.
The filling of the global with actual data is done via the GODStartup.vi program using:
- the content of the dynamic fork of the ORB element of DEVIL364 (the master of the 4 DEVILs)
- the value of a string hard coded into the DEVIL204 control program.
| Code Block | ||
|---|---|---|
| ||
%GOD
#GOD**002
@HCI(S) [(DBL),DI32,DU32 | ||
| Code Block | ||
| ||
%GOD #GOD**001 @HCI(S) [(DBL),DI32,DU32,DU32,DI32,TF,TF,TF,TF,DI32,DU16:32,TF,TF,TF,TF,HI32,HI32,DI32,DI32,DI32,DI32,DI32,DI32,DI32DU16:4,DU16:4,DU16:4,DU16:4,DU16:4,DU16:4]:4] |
...
DEVIL704.pref
The GOD class requires a dedicated section in the DEVIL pref file
| 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. |
Variables
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 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.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) |
| Turn for electrons | Turn for positrons |
|---|---|
 |  |
| Figure 1-a: The sequence [0,1,2,3] is sorted according to the direction of the electrons beam: starting from rack 063 (DEVIL364 > 365 > 366 > 367) | Figure 1-b: The sequence [1,0,3,2] is sorted according to the direction of the positrons beam:, starting from rack 071 (DEVIL365 > 364 > 367 > 366) |
...
initHWGOD.vi
Open the IP connections with the four VME SIS3153 controllers and return the connection handles.
The VME access is A32, D32 and "block transfer" is enabled.
The VME mapped size is 4 MByte (that is the whole Apple DEVIL memory).
The vme_base_address is set to E0000000 (which is the DEVIL extended base address).
Load the VME connection handles into the GGODConnection
Initialize the "aliveLogic.vi" state machine).
Controls
Data type | Name | Description |
|---|---|---|
| Bool | ddIn | Legacy data-dependency input |
Indicators
Data type | Name | Description |
|---|---|---|
| Bool | ddOut | Legacy data-dependency output. ddOut = True indicates that an error occourred in the vme_open |
Details
| Warning |
|---|
The connector pane pattern for all initHWXXX VIs is fixed and mandatory and – for (wrong) historical reasons – does not return any errors. |
Examples
---
GODStartup.vi
This is the real data loader of the GODSta.vi
Controls
...
Data type
...
Name
...
Description
...
Indicators
...
Data type
...
Name
...
Description
...
Details
...
the status element of the output error cluster of the vme_open SubVI. ddOut = True indicates that an error occourred in the vme_open |
Details
| Warning |
|---|
The connector pane pattern for all initHWXXX VIs is fixed and mandatory and – for (annoying) historical reasons – does not return any errors. |
Examples
---
...
GODStartup.vi
- close the IP connections with the four VME SIS3153 controllers and dispose the connection handles;
- close the four references to the VI template "2D_FIFO".
...
This is the real data loader of the GODSta.vi
Controls
Data type | Name | Description |
|---|---|---|
| Bool | ddIn | Legacy data-dependency input |
| errorCluster | errorIn |
Indicators
Data type | Name | Description | ||
|---|---|---|---|---|
| ddOut | Legacy data-dependency output | errorCluster | errorOut |
Details
...
Configuration folder /u2/dcs/source_linux/0_classes/GOD/configuration
has been copied from vldafneafp to vldantedev038
Examples
---
...
closeGOD.vi
- close the IP connections with the four VME SIS3153 controllers and dispose the connection handles;
- close the four references to the VI template "2D_FIFO".
Controls
Data type | Name | Description |
|---|---|---|
| Bool | ddIn | Legacy data-dependency input |
| errorCluster | errorIn |
Indicators
Data type | Name | Description |
|---|---|---|
| Bool | ddOut | Legacy data-dependency output |
| errorCluster | errorOut |
---
Examples
---
Details
---
Examples
---
...
...
readDEVILSocket.vi
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 as the number of channels of the multiplexer connected to the DVM.
Controls
Data type | Name | Description |
|---|---|---|
| boolean | init | T = initialize, F = regular run init = F: reads the socket "socketNumber" from the VME memory of the DEVIL "DEVILIndex" and returns the two parts |
| I32 | DEVILIndex | Index in the range [0, 1, 2, 3] corresponding to: INDEX 0, 1, 2, 3 |
| I32 | socketNumber | Pointer to the acquisition buffer in the range [0, 1926] |
| [DBL] | part X | Array of 32 DBL components containing the raw values of the X signals coming from both electron and positron BPMs. The components are in the same order of the values in the DEVIL memory locations. |
| [DBL] | part Y | Array of 32 DBL components containing the raw values of the Y signals coming from both electron and positron BPMs. The components are in the same order of the values in the DEVIL memory locations. |
| errorCluster | errorIn | When true, the VI does nothing and simply passes the error out. |
Indicators
Data type | Name | Description |
|---|---|---|
| [DBL] | part X | Array of 32 DBL: see corresponding control description above. The array is returned both for read and write operations. |
| [DBL] | part X | Array of 32 DBL: see corresponding control description above. The array is returned both for read and write operations. |
| errorCluster | errorOut | [ACQ numbers mismatch (num0, num1, num2, num3)] |
Details
| 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. |
Examples
---
...
GRawBuffer.vi
This VI is a functional global that stores, holds and returns the last X and Y parts acquired from the 4 DEVILs. It 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.
Controls
Data type | Name | Description |
|---|---|---|
| I32 | DEVILIndex | Index in the range [0, 1, 2, 3] corresponding to: INDEX 0, 1, 2, 3 |
| enum | mode | [init, read, write X and Y, write X, write Y] (read)
|
| [DBL] | part X | Array of 32 DBL components containing the raw values of the X signals coming from both electron and positron BPMs. The components are in the same order of the values in the DEVIL memory locations. |
| [DBL] | part X | Array of 32 DBL components containing the raw values of the Y signals coming from both electron and positron BPMs. The components are in the same order of the values in the DEVIL memory locations. |
| errorCluster | errorIn |
Indicators
Data type | Name | Description |
|---|---|---|
| [DBL] | part X | See corresponding control description above. The X array is returned both for read and write operations. |
| [DBL] | part X |
Indicators
| See corresponding control description above. The Y array is returned both for read and write operations. | ||
| errorCluster | errorOut |
Details
Write operation for both X and Y arrays: DEVILIndex selects the same lines of the two blocks and stores the two arrays. The previous content of the two lines is overwritten.
Examples
---
...
buildOrbit.vi
Gets raw data from the functional global GRawBuffer and reconstruct the actual orbit (horizontal or vertical). The mode (electrons or positrons) is determined by the DEVILSequence array The VI resizes the orbit to the standard 64 components by placing dummy values at the posizions indicated by HWMaskArray.
Controls
Data type | Name | Description |
|---|---|---|
| errorCluster | errorIn |
Indicators
Data type | Name | Description |
|---|---|---|
| [DBL] | part X | See corresponding control description above. The X array is returned both for read and write operations. | [DBL] | part X | See corresponding control description above. The Y array is returned both for read and write operations.
| errorCluster | errorOut |
Details
...
...
Examples
---