API read-only mode

Support & Troubleshooting
1

Moku model: All
Operating system: All
Software version: All

Bug or support request description: Hi all, I was wondering if there was a read-only way to monitor the state and/or get data through the API from a device that is already being controlled by a client gui or by another script through the API without interfering with the connection between the instrument and the controlling client/script? It seems that connecting to an instrument in Python always implies trying to get the ownership; if I try to GET from the URL endpoints directly (e.g. http://<moku_address>/api/mim/get_connections ), I get a json with code “INVALID_REQUEST” and messages[0] “API Connection already exists”. Is there a workaround for this?

1 Like
2

Hi @admitrieff ,
Thank you for reaching out! As of right now, there can only be one type of connection to the Moku at any given time. I would recommend to add your data acquisition (get_data() , summary()) to the script that is connecting to your Moku, and then process the data as needed.
Best,
Dylan

3

If you are interested in having multiple python kernels interact with a single moku device at once, a solution I have done some experimenting with is wrapping the moku object using pyro. This package does a great job of being invisible when it is working properly, but there is a bit of overhead to get it running.

Here is a snippet of code showing how simple the ‘wrapper’ around the Moku object is,

def create_MultiInstrument(IP,MIM_name,instrument_classes,instrument_names):
    exposed_MultiInstrument = Pyro5.server.expose(MultiInstrument)

    print(f"creating MultiInstrument at {IP}")
    MIM = exposed_MultiInstrument(IP, force_connect=True, platform_id=4)

    instruments=[]

    for idx,inst in enumerate(instrument_classes):
        obj = MIM.set_instrument(idx+1,Pyro5.server.expose(inst))
        print(f"created {obj} in slot {idx+1}")
        instruments.append(obj)

    dictionary = dict(zip(instruments,instrument_names))
    dictionary.update({MIM:MIM_name})

    return dictionary

After which you can ‘serve’ this object, making it accessible over the network

   Pyro5.server.serve(
        inst_dict,
    use_ns=True, verbose=True)

Now this python kernel will hang, and you need to spin up another script to act as a pyro ‘client,’ access the object and issue commands. The beauty is you should be able to have as many client scripts as you like, and your moku will be none the wiser…

Let me know if you try this out and have any luck, I am still in the early stages of experimenting with this solution.