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.
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]
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]
This function will be done in hardware *[0]
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]
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]
Previously the kernel weaked the fields when elevation motors exceeded 1080 rpm. This will be done by the rate loop board. *[0]
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]
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]
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]
* 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]
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]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]
The servo monitor functionality was dropped in the SRP. The new design needs to include this.
(Assuming data acquisition is estimated elsewhere)
Studied previously. Need a way to buffer and transfer data to a remote system to interface into a sampler stream.
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)
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.
Should be straight forward. A PID is relatively simple to code.
Will need an interface to tune parameters during testing.
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.
On telescope acceptance testing will require a fair amount of setup and adjustments. This estimate may be way too low.
*[7d]
Integration/Lab testing will be a continuous process, but a dry-run of the acceptance tests should be about *[5d]
Revisions necessary due to changes in architecture.
*[5d]
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 the old code cleanly running in simulation mode (no sense in working on ECAT portion).
*[2d]
I | Attachment | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|
jpg | Delivery_1_6.jpg | manage | 90 K | 2014-11-06 - 12:42 | JoeBrandt |