EOVSA PROJECT REVIEW: Monitor & Control System

1. EOVSA PROJECT REVIEW:Monitor & Control System Gelu Nita NJIT 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 EOVSA project review Meeting

3. EOVSA ARRAY CONTROL COMPUTER NI PXIe-1071 4-Slot Chassis NI PXIe-8133 RT Controller NI PXI-6682H Timing Module NI PXI-8431 RS485/422 Module 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) EOVSA project review Meeting

5. ACC: NI-PXI 6682H Timing Module To provide ACC high precision hardware/software synchronization and generate the absolute EOVSA timestamps • 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 EOVSA project review Meeting

6. ACC: NI PXI-8431 RS485/422 Module • 4 independent RS-485/422 serial ports, 3MBs baud rate • Threespare 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. EOVSA project review Meeting

7. 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 project review Meeting

8. EOVSA M&C Software Status • ACC Startup Sequence • ACC Schedule Server • ACC Stateframe Server 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. [Stateframe] string size = 16 buffer size = 10 bin size = 4868 bin path = "c:\ni-rt\startup\stateframe.bin" template size = 5267 template path = "c:\ni-rt\startup\stateframe.xml" [Network] TCP.schedule.port = 6340 TCP.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: • The ACC Schedule Server listens indefinitely at the TCP.schedule.portfor the Schedule Client to connect • The Client connects to the Server and immediately sends the command • 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 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.inifile, which must be retrieved, as needed, via FTP from acc.solar.pvt EOVSA project review Meeting

12. STATEFRAME CLIENT-SERVER TRANSACTION STEPS • The ACC STATEFRAME SERVER is continuously listening for a client to connect to a predefined state frame port. • 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. • 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. • The client reads the state frame and closes the connection to the server. 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.inifile • 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 Meeting