Instrument server documentation #93
Conversation
|
|
||
| `instruments`: this field will contain each instrument you wish to create. Under this field should be the names of each instrument you are creating | ||
|
|
||
| `type`: This specifies which QCoDeS driver the instrumentserver should use to create the instrument. Can either be a local file or a community-created driver |
There was a problem hiding this comment.
it has to be the python import path. If they put a path this will not work. The only way to passing this to a file is if they have that file in a package that install in editable mode.
|
|
||
| `type`: This specifies which QCoDeS driver the instrumentserver should use to create the instrument. Can either be a local file or a community-created driver | ||
|
|
||
| `address`: the tcp/ip address of the instrument on the same network as the instrumentserver |
There was a problem hiding this comment.
This is whatever the instrument uses as an address. Sometimes its a tcp/ip other times a usb adress others a serial port or even the serial number if that driver uses that
|
|
||
| `address`: the tcp/ip address of the instrument on the same network as the instrumentserver | ||
|
|
||
| `port`: which port (of the instrument) to communicate with (can generally be found in the manual of the instrument) |
There was a problem hiding this comment.
This is not part of the defaults arguments. This is specific to that instrument and that is why you need to put it inside of the init field. You should also mention what the init field does.
| The instrumentserver also contains functionality for config files. These config files contain set-up for QCoDeS instruments. These config files can then be used by the instrumentserver | ||
| on start-up to have the desired instruments already created without having to manually add them after starting the server. |
There was a problem hiding this comment.
repeated These config ... start on 2 sentences in a row.
I think the wording is a little confusing. The instruments are not already created, instead the server will instantiate those instruments at startup. There is a minor difference there.
| parameter_manager: | ||
| type: instrumentserver.params.ParameterManager | ||
| initialize: True | ||
| gui: |
There was a problem hiding this comment.
Maybe add the parameter manager with the custom GUI in the example before so you can mention how the instrumentserver supports custom gui's for instruments that need to be specified like this.
|
|
||
|  | ||
|
|
||
| The instrumentserver also supports loading parameters from a file. They can also be created manually either from the terminal or the GUI. |
There was a problem hiding this comment.
replace the They can also... to Parameters can also...
If you want to load parameters from file, then name of that file is important. Depending on the name it will either: not load the parameters, fully replace the parameters (add a warning about how they are all lost if that happens), make a new profile that you can switch to the other parameters there.
adding documentation for the instrument server