Introduction - CERN · Web viewIn the LabVIEW Real-Time execution system, processes with a higher...

CERNCH1211 Geneva 23Switzerland

EDMS NO. REV. VALIDITY

0000000 0.0 DRAFTREFERENCE

XXXX

Date : 201x-xx-xx

Software design document

Motion Drive Control (MDC)

DOCUMENT PREPARED BY: DOCUMENT CHECKED BY: DOCUMENT APPROVED BY:[Clement DERREZ EN-STI-ECE] [Checkers] [Approvers]

REFERENCE EDMS NO. REV. VALIDITY

XXXX 0000000 0.0 DRAFT

of 49

HISTORY OF CHANGESREV. NO. DATE PAGES DESCRIPTIONS OF THE CHANGES

0.0 2012-09-25 n Document started



of 49

TABLE OF CONTENTS1. Introduction ........................................................................................................................5

1.1 Purpose ..........................................................................................................................51.2 Scope .............................................................................................................................51.3 Overview ........................................................................................................................61.4 Reference Material .........................................................................................................61.5 Definitions and Acronyms ...............................................................................................6

2. System Overview ................................................................................................................72.1 System Description ........................................................................................................72.2 Requirements Summary .................................................................................................82.3 Design Constraints .........................................................................................................82.4 Scalability .......................................................................................................................92.5 Software versioning ........................................................................................................9

3. System Level Design .........................................................................................................103.1 High-Level Design Diagram ..........................................................................................103.2 Internal communication ................................................................................................103.3 External communication ...............................................................................................103.4 Error handling ...............................................................................................................113.5 Deployment and replication .........................................................................................12

4. System Architecture .........................................................................................................134.1 RT Architectural Design ................................................................................................134.2 RT Decomposition Description ......................................................................................144.3 FPGA Architectural Design ............................................................................................224.4 FPGA Motion Module Decomposition Description ..........................................................234.5 Step Generator Machine ...............................................................................................26

5. Data Design ......................................................................................................................385.1 Data Description ...........................................................................................................385.2 Data Dictionary ............................................................................................................38

6. Component Design ...........................................................................................................456.1 Motion Library ..............................................................................................................456.2 SHS Drivers Library ......................................................................................................456.3 Drivers status manager ................................................................................................456.4 Reset Commands Exceptions .......................................................................................456.5 Tune manager ..............................................................................................................466.6 Done notification manager ...........................................................................................466.7 Motion end manager ....................................................................................................476.8 State manager ..............................................................................................................476.9 ProfileCheck manager ..................................................................................................476.10 Tracetool manager .......................................................................................................476.11 AutoPostMortem manager ............................................................................................476.12 Warnings manager .......................................................................................................486.13 Errors manager ............................................................................................................486.14 Settings manager .........................................................................................................48



of 49

6.15 Sensors manager .........................................................................................................487. Appendices .......................................................................................................................491. Introduction ........................................................................................................................4

1.1 Purpose ..........................................................................................................................41.2 Scope .............................................................................................................................41.3 Overview ........................................................................................................................41.4 Reference Material .........................................................................................................41.5 Definitions and Acronyms ...............................................................................................4

2. System Overview ................................................................................................................43. System Architecture ...........................................................................................................4

3.1 Architectural Design .......................................................................................................43.2 Decomposition Description .............................................................................................5

4. Data Design ........................................................................................................................54.1 Data Description .............................................................................................................54.2 Data Dictionary ..............................................................................................................5

5. Component Design .............................................................................................................56. Human Interface Design .....................................................................................................5

6.1 Overview of Human Interface .........................................................................................56.2 Screen Images ................................................................................................................66.3 Screen Objects and Actions ............................................................................................6

7. Requirements Matrix ...........................................................................................................68. Appendices .........................................................................................................................6



of 49

1. Introduction

The Large Hadron Collider (LHC) is the largest particle accelerator ever built. The transverse energy density of the nominal beam is 1000 times higher than that previously achieved in proton storage rings. Tiny fractions of the stored beam would suffice to quench a super-conducting LHC magnet or even to destroy parts of the accelerators. The energy in the two LHC beams is sufficient to melt almost 1 ton of copper. The collimation system, based on more than 100 collimators located around the ring, protects the machine against beam losses and cleans the beam from its halo.

The jaws of the collimators move according to motion profiles, which are a function of time and depend on the LHC operational cycles. While the jaws of the collimator are performing a motion profile, the system deterministically calculates system health based on many parameters provided by the Central Control Application (CCA). Redundant subsystems are used to reduce critical errors. If the measured axis position violates one of the limits, the low level control system sends first a warning then requires a beam dump, depending on the amplitude of the error on the required jaw position. The collimators’ low level control system (LLCS) is responsible for the motion control, synchronization, and survey of more than 500 axes.

The LLCS consists of multiple subsystems:• CCA• Collimator Gateway• Motion Driver Controller (MDC)• Position Readout and Survey (PRS)This Software Design document will focus on the MDC.

1.1 PurposeThis software design document describes the architecture and system design of the

motor drive control (MDC). The MDC is responsible for the generation of stepping pulses and resolvers’ reading for up to three collimators.It receives the commands from the supervisory system about the movement to be executed by the collimator, verifies the consistency of the order with the specificity of the particular collimator(s) it is controlling, and performs the movement.

1.2 ScopeThe design decisions listed in this document are scoped to the MDC subsystem of the

LLCS.



of 49

1.3 OverviewThis document covers the design decisions made for the MDC system, including the

communication between the various real-time (RT) and FPGA processes.

1.4 Reference MaterialThe following documents were used as sources of material:

Technical_Specification_New_Softmotion_MDC_v9.doc

1.5 Definitions and Acronyms

Term Definition

Beam Dump Fast extraction of the circulating beam

CCA Central Control Application

DIM Data Interchange Management

FESA Front End Software Architecture

FPGA Field Programmable Gate Array

LHC Large Hadron Collider

LLCS Low Level Control System

LVDT Linear Variable Differential Transformer

MDC Motor Drive Control

PRS Position Readout and Survey

PXE Preboot eXecution Environment or Pre-Execution Environment; an industry standard for booting systems from a network location

VI LabVIEW Virtual Instrument

Table 1: Glossary



of 49

2. System Overview

2.1 System DescriptionFigure 1 on the following page describes the MDC context, as well as additional

descriptive information. Figure 1 shows the four modules listed and defined hereinafter:a. The MDC is the PXI system responsible for the generation of stepping pulses and the

reading of resolvers for up to three collimators. This document describes the requirements of the MDC.

b. The PRS is responsible for the synchronous monitoring of up to three collimators via the LVDT readings.

c. The Collimator Gateway concentrates all the data accesses from the top level application via a standard CERN middleware server, and establishes one to one connections with the collimators’ low level control systems through the Data Interchange Management (DIM) protocol.

d. The CCA is responsible for generating and orchestrating the settings for the whole system, and for sending them to the middleware referring to the collimators’ FESA class.



of 49

Figure 1: MDC Context

2.2 Requirements SummaryThis document is self-explanatory, and does not include a requirements summary. For

additional information on the CERN LHC MDC subsystem, please refer to the “Motor Drive Control (MDC) Requirements” document.

2.3 Design Constraints The MDC system must interface with and be controlled by DIM. The system will be programmed with NI LabVIEW Real Time, including LabVIEW

FPGA. The following NI hardware is integrated into the system:



of 49

Device Quantity

PerSystem

Description

NI PXI-1042 1 8-slot, 3U PXI Chassis with Universal AC.

NI PXI-8106 1 2.16 GHz Dual-Core Embedded Controller module.

NI PXI-7833R 1 to 3 1 per collimator controlled.R Series Multifunction Reconfigurable Input/Output (RIO) FPGA module, based on a 3 MGates Xilinx FPGA providing 8 analog inputs, 8 analog outputs and 96 digital inputs/outputs.

NI PXI-6653 1 Timing module. Optional: includes an OCXO to generate an extremely stable clock and 10 MHz reference signal that can be redistributed to all the other chassis geographically close to it to ensure a low drift of internal clocks of all the PXI chassis installed.

Figure 2: System PXI Components

2.4 ScalabilityThe software is designed to scale for use with one to three collimators.

2.5 Software versioningThe MDC code versioning use the following format:MDC 1 . x(Major update) . x(Minor update)



of 49

3. System Level Design

3.1 High-Level Design DiagramThe following diagram shows the high level software components of the MDC. This

document will focus on the LabVIEW Real-Time (RT code) and LabVIEW FPGA (FPGA code) parts:

Figure 3: MDC High level software system overview

a. FESA is the high-level control of the MDC and sends commands and receives data through the DIM interface.

b. The RT code performs all functions of the MDC system. It receives commands and settings and sends data through DIM, and communicates to the FPGA code through the FPGA interface.

c. The FPGA code controls the hardware through the I/O interface and sends and receives data from the RT code through the FPGA interface.

d. The Hardware consists of digital I/O connected to the FPGA.

3.2 Internal communicationData communication between processes inside a Collimator VI is performed using

custom Functional global Variables (FGV) and QUEUES. Data communication between Vis is implemented using FGVs. A detailed description of internal communication is given in 4. System architecture and 5. Data Design.

3.3 External communicationAll communication to and from the MDC to FESA is through the DIM library.a. Communication from CSS to MDC.

The communication from CSS to MDC is asynchronous. Data exchanged are of three types: Commands



of 49

Settings Profiles

b. Communication from MDC to CSS.The following elements are reported synchronously, at a 1Hz rate: Acquisition Warnings/errors

While settings, system health and drivers status are published at a 0.1Hz rate.The rest of the communication from MDC to CSS is asynchronous: Acknowledge commands Acknowledge settings State Postmortem

A detailed description of all data types is given in section 5.Data Design.Communication with the PRS is based on RS422 protocol, the PRS FPGA being the only

master on the bus. MDC FPGAs do not initiate any transaction on the bus.

Figure 4: Communication protocol between PRS and MDCThe baud rate can be up to 1 Mbps (to be defined). Status registers on MDC FPGA

boards are polled, including a CRC error bit:

Status register description here

3.4 Error handlingErrors and warnings are handled locally in each process. Error and warning status

information is periodically sent to the DIM process (at 1Hz). Error and warning status information consists of error and warning U64 data for each collimators handled by the system. See section 5.Data Design for a detailed description of the warning and errors at bit level.



of 49

3.5 Deployment and replicationThe MDC application software is specifically written so it can run on any of the LHC MDC

PXI. The configuration of each system is retrieved from the number of drivers motors’ drivers connected crossed checked with an ini file.

The MDC system uses Preboot eXecution Environment (PXE) to download and deploy the application from a network location. PXE is an industry standard for booting systems from a network location.



of 49

4. System Architecture

4.1 RT Architectural DesignThe figure hereinafter gives an overview of the main MDC RT processes and the main

inter process communication mechanisms. This is a high level overview of how responsibilities are partitioned and assigned to subsystems to achieve the complete functionality of the MDC.

Figure 5: RT processes and communication overview

The following processes are unique in the system: The Initialization procedure reads the static settings and system configuration

from the ini file, it initializes all main FGVs which are used to manage data structures in the system and which will be used by the other processes.

The Drivers Status process manages the serial communication with SHS drivers. It reads the status of every driver, and write/reads custom registers when new settings/commands are received.

The System Health process monitors the health of the PXI System (processor and controller temperatures, memory and CPU information) and publishes all system settings via DIM.

The Instant Updates process reports via DIM new states, PostMortem data buffers and commands & Settings acknowledges from the collimators Command loop, FPGA status and PostMortem processes.

The following processes are parts of a collimator VI and are duplicated with the number of collimators managed by the system:



of 49

The Command loop is responsible for receiving new commands, settings and profiles from CSS via DIM triggered user events. Custom acknowledges are then sent back via the instant updates process.

The Profile Generation process uses the FPGA Motion Module Softmotion module to prepare and serialize motion profile data (setpoints) to be sent via DMA FIFO to FPGA for steps generation.

The FPGA Status process reads all sensors’ values from the FPGA, updates errors and warnings accordingly. It manages the FPGA to CPU watchdog and the tuneN_reset system., the done notification and the Tune N motion management

The Postmortem process fills the postmortem buffer which contains the last 10 seconds of data. The postmortem buffer is sent through the instant update queue.

The Slow Updates process reports via DIM settings and sensors values, errors and warnings.

4.2 RT Decomposition Description4.2.1 Priorities

In the LabVIEW Real-Time execution system, processes with a higher priority number indicates a higher priority process. Lower priority processes execute during sleep or wait time of higher priority processes. Higher priority processes that need to execute immediately suspend execution of lower priority processes. Processes with the same priority use round robin execution. The priority numbers themselves only have meaning when related to the other processes. While loops are executed with lower priorities than RT loops.

The following table lists the priorities of the RT processes.

Process Priority Core

System health 30 AUTO

Commands loop 110 AUTO

Profile generation 95 AUTO

FPGA status 90 AUTO

Postmortem 60 AUTO

Slow updates 50 AUTO

Table 2: Priorities of RT processes

4.2.2 DIM LibraryDIM is used by most of the MDC processes to both receive and send data or commands

to and from FESA. The DIM interface and protocol is provided by CERN; a description of it is beyond the scope of this document.

Alessandro Masi, 09/10/13,

We should use another acronym since SoftMotion is an NI TM

Clement Derrez, 09/10/13,

They are. I missed this part when updating the document..


The collimator settings are not published in the system health process ???!!!


What is this ???



of 49

4.2.3 Motion LibraryThe motion library is used on the HOST to prepare the setpoints from the profile data.

The profile data is an array of positions [mm] and time [s] that is sent to the HOST. The algorithm presented below is used to change it to arrays of setpoints which will be then sent to the FPGA.

Figure 6: FPGA Motion Module SoftMotion setpoints algorithm

The result of the algorithm will be 5 arrays of 4 setpoint bytes, which corresponds to one per collimator axis. These arrays need to be processed before sending to the FPGA according to the algorithm below:


Because 5 is the number of axes of each collimator


A description of the setpoint fields is missing



of 49

Figure 7: FPGA Motion Module SoftMotion setpoints sorting algorithm

The outcome is one array that contains all setpoints for all drives, sorted by timestamp.The setpoint bytes’ format is the following:

d0 2 bits step nbr. 30 unused bits

d1 5 bits drive nbr. 1 bit dir. 5 bits divider 14 unused bits 7 high bits timestamp

d2 32 bits timestamps

d3 14 bits step nbr. 18 bits divider

4.2.4 Initialization procedurea. Design Pattern: The Initialization sequence is implemented as a basic state machine.

The procedure follows the sequence hereinafter, an “exit with error” state is reached in case any of the initialization actions results in an error:1) Check if the system is booting from SSD and if it needs update. Perform the

update if necessary.2) Configure the FPGA clock to be synchronized with the PXI 10MHz clock.3) If the system is a MDC-WT, configure the PXI-6653 timing card.4) Read the MDC configuration (number of collimators to manage) based on the

number of FPGA cards in the system crossed checked with an ini file.



of 49

5) Initialize all FGVs and FIFOs.6) Configure and start the DIM server.7) Start the Collimator VI(s), Drivers status, Instant updates and System health

processes.b. Related process:All processes in the system are starting in the last state of the successful initialization

procedure.c. Communication:FGVs and FIFOs which are used to manage data structures between processes are

created/initialized in the procedure.

4.2.5 Tracetool processa. Design Pattern: The Tracetool process is implemented as a while loop.b. Timing and Synchronization:The Tracetool process runs every second.c. Implementation:The process checks the status of the start and stop tracetool outputs from the tracetool

manager FGV, and executes the corresponding action (enable tracetool – stop tracetool) using the host address stored in the FGV. The “tracetool enabled” warning is activated on all collimators when data is being recorded.

d. Communication:The tracetool process uses the tracetool FGV to communicate with the commands loop.

All data recorded when the tracetool unit is enabled is sent to the host computer when the unit is stopped.

4.2.6 Drivers status processa. Design Pattern: The Drivers process is implemented as a while loop.b. Timing and Synchronization:The Drivers process runs every 3 seconds if no new commands are received from the

commands loop. New commands are executed immediately upon reception.c. Implementation:The Drivers status process executes first all requests from the commands loop pending

in the Drivers requests QUEUE, before reading and publishing via DIM the updated drivers’ status and sleeping until the next iteration.

d. Communication:



of 49

The commands process and Drivers status process communicate using the drivers’ requests QUEUE. The drivers’ process updates the settings list using the settings FGV.

4.2.7 System Health processa. Design Pattern:The system health process is implemented as a timed loop.b. Timing and Synchronization:The System Health Process is synchronized to the 1 ms system clock and runs once

every 10,000 cycles of that clock, which is once every 10 seconds.c. Implementation:The System Health process uses NI SMBus to read the PXI ambient and CPU

temperatures, and the NI RT target support VIs to gather information on the current CPU load and memory usage. System health data is then bundled and reported via DIM.

The System Health process publishes current settings values for all collimators handled by the system via DIM.

d. Related process:There are no related processes to describe as part of this software design document.

4.2.8 Instant Updates processa. Design Pattern: The Instant Updates process is implemented as a while loop.b. Timing and Synchronization:The Instant Updates Process is waiting for new instant updates elements in the instant

updates queue to execute.c. Implementation:The Instant update process waits for new instant updates elements in the instant

updates FIFO. When a new element is to be published, its type is checked and the appropriate DIM service is used to report the new state, acknowledge or postmortem buffer.When reporting a new state or acknowledge, the value published is included in the instant updates element. When requesting the publication of a postmortem buffer, the instant update process publishes all elements from the appropriate collimator’s postmortem queue.

d. Related process and communication:The instant update process communicates via a queue with the FPGA status, commands

loop and postmortem processes.

4.2.9 Commands processa. Design Pattern: The commands process is implemented as an event structure in a timed loop.


Settings are also published in the system health process yes.


No also settings ???!!!



of 49

b. Timing and Synchronization:The commands process is triggered by new DIM user events. The timed loop is

configured to be synchronized to the 1us 1ms system clock and running once every cycle. c. Implementation:The process waits for new DIM user events (Calibration, Command and Profile), checks

their validity and processes them. New profiles are sent via QUEUE to the Profile Generation process to avoid delaying the reception of new commands while setpoints are generated, whereas new settings and new commands are processed within the commands loop. Drivers’ requests are sent using a queue to the drivers’ status process. Upon reception of a command, the MDC resets a list of exceptions (warnings) related to the same command. See section 6. Component Design for a detailed description of the “reset commands exceptions” module.

d. Related process and communication:The commands process sends new drivers’ requests to the drivers’ status process, new

profiles data to the profile generation process and new instant updates to the instant updates process. All initial settings are received from FESA while the system is unconfigured, i.e.: IMOTORA, IMOTORB, IMOTORC, IMOTORD, IMOTORE (if the fifth axis is present on the collimator), MOTORES, MOTOVEL, MOTORAC, MOTORDE, AQNDELPUBPERIOD, GEARFACTA, GEARFACTB, GEARFACTC, GEARFACTD, GEARFACTE (if the fifth axis is present on the collimator), STEPLOSTTHD, RESONOFF, SWONOFF, DRVONOFF, STEPLOSTONOFF, SWLOGICONOFF, ANGLELIMIT and MECHLIMIT.

4.2.10 Profile generation processa. Design Pattern: The profile generation process is implemented as a timed loop. The timed loop is

configured to be synchronized to the 1us 1ms system clock and running once every cycle.b. Timing and Synchronization:The profile generation process waits for new approved profiles from the commands

loop. A QUEUE is used for both loops to communicate.c. Implementation:The profile generation process generates setpoints according to the input profile data,

then serializes and uploads these setpoints to the FPGA via DMA FIFO. TuneN and TuneN_count_input signals are configured when tuneN motion is requested.

d. Related process and communication:The commands process sends to the Profile Generation process approved profiles for

setpoints generation.

4.2.11 FPGA status processa. Design Pattern: The FPGA status process is implemented as a timed loop.b. Timing and Synchronization:


ms ???


ms ???!!



of 49

The FPGA status process is synchronized to the 1 ms system clock and runs once every cycle of that clock, which is once every 1 millisecond.

c. Implementation:The FPGA status process reads all controller position, resolver position, switches status,

timestamp, MDC state and motion/cRIO modules error information on FPGA. These values are stored in FGVs. (State, Sensors, warnings and errors FGVs). When a state change occurs, the new state is sent to the instant updates process via the instant updates queue. The process resets the tuneN control on FPGA at the end of a tuneN motion.The FPGA status process takes care of updating the CPU to FPGA watchdog counter and activates an error when detecting an FPGA stuck condition via the FPGA to CPU watchdog.

d. Related process and Communication:The FPGA status process gives the slow updates process data to be published via FGVs.

New states to be published are sent to the instant updates loop using a queue.

4.2.12 Postmortem processa. Design Pattern: The Postmortem process is implemented as a timed loop.b. Timing and Synchronization:The postmortem process is synchronized to the 1 ms system clock and runs once every

10 cycles of that clock, which is once every 10 millisecond.c. Implementation:The postmortem process stores all MDC postmortem information acquired at 100Hz in a

Queue. The queue reference is passed to the instant updates process, which publishes its entire contents via DIM.

d. Related process and Communication:The Postmortem process reads the values to be enqueued from the sensors, warnings,

errors and state FGVs.

4.2.13 Slow updates processa. Design Pattern: The Slow updates process is implemented as a timed loop.b. Timing and Synchronization:The Slow updates process is synchronized to the 1 ms system clock and runs once every

1000 cycles of that clock, which is once every second.c. Implementation:The Slow updates process reads every second the values to be reported from the

sensors, state, warnings and errors FGVs. The data is then bundled and sent via DIM.d. Related process and Communication:



of 49

The Slow updates process reads the values from the sensors, warnings, errors and state FGVs.



of 49

4.3 FPGA Architectural Design4.3.1 MDC FPGA Architecture

The figure hereinafter gives an overview of the MDC FPGA architecture together with its inputs and outputs.

Figure 8: MDC FPGA architecture

The complete control system consists of the following parts:1. Inputs

PRS communication: PRS timestamp and CPU stuck Trigger: Hardware or software trigger Switches: Connected to digital inputs Resolvers: Reading of cosine and sine signals in the FPGA

2. FPGA control motion Step generator composed by local FIFOs and steps generation Switches logic: Switches inputs with control of switches on the same jaw

(upstream and downstream). Invert counting and direction logic Step counter used for the steps generation and step lost


Enlarge the text in the boxes



of 49

Position monitoring: Block the steps generation in case of steps lost Resolver readout: Define the resolver position in steps Primary sine wave generator at 7.5kHz

3. Outputs Primary sine wave connected to the resolvers Steps and direction connected to the stepping motor drivers

The following schematic describes the main MDC FPGA processes and the main inter process communication mechanisms.

Figure 9: MDC FPGA Processes

The cRIO I/O, temperatures reading, Watchdog CPU, Position monitoring with resolvers (1 MHz), Resolvers position reading (400 KHz) and Resolvers primary sine wave generation (1 MHz) are implemented as while loops.

The following processes are implemented as SCTL: FPGA Motion Module Softmotion module Switches logic module Errors reporting Watchdog FPGA

4.4 FPGA Motion Module Decomposition DescriptionThe FPGA Motion Module softmotion architecture consists of four sections. The first

section is the dispatcher, responsible for reading out the DMA FIFO, for storing the data in the local FIFOs and set the first setpoint to an output register. The second one is the Motion


We can use this name instead of SoftMotion


Enlarge the text in the boxes



of 49

Synchronization Unit, responsible for controlling the trigger and the five stepper generators for the motors. The third one is the Step Generator, which generates the steps and direction to the output logic according to the setpoint received and the HOST commands. The last one, the Output logic consists in reading the switches status, inhibiting the drivers and counting the steps generated to the drivers. The signals DIR and STEP are connected to the switches logic block.

Figure 10: Architecture of the FPGA motion loop

4.4.1 MDC state transitionsThe MDC FPGA is responsible for hosting and managing the MDC state. The MDC state

management module is included in the FPGA Motion Module softmotion module.

Figure 11: MDC state management


FPGA Motion Module


Put in horizontal on an entire page



of 49

The reset signal is activated when the MDC enters the « Waiting for commands state » and results in the activation of the « abort » signal in the next SCTL cycle.

Figure 12: MDC State machine on FPGA

4.4.2 DMA Reading Logic

Figure 13: DMA Reading Logic Block Input/Output signals

The setpoint is stored in the DMA FIFO if DMA_Write_Inhibit is false and Full DMA is false (i.e this signal is provided by the FPGA RT driver).


Enlarge the text. To be checked the states transitions conditions



of 49

The data is sent to the outputSetpoint input data is sent to D0..D3 output when the local FIFOs in the FPGA are not full. The information of full local FIFOs is connected to the DMA reading logic because in that way the setpoints writing to the local FIFO is suspended until setpoints are consumed by the local FIFOs. The HOST can anyway send setpoints to the DMA FIFO even if the local FIFOs are full. The DMA FIFO size can hence be more than 5 times the size of the local FIFOs. The full local FIFOs is represented in the timing diagram in order to understand the DMA Reading logic behaviour. The select number is used to select the local FIFO which corresponds to the axis number.

4.4.3 Local FIFO

Figure 14: Local FIFO Input/Output signals.

The setpoint D0..D3 is read and stored in the local FIFO when the input select is active. The select input is used to select the local FIFO corresponding to one axis in the collimator.

The input Read_Enable Request comes from the Step generator Machine and informs the local FIFO about a SetPoint reading request. The signal Data_Valid is active when the data is available in the output register.

The empty signal is active when the local FIFO is empty. The Full FIFO signal informs the “DMA reading logic” that no more setpoints can be sent to the local FIFOs.

The Abort signal deletes the content of all the local FIFOs and the signal Data_Valid goes to low level.

The setpoint timestamp is sent to the Motion Synchronization Logic in order to execute the setpoint according to the offset time with respect to the start trigger.

4.5 Step Generator Machine


May be read_request


What does mean ???



of 49

Figure 15: Step generator machine Inputs/Outputs signals.

This block is responsible for generating the requested number of steps at the specified frequency according to the information contained in the Step generation Data (i.e. part of the entire setpoint).

When a setpoint is available in a register of the step generator machine the signal Generation Ready becomes active. Then the “motion Sync logic” block sends the signal StartGeneration to start the steps generation with the correct direction according to the setpoint data received. The signal Generation_Ready goes down during the execution. Once the setpoint is executed and a new setpoint is downloaded the signal Generation Ready is active again. Once the setpoint is executed the signal Generation_Done is activated.

In case of Tune N the setpoint is executed N times and is executed at every StartGeneration signal. The signal Finished Tune N is active when the number of repetitions reached N.

The command Abort stops immediately the steps generation and reset all the signals including the local register containing the setpoint data. The signal “Generation Done” is activated.

The command Pause freezes all the output signals and waits for a falling edge in Pause signal.

4.5.1 Motion Synchronisation Logic


Again the description of the set point fields is missing in the document !!!!!



of 49

Figure 16: Motion Synchronization logic Inputs/Outputs signals.



of 49

Figure 17: Motion Synchronization Logic States Machine.This block is responsible for synchronizing the execution of the motion command. In this

block a state machine is implemented to manage the setpoints reading from the local FIFO, the communication with the “Step Generation block” and the timing for the execution of the different setpoints according to the motion command sent.

The meaning of the different machine states is the following: Idle

The Idle state is the default state of the block. The outputs are all at low level.The state machine leaves the Idle state when at least one setpoint is stored in the

output register of the local FIFO. Read FIFO



of 49

The Setpoint is read with the command Read_Enable from the output register of the local FIFO when this one is not empty. The timestamp information is used in this block to compare it with the current timestamp to decide when starts to generate the steps.

The setpoint data needed to generate the steps are stored in a register of the block Step generator machine. Then the signal Generation Ready goes to high level once the setpoint is ready to be executed. Armed

Once the signal Generation Ready coming from the “Steps generation block” is raised up and the execution of the first setpoint is not yet started (i.e. “Execution” signal low) the machine goes in the “Armed” state waiting for a trigger rising edge. Instead if the setpoints consuming is already started (i.e. motion profile execution) this state is skipped because the signal “Execution” will be high and the setpoints consuming will proceed till the FIFO will be empty without waiting for the trigger. Wait

In this state the current timestamp generated by the Relative timestamp counter is compared with the setpoint timestamp. Once both timestamps are equal the machine will flow to the “Execute setpoint” state.

The signal Execute is true to inform the HOST about the setpoint execution. Execute setpoint

In the execute setpoint state the signal StartGeneration goes true to start the steps generation.

In Tune N mode the block goes to Armed state once the Generation Done is true which means that the setpoint was executed. The machine remains in this loop until the number of Tune nth executions equals to the Tune N number.

When the setpoint execution is finished and there is no more Tune N to be executed the StartGeneration signal will be set to low then the machine goes to the initial state Idle. This is the end of the Tune N command execution.

In the case of the execution of a simple displacement command (i.e. only one setpoint to be executed) the signal FIFO empty will trigger the transictiontransition to the “Idle” state (i.e. end of the displacement).

In the case of a motion profile execution if the local FIFO is not empty then the next setpoint is read and the procedure follows with the 2nd point. The “Armed” state is skipped because the signal “Execution” will be active.


Not really clear



of 49

4.5.1.1 Pause/Abort

Figure 18: Abort logic

The Abort signal is activated from the Host when receiving a new motion command to clean all FIFOs. It is the result of an OR operation between the Reset and the Position not reached internal signals and the Abort_i signal (coming from the Host). It stays activated during 5 SCTL cycles before being reset. In case the Abort signal is raised, the local FIFO is immediately erased and the machine state is forced to “Idle”.

If the Pause signal is activated (Rising edge), the state machine (Figure 17) remains blocked in the current state until a falling edge on the same signal is received.

If the Stop signal is active, no trigger is accepted by the system. The Stop signal being bundled with the Pause signal, a “stop” command from the Host consists in activating together the Pause and Stop signals on FPGA.

4.5.1.2 Relative Timestamp Counter

Figure 19: Relative timestamp counter input/output signals.

This block increments the timestamp counter. The counter is reset as soon as a Reset signal is received.

The Reset signal is given by the rising edge of the “Armedexecute” signal.


Not the trigger ???!!!!


Not really clear



of 49

4.5.2 Output and switches Logic

Figure 20: FPGA output logic.

The output system on the FPGA controls the flow of the signals for the drives and checks the status of the switches. It is also responsible for counting the steps that are generated and calculates the position which is then used to check for steps lost. The description of the implementation is described in the next pages following section of codes as shown on the diagram hereinafter:

Section 1 - Change the DIR signal polarity when the MDC sets the INVERT_DIR control.



of 49

INPUTS OUTPUTSDIR – direction signal that comes from the soft motion output (SOURCE: FPGA MOTION)

DIR_OUT – direction signal after the operation(DESTINATION: FPGA OUTPUT, section 3)

INVERT_DIR – signal that enable the DIR polarity inversion (SOURCE: MDC HOST)

if ( INVERT_DIR = 1 ) then DIR = not DIRelse DIR = DIRend if

Section 2 – A mask is applied on the switches array to filter out the unnecessary data (if any). The switches data is then passed to another section.

INPUTS OUTPUTSSWITCHES – is an array of switches status for the motor (SOURCE: FPGA INPUT)

ANTICO_SWITCH – anti-collision switch status output (DESTINATION: section 3)

SWITCHES_MASK – is a bit array mask for the switches array (SOURCE: MDC HOST)

INNER_SWITCH – inner switch status output (DESTINATION: section 3)OUTER_SWITCH – outer switch status output (DESTINATION: section 3)

ANTICO = SWITCHES[ANTICO] and SWITCHES_MASK[ANTICO] INNER = SWITCHES[INNER] and SWITCHES_MASK[INNER] OUTER = SWITCHES[OUTER] and SWITCHES_MASK[OUTER]

Section 3 – The latches will be set when the rising edge will be detected on the switches lines. LATCH_RESET resets all switches. The DIR_OUT signal is allowing a move in the other direction when the switch triggers.



of 49

INPUTS OUTPUTSANTICO – anti-collision switch (SOURCE: section 2 )

ANTICO_LATCH_OUT – anti-collision switch latch output (DESTINATION: section 4)

INNER – inner switch (SOURCE: section 2 ) INNER_LATCH_OUT – inner switch latch output (DESTINATION: section 4)

OUTER – outer switch (SOURCE: section 2 ) OUTER_LATCH_OUT – outer switch latch output (DESTINATION: section 4)

DIR_OUT – direction signal (SOURCE: section 1)LATCH_RESET – latch reset signal (SOURCE: MDC HOST)

if ( not DIR or LATCH_RESET ) ANTICO_latch = 0else if ( rising_edge(ANTICO)) then ANTICO_latch = 1end if

if ( not DIR or LATCH_RESET ) INNER_latch = 0else if ( rising_edge(INNER) ) then INNER_latch = 1end if

if ( DIR or LATCH_RESET ) OUTER_latch = 0else if ( rising_edge(OUTER) ) then OUTER_latch = 1end if



of 49

Section 4 – SWITCHES_STATUS is set when any of the switches is latched. This signal can be then used by the other motor logic.

INPUTS: OUTPUTS:ANTICO_LATCH – latched anti-collision switch status (SOURCE: section 4)

SWITCHES_STATUS – status for the switches (DESTINATION: FPGA INTERNAL, section 5)

INNER_LATCH – latched inner switch status (SOURCE: section 4)OUTER_LATCH – latched outer switch status (SOURCE: section 4)

SWITCHES_STATUS = ANTICO_LATCH or INNER_LATCH or OUTER_LATCH

Section 5 – Disable switches allows the system to not take into account the switches status.

INPUTS: OUTPUTS:SWITCHES_STATUS – switches status(SOURCE: section 4)

SWITCHES_STATUS_OUT – switches status or a fixed value when disabled (DESTINATION: 7)

DISABLE_SWITCHES – choice signal for the multiplexer (SOURCE: HOST)

if ( DISABLE_SWITCHES = 1) then SWITCHES_STATUS_OUT = 0else SWITCHES_STATUS_OUT = SWITCHES_STATUSend if

Section 6 – The switches status from the other motor on the jaw is passed to the output logic. The multiplexer is used to add it to the analysis.

INPUTS: OUTPUTS:SAME_JAW_SWITCHES – switches status signal from the other motor on the jaw (SOURCE: FPGA)

SAME_JAW_SWITCHES_OUT – same jaw switches status for the enable logic(DESTINATION: section 7)

SAME_JAW_SWITCHES_ENABLE – choice signal for the multiplexer (SOURCE: HOST)



of 49

if ( SAME JAW SWITCHES = 1) then SAME_JAW_SWITCHES_OUT = SAME_JAW_SWITCHESelse SAME_JAW_SWITCHES_OUT = 0end if

Section 7 – The ENABLE signal is a logic multiply of all signals that can block the motion

INPUTS: OUTPUTS:SWITCHES_STATUS_OUT – switches status for the current motor (SOURCE: section 5)

ENABLE – enable signal for the step output (DESTINATION: section 8)

SAME_JAW_SWITCHES_OUT – switches status for the other motor on the jaw (SOURCE: section 6)DRIVER_READY – signal from the motor driver (SOURCE: FPGA INPUTS)STOP_FROM_PRS – stop signal from the PRS system (SOURCE: FPGA INPUTS)IHIBIT - output inhibit signal (SOURCE: HOST)

ENABLE = not SWITCHES_STATUS_OUT and DEIVER_READY and not STOP_FROM_PRS and not SAME_JAW_SWITCHES_OUT and not INHIBIT

Section 8 – Enable logic for the step signal

INPUTS: OUTPUTS:STEP – step data from the soft motion(SOURCE: FPGA)

STEP_OUT – step data for the output (DESTINATION: FPGA OUTPUT)

ENABLE – output enable signal (SOURCE: section 7)

if ( ENABLE = 1) then STEP_OUT = STEPelse STEP_OUT = 0 end if

Section 9 – Counter of the output pulses. With additional logic to set its value and counter direction.



of 49

INPUTS: OUTPUTS:INVERT_COUNTING_DIRECTION – changes the counter direction (SOURCE: HOST)

POSITION – position of the motor in steps (DESTINATION: FPGA)

AXIS_REFERENCE_POSITION – value for the counter (SOURCE: HOST)RESET_AXIS_REFERENCE – signal at which the counter will load the value from AXIS_REFERENCE_POSITION (SOURCE: HOST)STEP_OUT – step signal (SOURCE: section 8)DIR_OUT – direction signal (counting direction) (SOURCE: section 1)

if (RESET_AXIS_REFERENCE) then position = AXIS_REFERENCE

else if (rising edge (STEP_OUT) ) then if (INVERT_COUNTING_DIRECTION) then COUNTING_DIR = not DIR else COUNTING_DIR = DIR end if

if (COUNTING_DIR) then POSITION = POSITION + 1 else POSITION = POSITION - 1 end ifend if

Section 10 – Driver reset signal is sent directly to the output. It is considered an output logic signal due to the fact that it is used in the same output module.

INPUTS: OUTPUTS:DRIVER_RESET – motor drive reset signal(SOURCE: HOST)

DRIVER_RESET – motor drive reset signal(DESTINATION: FPGA OUTPUT)

5. Data Design

5.1 Data DescriptionCustom FGVs and FIFOs (queues) are used to manage all data structures per collimator

in the system. The following diagram shows all main data communication paths in the system using FGVs and queues:



of 49

Figure 21: Data communication

See 5.2 Data Dictionary for a detailed description of all data structures.

5.2 Data Dictionary Acquisition/Sensors [Custom typedef - Cluster]

Element Type Description

Timestamp U64 Current MDC FPGA timestamp [ns]

Timestamp at trigger U64 MDC FPGA timestamp at last trigger [ns]

Ctrl positions Double 1D array Ctrl positions for axes 1-5 [mm]

Resolvers positions Double 1D array Resolvers positions for axes 1-5 [mm]

Switches status Boolean array Current switches status in the following format:

For switches A B C D E, AB and CD: SW_IN–SW_OUT

Processes timeouts Timeouts and process execution times [ms]

Table 3: MDC published sensors cluster

Acknowledge commands, Acknowledge settings [Custom typedef - Cluster]


Drv status includes all information read from the drivers : current, temperature, resolution, voltage and state.I am updating the diagram asap


In the Instant updates the state change and ack should be added- Why drv status ???



of 49

Id [INT16]

Error code [INT16 ENUM]

Ack [String[32]]

Error description [String[64]]

Table 4: Commands & Settings Acknowledge structure

Commands [Custom typedef - Enum]

Command DescriptiongoToAbs Load setpoints for absolute positioning

setResolversPosition Set all resolvers’ references

tune Load setpoints for relative positioning

profiles Load setpoints for relative positioning

changeQuota Load setpoints for absolute positioning of the 5th axis

setCurrentQuota Set the current vertical axis Ctrl position

disarm Disarm the system. Clears all local FIFOs on FPGA

stop Stop all ongoing motion – clear the local FIFOs

sendPostMortem Trigger the postmortem buffer sending via DIM

updateTimeStamp Update the current timestamp on FPGA upon trigger reception

resumeProfile Resume the last ongoing motion profile

softTrigger Software trigger on FPGA

endInitialization Trigger the change of state UNCONFIGURED – WAITING FOR COMMANDS

tracetoolOnOff Activate/deactivate the tracetool utility

autoPostMortemOnOff Activate/deactivate the automatic postmortem sending every 10 seconds.

stopFromPRSOnOff Activate/deactivate the stopfromPRS input on FPGA

readDriversReg Read the specified SHS drivers’ register

writeDriversReg Write the specified SHS drivers’ register

resetDriversHw Activates the reset drivers digital line on FPGA. Resets all 5 SHS drivers



of 49

resetFpga Reset the FPGA VI, closing and reopening its reference and resuming the previous variables’ values

resetWarnings Reset all warning bits

setCtrlPosition Set all axes’ references

pause Pause the current motion – timestamp is paused, local FIFOs not erased

resetErrors Reset all error bits

Table 5: MDC Commands

Errors [U64]The following table describes the bit level errors for a single collimator:

Error bit Error definition0 FPGA Stuck

1 CompactRIO Modules Error

2 CompactRIO Modules critical failure

3 CPU stuck

4 Resolver A step lost

5 Resolver B step lost

6 Resolver C step lost

7 Resolver D step lost

8 Left Jaw stopped

9 Right Jaw stopped

10 All switches active (cable broken)

11 Inner switch active

12 Anticollision switch active

13 Resolver A disconnected

14 Resolver B disconnected

15 Resolver C disconnected

16 Resolver D disconnected

17 Not Initialized

18 Driver disabled

19 Command process error

20 Trajectory generation process error

21 FPGA reading process error

22 Postmortem writing process error

23 Synchronous updates process error


The list is updated


Is this updated ???



of 49

24 Drivers process error

25 System health process error

26-63 unused

Table 6: Error bits Instant UpdatesData reported using the instant updates FGV’s queue is a cluster containing the following elements:

Element Type Description

Colli id INT16 ENUM Collimator id

Selector INT16 ENUM Used to select the kind of data to be published: State, Postmortem or acknowledge.

State INT16 ENUM New state to be published

Acknowledge [Custom Cluster] Settings/Commands Acknowledge to be published.

Table 7: Instant Updates

PostmortemThe post-mortem buffer contains the last 10 seconds of data acquired at 100Hz and a

header based on data acquired only once during the postmortem time frame. The postmortem buffer is a cluster of arrays which types are defined in the following table:

Parameter Type of array element

Description

timestamp Date/time MDC timestamp

resolvers Double Resolvers reading

switches Boolean Switches status

motorCtrlPosition 32-bit Actual motor controller position in mm for all axes

driversStatus 32-bit Drivers’ status

driversTemp 32-bit Drivers’ temperature

motorsResolution 32-bit Resolution setting

motorsVelocity 32-bit Axes velocity

motorsAcceleration 32-bit Axes acceleration

motorsDeceleration 32-bit Axes deceleration

iMotors 32-bit Motors’ current for all axes

driversResolution 32-bit Drivers’ Resolutionresolution

driversVoltage 32-bit Voltage


This is now up to date


Check if updated



of 49

Errors 64-bit Errors

acqDelaypubperiod 32-bit Acquisition delay

warnings 64-bit Warnings

State 8-bit MDC state

Table 8: Postmortem buffer

ProfilesMotion profiles are 2D array of doubles for each axis. Settings

Command DescriptionIMOTORA..E Motor current in mA

GEARFACTA..E Gear factor for axes A to E in steps/mm

MOTORES Motors resolution in steps/turn

MOTOVEL Motors velocity in steps/sec.

MOTORAC Motors acceleration in steps/sec2

MOTORDE Motors deceleration in steps/sec2

PUBPERIOD Publication period in ms

STOPJAWONSWITCH Enable/disable stop jaw on switch

STEPLOSTTHD Step lost threshold in mm

RESONOFF Resolvers enable/disable mask

SWONOFF Switches enable/disable mask

DRVONOFF Drivers enable/disable mask

STEPLOSTONOFF Steps lost detection enable/disable

SWLOGICONOFF Switches logic change enable/disable

ANGLELIMIT Maximum jaw tilt angle in mm

MECHLIMIT Axes’ mechanical limits in mm

PROCESSTIMEOUTS Timeouts for all processes

Table 9: Settings

State [INT16 ENUM]State of the MDC: [Unconfigured, Manage Timestamp, Waiting for commands, Armed,

Armed for tune, Motion Execution] TimestampTimestamp of the MDC: [U64]. Warnings [U64]The following table describes the bit level warnings for a single collimator:


This list is up to date yes


Is this updated ???


Tune Armed !!!!????



of 49

Warning bit Warning definition0 Command rejected because not accepted in the current MDC state

1 Motion command rejected: tilt angle too high

2 Motion command rejected because the arguments are out of the allowed range

3 Resolvers power supply A down

4 Resolvers power supply B down

5 Compact RIO modules warning (9217 temperatures acquisition module error)

6 Commands process finished late

7 Collimator trajectory generation process finished late

8 FPGA reading process finished late

9 Postmortem writing process finished late

10 Synchronous updates process finished late

11 Drivers reading process finished late

12 System Health process finished late

13 Switches disabled

14 Profile command rejected: first point different from the current position

15 Profile command rejected: profiles do not have the same duration

16 Profile command rejected: profiles of the two axes of the same jaw exceed maximum tilt angle allowed

17 Profile command rejected: profile out of range

18 Profile command rejected: profile exceeds maximum speed (2 mm/s)

19 Profile command rejected: non monotonic

20 Autopostmortem Enabled

21 TraceTool Analysis Enabled

22 Position not reached switches active

23 Outer switches active

24 Started from SSD

25 Disable stop from PRS active

26 Driver not ready

27-33 unused

Table 10: Warning bits



of 49



of 49

6. Component DesignThis section focuses on describing the functioning of each major system’s component in

a systematic way.

6.1 Motion LibraryFor a complete description of the motion library, refer to section 4.2.3.

6.2 SHS Drivers LibraryThe SHS drivers library is used on the host to manage all serial communication with the

stepper motors’ drivers. The executeDriversMessage and getPublishStatus Vis are using the library’s elements within the drivers’ process.

6.2.1 executeDriversMessageAs described in section 4.2.5, this VI is the first to execute in a drivers status process

cycle when drivers messages are present in the DRV_QUEUE FIFO. If no messages are present in the FIFO at the specified timeout (3 seconds), the process switches to the getPublishStatus VI and the executeDriversMessage VI does not execute.

This module is responsible for executing a single drivers’ command, 3 cases being present:

Writing to a register: Write new current value, new resolution value, new enable value, set the “reset” register to 1 or simply write to another specified register’s address.

Reading a specified register’s address. Probing the serial line to detect all available drivers.The VI follows these steps: applying the new setting’s value, verifying the corresponding

register’s new value and updating accordingly the settings FGV. An acknowledge is then posted to the instant updates process.

6.2.2 getPublishStatusThe getPublishStatus VI is responsible for updating reading the status information

(resolution, state, current, voltage and temperature) for every SHS driver connected to the system. This information is then bundled in an array of clusters and published via DIM. Its value is stored in the Drivers status FGV for possible PostMortem publication.

6.3 Drivers status managerThe drivers status FGV stores the current SHS drivers status (resolution, state, current,

voltage and temperature) for every collimator handled in the system.

6.4 Reset Commands ExceptionsUpon reception of a new command, the MDC resets a list of warnings:


Reading !!!!????



of 49

Command Warnings reset

Warning bit Warning definitiongoToAbs, setResolversPosition, tune,

profiles, changeQuota, setCurrentQuota, disarm, stop,

sendPostMortem, updateTimeStamp, resumeProfile, softTrigger,

endInitialization, tracetoolOnOff, autoPostMortemOnOff,

stopFromPRSOnOff, readDriversReg, writeDriversReg, resetDriversHw,

resetFpga, resetWarnings, setCtrlPosition, pause, resetErrors

0 Command rejected because not accepted in the current MDC state

1 Motion command rejected: tilt angle too high

2 Motion command rejected because the arguments are out of the allowed range

17 Profile command rejected: first point different from the current position

18 Profile command rejected: profiles do not have the same duration

19 Profile command rejected: profiles of the two axes of the same jaw exceed maximum tilt angle allowed

20 Profile command rejected: profile out of range

21 Profile command rejected: profile exceeds maximum speed (2 mm/s)

24 Position not reached switches active

30 Profile rejected non monotonic

6.5 Tune managerThe tuneN_i and tuneN_count inputs on FPGA are set when sending setpoints for a

tuneN type motion in the profile generation process. These 2 controls need to be reset when the corresponding motion is finished or aborted. The Tune Manager is responsible for detecting the end of a tuneN motion and resetting these signals. The module compares the new MDC state with the state from the previous loop iteration. The controls on FPGA are reset if:

TuneN is activeANDThe previous MDC state is MotionExecution OR ArmedTuneANDThe new MDC state is WaitingCommands.

6.6 Done notification managerThis FGV is responsible for detecting notifications to be sent from motion or

updatetimestamp commands once the system goes back into waiting for commands. When a new set of setpoints is sent in the profile generation process, the corresponding command ID is stored in the FGV. The “done” or “error” notification is then sent if:

The new MDC state is "waiting for commands"AND


The reset exception was used with every command in the old code, after discussion with Mathieu i included it for every command in the new code as well, but it is to be discussed


Why the commands list is so huge ???!!!



of 49

The new MDC state is different than the previous MDC stateANDThe previous MDC state is different from UNCONFIGURED.The Motion end manager is used from within this FGV to verify if the position reached

when sending the notification is the expected one. If the position is correct on all axes, the “done” notification is sent via the instant updates process. If the position differs from the expected one, the “error” notification is sent instead.

This FGV detects the state transition Motion_Execution -> Armed for tune. This information is then used in the motion end manager to update the next expected position.

[6.7] Motion end managerThe motion end manager verifies if the position reached at the end of a motion (profile,

tuneN or goToAbs) corresponds to the expected position. In case the two positions mismatch on at least one axis, the done notification manager sends an “error” acknowledge to the instant updates process. If a transition Motion Execution to Armed for tune has been detected in the done notification manager, the next expected position is updated with the corresponding tune N motion command.

6.7[6.8] State managerThe state FGV stores the current MDC state for each collimator handled in the system.

The state is updated from within the FPGA status process.

6.8[6.9] ProfileCheck managerThis FGV stores for each collimator the upper and lower limits used to check if the

positions of a new motion profile fall into the specified mechanical limits.

6.9[6.10] Tracetool managerThis FGV is responsible for managing the tracetool process, which is unique per system,

no matter the number of handled collimators. The tracetool host address is stored, with the current process status.

6.10[6.11] AutoPostMortem managerThis module stores the MDC autopostmortem status for all collimators handled by the

system. Its input actions are the followings:InitializeEnable AutoPostMortemDisable AutoPostMortemIncrement elements counterGet autopostmortem status


We also detect here the transition from armed to waiting for commands (triggered by a disarm command), from manageTimestamp to waiting for commands (upon trigger reception) and from armed for tune to waiting for commands (triggered by a disarm command)


Why not Motion Execution only ???!!! How the Tune N is managed ???!!!



of 49

The number of elements in the postMortem buffer is 1000. The counter is reinitialized to zero when the maximum number of elements is reached.

6.11[6.12] Warnings managerThis module stores all warning bits for all collimators handled by the system. Warning

bits are stored as I64. Its input actions per collimator are the followings:InitializeClear all warningsRead warningsSet warningClear warning

6.12[6.13] Errors managerThis module stores all errors bits for all collimators handled by the system. Errors bits

are stored as I64. Its input actions per collimator are similar to the ones available in the warnings manager, i.e:

InitializeClear all errorsRead errorsSet errorsClear errors

6.13[6.14] Settings managerThis module stores all settings values for all collimators handled by the system. Settings

are stored as a typedef cluster. (See section 5.2: Data Dictionnary).

6.14[6.15] Sensors managerThis module stores all sensors values for all collimators handled by the system. Sensors

are stored as a typedef cluster. (See section 5.2: Data Dictionnary).

6.15[6.16] Process times managerThe Process times manager is responsible for storing all process duration timeouts and

comparing them with the actual process iteration duration. It indicates if the timeout is reached and updates the stored process duration if it exceeds the specified timeout. Process times are published as synchronous updates.



of 49

7. AppendicesAppendices may be included, either directly or by reference, to provide supporting

details that could aid in the understanding of the Software Design Document.

Introduction - CERN · Web viewIn the LabVIEW Real-Time execution system, processes with a higher...

Documents

Transcript of Introduction - CERN · Web viewIn the LabVIEW Real-Time execution system, processes with a higher...