The Mirrotron Application Server

• Source code
• Control system overview

Table of Contents

• Functionality
• Data logging
• User Access
• Custom Applications
• Utility Applications
• Machine Permit system
  • Alarm scanning
  • Post-mortem buffer
  • Watchdog system
• Virtual Trays

Functionality

(contents)
The server for a Mirrotron control system is derived from the Blinky-Lite^TMBox as shown in Figure 1. The box can be instantiated on a small computer inside a firewall such as Raspberry Pi 3B+ which is more than adequate for a medium size control system or can be hosted in the cloud.

The primary tasks of the box are to:

• Subscribe to the messages from all of the trays in the system
• Scan each message for alarm notifications and notify alarm system
• Store the latest messages from in the tray database
• Archive a message when appropriate
• Serve applications to users

The box consists of three components that can reside on the same computer or separate (cloud) computers

• Application server
• MQTT Broker
• System database

Figure 1. Schematic of a Blinky-Lite^TMControl System

Data logging

(contents)
As shown in Figure 2, the application server subscribes to all reading and archive messages and sends them to the appropriate document collection. Blinky-Lite^TM uses MongoDB as a database. The database can be local or in the cloud. The list of collections are in the database are shown in Figure 3.

Figure 2. Data Logger Flow

Figure 3. MongoDb Database Flow

User Access

(contents)
Blinky-Lite^TM uses role-based access with JSON Web Token(JWT) technology for accessing applications as shown in Figure 4. Access and and setting history is logged in the database. Access and setting history apps are also shown in Figure 4.

Figure 4. Access Applications Flow

Custom Applications

(contents)
Every custom app is assigned an app slot as shown in Figure 5. The custom app accesses a library of user interface options as shown in Figure 6. Instead of having to write custom code for an app, the custom app is configured in the database as shown in Figure 7. Communications between the client and the server is handled through a websocket router as shown in Figure 8.

Figure 5. User Application Slots Flow

Figure 6. Cube Display App Flow

Figure 7. Cube App configuration

Figure 8. App websocket router

Utility Applications

(contents)
In addition to custom applications, the Blinky-Lite^TM box provides a number of utility applications for handling scalar and vector data as shown in Figure 9. Another utility application is a text-only integrated logbook as shown in Figure 10.

Figure 9. Scalar utility applications flow

Figure 10. Logbook App Flow

Machine Permit system

(contents)
The Machine Permit system is designed to protect the machine from damage due to a tray malfunctioning, not communicating, or an improper setting. The Machine Permit system uses MQTT for communication so its response time is on the order of 1 second. This is more than adequate for most events. However, for faster timescales such as an RF spark in the cavity, a dedicated loop should be used.

Alarm scanning

If any scalar cube strays outside the LOLO or HIHI alarm range, the machine permit will publish a message in which one or more critical setting cubes that subscribe to the message can take action. In the case of the Mirrotron RFQ, the critical setting cube turns off the RF frequency source.

Post-mortem buffer

Also published at the same time is a request for all the trays in the control system to immediately archive their state in the postmortem document collection of the database. This data will be used for the Post-Mortem application.

Watchdog system

All trays in the system have a watchdog counter that increments periodically anywhere from 1 to 10 seconds depending on the type of tray. If a tray watchdog does not increment in a specified period of time, it is assumed that the communication between the tray and the application server is not working and the machine permit will be pulled.

The machine permit flow is shown in Figure 11.

Figure 11. Machine Permit Flow

Virtual Trays

(contents)
Sometimes it is necessary to build a tray that is not based on physical hardware but acts on states of other trays. The Easy Setup Timer is such tray. The Easy Setup Timer is not part of the basic Blinky-Lite^TM box but is a customization.

To change the pulse length of the RFQ, five timing channels would need to be adjusted which would be time consuming and error prone. To make it easier to change the pulse length a virtual tray called the Easy Setup Timer was created. This virtual tray will adjust all five channels synchronously. The tray flow is shown in Figure 12.

Figure 12. Easy Setup Timer Flow