Goals
- improve the stability of the DAFNE orbit acquisition system.
Overall strategy
- develop and debug the new DEVIL204 along with the regular run of the legacy system;
- get rid of the phisical DEVIL204 by moving its code to a virtual machine;
- get rid of the 4 LEXTEL couples by employing the SIS3153 VME Ethernet controllers.
Repository
Type | Details |
---|---|
Type | git |
Link / Path | https://baltig.infn.it/lnf-da-control/lv-dcs-new204 NOTE: the only file included in the git repo is GOD.lvproj . No VIs are included in the git repo at this moment. |
Branch | main |
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) |
Description
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.
Repo git clonato in: /u2/dcs/source_linux/lib/lv-vme-chaos-driver
(dovrebbe essere creato nella /usr/local/natinst/LabVIEW-2012/user.lib/ ma questo andrebbe poi fatto su tutte le macchine. Messo invece nella .../source_linux/lib/ , vale per tutti).
Warnings
GGODSta.vi and GGODDyn.vi have the "append" and "write" cases DISABLED to avoid memcached real write operations
A LabVIEW project (GOD.lvprog) keeps track of all the DEVIL204 VIs.
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.
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).
Controls
Data type | Name | Description |
---|---|---|
Bool | ddIn | Legacy data-dependency input |
Indicators
Data type | Name | Description |
---|---|---|
Bool | ddOut | Legacy data-dependency output. ddOut = T 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
---
closeGOD.vi
Close the IP connections with the four VME SIS3153 controllers and dispose the connection handles.
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 |
Details
---
Examples
---
GGODConnection.vi
Array of cluster. Some variables are constants saved as default values
Variables
Data type | Name | Type | Description |
---|---|---|---|
abc | DEVIL | constant | [ 364, 365 ,366, 367 ] The sequence is sorted according to the direction of the beam for the electronic mode: clockwise, starting from rack 063 (DEVIL364) |
abc | element | constant | [ ORBRAK63, ORBRAK71, ORBRAK70, ORBRAK66 ] |
abc | controllerIP | constant | [ 192.168.192.91, 192.168.192, 192.168.192.92, 192.168.192.93, 192.168.192.94 ] |
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. |
Turn for positrons | Turn for electrons |
---|---|
Picture 1-a: The sequence is sorted according to the direction of the electrons beam: counterclockwise, starting from rack 071 (DEVIL365 > 364 > 367 > 366) | Picture 1-b: The sequence is sorted according to the direction of the positrons beam: clockwise, starting from rack 063 (DEVIL364 > 365 > 366 > 367) |
Details
---
Examples
---
GRawBuffer.vi
LNFDCS-122 - Getting issue details... STATUS