Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Warnings and Fixes to be done

#

Title

User Story

Importance

Notes

1
DEVIL204-Global write to memcached
Jira
showSummaryfalse
serverINFN Ticketing System
serverId8087fedc-8816-3706-9e66-78f987f39e0c
keyLNFDCS-132
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
  • GGODSta.vi and GGODDyn.vi have the "append" and "write" cases DISABLED for debugging
2
DEVIL204-Update DBFiles
Jira
showSummaryfalse
serverINFN Ticketing System
serverId8087fedc-8816-3706-9e66-78f987f39e0c
keyLNFDCS-133
As a developer I want updated versionof DEVILs' DBFiles  so that I can use them for loading data.Must Have
  • At this moment, DBFiles of DEVILs 364, 365, 366, 367 on /u2/dcs/db/DBFile3/ differ from those used by Apple (e.g. DEVIL365 has 24 components instead of 23). 
3
DEVIL204-Program data loading
Jira
showSummaryfalse
serverINFN Ticketing System
serverId8087fedc-8816-3706-9e66-78f987f39e0c
keyLNFDCS-134
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
4

DEVIL204-Optimize bundleORB VIs

Jira
showSummaryfalse
serverINFN Ticketing System
serverId8087fedc-8816-3706-9e66-78f987f39e0c
keyLNFDCS-135

As a developer I want a fast ORB dataset recontruction so that I can obtain a real time orbit acquisition.Must Have
  • The VIs .../0_classes/GOD/library/fetchORB[Sta|Dyn].vi and their SubVIs .../0_classes/GOD/library/bundleORB[Sta|Dyn].vi must be optimized by moving the code that parses the descriptors in the "init" frame so that it is executed only once.
5

DEVIL204-Database

Jira
serverINFN Ticketing System
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId8087fedc-8816-3706-9e66-78f987f39e0c
keyLNFDCS-122

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
6DEVIL204-DBFilesAs 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
  • At this moment the DBFiles have been copied into the directory
    /u2/dcs/source_linux/0_classes/GOD/DBFile2_temporary
  • The LoadRTDB204.vi uses this temporary path
7DEVIL204-HWMaskArrayFix the HW maskMust 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.

...

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 contain constant values (saved as defaults), others are written at init by the application. 

Variables

Data type

Name

Type

Description

Data type

Name

Type

Description

abcDEVILconstant[ 364, 365 ,366, 367 ] (see fig. 1-a, 1-b)
abcelementconstant

[ ORBRAK63, ORBRAK71, ORBRAK70, ORBRAK66 ]
The sequence is sorted according to the direction of the beam for the electronic mode: clockwise, starting from rack 063 (DEVIL364)

abccontrollerIPconstant[ 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)
U32vme handle
Written at startup by the initHWGOD.vi
U32DEVILBaseAddressconstant0xE0000000 for all 4 DEVILs
U32DEVILBufferOffsetconstant0x200000 (2 MB) for all 4 DEVILs
abcHCIDynDescriptorconstant

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
.../0_classes/GOD/library/VMEMemToORBDyn.vi
that reconstructs the ORBHCIDyn cluster by using the "HCIDynDescriptor".

U32HCIDynOffsetconstantPosition of the dynamic fork in the DEVIL memory. It varies depending on the lenght of other data written before in memory
U32HCIDynNumOfLongwordsconstantThe 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.
abcHCIStaDescriptorconstant

 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
.../0_classes/GOD/library/VMEMemToORBSta.vi
that reconstructs the ORBHCISta cluster by using the "HCIStaDescriptor".

U32HCIStaOffsetconstantPosition of the static fork in the DEVIL memory. It varies depending on the lenght of other data written before in memory.
U32HCIStaNumOfLongwordsconstantThe 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.


Turn for electronsTurn for positrons


Image Modified
Image Modified


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).

...

This is the real data loader of the GODSta.vi 

Controls

Data type

Name

Description




Indicators

Data type

Name

Description




Details

Configuration folder /u2/dcs/source_linux/0_classes/GOD/configuration
has been copied from vldafneafp to vldantedev038

...