Adapter Configuration#

In your adapter repository, within the configs folder, you will find one or more subfolders–each corresponding to a different configuration context. Each subfolder contains a single config.yaml file that defines the configuration for that context. Below is an example of a config.yaml file for a test configuration:

configs/test/config.yaml#
log:
  level: "DEBUG"
  loggerLevels:
    - logger: "tutorial"
      level: "DEBUG"
artificial:
  host: your_namespace.notartificial.xyz
  lab: lab_1a2b3c-4d5e-6f7g-8h9i-123456abcdef
  org: artificial
  prefix: your_namespace

adapter:
  name: tutorialAdapter
  remoteConfig: True
  actors:
    - id: "tutorial"
      abilities:
        tutorial: 1
  plugin:
    benchling:
      ...
    smb_config:
      ...
    resource:
      name: "my_Lab_Device_EG_Fluent" # user friendly name, unique in the adapter
      id: "fluent 1"
      driver:
        name: "fluent" # driver server side name.  use [server_url]/api/v1/drivers to list what's available
        url: "http://myURL:49835" #  driver server url, use 44339 if https
        resource_simulation: false # resource simulation in remote driver. To run without hardware
        driver_simulation: false # local driver api simulation. To run without driver
        user_name: "username"
        user_password: "MyPassword123"
        cert_file: "adapter/certs/ca.crt"

  asset_sync:
    devices:
      "ACell 1.1": { rid: "d1234567-34d0-4391-be64-7aef4e0b28be" }
      "BarcodeScanner 1.1": { rid: "91234567-c7f2-4b5d-aa50-1a6f0408932a" }
      "Bioshake 1.1": { rid: "a1234567-e2a3-4263-acd7-8181b15aa92e" }

  1. The log section typically does not need customization.

  2. The artificial section needs to be set to the correct instance. You can get the entire deployment config from your instance settings page. Go to your instance. Click on the Settings icon. Select the correct lab under the Labs section. Scroll down to the Deployment Config section and copy the entire artificial section there into your yaml file as shown above.

  3. The adapter section should list the name of your adapter. It will also have a list of actors and their abilities. For more information on filling in this section see the sections for creating actors (Defining Actors and Abilities) and writing adapter actions (Writing Adapter Actions).

  4. The plugin section will list all of the drivers available to your adapter. Note this is just the configuration information for each driver. An example is given above. It lists a driver to a Fluent device with a URL to the driver PC. Note you can simulate the driver, particularly useful during adapter development, just by changing that setting to true. When resource_simulation is set to true, the driver will not contact the actual hardware, but rather simulate it. Also put in the correct login credentials.

  5. The asset_sync section is a listing of all of the hardware devices in the lab by name. The rid’s for each of these devices can be obtained by logging into your instance, click on Settings, select the correct Lab and look in the Lab Configuration section for rid values. Copy those to the adapter.

To confirm your adapter is configured correctly, you will need to continue to the section on doing adapter and workflow development. See Setting Up An Adapter and other adapter development sections. When you run your adapter in a local dev container (as described in Set Up a Local Dev Container) or on your IPC, then the adapter should be visible in your Artificial instance, under the appropriate Lab, in the section for Adapters. If not, consult the Troubleshooting guide.

Configuration Contexts#

Configuration contexts are a way to manage different configurations for different environments. For example, you may have one configuration context for testing, one for production, and one for development. Each of these contexts could have different settings, such as different driver URLs, different actors, or different log levels.

The configs folder in your adapter repository should contain a subfolder for each configuration context. These subfolders can be named however you want, but only contain letters, numbers, -, and _ (and must start with a letter). Names like test, prod, demo, or dev are fine, but not mycompany@artificial.com or $%#^&. Each subfolder should contain a config.yaml file that defines the configuration for that context.

Adapters can have multiple configuration contexts, but only one context can be active at a time. The active configuration context is the one that will be used when the adapter is run or deployed.

You can set which context is active in the configs/context.yaml file. It has a single line that contains the name of the active configuration context (directory).

configs/context.yaml#
activeContext: test

Troubleshooting#

  1. Make sure your context.yaml file is pointed to the correct config context folder.

  2. Make sure the Deployment config in the config.yaml file matches the one under the correct lab in LabOps.

  3. Check your System Monitor to see if it is connected. If it is not connected, try the below items:

    • Make sure the computer running the adapter has opened up the port specified in your config.yaml, usually 49835.

    • Make sure the driver is running or the adapter is set to simulation.

    • Make sure the adapter is running on the same network as lab/instrument PC.