Universal Resource Identifiers :: RCP Communications Protocols

navigation bar

Table of Contents >Quanser Rapid Control Prototyping Toolkit >Communication Protocols >

Universal Resource Identifiers

Universal Resource Identifier or URI's are used to identify resources. They are very similar to Universal Resource Locators or URLs, such as https://www.quanser.com, which are familiar to anyone who has used the World Wide Web. RCP makes extensive use of URI's.

RCP was designed to minimize the number of LabVIEW VIs that the user must learn to use it effectively while providing the maximum flexibility and extensibility possible. For example, RCP provides a single set of communication VIs for all the communication mediums that it supports. RCP also provides a single interface between LabVIEW and real-time code. All of these VIs and interfaces involve communicating with a remote or local host or device. Yet RCP supports a variety of communication mediums for each of these VIs and interfaces. How can RCP support different communication mediums in all of these instances without providing separate VIs or interfaces for each communications medium? The answer is URI's. RCP uses URI's for all of its communications because they provide a uniform, extensible and flexible means of identifying the communication medium and protocol to use and associated communication parameters. Furthermore, using a single set of VIs or a single interface makes it very easy to change communication protocols and parameters without having to change all the communication VIs in your block diagram! For example, this flexibility was used by Quanser engineers to switch between wireless serial communications with an embedded board to TCP/IP communications; only a single parameter, the URI, of one VI in the block diagram had to be changed while the rest of the VI stayed exactly the same!

RCP uses a simplified version of URI's. The URI's used in RCP take the following form:

<protocol>:<hier-part>?<option>=<value>,...

where the hierarchical part, <hier-part>, takes the form:

hier-part = <authority> | <path> | <authority>/<path>

authority = //<hostname>:<port>

For example, valid URIs are:

shmem://mymemory:1?memsize=4096

tcpip://quanser-dev:18000

serial://quanser-uav:2?baud=57600,word=8,parity=none,stop=1

file://localhost/home/drmadill/myfile.txt?mode=w,share=no

file:/C:/Temp/myfile.txt

file:myfile.txt

The hierarchical part consists of an authority, a path or both. The path component takes the form of a standard file system path. Use of the forward slash ("/") to separate levels in the hierarchy is recommended. The path is treated as absolute if it is preceded by an authority or begins with a slash ("/") character. Otherwise it is treated as a relative path.

Only the protocol and hierarchical part are required. The <protocol> indicates the communications protocol and medium to use. For example, tcpip indicates the TCP/IP protocol over Ethernet, while serial indicates serial communications over a serial port. The <hostname> indicates the remote (or local) host with which to communicate. For example, for the tcpip protocol the hostname is a standard hostname such as quanser-dev. For the serial protocol the hostname is required, but ignored, since serial ports do not have an associated hostname.

The <port> indicates the port to use for communications. Ports are typically associated with TCP/IP or UDP protocols, but RCP uses the port in a more general manner. For example, for the tcpip protocol the port is indeed the TCP/IP port used for communications, but for the serial protocol it indicates the serial port to use. For example, the URI serial://quanser-dev:2, which has a port of 2, refers to COM2 on Windows. If no port is specified then a default port is used. However, it is a recommended practice to always specify a port.

The <option> indicates an option specific to the communication protocol. Communication protocols generally support a variety of options and each option typically has an associated value. Options are separated by a comma or semicolon. If an option is not specified then a default value is used for that option. For example, the tcpip protocol supports a backlog option (among others) which determines how many client connections may be pending on a listening socket. Likewise, the serial protocol has a baud option which determines the baud rate used for serial communications. For example, the URI serial://quanser-dev:1?baud=57600,flow=hw indicates serial communications using COM1 on Windows at a baud rate of 57.6kbaud and using hardware flow control.

For the interpretation of the hostname and port and the options supported by a particular protocol, see the list of protocols below. Protocols may be added at any time, so the list below may not be complete.

navigation bar