Delivery 1

Our definition of 'Delivery 1' means the new linux CCU with a position only control loop integrated with the new rate loop card.

In the paragraphs below I sometimes refer to "signal's". These are basically data streams which are routed between the various components. They have a data format and semantic which are specific to the communicating components.

Some items have estimates which are prefixed with an astrisk (e.g. * [3]), which are subtask estimates and are included in the estimate for the section.

Replace Kernel(23d)

Replace functionality

Extract Kernel

The kernel previously was a core component of the system. The task control (there was a separate support mechanism for it), can/will be removed. A number of kernel cross-checks will need to be replaced to monitor other components (interface components, PID controller, etc.)

The hardware will handle enable/disable sequencing previously performed by the kernel. The PID rate demand output will be held at zero rate during the enable sequence.

Limited rate/cold weather operation will be handled as it is now. The rate loop board will reduce the max rate. The CCU will monitor the number of disabled motors and prevent motion when a minimum number of motors are not available.

The kernel previously provided a trajectory profile generator for when the OCU was in control. This included a limiting of the maximum rate to the rate specified by the operator.

We will need a PID control loop module to replace the loops run by the kernel.

*[10d]

Replace Kernel(23d)

Replace functionality

Extract Kernel

The kernel previously was a core component of the system. The task control (there was a separate support mechanism for it), can/will be removed. A number of kernel cross-checks will need to be replaced to monitor other components (interface components, PID controller, etc.)

The hardware will handle enable/disable sequencing previously performed by the kernel. The PID rate demand output will be held at zero rate during the enable sequence.

Limited rate/cold weather operation will be handled as it is now. The rate loop board will reduce the max rate. The CCU will monitor the number of disabled motors and prevent motion when a minimum number of motors are not available.

The kernel previously provided a trajectory profile generator for when the OCU was in control. This included a limiting of the maximum rate to the rate specified by the operator.

We will need a PID control loop module to replace the loops run by the kernel.

*[10d]

Enable/disable (in HW)

This function will be done in hardware *[0]

Trajectory in OCU mode

This can be handled by either:

A. simply clipping the rate demand to the maximum specified by the operator.

B. Limit the rate through the use of a profile generator.

This would be a modification to the OCU interface & Control Loop module

*[4d]

Limited rate operation

As is done now, the CCU monitors for the limited rate conditions, and lowers its demands accordingly.

The PLC and HW take care of the rest. The reduced rate state will need to propagate to the fault checking components.

*[3d]

El field control

Previously the kernel weaked the fields when elevation motors exceeded 1080 rpm. This will be done by the rate loop board. *[0]

Revise signal paths

Lots of information was being routed through the kernel. All these signals will need to be routed/replaced/re-defined. More work than it sounds.* [10d]

Revise Status Processing(8d)

Most of the old code can be re-used, but many of the signal sources and possibly signal semantics will need to be updated.

*[8d]

Remove MCI signals

Add control sequencing

Add New fault checks

Create A/D Interface(12d)

Hardware Architecture

Need to find a card (set) with at least 72 channels (3-32 channel cards?)

This may be a trick to fit in a stock PC. Might need to move to:

A: Compact/Industrial PCI system

B: Use a remote PCI expansion chassis

C: Find a really high-density card

D: Use a BIT-3 and a VME chassis and I/O cards

*[0]

Interface software

* Determine how it works (interrupter/batch mode capable?)

* Determine strategy for interface

* Create RTDM interface driver

* Create matching CCU Component

Note: This requires getting properly documented hardware!

*[12d]

Create D/A Interface(6d)

Interface software

The D/A interface should be significantly simpler than the A/D interface, but still has similar tasks:

* Determine how it works (interrupter/batch mode capable?)

* Determine strategy for interface

* Create RTDM interface driver

* Create matching CCU Component

*[6d]

Create Encoder Interface(3d)

Current proposal is to use a PCI RS-422 card at 56-119k baud.

A RT serial setup will be required. (Xenomai provides 16550A compatible driver)

* RTDM driver available

* CCU Component *[3d]

ServoMonitor Module(14d)

The servo monitor functionality was dropped in the SRP. The new design needs to include this.

(Assuming data acquisition is estimated elsewhere)

RT to Sampler

Studied previously. Need a way to buffer and transfer data to a remote system to interface into a sampler stream.

Define Interfaces(3d)

Interfaces for:

* Axis rate/tach (Analog-in)

* Servo monitoring (Analog-in)

* Axis rate demand (Analog-out)

* Encoder RS-422 serial digital input

* Modbus (register usage/semantics)

* Simulink interface (testing)

* M&C interface (servo monitor data to sampler)

* statusDef.conf (Used by ACU and OCU for status. Need to remap/revise entries)

Port to Xenomai-3/RH6(3d)

The previous system used Xenomai with Redhat 5, and the RTAI programming interface. (Historical since we began the project using RTAI, then through the use of a compatibility layer switched to using Xenomai. This layer needs to be removed.

New Xenomai build/configure

Remove RTAI and use native API

Create PID/Control loop module(7d)

Should be straight forward. A PID is relatively simple to code.

Will need an interface to tune parameters during testing.

Testing(17d)

We currently have an extensive acceptance test procedure, however, this will need to updated.

Lab testing and development will require some additional components for incremental testing.

One item will be a 'simulated' rate loop board which sends the rate demands to a simple local plant model, or remotely to the Matlab simulink plant model.

Acceptance Testing

On telescope acceptance testing will require a fair amount of setup and adjustments. This estimate may be way too low.

*[7d]

Integration Test

Integration/Lab testing will be a continuous process, but a dry-run of the acceptance tests should be about *[5d]

Revise Test Procedure

Revisions necessary due to changes in architecture.

*[5d]

Plant Models(4d)

Simple Plant Model

Create a local RT model using simple algorithms such as are used in the current CCU simulator.

This does not include a Matlab interface (scheduled for delivery 2)

*[4d]

Get Old System Running(2d)

Get the old code cleanly running in simulation mode (no sense in working on ECAT portion).

*[2d]

-- JoeBrandt - 2014-11-06
Topic revision: r1 - 2014-11-06, JoeBrandt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback