(starting page) |
(cloudmakers) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
[http://indilib.org/ INDI] (Instrument-Neutral Distributed Interface) is a distributed control protocol designed to operate astronomical instrumentation. INDI is small, flexible, easy to parse, and scalable. It supports common DCS functions such as remote control, data acquisition, monitoring, and a lot more. | [http://indilib.org/ INDI] (Instrument-Neutral Distributed Interface) is a distributed control protocol designed to operate astronomical instrumentation. INDI is small, flexible, easy to parse, and scalable. It supports common DCS functions such as remote control, data acquisition, monitoring, and a lot more. | ||
It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types and it | It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types, working with 64-bit programs and it can communicate over the network. | ||
[http://indilib.org/ | [http://indilib.org/devices.html List of devices supported by INDI.] INDI runs or is used on many operating systems, obviously all Linux distributions, but also Mac OS X with [http://www.cloudmakers.eu/indiserver/ Cloudmakers contribution] and on [http://indilib.org/about/clients.html Android]. Windows operation is also possible but non-free, with wINDI. | ||
INDI drivers communicate with devices. The INDI server optionally offers an INET socket link to INDI drivers, and thus makes the relay between clients and drivers, as show below. Clients can request a description of devices and their capabilities (called Properties), which will allow them to interact with the devices. They can get the current value of properties, modify them, or be notified when the value changes. Graphical clients should generate dynamic GUIs according to the description. | |||
[[File:INDI_arch.gif|frame|250px|center|The INDI architecture]] | |||
[http://indilib.org/about/clients.html List of clients using INDI.] | |||
The INDI protocol is simple and uses XML. Properties can be of the following types: Text, Number, Switch, Lights, and BLOB. Switch is the boolean value, Lights is a feedback type defined with 4 states (idle, OK, busy, alert), and BLOB is the binary large object. | |||
Even if GUI can be dynamically generated, it's only useful for user interaction and not for complex programming like autoguiding or autofocus. That's why INDI has specified standard INDI drivers, which are a [http://indilib.org/develop/developer-manual/101-standard-properties.html list of properties] related to a type of device. For example, the [http://www.indilib.org/api/classINDI_1_1Telescope.html Telescope standard] has a <code>Goto</code> function. Some interfaces, like the [http://www.indilib.org/api/classINDI_1_1GuiderInterface.html Guider Interface] will probably be useful too. Obviously, if a device supports more functionalities than the standard interface, the INDI driver should not be limited to it. | |||
[http://www.indilib.org/api/index.html Link to INDI API.] | |||
Latest revision as of 23:20, 6 December 2015
INDI
INDI (Instrument-Neutral Distributed Interface) is a distributed control protocol designed to operate astronomical instrumentation. INDI is small, flexible, easy to parse, and scalable. It supports common DCS functions such as remote control, data acquisition, monitoring, and a lot more.
It can be regarded as an abstraction layer, like Ascom on Windows, but to many device types, working with 64-bit programs and it can communicate over the network.
List of devices supported by INDI. INDI runs or is used on many operating systems, obviously all Linux distributions, but also Mac OS X with Cloudmakers contribution and on Android. Windows operation is also possible but non-free, with wINDI.
INDI drivers communicate with devices. The INDI server optionally offers an INET socket link to INDI drivers, and thus makes the relay between clients and drivers, as show below. Clients can request a description of devices and their capabilities (called Properties), which will allow them to interact with the devices. They can get the current value of properties, modify them, or be notified when the value changes. Graphical clients should generate dynamic GUIs according to the description.
The INDI protocol is simple and uses XML. Properties can be of the following types: Text, Number, Switch, Lights, and BLOB. Switch is the boolean value, Lights is a feedback type defined with 4 states (idle, OK, busy, alert), and BLOB is the binary large object.
Even if GUI can be dynamically generated, it's only useful for user interaction and not for complex programming like autoguiding or autofocus. That's why INDI has specified standard INDI drivers, which are a list of properties related to a type of device. For example, the Telescope standard has a Goto function. Some interfaces, like the Guider Interface will probably be useful too. Obviously, if a device supports more functionalities than the standard interface, the INDI driver should not be limited to it.