Page History

Aggiornamento versioni

15/12/2021

Impostazione GMG1Dyn all'avvio del DEVIL

13/12/2021

Il recupero dei valori dinamici da memcached da caricare nella GMG1Dyn all'avvio del DEVIL è svolto nella GMG1Loader_eth.vi dal SubVI 

/source_linux/0_classes/MG1/database/GMG1DynRecoverData.vi

Per evitare disallineamento fra i set e i readout delle polarità, si cambia il valore recuperato da memcached da "polaritySetting" a "outputPolarity".
Si forza quindi l'ultimo valore di "outputPolarity" salvato su memcached nel "polaritySetting" della dinamica.

Nuova sottoclasse per nuovi alimentatori EEI per Quad., Dip. e Dip. pseudo-pulsato.

Allestimento

Macchina: vldantedev024 (LabVIEW 2012, SP1)
DEVIL:       671
VNC:         192.168.198.124:5971
prefs:        TCP_DCS port = 6345, idleTime = 100 ms

Link of this table:
https://drive.google.com/open?id=1u7TyK1WsR3w2GasDIqW6S-gNXBDvYNkV

Link of another table with the same information:
https://docs.google.com/spreadsheets/d/1n2rS3Ecr308gLilQp7u6ZMFP828-Q82ixltUHv28k68/edit?usp=sharing

New elemType descriptors

Excerpt from  MG1 class documentation

Ethernet connection

Questi alimentatori si connettono in Ethernet e quindi abbiamo lo stesso problema degli alimentatori Genesys e CAENels Easy Driver.
Anche quì, si usa un canale seriale fake per ogni alimentatore e si mette l'IP nel campo subID2.
P.es.: l'IP 192.168.190.131 si scrive come con 4 HEX come C0A8BE83

Quindi, i DBFiles avranno come subID2

#SER66911

@HCI(S)[DI32,(DBL),HU32,DU32,DU32,HU32,DU32,DU32,(DBL):1]
0,SER66911,0,0,0,0,0,0,DIPLLXXX

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32]
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan1,0,0,C0A8BE83

Sviluppo del driver

Si usano i VI della libreria Modbus TCP installati nella vi.lib di LabVIEW.
Il driver eei_CMD_exec.vi è stato sviluppato secondo la stessa struttura dei drivers dei correttori CAENels, dei CAENels Easy Driver e dei Genesys.

Sviluppo di Command e Control

Si parte dalle versioni _newOCEM_3.3.vi create per i CAENels Easy Driver

Modifiche rispetto alle versioni precedenti

MG1Ctrl_newOCEM_3.4.vi     EEI in progress, CAENels NGPS beta
MG1Cmd_newOCEM_3.4.vi      EEI in progress, CAENels NGPS beta
initHWMG1_newOCEM_3.4.vi   EEI in progress, CAENels NGPS beta
closeMG1_3.4.vi            EEI in progress, CAENels NGPS ready
.../0_classes/MG1/cmd/exeCmd(MG1)_3.4.vi                       EEI, CAENels NGPS
.../0_classes/MG1/cmd/startCmd-MG1_3.4.vi                      EEI, CAENels NGPS
.../0_classes/MG1/cmd/bypass-MG1_eth_3.3.vi                    EEI, CAENels NGPS
.../0_classes/MG1/cmd/libraries/elemType2InterfaceType_3.3.vi  EEI, CAENels NGPS
.../0_classes/MG1/cmd/libraries/SWTCFinalDataCheckE642_3.3.vi  EEI, CAENels NGPS
.../0_classes/MG1/cmd/libraries/SWTCSeekLastData_3.3.vi        EEI, CAENels NGPS

L'alimentatore EEI pulsato DP01, ha degli stati non previsti nella classe MG1:

modalità di trigger

• HW trigger
• software trigger

Si usa il comando di sistema (modificato per EEI) WAVE:

WAVE <elementName> DC|PULSED

modalità "autodev"

• autodev ON
• autodev OFF

Dato che non esiste un comando di sistema apposito, si imposta autodev ON con il comando CMSG, mettendo ad "1" il bit 8 della command word #1 (Modbus address 0).
Si esce da autodev con il comando di standby.

Il numero di cicli (al set ed a zero) che l'alimentatore dovà eseguire quando è in modalità autodev ON, si impostano con il comando di sistema (modificato per EEI) SET2.

Per tenere le informazioni dinamiche che non sono previste dalla classe MG1 è stato introdotto il typeDef:

.../0_classes/MG1/controlTypes/MG1_EEI_ctrlLibrary/MG1_EEI_Pulsed_Aux.ctl

MG1_EEI_Pulsed_Aux.ctl

che viene tenuto nella globale:

.../0_classes/MG1/RTDBGlobals/GMG1-EEIPulsedAux.vi

che viene aggiornata e scritta su memcached dal VI:

.../0_classes/MG1/ctrl/eei_parser.vi

Questa "dinamica ausiliaria", viene scritta su memcached con la chiave:

<elementName>_AUX ovvero DHPTB102_AUX

(vedi documentazione alla pagina https://confluence.infn.it/x/cYU2Aw)

MG1Ctrl_newOCEM_3.4.vi

.../0_classes/MG1/ctrl/eei_parser.vi
.../0_classes/MG1/ctrl/eei_parseStatusWords.vi

Rimangono i faults da decodificare

MG1Cmd_newOCEM_3.4.vi

Debugging dei comandi per sottoclasse EEI

In arancio: comandi che richiedono una validazione operativa

In verde: comandi debuggati

ONLN  set online = T/F

When an element is OFFLINE (as a consequence of a ONLN ELELLNNN OFF command), the control is skipped for that element.
As soon as any new command arrives, the element is put back in the ONLINE condition.

BYPS  set bypass = T/F

PUTT  error: notExecutableCmd

PUTT ELELLNNN MG1,<..... flattened cluster .....>

EMSK  set error mask to 0,0

      EMSK <elementName> N,M

CMSG  executes a direct Modbus command. In the EEI sub-class it is also possible to set a busy time (sandglass on magterminal)

<maxCmdExeTime>,<Modbus address>,WS|WM,<value>[:<value1>: ... :<valueN>]

integer   maxCmdExeTime: [sec]   determines the bysy time (sandglass ON on magTerminal)
integer   Modbus address
string     WS|WM   "write single word" or "write multiple words"
integer or [integer] U16 or array of U16  da scrivere <value>:<value1>: ... :<valueN>     words [U16] da scrivere

example (current sett at 2.5 A):

CMSG ELELLNNN 1,2,WM,2500:0

given that the sign is not used, we can also use CMSG ELELLNNN 2,WS,2500

example (MODE STBY, MODE OPER):

MODE STBY: CMSG ELELLNNN 5,0,WS,1

MODE STBY: CMSG ELELLNNN 5,0,WS,2

VI for sending Modbus frames with the CMSG command:

/u2/dcs/source_solaris/0_classes/uni_mag/lib/buildModbusFrame.vi

QMSG  error: notExecutableCmd

INIT  restablish TCP/IP connection with the i-th PS

      WARNING: set slew rate to 50% of MAX      Parlarne con Iungo

RESE  send reset

      WARNING: set slew rate to 50% of MAX      Parlarne con Iungo

POWR  send global_off

      OFF

MODE  send standby/operational            aggiustare tempo di commutazione usando maxCmdExeTime#3.

      MODE <elementName> STBY|OPER

POLA  unipolarWithRemoteCtl   set polarity

20/05/2022 - Change in POLA Executor for EEI sub-class.
Given that the EEI PSs doesn't directly switch from one polarity to the opposite one, the startCmd code that executes the POLA command has been changed. Now it send the modbus command "go to polarity open" before the actual modbus command "go to polarity X".

      bipolar                 error: notExecutableCmd

SSLP  set slew rate

NOTE: the power supply must stay in STANDBY state to accept the SSLP command.
Specifications for quadrupoles ask for a ramp rate setting from 1 to 10 [A/s] so that the raw setting range should be (10,100). Conversely, the accepted raw range is (10,290), with lower and higher values forced to 10 and 290. The raw setting range for quadrupoles seems wrong: it should be (10,100) and not (10,290). It is not clear what happens for raw settings between 101 and 290.

PSET  load current set register

      MG1Dyn.currentPreSetting <- TRUE

SETT  set current and start ramp

WARNING: se si setta un valore in polarità negativa, il readout sarà con il segno negativo e quindi la control produrrà un errore di value not reached! RESOLVED

SET2  sets the two values for the #OfCycleAtSet and #OfCyclesAtZero

      SET2 <elementName> <#OfCycleAtSet>: <fakeName> <#OfCyclesAtZero>

      WARNING: fakeName is mandatory and must be a 8 characters string. As an example, it could be a repetition of <elementName> or any 8 characters dummy string (e.g. "FAKENAME")

STRG  send start ramp

      MG1Dyn.currentSetting <- MG1Dyn.currentPreSetting

      MG1Dyn.currentPreSetting <- 0

      STRG <elementName> 0|1

      NOTA: si potrebbe discriminare il paramentro e fargli fare:

      start ramp oppure autodev

WAVE  set the trigger mode. Argument = DC | PULSED

      WAVE <elementName> DC|PULSED

01-02-2019 (for CAENels Easy Driver)

Creazione nuova sottoclasse per nuovi correttori CAENels Easy Driver.

Nonostante si tratti di alimentatori destinati a correttori, la classe utilizzata è la MG1 perchè gli alimentatori non sono strutturati con una unità principale che gestisce dei canali.

Con l'occasione si predispone il TypeDef elemType anche per la prossima sottoclasse degli alimentatori EEI.

Nuovo elemType descriptor

byte 3      unico tipo
byte 2      bipolare
byte 1      unica interfaccia
byte 0      Protocollo CAENels Easy Driver

Quindi, nei DBFiles si dovrà mettere come elemType:

@HCI(S)[(I32),(DBL),HU32,DBL,DBL,DBL,DBL,DI32,DBL:1:5]
MG1,CHHLLXXX,00000006,......

Connessione ethernet

Questi alimentatori si connettono in Ethernet e quindi abbiamo 2 problemi:

1. la classe MG1 prevede l'impiego di una seriale;
2. la connessione IP richiede di avere un IP address nella statica.

I due problemi si risolvono come già fatto per il protocollo degli alimentatori Genesys usati per i solenoidi (classe MG1, DEVIL 669):

si usa un canale seriale fake per ogni alimentatore e si mette l'IP nel campo subID2. Il nome della seriale viene creato a partire dal numero del DEVIL: SER664XX (è solo una convenzione, qualsiasi altra va bene). Ovviamente i nomi delle seriali fake NON DEVONO ESSERE GIÀ USATI.

P.es.: l'IP 192.168.190.131 si scrive come con 4 HEX come C0A8BE83

Quindi, i DBFiles avranno come subID2

#SER66911

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

0,SER66911,0,0,0,0,0,0,CHHLLXXX

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32]

1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan1,0,0,C0A8BE83

Sviluppo del driver

Data la somiglianza con il sistema CAENels SY3634, si parte dal driver dei correttori CAENels:

/u2/dcs/source_linux/3_hell/drivers/caenels/SY3634/SY3634_CMD_exec.vi

e anche dai drivers dei magneti Genesys:

/u2/dcs/source_linux/3_hell/drivers/Genesys/

Per la tecnica di inizializzazione, consultare il codice della initHWMG1, case del protocollo "Genesys".

Per la tecnica di de-inizializzazione, consultare il codice della closeMG1, case del protocollo "Genesys".

Sviluppo di Command e Control

Si duplicano le attuali versioni _newOCEM_3.2.vi come

      MG1Ctrl_newOCEM_3.3.vi

      MG1Cmd_newOCEM_3.3.vi

      initHWMG1_newOCEM_3.3.vi

      closeMG1_3.3.vi

Le versioni _newOCEM_3.3 sono state installate solo sui DEVIL 664 e 665 sulla vldantedev028.

MG1Ctrl_newOCEM_3.3.vi

.../0_classes/MG1/controlTypes/MG1_ctrlLibrary/commProtocol_3.3.ctl

.../0_classes/MG1/ctrl/parserE642_eth_3.3.vi

.../0_classes/MG1/ctrl/parserE642_noStatic_eth_3.3.vi

MG1Cmd_newOCEM_3.3.vi

.../0_classes/MG1/cmd/exeCmd(MG1)_3.3.vi

.../0_classes/MG1/cmd/startCmd-MG1_3.3.vi

.../0_classes/MG1/cmd/closeCmd-MG1_3.3.vi

.../0_classes/MG1/cmd/bypass-MG1_eth_3.3.vi

.../0_classes/MG1/cmd/libraries/elemType2InterfaceType_3.3.vi

.../0_classes/MG1/cmd/libraries/SWTCFinalDataCheckE642_3.3.vi

.../0_classes/MG1/cmd/libraries/SWTCSeekLastData_3.3.vi

initHWMG1_newOCEM_3.3.vi

Sostituito VI

.../globals/selectGElemList3-classID_eth.vi

con

.../globals/selectGElemList3_eth_corrected.vi

12-10-2017

A seguito della nuova pratica operativa di DAFNE, che richiede il cambio del set dei sestupoli dell'accumulatore ad ogni switch di macchina, si è manifestato il seguente problema: spesso i sestupoli (Danfysik SYS8X00) non eseguono il cambio di set.

Dopo aver indagato, si scopre che il problema sparisce se nella macro setCurrent&TrigSYS8X00_multi.vi, si introduce una wait subito dopo l'indirizzamento.

Questa pratica di inserire una wait era in effetti presente in tutte le altre macro SYS8X00 che effettuano sequenze del tipo address+comando, nelle quali il delay dopo l'indirizzamente è fatto con la hold.vi e non con l'operatore wait.

Probabilmente il problema (mai sofferto prima) è correlato al cambio del sistema di virtualizzazione che è più responsive e quindi richiede sleeps più pronunciate.

Modifiche fatte oggi:

/u2/dcs/source_linux/0_classes/MG1/cmd/libraries/setCurrent&TrigSYS8X00_multi.vi

- aggiunta wait di 100 ms nel frame 2, dopo l'indirizzamento fatto da add_8X00_multi.vi

- aggiunta (per buona misura) anche una wait di 100 ms nel frame 5 del VI, prima dell'invio del trigger-start.

/u2/dcs/source_linux/3_hell/drivers/SYS8X00/hold.vi

- aumentata la wait da 20 a 50 ms.

25-05-2017

MG1Ctrl_newOCEM_3.2.vi

MG1Cmd_newOCEM_3.2.vi

initHWMG1_newOCEM_3.2.vi

NOTA: la versione precedente _newOCEM è stata abbandonata

WARNING: nel frame 2, la costante enum è linkata ancora alla vecchia versione del typeDef commProtocol.ctl e non alla nuoava commProtocol_3.2.ctl utilizzata dal VI elemType2InterfaceType_3.2.vi

14-04-2017

MG1Ctrl_newOCEM.vi

MG1Cmd_newOCEM.vi

initHWMG1_newOCEM.vi

Top-level VIs da usare nelle control6XX, command6XX e initHW6XX dei DEVILs creati per OCEM che si intende far funzionare senza notifica spontanea (modalità adatta per alimentatori in singola connessione).

I VI includono la modifica introdotta nella versione _fixedTH.

In più, i VI utilizzano il nuovo driver seriale serialRead_6.66 che utilizza:

VISA: protoRead4.0.vi

native: protoRead6.66.vi

I driver OCEM sono stati modificati e sono:

E642Poll_3.0.vi

E642MultiPoll_3.0.vi

E642Select_3.0

MG1/cmd/MG1Cmd_newOCEM.vi

            MG1/cmd/exeCmd(MG1)_3.0.vi

                        MG1/cmd/startCmd-MG1_3.0.vi

                                    MG1/cmd/libraries/setCurrentE642_3.0.vi

                                    MG1/cmd/libraries/work in progress for SET2/setDoubleCurrentE642_3.0.vi

                                    3_hell/drivers/E642/E642Init_3.0.vi

                        MG1/cmd/closeCmd-MG1_3.0.vi

                                    MG1/cmd/libraries/SWTCFinalDataCheckE642_3.0.vi

            3_hell/drivers/E642/E642Init_3.0.vi

Messa in test sul DEVIL697 la mattina del 14-04-2017.

Fig. 20170414.1

31-03-2017

MG1Cmd_fixedTH.vi

initHWMG1_fixedTH.vi

Top-level VIs da usare nelle command6XX e initHW6XX dei DEVILs creati per OCEM che si intende far funzionare senza notifica spontanea (consigliato per alimentatori in singola connessione):

/u2/dcs/source_linux/0_classes/MG1/cmd/MG1Cmd_fixedTH.vi

/u2/dcs/source_linux/0_classes/MG1/initHW/initHWMG1_fixedTH.vi

L'unica modifica fatta è nel sub-VI

/u2/dcs/source_linux/0_classes/MG1/cmd/libraries/buildPgmTable_fixedTH.vi

Fig. 20170331.1

E' stato però necessario propagare il salvataggio con il suffisso _fixedTH per tutta la catena dei VI chiamanti sino ai top-level VIs.

Gerarchia del top-level VI MG1Cmd_fixedTH.vi

Fig. 20170331.2

che chiama:

Fig. 20170331.3

che chiama:

Fig. 20170331.4

che chiama:

Fig. 20170331.5

Gerarchia del top-level VI initHWMG1_fixedTH.vi

Fig. 20170331.6

che chiama:

Fig. 20170331.7

10-11-2016

MG1Cmd_eth.vi

Aggiornata introducendo la

   closeCmd-MG1_multi_2.0.vi

   ver. 2.0, build 20161017-1600

Al momento la versione MG1Cmd_eth.vi in run ha ancora sul pannello frontale il tag ver. 2.0, build 20160801 – 1550

• aggiornare il tag come ver. 2.1, build 20161110 – 1500
• salvare
• salvare per backup come MG1Cmd_multi_2.1.vi

03-11-2016

MG1Ctrl_multi_3.4.vi

ver 3.4, build 20161103-1140

NOTA: battezzata come VI canonico MG1Ctrl_eth.vi

Derivata dalla 3.3, semplificata ulteriormente la sequenza che la control esegue al "contextual check" (ovvero alla fine di un comando E642).

Nella ver. 3.3 era:

multiPoll - select (SL, COR) - multiPoll

Nella ver. 3.4 è:

multiPoll - select (SL, COR) (l’esito verrà preso alla successiva iterazione su quell’elemento).

Fig. 20161103.1

Modificata gestione della slow-poll, gestita dal VI

/u2/dcs/source_linux/0_classes/MG1/ctrl/extraFetchLogic_timed.vi

che utilizza anche un timeout congiuntamente al beat.

18-10-2016

MG1Ctrl_multi_3.3.vi

ver 3.3, build 20161018-1620

NOTA: non battezzata come VI canonico.

Derivata dalla 3.2, mantiene la semplificazione della sequenza che la control esegue al "contextual check" (ovvero alla fine di un comando E642).

Reintrodotta la slow-poll gestita dal VI

/u2/dcs/source_linux/0_classes/MG1/ctrl/extraFetchLogic.vi

che invoca una extraFetch ogni "beat" chiamate di control.

Ogni "beat" chiamate di control viene fatta una extraFetch su un elemID che si incrementa a wrap-around.

Calcolo del parametro "beat":

un elemento viene selezionato ogni ( beat * N ) cicli di control. Per OCEM E642, mediamente la control esegue circa 500 cicli al minuto e quindi, mettendo beat = ( 200 / N ), si ha una extraFetch ogni  circa 20 secondi.

Fig. 20161018.1

Introdotto un "local counter" che si inizializza a zero nel frame di init e poi si incremeta di 1 ad ogni giro. Questo counter viene utilizzato per forzare l'esecuzione delle extraFetch nei primi N giri della control (con N = numero degli elementi).

Aggiunto un controllo che attiva e disattiva il contextual check. Il controllo non è connettorizzato e deve essere modificato a mano e salvato cone "default"per poter funzionare.        

KNOWN BUG: TO BE FIXED

Il parametro beat è calcolato giusto per una freq. Di control che è quella della seriale native; per le VISA viene troppo lento.

17-10-2016

closeCmd-MG1_multi_2.0.vi

Creata nuova versione della closeCmd-MG1_multi.vi con la seguente gerarchia.

closeCmd-MG1_multi_2.0.vi           (questa nuova versione)

  SWTCFinalDataCheckE642.vi         (manda ON e riceve tutti i dati)

    SWTCSeekLastData.vi             (analizza tutti i dati)

      parserE642_noStatic_eth.vi    (esegue parsing completo e aggiorna dyn)

Fig. 20161017.1

17-10-2016

SWTCFinalCheckE642.vi

Il VI SWTCFinalCheckE642.vi

/u2/dcs/source_linux/0_classes/MG1/cmd/libraries/SWTCFinalCheckE642.vi

chiamato dalla closeCmd-MG1_multi, esegue la seguente sequenza:

select (ON) - select (SL) - multiPoll

poi analizza i dati ottenuti con la multipoll, desume solo lo stato oper/stdb e lo passa al VI chiamante closeCmd-MG1_multi che aggiorna la globale dinamica.

14-10-2016

MG1Ctrl_multi_3.2.vi

NOTA: non battezzata come VI canonico.

Derivata dalla 3.1 e semplificata nella sequenza che la control esegue al "contextual check" (ovvero alla fine di un comando E642).

Nella ver. 3.1 era:

multiPoll - select (SL, COR) - multiPoll - select (SL, COR)

Nella ver 3.2 è:

multiPoll - select (SL, COR) - multiPoll

11-10-2016

MG1Ctrl_multi_3.1.vi

NOTA: non battezzata come VI canonico.

Rimossa la richiesta esplicita di SL e COR ogni 10 giri (funzione denominata "slow poll"). La richiesta esplicita viene fatta solo ai primi N giri di control per poter avere le informazioni necessarie ad aggiornare i readouts di stato logico, allarmi, polarità. La struttura originale che cadenzava l'evento di slow poll è stata modificata.

Fig. 20161011.1 - Struttura che genera l'evento di slow poll in uso sino alla ver. 3.0

19-09-2016

GMG1DynRecoverData.vi

Modifica sul ripristino dei valori di set dopo un riavvio del DEVIL.

Nella fase di "append", il caricamento dei valori da Memcached avviene solo per:

      sysFlags.onLine

      sysFlags.byPass

      statusSetting

e non più per tutte le sysFlags.

Il VI chiamante GMG1Loader_eth.vi rimane invariato nel codice.

04-08-2016

OpenMG1.vi

Introdotto metodo openMG1.vi nella path dedicata:

/u2/dcs/source_linux/0_classes/MG1/open

Attualmente il VI è vuoto.

GMG1Loader_eth.vi

La versione in run sino ad oggi, viene salvata come "GMG1Loader_eth_20160804.vi".

Modifica che consente il ripristino dei valori di set dopo un riavvio del DEVIL.

Nella fase di "append" viene fatto il caricamento dei valori di:

(dopo varie modifiche, aggiornato al 03/04/2017)

      sysFlags.online

      sysFlags.bypass

      statusSetting

      polaritySetting

      currentSetting

prendendo quelli che sono presenti in memcached. Nel caso in cui ci sia un errore di accesso o di unflatten, viene utilizzato il valore di default come scritto nel file .DBDyn .

WARNING: la GMG1Loader_eth.vi utilizza il Sub-VI "GMG1DynRecoverData.vi" e quindi è strutturalmente diversa da tutte la altre GXXXLoader_eth.

Fig. 20160804.1 /u2/dcs/source_linux/0_classes/MG1/database/GMG1DynRecoverData.vi

02-08-2016

closeCmd-MG1_multi.vi

Introdotto controllo effettivo del fatto che a seguito della Select "ON" inviata dalla close all'alimentatore OCEM, questo abbia effettivamente raggiunto lo stato 2 = operational.

Dato che il controllo richiede un certo tempo, prima si setta la flag "busy" a TRUE e dopo si resetta a FALSE. Questo è necessario altrimenti da primo livello si vede un tempo morto sull'elemento senza la "clessidra" visualizzata.

WARNING: questa azione hardware è un'eccezione nella close che in tutti gli altri casi esegue solo un check dei valori aggiornati dalla control. Oltretutto l'azione è anche specifica per alimentatori OCEM, mentre la close è di norma indipendente dal tipi di alimentatori.

Questo è potenzialmente pericoloso ma attualmente protetto dal fatto che il comando SWTC viene preso in considerazione dalla start solo per alimentatori OCEM (per ora!).

MG1Ctrl_eth

frame 3

      caso E642

            nel caso di driver seriale tipo 1 ( 0 = Moxa-VISA, 1 = tty nativo )

            rimossa la wait di 25 ms in dd dopo la E642Select

02-08-2016

E642MultiPoll(gsd)_multi.vi

Introdotto input max#OfPools con default=5

Nella MG1Ctrl_eth, nel case frame #3, nel caso di doContextualCheck=T, viene fatta la multi-poll con max#OfPools=10 per svuotare completamente il buffer OCEM.

La condizione "doContextualCheck=TRUE" viene attivata nel case frame #2 quando:

(maxCmdExeTime has elapsed) AND (protocollo is equal to E642)

Fig. 20160802.1

Alla fine del case frame #3, doContextualCheck viene resettato a FALSE (anche se era già FALSE. Questo non è ottimizzato ma è semplice e comunque è un'operazione minimale).

01-08-2016

Transizione a versione "_multi" dei drivers seriali per i top-level VIs della classe MG1 e introduzione della funzionalità "_smart" nella MG1Ctrl_eth.vi.

WARNING: leggere anche il changelog della classe SER.

La versioni storiche delle initHWMG1_eth, MG1Ctrl_eth, MG1Cmd_eth — in run sino ad oggi senza version number — vengono rinominate come ......_eth_1.0.

Le versioni initHWMG1_smart, MG1Ctrl_smart, MG1Cmd_smart, create a partire dalle "_eth" storiche, introducono la funzionalità "smart" che effettua un check contestuale nella control (solo per gli alimentatori OCEM) quando maxCmdExeTime è trascorso.

Le versioni initHWMG1_multi, MG1Ctrl_multi, MG1Cmd_multi — in test su singolo DEVIL dal settembre 2015 ad oggi — vengono modificate dotandole di funzionalità "smart" e rinominate come "..._eth" per poter essere re-linkate ai vari DEVILs.

initHWMG1

$ mv initHWMG1_eth.vi initHWMG1_eth_1.0.vi

$ mv initHWMG1_multi.vi initHWMG1_multi_2.0.vi

$ cp initHWMG1_multi_2.0.vi initHWMG1_eth.vi

MG1Ctrl

$ mv MG1Ctrl_eth.vi MG1Ctrl_eth_1.0.vi

$ mv MG1Ctrl_eth_smart.vi MG1Ctrl_eth_smart_2.0.vi <--- NON USATA

$ mv MG1Ctrl_multi.vi MG1Ctrl_multi_3.0.vi

$ cp MG1Ctrl_multi_3.0.vi MG1Ctrl_eth.vi

MG1Cmd

$ mv MG1Cmd_eth.vi MG1Cmd_eth_1.0.vi

$ mv MG1Cmd_multi.vi MG1Cmd_multi_2.0.vi

$ cp MG1Cmd_multi_2.0.vi MG1Cmd_eth.vi

22-11-2011

MG1Cmd_eth

creato nuovo comando WAIT che effettua una attesa asincrona per un elemento (altri comandi su altri elementi vengono eseguiti nel contempo).

Sintassi

WAIT <element name> <milliseconds to wait>

esempio

WAIT DHPTT001 3000

modificato il file

/u2/dcs/prefs/globals/GClassAndServices.pref

con l'aggiunta del nuovo servizio alla fine del rigo di MG1

MG1:RESV:ONLN:BYPS:PUTT:EMSK:CMSG:QMSG:INIT:RESE:POWR:MODE:POLA:SSLP:PSET:SETT:SET2:STRG:WAVE:SWTC:WAIT

ATTENZIONE: questa modifica e' stata fatta SOLAMENTE sulla piattaforma Linux e per la MG1Cmd_eth. Quindi — alla data attuale— non e' operativa:

- sul DEVIL335 (dante065 con programma VME-Lextel) DISMESSO

- sui DEVIL Apple

08-03-2011

MG1Ctrl_eth

frame 3

      caso SYS8X00

            frame interno 3

                  sub-VI readS1_8X00

                        sub-VI decodeS1_8X00

Operatore Type Cast: riabilitata modalita' di conversione per 4.x (altrimenti non decodifica il correto bit-pattern nel vettore di U8 di destinazione dal vettore di booleani.

Creata versione MG1Ctrl_eth_nextVersion.vi. Differisce dalla versione standard per la cadenza di slow-poll che viene fatto in round robin anziche in blocco.

Finche' mantiene questo nome, non puo' essere usata con il devil alpha-unique.

03-01-2011

MG1Ctrl_eth

frame 3

      caso E642

            nel caso di driver seriale tipo DEVIL (= 0 = Moxa)

            rimossa la wait di 25 ms in dd dopo la E642Select