Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

x.2 Architectural Plan by Mind Map: x.2 Architectural Plan
0.0 stars - reviews range from 0 to 5

x.2 Architectural Plan

x has a MVC style architecture. This document highlights the objects involved in the user interfaces and how they communicate to the controller and hardware interface in the backend.   Frontend 1)Experiment Runner 2)ScriptEditor   Backend 1) HWController 2) BECHWCBasics (implements the abstract methods of the HWContoller class)   Events 1) HWControllerEvent (both the ExperimentRunner and the HWController have a copy of these events) 2) ScriptEdEvent (Enables communication between the Script Editor and the Experiment Runner)  

ScriptEditor

View and manipulate a DataPoint Script. The DataPoint script controls the sequence of events (hardware output changes) that perform a specific experiment. Normally running a DataPoint Script for the BEC experiment will result in an absorption image, which constitutes one data point of an experiment.

HWController

The Hardware Controller (HWController) should be used as an abstract class. It provides an interface for messages to be relayed to and from the user interface (via the HWControllerEvents), as well as, keeping track of the state of the hardware. However, it does not have any access to the hardware interface. It should be implemented by a child class to deal with the hardware interfaces, and the specifics of controlling that hardware. Using different implementations, and child classes, different types of experiment can be performed, using different hardware, with out the need to change any other part of the program.  

BECHWCBasic

HWControllerEvent

This class links together the Viewer and the Controller. It provides a method of communication between the ExpeirmentRunner user interface and the HWController.

ExperimentRunner

Operates the experiment by running scripts, and changing the current output state of the hardware connected to the computer. It sends and receives labview events (HWControllerEvents) to the backend controller, which performs the actually work of compiling scripts, and manipulating the hardware interfaces. Thus this object, has no idea who it is sending messages to, or who is replying to those messages. Therefore, complete isolation between the backend hardware, and the frontend user interface is achieved. Hence any changes to the backend do not affect the frontend, and visa versa.  

ScriptEdEvents

This class links together the ExperimentRunner with the ScriptEditor. It provides a method of communication between them. Events: Open(Path) opens a script Save(Path) saves a script, currently this is not used. Close, closes the script editor.   In the future these events will be expanded upon so that the ExperimentRunner may manipulate a script. For example, you may want to make a scan of a certain parameter. This will be configured in the ExperimentRunner, and it will rewrite the script accordingly saving it to a new name.  

AnalogOutput

Generic AnalogOutput Abstract Class. Represents an Analog output device. It is appart of the hardware abstraction layer. Classes who inherit from this class implement its methods to provide for the specifics of the individual hardware and its driver.

niDAQmxAo

SoundAo

DigitalOutput

Generic DigitalOutput Abstract Class. Represents an Digital output device. It is appart of the hardware abstraction layer. Classes who inherit from this class implement its methods to provide for the specifics of the individual hardware and its driver.

niDAQmxDo

DIO64

CameraManager

This class manages everything to do with a camara. It binds together the various subprograms of the camera into one package.   The CameraController controls the hardware of the camera via the CameraAcquisitor (the acquisition system) and the CameraTempController (temperature control). Once an acquisition is complete, the CameraAcquisitor gets the images and saves them. The location of the saves images are passed to the controller. The Controller then processes the images and sends a picture event containing those addresses. This event is overheard by the Snapper which updates the images on the screen.   The Camera manager has access to all the programs that operate the camera and its settings, providing a single interface which can be used for complete automation of the camera acquisition process.

DatabaseGF

The DeviceDatabase is a global object, and there should only be one of them at any time floating around the program. To achieve this I make use of a functional global, (sometimes called Action Engines, or labview 2-style global, http://forums.ni.com/ni/board/message?message.uid=503801): databaseGF   All Access to the database is controlled through this functionalGlobal. I.e. An object may modify the database object, and to provide it to everyone else, it writes it to the functional Global. Other objects may read from the functional Global to get the latest copy of the database.

CameraController

The CameraController is an abstract class, and should be implemented by child classes for camera specific operations. The purpose of the CameraController is to control the CameraAcquisitor, and the CameraTempController. Both of these object are also abstract classes, implemented for camera specific function.

AndorController

ICCameraConroller

CameraAcquisitor

The CameraAcquisitor is a generic camera with computer control acquisition capability. This class controls the acquisition of images from cameras connected to the computer. It is an abstract class implemented by children classes for specific camera functionality. Currently it is implemented for two types of camera, an Andor Ikon m (may function with other andor camera which use the same driver), and usb cameras from Image Control.

AndorAcquisitor

CameraTempController

This class is designed to be used for cameras whose temperature can be controlled by the computer. It is an abstract class providing the mechanism to change and update the set-point of the camera, as well as keeping track of the cameras current temperature. However, it does not interact directly with any camera hardware. Its implementation classes perform these camera specific tasks. Thus the Andor Ikon m camera has a temperature controller, AndorIKonTempController, which implements the abstract methods of its parent.

AndorTempController

SnapperEvents

SnapperEvents   Send picture addresses from backend controller to frontend view (Snapper). Other events include frontend.snapShot which instructs the backend to start an acquisition. Also there is a close event to stop the program.

Snapper

View pictures taken by the camera, and the results of any image analysis performed.