Upload
ginger-juliet-tate
View
216
Download
1
Tags:
Embed Size (px)
Citation preview
1
EOVSA PROJECT REVIEW:MONITOR & CONTROL SYSTEMGelu Nita
NJIT
24-25 SEPTEMBER 2012EOVSA PROJECT REVIEW MEETING
EOVSA PROJECT REVIEW MEETING 2
OUTLINE
EOVSA M&C Hardware Status Array Control Computer (ACC) Distributed Compact Reconfigurable
Input/Output (cRIO) Modules
EOVSA M&C Software Status ACC Startup Sequence ACC Schedule Server ACC Stateframe Server
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 3
EOVSA ARRAY CONTROL COMPUTER
24-25 SEPTEMBER 2012
NI PXIe-1071 4-Slot Chassis1. NI PXIe-8133 RT
Controller2. NI PXI-6682H Timing
Module3. NI PXI-8431 RS485/422
Module4. Unused/Available
EOVSA PROJECT REVIEW MEETING 4
ACC: NI PXIE-8133 RT CONTROLLER
Real-Time PharLap OS Quad-Core i7-820QM, 1.73 GHz, 4
GB RAM High-bandwidth PXI Express
embedded controller with up to 8 GB/s system and 2 GB/s slot bandwidth
Two 10/100/1000BASE-TX (Gigabit) Ethernet 1 port connected to the EOVSA network 1 port connected to the HITITE synthesizer
(4 Hi-Speed USB, ExpressCard/34, GPIB, RS232 serial, 120GB HDD, and other)
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 5
ACC: NI-PXI 6682H TIMING MODULE
24-25 SEPTEMBER 2012
Onboard high-stability 10 MHz TCXO (1 ppm) may be used for replacing the RT Controller internal 10 MHz clock
Onboard routing of internal and external clock and trigger signals
Used features:
1 PPS input (SMB): for automatic onboard clock drift correction
Dedicated Ethernet port: for IEEE-1588-2008 Precision Time Protocol (PPT) absolute time synchronization with the onboard clock with the EOVSA GPS timing system
Automatic PXI system clock synchronization with the Timing Module onboard clock
Unused features, but available if needed:
1 10 MHz clock output (SMB connector)
2 general purpose DIO channels (SMB connectors)
GPS antenna input
To provide ACC high precision hardware/software synchronization and generate the absolute EOVSA timestamps
EOVSA PROJECT REVIEW MEETING 6
ACC: NI PXI-8431 RS485/422 MODULE
4 independent RS-485/422 serial ports, 3MBs baud rate
Three spare ports
Modbus/RTU M&C of the LO system
Not tested yet, but no foreseen challenges
Modbus/RTU M&C of the DC system ( network of 16 DC modules)
Not tested yet, remains to be determined if the planned implementation of the DC control system would be able to meet the 10 microsecond timing constraint for switching the DC attenuations at the beginning of each 20ms time slot.
Fallout option: implementing the switching on the local DC Rabbit embedded controller based on a 50Hz hardware trigger.24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 7
DISTRIBUTED NI CRIO-9074 RT M&C MODULES
24-25 SEPTEMBER 2012
400 MHz real-time processor Runs antenna M&C RT application
Two 10/100BASE-T Ethernet ports TCP/IP communication with ACC
SNTP/PTP absolute time synchronization
Modbus/Ethernet with the Antenna controller
Modbus/Ethernet with the Front-end controller
(not yet tested)
DIO (SMB) input 1PPS input for clock drift correction
TBD 1PPS routing to the Front-end
controller
Unused features 2M gate, 8-slot FPGA chassis for
custom I/O timing, control, and processing
RS232 serial port for connection to peripheral
• 3 Modules on EOVSA site to be used for the prototype
• 2 Modules at NJIT currently used for development
• 11 Modules yet to be ordered
EOVSA PROJECT REVIEW MEETING 8
EOVSA M&C SOFTWARE STATUS
ACC Startup Sequence ACC Schedule Server ACC Stateframe Server
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 9
ACC STARTUP SEQUENCE
At its startup, the ACC retrieves all its predefined settings from an initialization file
c:\ni-rt\startup\ACC.ini The ACC.ini files will be
available for download via anonymous ftp from acc.solar.pvt
The initialization file will encode as key-value pairs all information needed by the EOVSA subsystems to establish communication with the ACC.
The ACC.ini file may be updated as the result of a software upgrade, therefore the clients must make sure that the file is downloaded and decoded during their own startup sequence.
24-25 SEPTEMBER 2012
[Stateframe]string size = 16buffer size = 10bin size = 4868bin path = "c:\ni-rt\startup\stateframe.bin"template size = 5267template path = "c:\ni-rt\startup\stateframe.xml" [Network]TCP.schedule.port = 6340TCP.stateframe.port = 6341
EOVSA PROJECT REVIEW MEETING 10
ACC SCHEDULE SERVER
The ACC will schedule its real-time tasks based on commands received via a TCP/IP connection from the EOVSA Schedule Computer. For this purpose ACC runs the ACC SCHEDULE SERVER that listens for commands from the EOVSA Schedule Application (CLIENT) and distributes them to the EOVSA subsystems for execution. The transaction steps are as follows:
1. The ACC Schedule Server listens indefinitely at the TCP.schedule.port for the Schedule Client to connect
2. The Client connects to the Server and immediately sends the command
3. The Server reads the command, queues it for executions and closes its side of connection
NOTES: The ACC Schedule Parser will sequentially write into the STATEFRAME the most current
schedule command that has been or is being executed. It will be the responsibility of the Schedule Client to poll the Stateframe and decide
whether or not to a new command may be sent. The Schedule Command may send at any time an ABORT command that will result in
flushing all yet unexecuted commands from the ACC Schedule Queue
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 11
ACC STATEFRAME SERVER
The EOVSA array control computer (ACC) hosts the state frame server (SFS) to which all other EOVSA subsystems (clients) may connect at any time via TCP in order to request a copy of the one of the available state frames (current or past, up to a predefined number of seconds relative to the current time).
The information needed to initiate a successful STATEFRAME transaction will be contained in the c:\ni-rt\startup\ACC.ini file, which must be retrieved, as needed, via FTP from acc.solar.pvt
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 12
STATEFRAME CLIENT-SERVER TRANSACTION STEPS1. The ACC STATEFRAME SERVER is continuously listening for a client
to connect to a predefined state frame port.
2. The client connects to the state frame server and sends a state frame request in the form of an I32 number indicating how many seconds in the past the desired state frame is. In normal conditions the client will request the state frame situated 1 second in the past. However, the yet incomplete current state frame may be requested (t=0), as well as any state frame still available in the SFS circular buffer.
3. The server sends the requested state frame and closes its side of connection. If the requested time index is outside the SFS buffer’s bounds, a blank state frame is served.
4. The client reads the state frame and closes the connection to the server.
24-25 SEPTEMBER 2012
EOVSA PROJECT REVIEW MEETING 13
STATEFRAME XML TEMPLATE RETRIEVAL The STATEFRAME clients must retrieve the data template
from the ACC (acc.solar.pvt) via FTP from a location indicated in the c:\ni-rt\startup\ACC.ini file template path = "c:\ni-rt\startup\stateframe.xml“
For testing purposes, the STATEFRAME clients may also download a copy of a blank stateframe binary string from a location indicated in the in the initialization file: bin path = "c:\ni-rt\startup\stateframe.bin“
To comply with the fixed-sized STATEFRAME requirement, all stateframe string tags will be coerced to a fixed size predefined by the the initialization file: string size = 16
REFERENCE: Proposed Self-Describing Template for Data Exchange between EOVSA Subsystems.docx
24-25 SEPTEMBER 2012