Installation

Configuration

Some of the chamber configurations (notably simulation) do not require any configuration on the part of the user. However, in most configurations there are many fields that must be set for the system to work properly.

Before you start

Make sure your file explorer application is set to show file extensions! This lesson will be very confusing if you don't.

There are a lot of modules, and each one has unique fields and settings. This lesson only covers the settings shared amoung modules, and how those modules are used. To know more about a specific module find it on our component database.

In general, never change the Module_Name field in any file. It's really bad practice. Instead, copy over the template configuration file for the module you want to replace it with into the current files location, and delete the old file.

Configuration directory structure

Navigate to the location of your chamber configuration. Inside you'll see two files:

  • Templates - blank (or common configurations) configuration files that you can use as a starting point. This folder is automatically regenerated each time the program is run, so don't bother making changes here!
  • Configuration - The actual configuration files in use. For organizational purposes, you can put any subdirectories here you want: all of them will be searched for configuration files.

The software has a large internal database of behaviour modules, and it uses the configuration files within the Configuration directory to know which modules to load, how to load them, and what keywords to call them on.

The .ChamberConfig file

Required in every configuration is exactly one file with the extension .ChamberConfig. This file defines the name of the chamber, any nicknames it might have, and the location it stores acquired files to.

  • Set NAME to the name for this chamber. We often use names like percival9, Tesla, or NatesTestbed. Set it to whatever you want. Just make sure no one else uses the same name, or it might conflict when uploading data!
  • Set DESTINATION to some valid location on your computer that has enough space for what you are doing. This location is NOT cleared after use, so eventually it will become full!

The .DriverConfig files

A .DriverConfig file describes a module that does or sets something in the chamber. For instance, communication with the SmartLight hardware or telling the PercivalAPI to set the humidity. There are a few important fields in every one of these files:

  • Module_Name - The name of the actual module to load. This might be SmartLight or LegacyI2C_DoubleRail.
  • Command_Name - The command that will trigger this module when called by a user or script.
  • Warner - What system will be used to alert of a failure by this Driver. There are a few keywords here: default will use the systems default (set in the .ChamberConfig file), and if empty it will not attempt an alert at all.
  • Checker - This feature is still in development!

The .TaskConfig files

A .TaskConfig file describes a module that performs some extra or auxillary task. For example, the SamplePicture.TaskConfig will load the module that takes a sample picture before a script is run.

There is only one shared field here:

  • Module_Name - Like in .DriverConfig files, the name of the actual module to load. Examples might be SamplePicture or EODNotify.

The .ResourceConfig files

A .ResourceConfig file describes a shared module that is used by other modules to complete tasks. It's special because Resources can require other Resources, which means our dev had to make it do dependency resolution.

Like before, there is only one shared field here:

  • Module_Name - The name of the actual module to load. Examples might be LegacyFPGA_Control or Email.

The .SensorDriverConfig files

Okay, this is going to start getting a little more complex. To get a camera working you need at least 3 files, and the .SensorDriverConfig loads the module that actually runs a camera and saves its data.

There are two shared fields here (but SensorDrivers usually have a lot of unique ones).

  • Module_Name - The name of the actual module to load. Examples might be HitachiCameraDriver or AVTCameraDriver.
  • Warner - Like in .DriverConfig files, the ID of the Warner that will be used to alert of failers.

The .SensorGroupConfig files

Sensors are organized into SensorGroups, denoted by the .SensorGroupConfig files. Each SensorGroup has shared information between Sensors. These sensors have to have simular characteristics for us to get them working together with such tight timing constraints!

There are 3 shared fields here:

  • Module_Name - The name of the actual module to load. Examples might be HitachiCameraGroup, or AVTCameraGroup.
  • ID - The name of the SensorGroup. This has to be unique to the chamber. When you have multiple CameraGroups, this is how you specify which one to use.
  • Sensors - The IDs of the Sensors that make up this SensorGroup. If you only have one SensorGroup, you can simply use the keyword * to automatically include all Sensors.

The .Sensor files

Finally we get to the actuall sensors (usually cameras), specified by their .SensorConfig files. You need one of these for every sensor in your chamber, and often they will be very similar.

There are 2 shared fields here:

  • Module_Name - The name of the actual module to load. Examples might be HitachiCamera, or AVTCamera.
  • ID - The ID of the samera. This has to be unique to the chamber. This will show up in the chambers output and logs, to identify which images are from which sensor.