EOVSA PROJECT REVIEW: MONITOR & CONTROL SYSTEM Gelu Nita NJIT 24-25 SEPTEMBER 2012 EOVSA PROJECT...

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 ARRAY CONTROL COMPUTER


NI PXIe-1071 4-Slot Chassis1. NI PXIe-8133 RT

Controller2. NI PXI-6682H Timing

Module3. NI PXI-8431 RS485/422

Module4. Unused/Available


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)



ACC: NI-PXI 6682H TIMING MODULE


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


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


DISTRIBUTED NI CRIO-9074 RT M&C MODULES


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 M&C SOFTWARE STATUS

ACC Startup Sequence ACC Schedule Server ACC Stateframe Server



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.


[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


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



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



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.



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


EOVSA PROJECT REVIEW: MONITOR & CONTROL SYSTEM Gelu Nita NJIT 24-25 SEPTEMBER 2012 EOVSA PROJECT...

Documents

Transcript of EOVSA PROJECT REVIEW: MONITOR & CONTROL SYSTEM Gelu Nita NJIT 24-25 SEPTEMBER 2012 EOVSA PROJECT...