Extern devices
VRmaze offers the ability to interface various external devices so that you can acquire data from a device or send commands to a device.
Communication System
VRmaze supports communication over virtual COM ports and TCP/UDP network.
Methodology in VRmaze
In VRmaze, the general procedure is often the same. We assume that the protocol does not have to be tailored specifically to a computer to work properly. Plugging a device into a computer assigns it an automatic virtual communication port (COM port) that may be different from machine to machine.
VRmaze offers to store virtual COM port information directly in the preferences to allow a device to be used without changing the protocol. The principle is as follows: a protocol using an external device will check the address of the communication port directly in the software preferences and use the address to establish the communication. When changing computer, the protocol will use the address given in the preferences of the second computer, so no modification of the protocol will be necessary.
Network communication
In the case of network communication, there are not necessarily any software preferences to configure.
Communication Entity
Nodes allowing communication as well as interaction with devices are very often of type Entity and will therefore be available at the entity list level.
Specific preferences
In VRmaze, each type of device has its own preferences. In addition to the communication port, some devices use other preference properties to store calibration data for example.
Microphone case
The case of the microphone is a little different. This device does not have a management node, only a node for recording as a specific DataRecord.
Communication
In VRmaze, communication with a device is a conjunction of two nodes. The first node manages the communication by opening and closing the virtual COM port. The second node uses the data provided by the first node to produce an interaction, record data, or send a new command to the device. This second node never interacts directly with the device, it always goes through the node managing the communication. The interest lies in the fact that there can be more than one node using the data from a peripheral, just as there can be more than one node sending orders to the peripheral without having to open and close the communication each time.
Opening communication
Whether in virtual communication port or network port, receiving data from a device can only be done with one port opening, it is not possible to open a communication port twice at the same time, so it is necessary to have only one management node activated at any given time.
Activating a management node
The management node must be placed at a strategic location in the protocol tree. If communication is to be open throughout the protocol, this node must be a direct child of the protocol. For communication within an experiment only, the node should be either at the protocol level (this will not interfere with other experiments) or more properly as a direct child of the experiment. It is also possible to place the handler directly as a child of a trial, but this is more rare and often less efficient.
Storing results or sending new orders
In VRmaze, the storage of results in the form of DataRecords is necessarily done in a trial node. The nodes storing the results have natively their own backup system with specific trackers. The communication methodology with the management node is as follows: the storage node registers with the management node and then, with each new data received by the management node, the latter sends the new data to all registered nodes. When the new data is received, the storage node takes this new value and performs its action in correspondence.
Regarding the sending of new orders, the methodology is a little different. The specific handler, able to send new orders, defines in its source code a set of methods that can be called by the interaction node. This interaction node does not handle the content of the order directly, it just calls the desired function of the communication handler. When a function of the handler is called, the handler translates the order into a command that can be interpreted by the device and sent to it.