UCON Protocol Quick Start Guide - Basic Guidelines for Using UCON
The U-CON Protocol Quick-Start Guide will walk you through the configuration of an Unsolicited Serial protocol for a barcode scanner. While your particular protocol might be quite different from this, this protocol includes the configuration steps required for most protocols. Steps for other protocols are also noted in this guide.
Starting a U-CON project begins with reviewing your protocol and knowing some things about the communications you will be doing based on this.
- Are you using Serial or Ethernet to connect to the device?
- Is the connection a solicited or unsolicited message?
- Solicited messages are when the UCON has to send a message or command requesting a read or a write.
- Unsolicited messages are when the device will connect to the PC to start sending message without a request or command.
Once you know if your making a Serial or Ethernet connection and whether communications are solicited or unsolicited, you can begin configuration of the TOP Server. If you have never configured a Channel or Device in the UCON or TOP Server before, please refer to our TOP Server Quick-Start Guide. Once you have configured your Channel and Device for your system, right-click on the Device you have created and choose Properties. Next, click on the Transaction Editor tab as seen below.
|
|
|
|
|
Once you know if your making a Serial or Ethernet connection and whether communications are solicited or unsolicited, you  can begin configuration of the TOP Server. If you have never configured a Channel or Device in the UCON or TOP Server before, please refer to our TOP Server Quick-Start Guide. Once you have configured your Channel and Device for your system, right-click on the Device you have created and choose Properties. Next, click on the Transaction Editor tab as seen below.
The Transaction Editor is where you will configure the UCON transactions based on your protocol that will be used to communicate with your device. All tags for the UCON project will be created and modified through the Transaction Editor. Do not modify tags outside of the Transaction Editor as any of these changes will not be passed to the Transaction Editor and will fail to work with your protocol.
You can also add a password to the Transaction Editor to prevent unwanted changes. We recommend that you wait to use this feature until after you have verified communications with your device.
|
|
|
|
|
Once you click on the “Launch Transaction Editor” button, you will see the Device Profile window open, as seen below.
|
|
|
|
|
|
|
|
|
|
As you can see, the Device that was configured is called Device1. When you highlight your Device, the three yellow Icons will appear available as in the image above. The first yellow Icon/Button is for creating a group to organize the tags and tag blocks in your project. The second is for creating a block which is a group of tags that work together for sending or receiving data in the same message. The third is for creating a tag under a device, tag block or tag group to hold information.
|
|
|
|
|
|
|
|
|
|
Next highlight the word under the block name, (it will say either Unsolicited or Read), then right-click in the right window under the Step field and the Options/Commands available will display as shown below.
|
|
|
|
|
|
There are four different categories of commands available for use in the Transaction Messages for sending and receiving data:
- Write Commands are used for controlling the data sent to a device.
- Read Commands are used for receiving data from a device and passing it to a client application.
- Conditional Commands are used advanced applications involving conditional processing of received data based on conditions you have defined.
- Processing Commands are used for certain internal processing operations in the UCON driver.
|
|
|
|
|
|
|
Most protocol implementations are going to use mostly Write and Read commands for communications. When doing a Solicited message, the first step is normally to Write a Character or String as part of the first command requesting a read. When doing an Unsolicited message, the first step will be to do a Read Response. The Read Response is used to determine what incoming information makes up a single RX message or packet of information.
|
|
|
|
|
|
Notes on Commands
When doing a read or write to the device, the first step is normally to write special characters or a string using Write Chracter or Write String. This gets put into the TX buffer which gets transmitted by using the Transmit command. When doing a write, you will also need to use either the Copy Buffer or Write Data command to move the data your client wrote to the tag to the TX buffer.
The Read Response can be used after the Transmit when waiting for a response to the commands sent. This puts the information coming to the PC port into the RX buffer. Once in the RX buffer you can use the Update Tag command to put data into your tags. You can also use the different Test commands to check the incoming data for expected characters or ID data.
Using the Log Event command is also helpful for debugging a protocol. By sending specific messages to the Server’s Event Log, you can be sure what specific actions have or have not taken place when testing your configuration.
|
|
|
|
|
|
|
As shown below, the Read Response command can determine the size or length of a response packet using one of 3 methods:
- Frame has known length - this method is used when a response packet will be a known number of bytes in length.
- Frame is terminated by stop characters - this method is used if a response will always end with a particular character.
- Frame contains a data length field - this method is used if a specific byte or bytes in a response specifies a length.
|
|
|
|
|
|
|
|
|
|
We are creating a barcode scanner protocol in this example above that is using a carriage return and a line feed as special stop characters. Now that UCON now knows how to receive responses from the device, we need to create a tag to receive data from the incoming string of data. Highlight the tag block in the left pane and click on the second yellow button/icon to create a tag. We will first create a tag named “Counter”.
|
|
|
|
|
|
This is a special tag that will be used to keep a count of each incoming data event. This is done because two scans might hold the same string value and we would need to know that the data has changed, since identical values will not register as data changes. If we only read the data tag in our client an event won’t happen to notify our client of a change, but this counter tag value will change every time we get a new read, regardless of the value.
In this case we have made it a Long, but you can configure this to increment to any size number, and the value will increment up to the maximum possible value for that data type before rolling back to 1 again.
|
|
|
|
|
|
|
The next tag we will create will hold the string value of the data from the Barcode.
|
|
|
|
|
The configuration of this tag will determine how much of the data will be interpreted as information for this tag. If we set the data type to Word, only 2 bytes of information would be seen as belonging to this tag even if the data contained more then 2 bytes of information.
In this case we don’t know how long the String will be in every case, so we have to define it as a variable length string. This is done by clicking on the Format properties button.
|
|
|
|
|
|
|
|
For a variable length String we need to make sure the Fixed length box is not checked.
Since our data ends with a carriage return and line feed there are two ways we can determine the end length of the string.
- First, we can click the “Parse to next delimiter” option and use the carriage return character, as shown.
- Second, we can just change the “Read up to” field to 2 bytes, telling UCON to place all bytes in this field until there are only 2 bytes left in the frame.
Either method will work for this simple protocol, but for cases where the data contains more than one tag of information you will want to use the “Parse to next delimiter if present” setting, if there is one, for variable length data.
|
|
|
|
|
|
|
|
Once we have these two tags configured, we highlight the Unsolicited listing in the tree of the Device Profile again. Then, right-click under the existing Read Response entry that we have already added and choose the Update tag command.
|
|
|
|
|
|
The first tag that we will update is our Counter tag. The tags we create will show up under the Tag drop down as shown to the left. Since this tag is for counting events, we select the Event Counter as the Data source. You can add a description to these if you like to help keep track of your protocol configuration.
Next, we will right-click under the previous Update tag event and enter another Update tag event. In this case we will now update the Input tag. The input tag’s Data Source is the Read Buffer, as shown below.
Once this is done we can close the Device protocol window. It will ask if we want to update the Server and we will click Yes, so our work will be saved. This is a good time to save the whole project in the Server by clicking on the File menu and choosing Save As.
|
|
|
|
|
|
|
Now, we can test our protocol by opening the OPC Quick Client with the icon for the OPC Quick Client. See the OPC Quick Client information on how to use the OPC Quick Client.
It’s also a good idea to right-click on the Channel in the TOP Server, choose Properties and enable the diagnostics. The Channel Diagnostics can now be opened by right-clicking on the Channel.
With both of these open, you can now do a scan and test the protocol. The OPC Quick Client should show the value scanned in the Input tag and the Counter tag should increment to 1. The diagnostics should show the RX values returning in White.
|
|
|
|
