: Troubleshooting I/O Issues in Industrial Application Server

 

NOTE:  This article and all content are provided on an "as is" basis without any warranties of any kind, whether express or implied, including, but not limited to the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall Q-mation be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortuous action, arising out of or in connection with the use or performance of information contained in this article.

 

 

Troubleshooting I/O issues in Industrial Application Server can seem complex to those who do not know the diagnostic data available to them.  However, once those tools are learned, many discover that Industrial Application Server gives the user a great depth of diagnostic and troubleshooting capabilities that allows him/her to be able to diagnose I/O issues quickly and effectively.  This article discusses strategies within Industrial Application Server that users can implement to diagnose connectivity issues.

 

  1. Check to see that the DI Object is connected (if using DDESuiteLinkClient or OPCClient)

The first thing one always wants to check when troubleshooting I/O Connectivity is to make sure that the DI Object you are using to connect to the your data servers is indeed connected.  To find this, go to the DDESuiteLinkClient object that the object is configured to access, and check the .ConnectionStatus attribute in your object viewer.  If the status is “Disconnected,” then there is an issue between your DI Object and the Data Source you are trying to connect to.  You can attempt to reconnect a $DDESuiteLinkClient object by selecting the .Reconnect attribute, double-clicking to edit the property value, setting the value to “true” and hitting OK.  If the status still says “Disconnected”, you will want to check the connections between your data source and the DI Object. 

NOTE – this is a one-shot value, so it will never VISIBLY turn true in the object viewer.  Additionally, do not hit “Apply,” then “OK”, for then it will send TWO reconnects to the object. While this will not cause an issue in most cases, it is good practice to either click “Apply” then “Cancel” or just click “OK” when editing values in Object Viewer.

 

Remember, The Object Viewer has the ability to save multiple watch windows with different sets of attributes.  A good practice is to make a watch window tab for each DI Object you have with the .ConnectionStatus, .ServerName, .ServerNode (and in the case of $DDESuiteLinkClient, .Reconnect) attributes. This creates a central location to see all of the connection data for a system.  (If you’re really ambitious, you may even want to create a screen in InTouch to display all of this data as well, as every attribute accessible in Object Viewer is also accessible through InTouch!)

  1. Ensure any related objects are On Scan

If you are accessing attributes from different objects or engines, ensure that those objects are on scan.  Remember, in the Industrial Application Server runtime, an object can be deployed to a platform, but may be off scan.  If an object is off scan then it is not part of the engine process at that time, and hence any references to attributes on that object will come up invalid.

 

 

To see if an object, engine, or platform is off-scan, simply open up Object Viewer.  In the object selection tree, if the object has a yellow exclamation point on it, select it and look at the .ScanState attribute – if this is false, then the object is off-scan.

  1. Check the InputSource of the object, verify it is correct

Every attribute that is configured to accept I/O from outside its object has an .InputSource sub-attribute, which tells it where to get its data.  Oftentimes, problems with communication simply boil down to the attribute not looking at the right attribute because oftentimes in Industrial Application server the I/O is automatically configured via scripting. Additionally, keep in mind any parameters that may be needed for that attribute to correctly address the item in the PLC.  A good example of this is Program Scope tags in Allen-Bradley Contrologix PLCs, where the item must be prefixed by the program name.  If the address in this InputSource is wrong, check the scripting to verify it is accessing things correctly.

 

  1. Check the .ReadStatus of the object

In addition to the .InputSource of the object, there is a .ReadStatus sub-attribute associated with each I/O attribute. The .ReadStatus attribute will be empty if communications are good, but if communications are bad, the .ReadStatus attribute will give hints as to what may be going wrong with the communications.  For example, a ‘Configuration Error: invalid attribute ID’ often means that the attribute that the object is trying to connect to does not have the attribute specified.  ‘Configuration Error: invalid item ID’ often means that the attribute is attempting to connect to an item in the desired device that does not exist.

  1. Check your DA Server

If the previous four points did not seem to solve the communications issues observed, chances are that it is a problem between your IO server / DA Server and the field device itself.  If you are using one of Wonderware’s Data Access Servers, or DA Servers, be sure to check the Diagnostics in the DAServer manager, which is located in the System Management Console.  The DA Server’s diagnostics give an item-by-item status of what is currently being polled by its clients.  If a particular attribute being polled by your DI Object is showing bad quality (designated by a red square in the Diagnostics), then check other items coming from the topic in the Device Groups diagnostic section.  If all of the items being polled by a topic are bad, then there is an issue with communications between the DA Server and the field device.

 

 

Additionally, the Log Viewer, also located in the System Management console, will also give feedback if there is a problem with communication.  By filtering by the server name (i.e. DASABTCP), the Log Viewer will show all messages received by that server, and oftentimes, this will give hints as to the issue.  For example, if an item is misnamed, the server will throw a message into the logger either stating it is an invalid item or that the server failed to poke the item (if a write is attempted).

 

Please feel free to email support@qmation.com with questions.

 

©2003 Q-mation, Inc. All rights reserved. All trademarks are the property of their respective owners.