Skip to the content.

Remote Modules

Qudi supports accessing modules of a qudi instance that is running on a different (remote) computer within the same LAN. A possible configuration for this looks like:

Server

global:
    remote_modules_server:
        address: "ip.address.of.this.machine"
        port: port_of_the_server(int)
      
hardware:
    name_of_hardware:
        module.class: "hardwarefile.classname"
        allow_remote: True
        options:
            ...

Client

global:
    force_remote_calls_by_value: True
    # If this flag is set (True), all arguments passed to qudi module APIs from remote
    # (jupyter notebook, qudi console, remote modules) will be wrapped and passed "per value"
    # (serialized and de-serialized). This is avoiding a lot of inconveniences with using numpy in
    # remote clients.
    # If you do not want to use this workaround and know what you are doing, you can disable this
    # feature by setting this flag to False.

hardware:
    remote_hardware:
        native_module_name: "name of module in server's config file"
        address: "ip.address.of.remote.hardware.server"
        port: port_of_remote_hardware_server(int)

For a more elaborate explanation refer to the configuration documentation. Moreover, subsequent processing of python objects in a corresponding logic on the client side may need a preliminary netobtain, which migth look like this:

from qudi.util.network import netobtain
...
data = ...get_data_from_remote_hardware()
data = netobatin(data)

For a detailed explanation refer to the rpyc (netref) documentation.

In case you can not access your remote module, it might be also worth checking your firewall settings and the ethernet adapter settings (public/private network) of your machines.