Transcript nAos - AB-CO Front-end

nAos
new Analog observation system
Stephane Deghaye
AB/CO/FC section meeting
22 January 2003
Overview
The nAos system
The vscope application
The nAos front-ends
Telecom
Future
The nAos system
Virtual oscilloscopes
LAN
VXI crates
Analog inputs
Analog inputs
Analog inputs
Triggers
Oracle database
The vscope application
C / SQL / MOTIF;
3rd generation of frame;
LOC: 40k;
Maintenance cost: ++
Feasible in Java ?
(performance)

The database
38 tables – 12 commons, 13 CPS & 13 SPS.
True relational design with PK, FK and constraints
Store information on:
–
–
–
–
–
Signal location
Menu hierarchy
Signal setting and global setting
Hardware installed
Events and statistics.
The front-ends
Back-plane bus standards;
Operating system and system facilities;
Application.
VXI
Definition of the two outer columns of the P2 to
include:
–
–
–
–
–
–
A very stable 10 MHz ECL clock
ECL and analog supply voltages
ECL & TTL trigger lines
An analog summing bus
The module identification bus
The local bus (daisy chain structure)
Deeper than the VME standard (x2).
CompactPCI
Synchronous bus PCI @ 33MHz;
Wider bandwidth than in the VME (! 64x, …);
Shorter back-plane available due to reflection
 Bridge in the back-plane;
Today, fast scopes are only in CPCI.
Operating systems
VxWorks on VXI with NI CPU 030;
LynxOS on VXI with VME CPU CES;
Linux on CPCI with CPCI CPU (x86 based).
VxWorks on VXI
RTOS;
Mono-user;
Everything is bound dynamically to the kernel;
Use of the NI resource manager (PnP);
License problem.
RIO 8062
PowerPC
VME Controller
Glue logic
VXI Connectors
LynxOS specialists at
CERN;
Better integration of the
nAos crates;
Need to write our own
RESMAN (A. Gagnaire);
Need to use an VME/VXI
adapter.
VME Connectors
LynxOS on VXI
nAos FE applic. (VxWorks)
Multi-threads (VxWorks)  all data shared;
Written in C;
One big file with everything + pseudo device
driver for each HW module;
Use of message queues for inter threads
communication;
Some nice remote diagnostic features.
nAos FE applic. (LynxOS)
Multi tasks + threads for simple tasks
(e.g. waiting on a handle);
Use POSIX shared memory segment;
Modularization of the applic (one file per
process, library for HW access and for common
functions);
Add auto recovery & debugging features.
Process View
LAN
dtmrtNao
PLS server
NaosBig|BrotherServer
SURVEY server
NaosServer
SERVICE server
90
Telegrams
90
N
tEndDigit
Task
60
VH
90
N
N
NaosQueueServertoManager
NaosQueueManagerToRoute
NaosManager
Task
NaosDispacher
Task
NaosQueueManagerToCount
91
N
NaosRoutingSignal
Task
91
L
NaosQueueManagerToScope[1-8]
95
NaosTrgTraiMulpx
Task
95
H
L
NaosQueueWd
Scope1Ctrl
Scope1Ctrl
Scope1Ctrl
Scope1Ctrl
Task
100
L
NaosQueueMsgDispatcher
Vxi Hardwares
Scope
Ÿ
HP E1428A
Mulpx
Ÿ
18x12PF
Ÿ
HP E146 A
tJeton
Delay 2 mm
102
VL
The nAos Protocol
Messages structure
Group Key ScopeLA
ChannnelNo
Parameters
• Group: 1 byte, message identifier, response => MSB = 1;
• Key: 1 byte, comb. of the virtual scope no and the channel no;
• ScopeLA: 1 byte, logical address of the scope used;
• ChannelNo: 1 byte, channel no in the scope of LA ‘ScopeLA’
• Parameters: ASCII chars depending of the group, from 0 to …
NB: Several messages can be send at the same time by separating them with a ‘;’
The nAos Protocol
Parameters structure
• No parameter. E.g SCOPE_TYPE, WS_COUNTV_UNLOCK;
• Fixed in number and position.
E.g. ADD_SIGNAL (signalID, prio, triggerCrate, triggerId, triggerCode);
• Variable in number and position => tag or tag-value pair.
E.g. SCOPE_ACTION(PROP_TIME, #PROP_TIME, …).
UDP/IP
• Connectionless
• Unreliable
Where we want to go…
The nAos needs to be re-written using standard
components;
The vscope application is now unmaintainable;
We can share hardware and software with other
groups (SiWG);
nAos can be more than just curve visualisation
(Contract ?)
We need another way to trigger the scopes;
Trigger…
True pulse (not a trigger)
Tagging module
Pretrigger (computed)
Pretrigger (computed)
The END !
Thank you !
Vscope zoom