Top Ten Considerations for deviceWISE Configurations

Introduction
When configuring deviceWISE for a specific application, customers have encountered
challenges where they required additional information. This document provides a look at
ILS Technologys best practices and recommendations to avoid common issues customers
encounter while configuring applications using deviceWISE.
1. How do you define a transport to a specific Microsoft SQL Server database instance?
When configuring a deviceWISE SQLServer transport for an instance other than the default
instance, you may encounter issues like failure to validate the transport. The exception log
will indicate the following error:
Login failed for user 'xxxxx'.
This error is due to the deviceWISE transport attempting to connect to the default instance
rather than the specific instance, and the userid is not configured on that specific instance.
If the SQLServer instance is configured to listen on a dynamic port then you might see the
following error in the exception log instead.
Connect timed out. Verify the connection properties; check that an instance of SQL
Server is running on the host and accepting TCP/IP connections at the port, and that
no firewall is blocking TCP connections to the port.
To correct this issue, follow these steps to make sure that you have configured the
transport definition correctly.
(1) Verify that SQLServer is configured for mixed mode authentication. ( NOTE: This step is not

Figure 1
1

required for deviceWISE Enterprise on Windows ) To verify, launch the SQLServer Management
Studio and go the Server Properties as shown in Figure 1.
On the Properties screen make sure that Server Authentication has been set to SQL Server and
Windows Authentication as shown in Figure 2.

Figure 2.
(2) Determine the port number that the SQLServer Instance is listening on, and make sure that the
instance is listening on a static port.
(a) Connect to the Instance using SQLServerManagementStudio .
(b) Run the following command as shown in Figure 3. Look for the Server is listening on entry.
This gives you the port number that the instance is listening on.

Figure 3
2

(3) Configure Instance to Listen on a static port

If the instance is configured to listen on a dynamic port, then you need to configure it to listen
on a static port.
(a) Launch the SQL Server Configuration Manager application
(b) Select Protocols for the instance as shown and then Right Click and select Properties as
shown in Figure 4.

Figure 4.

(c) Select TCP/IP properties as shown in Figure 5. You can modify the IPAll configuration to
specify a static port 1433 as shown.

Figure 5.
You could also configure the instance to listen on static port on all network interfaces [0.0.0.0]
as shown in Figure 6. Make sure you blank out the TCP Dynamic Ports field.

Blank out Field

Figure 6.

(4) Configure the deviceWISE SQLServer Transport Definition with the specific port number, as
shown in Figure 7.

Figure 7.
Also specify the instance Name in the extended attributes panel as shown in Figure 8.

Figure 8.
Additional Reference Information
http://support.microsoft.com/kb/823938

2. How do I set up a listener?

A listener is a little more complex than a transport. For this example we will use a TCP
listener. The first step is to configure the listener. You will need to have two groups of
information to configure the listener, the TCP connection information and the message
information. The connection information consists of the port number, maximum message
size, number of connections, timeout, and the IP addresses and subnet masks you want to
receive messages from. The message information includes the format, delimiters, encoding
and termination character. For this example, we will use an ASCII message format. An
example listener configuration is shown in Figure 9.

Figure 9
The second step is to configure the listener map. The listener map defines the message that
will be received by the listener. In the example in Figure 10, the listener map is expecting
four parameters: a string, an integer, the float and a timestamp. When a message is
received from one of the four IP addresses defined in the listener, and it calls the

TestTCPListener listener map with its four parameters, it will process the trigger set up for
that message.

Figure 10
The message for this listener map would look like the following:

One of the key parameters is the first. The message is required to start with the name of
the listener map it is calling. Following the listener map name are the input parameters
defined in the listener map, separated by the delimiter defined in the listener configuration
and terminated with the termination character, also in the listener configuration.
The final step is to define a trigger to fire on receipt of the TCP message. For this trigger,
the event will be a listener event, and the corresponding listener map is selected to define
the message to be received. Once these are selected, the message parameters will appear
as event variables, and can be used in the trigger for processing the data. Figure 11 gives an
example of a listener trigger.

Figure 11

3. How do I get a consistent and valid indicator that my database select transaction has
successfully completed?
In deviceWISE, the default pattern is to map all information from an SQL request to a
register in the PLC. However, the order of this mapping is not deterministic. The following
data is usually returned from an SQL query:
1) Status of query-- "result status" INT4
2) Number of rows -- "row count" INT4
3) Block of result data -- "data"
In the case of the PLC logic, the ladder may be looking for the "status of query" to change to
trigger the next activity with the data. However, the problem is that that "status" may be
written before the data is written. Then the PLC logic could start to operate on data
registers which have not yet been updated.
To solve the problem, add one step in the trigger definition. When mapping the query
results, do not map all items directly to the PLC. Instead, map the "data" directly to the PLC
and map the "result status" and "row count" to local variables in deviceWISE as INT4.

Perform the following steps in the trigger to ensure deterministic interlock of data to the
PLC:
1) Map row data to PLC, but map the returned status and row count to local variables
2) Add action "device commit" to flush the data to the PLC
3) Set the local variables to the PLC: "status" and "row count"
3) Add another action "device commit" to flush the status and row count to the PLC.
The PLC program can now look for the "result Status" and "row count" and be guaranteed
that, if successful, the data is already present.

4. How do I use the FB56 instruction in the ERPC ?

The FB56 provides an unsolicited message for a transactional type of application. The PLC is
responsible for collecting all the data and then triggering the FB56 function. The FB56
function will enter the "in progress" state until deviceWISE confirms what happened to the
data. If the transaction completes successfully, then the FB56 will wake up with an OK. If
the transaction fails or enters store and forward, the FB56 function will receive an error.
The important fact is the data is atomic. For example, if the data to be sent is scattered
across multiple dbs (tags) in the PLC, a snapshot is taken of this data atomically (which
means that the PLC can change the original data) and starts the delivery process.
The primary advantage on the Siemens implementation is the PLC Programmer sets the
"envelope" and the deviceWISE integrator decides what data items are to be included.
The FB56 and deviceWISE logic triggers are good for simple transactions. The PLC will know
if it the transaction completes successfully and data is atomic.

5. How do I set up the trigger action routing to minimize failing triggers?

One of the initial ways that a trigger can fail is to have incorrect action routing. The person
configuring the triggers needs to make sure each action is routed to the correct next action
to properly perform the operations they define. The routing tab has multiple conditions
which should each be routed for the trigger to function successfully, as shown in Figure 12.

Figure 12

Make sure to check all the routing options, and for best practices, do not leave any with an
UNDEFINED path. The failure path provides a means for handling errors in your triggers.
It is a good practice to develop error handling actions to reduce troubleshooting time if a
trigger fails. The minimum is to assign failure paths to the ENDERR path, if no other error
handling is required. This is shown in Figure 13.

Figure 13

6. How do I fix invalid licenses for deviceWISE Embedded for the ERPC?
This is a common problem for all deviceWISE Embedded for ERPC customers. The primary
cause for this problem is the clock is not set in the CP. The license processing on
deviceWISE is based on the date and time in the CP. The CP does not have a clock that is
battery backed up. When the CP is powered off, the clock stops. There are two ways to get
the correct time in the CP, and they are both controlled by Step7. The ERPC needs to be
configured to source the time & date from a company time keeper. Usually NTP is used, but
Siemens has another method, called SIMATIC TIME. In either case the date and time needs
to be set or licenses will not work.

7. How do I use the MSG instruction from a Rockwell PLC ?

A Rockwell unsolicited message can initiate the execution of a deviceWISE trigger from the
ladder logic in a Rockwell PLC. This can take the place of having a deviceWISE trigger
constantly polling a Rockwell PLC variable to see if an event has occurred. The data can be
any data buffer available within a Logix, a PLC-5, or a SLC 500 PLC. The trigger will execute
the actions that are defined in it. For example, a trigger could read data from a PLC variable,
write data to a PLC variable, send a transaction to an enterprise application, etc. For more
information on triggers and actions, see the deviceWISE Trigger Actions Guide and
Reference.
Defining a Rockwell Logix unsolicited message using the RSLogix tool
The following section shows an example in the Rockwell Software RSLogix 5000 of how to
add a rung of a ladder and configure a message instruction that can send an event
notification to deviceWISE.

10

1. Add a MESSAGE structure to the global tag space. It can be named anything you want.
Add a rung of a ladder to send the message instruction.

2. Configure the message instruction by clicking the button. You will see a dialog box
similar to Figure 14:

Figure 14
Here are some notes on the important parameters of the above configuration panel:

Message Type: Must be CIP Generic.

Service Type: Must be Set Single Attribute or Get Single Attribute.
Instance, Class, Attribute: Can be any combination, the event will use these three
values to establish a match to find the correct deviceWISE trigger to execute.
Source Element: Can be any tag in the system that you wish to send to the
deviceWISE trigger.
Source Length: The number of data bytes to send, this number should not exceed
the size of the tag defined in the Source Element field.

3. Next go to the Communication tab in the configuration panel. It will look like Figure 15:

11

Figure 15
4. The Path should be set to the proper path to reach the deviceWISE node that contains
the trigger to execute. In general, the path will be first to the Ethernet module in the rack,
then 2 (for Ethernet), and the IP address of the deviceWISE node. For example:
LocalENB, 2, 192.168.5.243
Where: LocalENB: is the name assigned to the Ethernet module in the PLC rack. 2: indicates
that the next path is an Ethernet route. 192.168.5.243: is the IP address of the deviceWISE
node. Refer to your RSLogix 5000 documentation for more information.

Defining a trigger for an unsolicited message

Two new trigger events will be available under the PLC Logic Events Trigger Event Type
menu option to support the receipt of unsolicited messages from Rockwell PLCs, The
Rockwell (CIP) option will support the receipt of unsolicited messages from ControlLogix
PLCs, while the Rockwell (PLC5/SLC) option will support the receipt of PLC-5 Typed Write or
PLC-2 Unprotected Write messages from PLC-5 and SLC 500 PLCs.

12

Figure 16
Unsolicited Logix Listener trigger
To define a trigger that executes when a Rockwell Logix unsolicited message is sent, select
the Rockwell (CIP) Trigger Event Type and then set the Trigger Definition fields in Figure 17:

Figure 17

13

8. What are some rules of thumb regarding capacity planning and tuning?
What commonly occurs when a new user configures deviceWISE for the first time is they
configure triggers at fast rate, which they may not need. The result is the communications
method becomes unnecessarily busy. There are two parameters to focus on for capacity:
CPU usage and memory usage.
A good rule of thumb for CPU usage is during steady state of operation, the CPU should not
exceed 60%. This will allow capacity for processing spikes, store and forward recovery, and
other CPU intensive operations. A good rule for memory usage is to keep it below 90%.
Anything over 95 % is dangerous. Memory usage is a function of how many items are
defined and started in the system. The items include devices, triggers, local variables,
transports, transport maps, listeners, listener maps and others.
In systems where the communication speed is critical and the application is transactional,
try using the FB56 unsolicited instruction.

9. What are some rules of thumb regarding naming conventions?

Here are a few notes on naming conventions for the components of a deviceWISE project.
It is a good practice to put a common prefix on all the components of project or application
to keep them grouped together and easy to identify. This will make it easy to select the
correct transport map in a trigger, or transport for a transport map. When exporting a
project, the prefix is an easy, visual way to make sure you are not referencing an unwanted
component.

10. Reminder to backup the deviceWISE configuration or export the projects

This cannot be stressed enough. Take exports and database backups of your nodes and
projects as you work through the configuration cycle, and as you make changes to your
application. You always want to have a backup of the current and previous deviceWISE
configurations in case there is a problem and you need to restore the previous
configuration. Make it a practice to take a backup or export before and after each time
changes are made.

14