If your device uses an unusual protocol then you can use DAQFactory sequence scripting to create your own protocol driver. To do so, create a new comm device as described earlier and click on the New Protocol button at the bottom of the comm device configuration window. Creating a protocol is almost identical to creating a user device with a few differences. To learn about creating a user protocol, please review the section on Creating a User Device and Local Variables keeping in mind the following points:
1) The File Name should end in .ddp instead of .dds. It still must be placed in your DAQFactory installation directory.
2) You should use the low level comm functions to communicate with your device. They are all local to your protocol code. Since you don't know what comm device your protocol might be assigned to, you should not use the Device.CommDevice. notation described in the section on low level comm, but instead simply reference the functions directly. For example:
Write("GetSomeData" + Chr(13))
strResult = ReadUntil(13)
This will insure that your protocol will work with whichever port it gets assigned to.
3) Since you will probably be using the low level comm functions, you can ignore the parts about extern DLL calls. Instead, you probably should do a Purge() or perhaps an Init() in your OnLoad event, and maybe a Purge() in the OnUnload event.
4) In addition to the OnLoad() and OnUnload() events, there are additional events called OnReceive(strIn) and OnSend(strOut). OnReceive() is called with every character received on the port and OnSend() is called with every string sent out the port. Note the difference, OnReceive() is with every individual character, while OnSend() is with each complete string (i.e. with each Write() call) not each character in the string. OnReceive() passes in the variable strIn that contains the character received, while OnSend() passes in the variable strOut containing the string sent out.
Note: You cannot Write() from within the OnSend() event. This will create an infinite loop as Write() will trigger the OnSend() event. If you do so, you are likely to hang the communications and have to restart DAQFactory.
You can, however do Read() and ReadUntil() from within the OnReceive, which is often very handy. For example, if you have a device that simply outputs a value every second followed by a carriage return, you might put:
if (strIn == chr(13)) // we've received the EOL character
private string DataIn = ReadUntil(13) // read what we've accumulated
Channel.AddValue(strDevice,0,"Input",0,StrToDouble(DataIn))
endif
This routine also shows the use of the AddValue() command that doesn't require a channel name and the strDevice variable of your device. You would want to create an I/O type called "Input", but with no code. The code above will take the value and put it in our device, D# = 0, I/O Type "Input" and channel 0.
5) When you create a new protocol, a standard Poll() function is created for you. This function performs a simple poll and wait for response. Its format is Poll(string out, until) where out is the string to send out the port, and until is the ASCII code that marks the end of the incoming line. This function will generate an error if there is a timeout, otherwise it will return the string received. The script for the code is completely viewable and even editable. The function is a very commonly used function and is provided to make creating new protocols easier.
6) Even though you may be sending your value out as a string using Write() or reading it as a string with Read(), you will probably want your I/O types to be numeric. The deciding factor is how DAQFactory stores the value internally for calculations and not how the communication with the actual device is done.
7) Local variables are specific to the device the protocol is assigned to, not the protocol itself. This means if you use the same user protocol on two different ports and therefore two different comm devices, you will have two sets of local variables.
8) Within a function or I/O type, you can access the device name that the user assigned your protocol two through the strDevice variable. This is most often used with the Channel.AddValue() function as shown above.