Once you have created a port to communicate on, you can then select the desired protocol to communicate. The protocol is essentially the language used to communicate with your device and will be specific to your device. Many devices use a standard protocol, and we've provided protocol drivers for these protocols. For example, Modbus, which is used in a wide variety of devices. With the protocol drivers provided with DAQFactory, all you need to do is select the protocol and the port for your Comm Device and you are done. You can hit OK and begin using your device as described in Using Comm Devices. If your device uses a more unusual protocol that we do not currently include with DAQFactory, you have a couple choices. Your first choice is to contact us and see what would be involved for us to develop a protocol driver for your device. This can often be very simple and affordable. The other choice is to use DAQFactory scripting to write your own protocol driver. For many devices this is actually not a difficult task and is the subject the section, User Comm Protocols.
In addition to the regular DAQFactory protocols and user protocols, there is the NULL Protocol. The null protocol is just that, a nothing protocol. It does nothing. Use this protocol when you wish to use the low level communication functions of the comm port from a sequence or elsewhere in your application. One use for this is when you wish to receive data from a device that does not require polling and simply streams data to you without prompting. Using the OnReceive event of a user protocol is probably better for this type of device, but this serves as an example: In this case you could create a Comm Device with the null protocol, then create a simple sequence to read from the port. For example, to read from a streaming input where each line ends in a carriage return (ASCII 13) you might do:
Private string strIn
while (1)
try
strIn = Device.MyComm.ReadUntil(13)
... parse strIn ...
catch() // catch any comm errors and ignore
endcatch
endwhile
Note that we don't need a delay() in the loop as long as the timeout on the port is set to at least 20 milliseconds. The loop will run as fast as the data is coming in, but will pause whenever it is waiting for more data.