Universal Resource Identifiers :: QUARC Communications Protocols

navigation bar

Table of Contents > QUARC > User's Guide > QUARC Communications 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. QUARC makes extensive use of URI's.

QUARC was designed to minimize the number of Simulink blocks that the user must learn to use it effectively while providing the maximum flexibility and extensibility possible. For example, QUARC provides a single set of communication blocks for all the communication mediums that it supports. Likewise it provides a single set of blocks for administering QUARC Target Managers running on remote hosts. QUARC also provides a single interface between Simulink and real-time code. All of these blocks and interfaces involve communicating with a remote or local host or device. Yet QUARC supports a variety of communication mediums for each of these blocks and interfaces. How can QUARC support different communication mediums in all of these instances without providing separate blocks or interfaces for each communications medium? The answer is URI's. QUARC 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 blocks or a single interface makes it very easy to change communication protocols and parameters without having to change all the communication blocks in your diagram! For example, this flexibility was used by Quanser engineers to switch between wireless serial communications with an embedded Gumstix board to TCP/IP communications; only a single parameter, the URI, of one block in the model had to be changed while the rest of the model stayed exactly the same!

QUARC uses a simplified version of URI's. The URI's used in QUARC 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 QUARC 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 or /dev/ser2 on Linux. 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 or /dev/ser1 on Linux at a baud rate of 57.6 kbaud 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.