Document status
DRAFT
Document owner

Alessandro Stecchi

Designer
Developers
QA

Description

Single Power Supplies.

Static Fork


DBFile example
#QUATT007
@HCI(S)[(I32),(DBL),HU32,DBL,DBL,DBL,DBL,DI32,DBL:2:4]
MG1,QUATT007,01010001,0.1,3.0,3.0,3.0,1,11.0:12.0:13.0:14.0:21.0:22.0:23.0:24.0
@ReadOut(A)[(DBL),DBL,DBL,DBL,DBL,DBL,DBL]
currRead,1.5258789E-3,0.0,0.0,100.0,0.05,0.5
voltRead,1.0,0.0,0.0,255.0,255.0,255.0
slewRead,0.002444987775,0.0,1,10.0,0.02,1.0
ADCCRead,1.0,0.0,0.0,10.0,1.0,3.0
@Settings(A)[(DBL),DBL,DBL,DBL,DBL,DBL]
currSett,1.5258789E-3,0.0,0.0,100.0,0.001
slopSett,0.002444987775,0.0,1,10.0,0.02
@EXTRA(S)[DI32,DI32,DI32:2:1]


Json
{
  "MG1HCISta.ctl": {
    "recordClass": 0,
    "elemName": 0,
    "elemType": 0,
    "maxCmdExeTime#0": 0,
    "maxCmdExeTime#1": 0,
    "maxCmdExeTime#2": 0,
    "maxCmdExeTime#3": 0,
    "polaritySwitch": 0,
    "interpolCoeff": [
      []
    ]
  },
  "readOutArray": [],
  "settingArray": [],
  "MG1ExtraSta": {
    "serialChID": 0,
    "slaveAddress": 0,
    "E642PgmTable": [
      []
    ]
  }
}

Dynamic Fork

DBFile example
#QUATT007
@HCI(S)[(DBL),DI32,DI32,DI32,DI32,DI32,DI32,TF,TF,TF,TF,TF,TF,DBL,DI32,DI32,DBL,DBL,DI32,DI32,DBL,DBL,DBL,DU32:4]
QUATT007,0,000,0,0,0,0,1,0,1,0,0,0,0.0,0,0,0.0,9.9,0,0,0.0,9.9,0.0,0:0:0:0


Json
{
  "MG1HCIDyn": {
    "elemName": 0,
    "status": 0,
    "consoleName": 0,
    "errorMask": 0,
    "cmdExeStartTime": 0,
    "maxCmdExeTime": 0,
    "cmdExecution": 0,
    "sysFlags": {
      "onLine": false,
      "byPass": false,
      "remote": false,
      "busy": false
    },
    "triggerArmed": false,
    "rampOn": false,
    "currentPreSetting": 0,
    "statusSetting": 0,
    "polaritySetting": 0,
    "currentSetting": 0,
    "slewRateSetting": 0,
    "cycleMode": 0,
    "outputPolarity": 0,
    "outputCurr": 0,
    "slewRateReadout": 0,
    "outputVolt": 0,
    "faults": []
  }
}

Details

Status codes

MG1HCIDyn.status = readout status

0  = Shutted down (status not readable)
1  = Standby
2  = Operational
3  = Faulty (there are some interlocks on the PS)
4  = Bad (Communication error or protocol violation or incoherent information)

Element type descriptor

The elemType descriptor discriminates the PS sub-class (OCEM E642, DANFYSIC SYS8X00, etc...)

@HCI(S)[(I32),(DBL),HU32,DBL,DBL,DBL,DBL,DI32,DBL:1:5]

MG1,DVRTT001,00010101,3,3.0,3.0,3.0,1,0.812713:3.660710:0.002425:-0.000008:-0.0

byte 3

PS type

(*) meaningful only for E642 and EEI

byte 2

Polarity control

byte 1

InterfaceType

(*) meaningful only for SYS8X00, serial Modbus

byte 0

Protocol

E642 (alarm type)

0 = 1, 5A, 5B
1 = 2, 3, 4
2 = DIP/WIG
3 = TermPoleWIG

EEI

1 = Quadrupoles DC
2 = Dipoles DC
3 = Pseudo-pulsed

0 = bipolar
1 = unipolar with rem. ctl
2 = unipolar without rem. ctl

0 = SYS8000
1 = SYS8X00 uni
2 = SYS8800 bip

0 = E642 uni
1 = E642 bip
2 = E642 pulsed

0 =  Splitter(modbus)
1 = Skew(modbus)
2 = BTF_Pulsed(modbus)

0 = SYS8X00
1 = E642
2 = Modbus
3 = Probus
4 = VSP
5 = Genesys
6 = CAENels Easy Driver
7 = Modbus TCP EEI
8 = CAENels NGPS (new UFS)

NOTE (*): byte 1 and byte 3 are decoded by the elemType2InterfaceType VI only for some PS classes:

  • byte 1 is meaningful only for SYS8X00 and serial Modbus
  • byte 3 is meaningful only for E642 and EEI
  • byte 0 and byte 2 do not depend on "protocol" and are passed through as they are.
    Be aware that byte 1 and byte 3 can also be used to discriminate other types but, in that case, they have to be interpreted by a dedicated piece of code.

Most recent elemType descriptors


byte 3 (*)byte 2byte 1 (*)byte 0
EEI Quadrupoles DC01010007
EEI Dipoles DC02010007
EEI Dipole pseudo-pulsed03000007
CAENels NGPS (new UFS).........08

Pattern for EEI

byte 3      01 = Type quadrupole DC, 02 = Type dipole DC, 03 = Type dipole pseudo-pulsed
byte 2      00 = bipolar, 01 = unipolar with remote control of polarity change
byte 1       xx = interface type (unique in this case ?) TO BE DECIDED: maybe the pseudo-pulsed should be different
byte 0      07 = Protocol EEI

Pattern for CAENels NGPS

byte 3      xx = TO BE DECIDED
byte 2      xx = TO BE DECIDED
byte 1       xx = TO BE DECIDED
byte 0      08 = Protocol CAENels NGPS

How to search for a specific elemType in all DBSta files

Example of DBFile for an element of class "MG1"
%MG1
#DHSA*001
@HCI(S)[(I32),(DBL),HU32,DBL,DBL,DBL,DBL,DI32,DBL:2:4]
MG1,DHSA*001,00020000,0.1,3.0,3.0,3.0,1,11.0:12.0:13.0:14.0:21.0:22.0:23.0:24.0
... etc ...
             XXXXXX00
			       --

The first byte of the elementType field, indicates the PS protocol (e.g. in the above example, "00" indicates the protocol SYS8X00).

Using the egrep command

egrep "^MG1,.{8},[0-9]{6}00," ./DEVIL6??.DBSta

^MG1		matches "MG1" at the beginning of a line
,			matches ","
.{8}		matches any sequence of 8 characters (e.g. DHSA*001)
,			matches ","
[0-9]{6}00	matches any sequence of 6 digits followed by "00" (e.g. 00020000)
,			matches ","

Example of search: an OCEM PS that can switch has the elemType:

XX01XX01

grep [0-9][0-9]01[0-9][0-9]01 ./DEVIL6??.DBSta
or
egrep "^MG1,.{8},[0-9]{2}01[0-9]{2}01," ./DEVIL6??.DBSta

maxCmdExeTime

maxCmdExeTime#0

SETT (* ∆I)

STRG (* ∆I)

maxCmdExeTime#1

RESE


maxCmdExeTime#2

POWR

MODE (STBY->OPER)

POLA

WAVE
SWTC

maxCmdExeTime#3

MODE for EEI (OPER->STBY)

  • No labels