Adapter Configuration ===================== In your adapter repository, within the :file:`configs` folder, you will find one or more subfolders--each corresponding to a different :ref:`configuration context`. Each subfolder contains a single :file:`config.yaml` file that defines the configuration for that context. Below is an example of a :file:`config.yaml` file for a test configuration: .. code-block:: yaml :caption: :file:`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" } #. The log section typically does not need customization. #. 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. #. 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 (:doc:`adapter_actors_abilities`) and writing adapter actions (:doc:`adapter_actions`). #. 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. #. 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 :doc:`adapter_setup` and other adapter development sections. When you run your adapter in a local dev container (as described in :doc:`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 :file:`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 :file:`test`, :file:`prod`, :file:`demo`, or :file:`dev` are fine, but not :file:`mycompany@artificial.com` or :file:`$%#^&`. Each subfolder should contain a :file:`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 :file:`configs/context.yaml` file. It has a single line that contains the name of the active configuration context (directory). .. code-block:: yaml :caption: :file:`configs/context.yaml` activeContext: test --------------- Troubleshooting --------------- #. Make sure your context.yaml file is pointed to the correct config context folder. #. Make sure the Deployment config in the config.yaml file matches the one under the correct lab in LabOps. #. 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 :file:`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.