|
|
What
is a Profile?
| A profile is a file that contains the definition of all
messages used by the UOS OPC Server to communicate with a field device or
group of field devices. It defines how to read and write data and how to handle error
responses. Each profile is assigned a name so that it can be associated with the type of
I/O hardware that it supports. You load the profile by using the profile browse button
located in the UOS OPC Server user interface (called the Powertool). Loading a profile is
the same as selecting hardware type in any other OPC server. |
| Integrators and end users can
build their own profiles using the UOS Profiler (sold
separately). Building a profile is the key step in creating a new OPC Server.
Building a profile does not require any programming (Visual C++, C++,
VB, etc.) expertise. |
| A profile is comprised of four object types: Command Group
Objects, Command Sequence Objects, Message Objects and Communications Objects. They are
also referred to as GroupObjects, SeqObjects, MsgObjects, and CommObjects respectively. |
| |
| Command Group Objects (GroupObjects) |
| Each GroupObject defines a specific function to transfer
data or to initiate a control action between the UOS OPC Server and a field device. An
example of a GroupObject to transfer data would be reading the process variable (PV) and
loop setpoint (SP) for a temperature controller. A second GroupObject may read the entire
set of controller tuning parameters. A control action GroupObject would be one that
changes the controller mode from Manual to Auto. A GroupObject is comprised of Sequence
Objects and Message Objects. The tree below shows the structure for a single
GroupObject. |
Figure 1 - Read/Write Command Group
Object (Group Object) Structure
| Command Sequence Objects (SeqObject) |
| A GroupObject has two parts: a Read command sequence
object (ReadSeqObject) and a Write command sequence object (WriteSeqObject). The
purpose of the ReadSeqObject is to define the messages necessary to read data from a
device. It can be used in a different way for advanced functions, but reading is the
primary purpose. As you might expect, the purpose of the WriteSeqObject is to write data
to a device. Figure 1 shows the ReadSeqObject and the ReadSeqObject for a command group. |
| |
| Message Objects (MsgObjects) |
ReadSeqObjects and WriteSeqObjects are comprised of
MsgObjects. There are three types: Request, Response and Error. A simple ReadSeqObject
would contain the following message objects:
- Request data from a device using the Request MsgObject AND…
- Receive a response from the device in a format defined by
the Response MsgObject OR…
- Receive an error response from the device in a format
defined by the Error MsgObject.
Each message object type is represented in the UOS Profiler
by an icon as shown below. A Request MsgObject is represented by a right arrow icon to
indicate that communications is going OUT of the OPC Server to the device. The Response
and Error MsgObjects are represented by a left arrow icon to indicate a communications
flow INTO the OPC Server. |
| Figure 2 shows a simple read-only GroupObject that contains
a ReadSeqObject. The ReadSeqObject contains a Request, Response, and Error MsgObject. Note
that the WriteSeqObject is empty. This GroupObject will not support writes to a device. |
Figure 2 - Read-Only Group Object
Structure
| How the UOS Profiler uses GroupObjects, SeqObjects, and
MsgObjects |
| There is one class of objects that we have not explained
yet. Before we do, lets see how the UOS Profiler uses GroupObjects, SeqObjects and
MsgObjects to define communications with a serial device. |
| The Figure below shows a snapshot of the UOS Profiler
workspace used to build a profile. All GroupObject names are listed in the area labeled Command
Group List. A description of the selected GroupObject is shown in the Description field. The read and write SeqObjects and their related MsgObjects are shown in the area
labeled Command Group Tree. The ReadSeqObject is labeled Read and the
WriteSeqObject is labeled Write. |
| To build a new GroupObject (Command Group), name it and use
the message object buttons to add the required MsgObjects to the read and write
SeqObjects. The command group highlighted (named RW_Holding) was build to read and write
Modbus Holding resisters. |
Figure 3 - UOS Profiler Workspace
| Communication Objects (CommObjects) |
| As noted above, there is one more class of objects needed
to define communications with a serial device. This final object class is called
Communications Objects or CommObjects. CommObjects are used to define the detail content
of each MsgObject. There are ten CommObjects. They are shown in the table below. |
Table 1 - UOS Profiler CommObjects
|
CommObject
|
Description
|
| [Const] |
Specifies a constant. |
| {Var} |
Specifies a variable. A variable
can contain a single data item or an array of data items. |
| <Start> |
Specifies the Start address of a
block of data |
| <End> |
Specifies the End address of a
block of data |
| (Msg Len) |
Specifies the message length. |
| <Data Len> |
Specifies the number of data
items to read or write |
| <Dev Addr> |
Specifies the field device
address. |
| (Checksum) |
Specifies the location and type
of Checksum checksum |
| [Parameter 1] |
Specifies any device protocol
parameter |
| [Parameter 2] |
Specifies any device protocol
parameter |
| The best way to understand how CommObjects are used to
build a MsgObject is to look at an example. We will use Modbus RTU protocol in our
example. The message structure (MsgObject) to read Holding Registers for the Modicon
984/385 is: |
Table 2 - Modbus RTU Read Request MsgObject
|
Device
Address
|
Modbus
Function Code
|
Register
Start Addr
|
Number of
Registers to read
|
Checksum
|
| 01h |
03h |
0000h |
0010h |
4406h |
| <Dev Addr> |
[03h] |
<Start> |
<Data Len> |
(Checksum) |
| The first row in the table describes the Modbus protocol to
Read a block of Holding registers. The second row contains the hex codes to read 16 (10h)
holding registers starting at address 0000h from a device whose address is 01h. The third
row shows how CommObjects are used to build the MsgObject. Compare this row to the Selected
Command field shown in Figure 3. |
| All CommObjects enclosed with < > are user
configurable. This means that the value for the CommObject must be entered when setting up
the UOS OPC Server for communications with a device. When the profile containing this
MsgObject is loaded the corresponding fields will automatically become active to allow
user configuration. For this example, it gives the user the flexibility to select the
device to read from and the block of holding registers to read. |
| CommObjects enclosed with [ ] are constants. Constants are
fixed (cannot be changed by the user). |
| CommObjects enclosed with ( ) are protocol dependent. For
example, the Modbus RTU protocol checksum is a CRC-16 calculation that depends on the
values of all CommObjects from <Dev Addr> to <Data Len> inclusive. |
| CommObjects enclosed with { } are variables. A Variable
CommObject would be used in the Read Response MsgObject (not shown here). Variables may
contain a single data item or an array of data items. Variables may also be digital or
analog. |
| The CommObjects shown in Table 1 are used to build Request,
Response and Error MsgObjects. |
| |
|
