Communication Guide, Trident v1

Trident Version 1 Systems
Communication Guide
for Trident v1 Systems
Assembly No. 9700079-002
April 2004
Information in this document is subject to change without notice. Companies, names and data used in
examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express
written permission of Triconex.
© 2004 Invensys Systems, Inc. All Rights Reserved.
Triconex, Tricon, Trident, TriStation 1131, TriStation MSW, and CEMPLE are trademarks of Invensys plc,
its subsidiaries and affiliates. All other brands may be trademarks of their respective owners.
Document No. 9720079-003

Printed in the United States of America.
Contents
Preface ix
Summary of Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Product and Training Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 1 Introduction 1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
TriStation Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Client/Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Peer-to-Peer Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Modbus Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Triconex Time Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Network Printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Module Capabilities and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Ethernet Port Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 2 Communication Hardware 5

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Triconex Communication Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Redundant Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
PC Redundancy for TriStation and SOE Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Testing for Hardware Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Media Conversion Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Media Adapter Units (MAUs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Print Servers and Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 3 TriStation Communication 13

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Communication Accessories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
MP Connection to a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Installing a Network Interface Card in a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . 17
Installing DLC Protocol on a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Directly Connecting a Trident MP to a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . 18
Connecting a Trident MP to a TriStation PC Using a Hub . . . . . . . . . . . . . . . . . . . . . 19
Setting the Trident Node Number with an Address Plug. . . . . . . . . . . . . . . . . . . . . . 20
Configuring an MP Connection to a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Communication Guide for Trident v1 Systems

iv Contents
CM Connection to a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Installing an NIC Card in a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Installing TCP/IP Protocol on a TriStation PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Directly Connecting a Trident CM to a TriStation 1131 PC . . . . . . . . . . . . . . . . . . . . 24
Connecting a Trident CM to a TriStation PC Using a Hub . . . . . . . . . . . . . . . . . . . . . 25
Setting the Trident Node Number with an Address Plug. . . . . . . . . . . . . . . . . . . . . . 26
Configuring a Trident CM Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
TriStation Software Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Installing the TriStation 1131 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Uninstalling the TriStation 1131 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Verifying the TriStation 1131 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Tagnames and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Write Access by External Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 4 Client/Server Communication 33

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Configuring Ethernet Ports in TriStation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuring a CM Ethernet Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Setting the IP Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting an IP Address Using a Trident MP Connection . . . . . . . . . . . . . . . . . . . . . . . 40
Setting an IP Address Using a Trident CM Connections . . . . . . . . . . . . . . . . . . . . . . 40
Message Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
DDE Server for Triconex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Specifications for Windows PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Installing the Triconex DDE Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring the DDE Server Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Specifying Triconex Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring Server Properties for 802.2 Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Testing a TCP/IP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuration Requirements for Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuring Redundancy With TCP/IP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuring Redundancy With 802.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Requesting Data with a DDE Client Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Requesting Network Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Monitoring Responses from the Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
OPC Server for Triconex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configuring the OPC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Redundant Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Adjusting System Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Other OPC Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
OPC Data Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
OPC Redundancy Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Contents v
Chapter 5 Peer-to-Peer Communication 61

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Peer-to-Peer Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Estimating Memory for Peer-to-Peer Data Transfer Time. . . . . . . . . . . . . . . . . . . . . . 64
Configuring Peer-to-Peer Ports in TriStation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Allocating Peer-to-Peer Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Using Send and Receive Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Send and Receive Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Sample Send and Receive Pair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Restrictions on Data Transmission Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Monitoring Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Status of Communication Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Status of Ethernet (Net1 and Net2) Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Sample Peer-to-Peer Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fast Send to One Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Sending Data Every Second to One Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Sending Data Only When Requested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fast Send of Safety-Critical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 6 Modbus Communication 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Physical Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Physical Media Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Multi-Point Connection Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Hardware Handshake Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Valid Modbus Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Modbus Communication Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Configuring Serial Ports in TriStation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Configuring MP and CM Serial Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Setting Signal Delays for Hardware Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Programming for Triconex Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Processing of Modbus Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Function Blocks for Communicating with Non-Triconex Slaves . . . . . . . . . . . . . . . . 88
Function Blocks for Communicating with Trident Slaves. . . . . . . . . . . . . . . . . . . . . . 89
Function Blocks for Communicating with Tricon Slaves . . . . . . . . . . . . . . . . . . . . . . 89
Sample Modbus Read Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Sample Modbus Write Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Programming for Triconex Slaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
How REAL Numbers are Scaled to Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Scaling REAL Values to Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
How Trident REAL Values are Transmitted Without Scaling . . . . . . . . . . . . . . . . . . 95
Disabling Scaling of REAL Values for Trident Tagnames. . . . . . . . . . . . . . . . . . . . . . 95
Sample Modbus Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

vi Contents
Chapter 7 Related Communication Features 97

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Trident Write Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Tagnames and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Time Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Master Node in a Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Time Adjustments from External Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Combination Schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Setting the Controller Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Setting Time Synchronization Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Printing from a Trident Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Printing and Scan Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Printing Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Selecting Printing Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Installing Printer Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Configuring a Trident CM for Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Using Print Function Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Appendix A Communication Module Capabilities 109

CM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Message Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Physical Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Types of Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CM Front Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
CM Communication Indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Protocols Supported by CM Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Appendix B Main Processor Capabilities 119

MP Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Message Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Physical Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Serial Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
TriStation Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Debug Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
MP Front Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
MP Communication Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Appendix C TSAA Protocol 129

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Byte Ordering in Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Symbol Table Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
TSAA Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
TRICON_DATA (Type 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Contents vii
TRICON_DATA_REQ (Type 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

WRITE_TRICON_DATA (Type 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
WRITE_TRICON_DATA_RSP (Type 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
READ_TRICON_CLOCK (Type 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
READ_TRICON_CLOCK_RSP (Type 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
SET_TRICON_CLOCK (Type 7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
SET_TRICON_CLOCK_RSP (Type 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
ADJUST_TRICON_CLOCK (Type 9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ADJUST_TRICON_CLOCK_RSP (Type 10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
READ_TRICON_DATA (Type 11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
READ_TRICON_RSP (Type 12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
TRICON_SOE_REQ (Type 13). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
TRICON_SOE_RSP (Type 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
TRICON_CPSTATUS_REQ (Type 15) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
TRICON_CPSTATUS_RSP (Type 16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
TRICON_SOE_DATAAVAIL (Type 17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
TRICON_GET_SYMBOL_REQ (Type 22, Trident Only) . . . . . . . . . . . . . . . . . . . . . . 153
TRICON_GET_SYMBOL_RSP (Type 23, Trident Only) . . . . . . . . . . . . . . . . . . . . . . 154
Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Appendix D Modbus Protocol 159

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Message Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Determining Message Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Modbus Functions and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Modbus Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Communication Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Function Names and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Modbus Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Sample Query and Response Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Modbus Message Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Modbus Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Read Coil Status Function (Function 01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Read Input Status (Function 02) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Read Holding Registers (Function Code 03) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Read Input Registers (Function Code 04) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Force Single Coil (Function Code 05) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Preset Single Register (Function Code 06) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Read Exception Status (Function Code 07) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Loop-Back Diagnostic Test (Function 08). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Force Multiple Coils (Function Code 15) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Preset Multiple Registers (Function Code 16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Transmission Errors and Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Transmission Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

viii Contents
Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Exception Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Exception Response Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Glossary 179
Index 187

Preface
This guide describes communication features available with Trident version 1 systems,
including how to install and configure communication modules. This document replaces all
previous versions of the Trident Communication Guide.
Trident version 1 systems can be used with TriStation versions 3.0 through 4.0 and later.
In this guide, Triconex controllers refers to Tricon and Trident controllers.
Summary of Sections
• Chapter 1, Introduction—Describes the types of communication available with a
Triconex controller and the capabilities of its communication modules.
• Chapter 2, Communication Hardware—Discusses the hardware used to enable
Triconex controllers for communication with each other and with external devices.
• Chapter 3, TriStation Communication—Explains how to connect a TriStation PC to a
Triconex controller and specify write access to points.
• Chapter 4, Client/Server Communication—Explains how to configure Ethernet ports
in the TriStation project and how to configure and use the Triconex OPC Server and
DDE Server client/server programs which use the TSAA messaging protocol.
• Chapter 5, Peer-to-Peer Communication—Explains how to set up controllers for
communication in a Peer-to-Peer network.
• Chapter 6, Modbus Communication—Explains how to set up a controller for
communication as a Modbus master, slave, or both.
• Chapter 7, Related Communication Features—Describes the time synchronization and
parallel printing features of a Tricon controller.
• Appendix A, Communication Module Capabilities—Describes CM operation and
physical communication interfaces.
• Appendix B, Main Processor Capabilities—Describes MP operation and physical
communication interfaces.
• Appendix C, TSAA Protocol—Provides a programmer’s reference for TSAA, which is a
Triconex protocol used for client/server applications.
• Appendix D, Modbus Protocol—Provides detailed information about the Modbus
protocol that can be used by Triconex serial ports.
• Glossary—Provides definitions of terms used in this guide.

x Preface
Related Documentation
These Triconex books contain related information:
• Planning and Installation Guide
• Developer’s Guides for TriStation MSW and TriStation 1131
• Safety Considerations Guide
• SOE Recorder User’s Guide
Product and Training Information

To obtain information about Triconex products and in-house and on-site training, see the
Triconex Web site or contact the regional customer center.
Web Site
http://www.triconex.com
Technical Support
Customers in the U.S. and Canada can obtain technical support from the Customer Support
Center (CSC) at the numbers below. International customers should contact their regional
support center.
Requests for support are prioritized as follows:
• Emergency requests are given the highest priority
• Requests from participants in the System Watch Agreement (SWA) and customers with
purchase order or charge card authorization are given next priority
• All other requests are handled on a time-available basis
If you require emergency or immediate response and are not an SWA participant, you may
incur a charge. Please have a purchase order or credit card available for billing.
Telephone
Toll-free number 866-746-6477, or
Toll number 508-549-2424 (outside U.S.)
Fax
Toll number 508-549-4999
E-mail
ips.csc@invensys.com

1
Introduction
Overview 2
Module Capabilities and Usage 4

2 Chapter 1 Introduction
Overview
Trident controllers can communicate with other Triconex controllers and with external devices
by using ports on the Main Processor (MP) Baseplate and the Communication Module (CM)
Baseplate.
This table lists the protocols available with each module.
Supported Protocol MP CM
TriStation 3 3
TSAA Client/Server 3
Peer-to-Peer 3
Modbus Slave 3 3
Modbus Master 3
Modbus Master/Slave 3
Time Synchronization 3
Network Printing 3
For guidelines on using Triconex communication protocols in safety-critical applications, see

the Safety Considerations Guide.
TriStation Communication
TriStation protocol enables communication between a TriStation PC and a Triconex controller.
A TriStation PC can be connected to a Triconex controller through an Ethernet port on the CM
Baseplate, or through a serial port on the MP Baseplate.
TriStation MSW (Multi-System Workstation) and TriStation 1131 Developer’s Workbench are
used to develop and monitor applications which run in a Triconex controller. The TriStation
1131 software is compliant with Part 3 of the IEC 61131 International Standard for
Programmable Controllers.

Overview 3
Client/Server Communication
TSAA protocol enables client/server communication between a Triconex controllers and a PC.
OPC Server and DDE Server use TSAA protocol to exchange data with Triconex controllers.
TSAA protocol can also be used to write custom programs for accessing Triconex points.
Triconex OPC Server

OPC Server is a client/server application, available from Triconex or Matrikon, which allows
OPC clients to read and write to Triconex program variables. OPC is a standard set of non-
proprietary interfaces used to develop client/server programs. For more information, see OPC
Server for Triconex (page 55).
Triconex DDE Server

DDE Server is a client/server application that allows DDE clients to read and write to Triconex
program variables. Using DDE Server, any Windows application that supports DDE protocol,
such as Microsoft Excel, can access Triconex variables. For more information, see DDE Server
for Triconex (page 45).
Peer-to-Peer Communication
Triconex Peer-to-Peer protocol allows multiple Triconex controllers in a closed network to
exchange safety-critical data. The controllers exchange data by using Send and Receive function
blocks in their TriStation applications. The controllers can synchronize their time with the
master node (the one with the lowest node number) or with an external device, such as a DCS.
Modbus Communication
Modbus is an industry-standard master/slave protocol that is traditionally used for energy
management, transfer line control, pipeline monitoring, and other industrial processes. A
Trident controller can operate as a Modbus master, slave, or both. A DCS typically acts as the
master while the Triconex controller acts as a slave. The master can also be an operator
workstation or other device that is programmed to support Modbus devices.
The Trident controller includes serial ports on the CM and MP that enable communication with
Modbus devices. Each CM and MP port can operate in a point-to-point configuration with a
single Modbus device. In addition, each CM port can operate in a multi-point configuration
with several Modbus devices connected to a serial link.
Triconex Time Synchronization

The Time Synchronization protocol allows networks of Triconex controllers to be synchronized
with each other, and optionally, with external devices.
Triconex controllers on a network are typically synchronized with the master node (the
controller with the lowest node number). If desired, the master node can accept time
adjustments from an external device, such as the Foxboro DCS or an OPC client, so that the

4 Chapter 1 Introduction
external device time prevails for all Triconex controllers on the network. Triconex Time
Synchronization can be used with external devices that use TSAA or Modbus protocol.
If networked controllers are collecting event data for system maintenance and shutdown
analysis, Triconex Time Synchronization must be used to ensure accurate time-stamping of
events.
Network Printing
A Trident controller can send brief ASCII text messages to a printer by means of a print server
connected to an Ethernet port on the CM. These messages are typically used for alarms, status
and maintenance. The printing devices you can use with a Trident controller include an HP
JetDirect-compatible print server, a printer, and a router or hub.
Module Capabilities and Usage

This table lists the types of communication that can be done using ports on the MP and CM.
Type of Connection MPs Only One CM Two CMs

Trident as Modbus Slave 3 serial ports 3 serial ports 6 serial ports
Trident as Modbus Master not available 3 serial ports 6 serial ports
Trident as Combination Modbus not available 3 serial ports 6 serial ports
Master/Slave
TriStation Communication using DLC 3 TriStation not available not available
Protocol ports
TriStation Communication using not available 1 Ethernet port 2 Ethernet ports
TCP/IP Protocol
TSAA Client/Server Communication not available 1 Ethernet port 2 Ethernet ports
Peer-to-Peer Communication (for one not available 1 Peer-to-Peer 2 Peer-to-Peer
network of Triconex controllers only) port ports
HP JetDirect Printing not available 1 Ethernet port 2 Ethernet ports
Ethernet Port Connections

On each Trident CM, one Ethernet port (Net1 or Net2) can be configured for communication
with multiple devices on a network, such as a TriStation PC, a print server, and a client
workstation. The other Ethernet port on a CM must be configured for Peer-to-Peer
communication or left unconfigured. For more information, see Configuring Ethernet Ports in
TriStation (page 36).

2
Communication Hardware
Overview 6
Triconex Communication Cables 7
Redundant Devices 8
Print Servers and Printers 11

6 Chapter 2 Communication Hardware
Overview
This chapter describes Triconex products and other devices that must be purchased to enable a
Triconex controller for communication. Typical configurations include redundant modules,
cables, and workstations, but can include other devices.
Triconex supplies communication cables, but does not supply PCs, hubs, MAU devices, print
servers, or printers. You must purchase these devices from manufacturers such as Black Box
Network Services and Hewlett-Packard.
If the system requires a hub, it should operate at 10 or 100 megabits per second, or be auto-
negotiable for either speed. Most hubs do not require configuration and do not have IP
addresses. If you are using a managed hub, follow the manufacturer’s instructions for
installation and configuration.
In hazardous indoor locations, apparatus used with Triconex

WARNING communication modules must be FM certified for Class I, Division II.
If you need assistance with selecting communication hardware, please contact your Network
Administrator or Information Technology department.

Triconex Communication Cables 7
Triconex Communication Cables

This table lists the communication cables available from Triconex for use with Trident
controllers. The standard length for the cross-over cables and straight-through cables is 20 feet,
but you can also order lengths of 1, 3, 6, and 10 feet. The standard length of the RS-232 cable is
15 feet, but you can order other lengths if necessary up to a maximum of 50 feet.
Cable Type Use Part Number

Cross-over Cable MP TriStation port to TriStation PC 1600044-020
• 10BaseT CM Ethernet port to TriStation PC
Ethernet port to Ethernet external device1
• 100BaseTX Peer-to-Peer port to Peer-to-Peer port
Straight-through Cable: MP TriStation port to hub 1600045-020
• 10BaseT Ethernet port to hub
Peer-to-Peer port to hub
• 100BaseTX
DB-9-pin to DB-25-pin adapter Serial port to Modbus master or slave devices 1420102-001
RS-232 cable 4000090-0xx
1. Typical Ethernet devices are print servers and PCs used for SOE, OPC Server, or DDE Server.

Redundant Devices
To ensure continuous operation of a Triconex system if a hardware failure occurs, you can create
a redundant configuration. Redundant devices can include modules, workstations, cables,
hubs, media converters, printers, and power sources.
A redundant device operates in parallel with a primary device so that, if the primary device
fails, the redundant device is easily or automatically placed into service. A typical configuration
includes two CM modules with redundant cables connected to one port on each module. The
redundant modules protect against internal faults, and the redundant cables protect against
cable breakage. To protect against network failures, you can connect a primary workstation to
one network and a redundant workstation to another network, as shown in this figure.
Redundant OPC Server

NOTE: For Tricon, you must use
NET2 ports for Ethernet
connections. For Trident, you can
use NET1 or NET2 ports.
Trident Controller
CM
To CM
NET2
Ports
To NCM To NCM
NET2 NET2
Ports Ports
NN
NET 2 NN
NET 2
M M M CC M M M CC
P P P MM P P P MM
A B C 1 2 A B C 1 2
Tricon Controller MP Tricon Controller
Primary Ethernet Network To DCS
TriStation PC SOE PC Primary OPC Server

Redundant Devices 9
PC Redundancy for TriStation and SOE Recorder

For TriStation and SOE Recorder, you can maintain redundant PCs and place them into service
manually if the primary workstations fail. An efficient practice is to install the necessary
programs on the PCs in advance. For TriStation, you should install the TriStation 1131 software
and store a backup copy of the project on the redundant workstation. For SOE, you should
install and configure the SOE Recorder software on the redundant workstation.
Testing for Hardware Failures

A redundancy scheme is effective only if the primary and redundant devices are connected and
operational. Routing the redundant cables over different paths through the facility reduces the
possibility of cable damage. To test for hardware failures, you must use port status attributes in
the TriStation application.
These Triconex communication products provide another layer of redundancy testing:
• The Peer-to-Peer and Time Synchronization protocols transmit messages over both the
primary and redundant networks at all times, discarding duplicate messages when
both networks are operational.
• The OPC Server and DDE Server programs communicate with the Triconex controller
over the primary network and switch to the redundant network if the primary device
fails.
If you are using Modbus protocol or a customized TSAA application, you must develop the
additional layer of redundancy testing on your own.

Media Conversion Devices

Media conversion devices are used to convert CM ports to other Ethernet media types or to
extend network distances. You can use either a hub with a media converter or a Media Adapter
Unit (MAU). Triconex does not sell hubs or MAUs, so you must buy them from another
manufacturer such as Black Box Network Services.
Media Adapter Units (MAUs)

The CM provides four MAU connectors that can be used instead of the RJ-45 connectors on the
Net1 and Net2 ports. You can buy MAUs that allow the CM to support the following media
types and distances.
Net1 MAU Connectors

• AUI 10Base-FL multi-mode fiber—1.24 miles (2 kilometers)
• AUI 10Base2 ThinNet 50-ohm coax—606.8 feet (185 meters)—allows Peer-to-Peer
connection with Tricon version 9 controllers
Net2 MAU Connectors

When a MAU is installed and configured in the TriStation project, the corresponding RJ-45
connector is disabled.
For more information, see Chapter A, Communication Module Capabilities
• MII 10BaseFX to 100BaseFX single-mode fiber—8.68 feet to 12.4 miles (14 to 20
kilometers)
• MII 1BaseFX to 100BaseFX multi-mode fiber—1.24 miles (2 kilometers)

Print Servers and Printers 11
Print Servers and Printers

The Trident controller supports JetDirect-compatible print servers that must be connected to
Centronics-compatible printers. The print server must be specified for the JetDirect print
protocol and speeds of 10 or 100 megabits per second.
Triconex has tested and can recommend the following Hewlett-Packard print servers:
• HP JetDirect Ex Plus
• HP JetDirect 500X Series, model J3265A
This figure depicts a typical configuration that includes a print server.
HP JetDirect-Compatible
Print Server Trident Controller
Centronics-Compatible
Printer
Ethernet CM
Standard
Hub
Printer Cable
Ethernet Cable
Ethernet Cable
MP
Other Network
Connections


3
TriStation Communication
Overview 14
Communication Accessories 15
MP Connection to a TriStation PC 16
CM Connection to a TriStation PC 22
TriStation Software Installation 29
Tagnames and Aliases 31
Write Access by External Devices 32

14 Chapter 3 TriStation Communication
Overview
This chapter describes the tasks required to connect a PC used for TriStation to a Trident
controller. TriStation must be used to program and operate the controller, and to establish its
address on an Ethernet network. TriStation can also be used for diagnostic monitoring of
downloaded projects that are running in Trident controllers on a network.
The initial task is to set up a PC with the required hardware and communication protocols. This
includes installing a network adapter card and the DLC or TCP/IP protocol. If you plan to
connect the TriStation PC to an MP port on the Trident controller, the DLC protocol must be
installed on the PC. If you plan to connect the TriStation PC to a CM port, the TCP/IP protocol
must be installed on the PC.
The next task is to install the TriStation 1131 software on a PC using the setup program provided
by Triconex. Then you can physically connect the TriStation PC to an MP or CM port on the
Trident controller. You can connect the PC directly to one of these ports, or to an Ethernet hub
that is connected to one of the ports.
Your communication cable must be rated for 10 or 100 megabits per second. Hubs can be auto-
negotiable for either speed. You can buy communication cables from Triconex or from other
manufacturers. You must buy hubs from other manufacturers.
Another essential task of the physical connection is to set the node address of the Trident
controller using a Triconex-supplied address plug. The physical address must match the logical
address that you set in the TriStation configuration.
After the physical connection tasks are completed, you must logically configure the connection
in the TriStation project. After completing the physical and logical connection tasks, you can
download, run and monitor the TriStation application.
The sections in this chapter include detailed instructions for all of these tasks.

Communication Accessories 15
Communication Accessories
The TriStation PC can be directly connected to an MP or CM port on the Trident controller, or
to an Ethernet hub that is connected to one of these ports. These accessories are available from
Triconex.
In hazardous indoor locations, apparatus used with Triconex

WARNING communication modules must be FM certified for Class I, Division II.
Accessory Part/Model Description

Cross-Over Cable (10BaseT or 1600044-020 MP and CM Ethernet direct connection to
100BaseTX) TriStation PC.
Straight-Through Cable (10BaseT 1600045-020 MP and CM Ethernet connection to TriStation
or 100BaseTX) PC through a network hub.
25-pin to 9-pin adapter 1420102-001 Needed for EICM connection if PC has a DB-9-
pin connector
Network Hardware Accessory 7600-3 Used for ACM and NCM Ethernet connections.
Kit (10Base2) Includes NIC card, 10Base2 cable, BNC T-
connectors, and terminators.
A suitable hub should operate at 10 or 100 megabits per second, or be auto-negotiable for either
speed. Most hubs do not require configuration and do not have IP addresses. If you are using a
managed hub, follow the manufacturer’s instructions for installation and configuration. You
must purchase hubs elsewhere because Triconex does not supply them. Examples of
dependable manufacturers are Black Box Network Services and Hewlett-Packard.

MP Connection to a TriStation PC
This section explains how to connect a TriStation PC to a Trident MP port. This can be a direct
connection from the MP to the PC, or a connection through a hub on a network.
To set up the connection you must install a network interface card and DLC protocol on the PC,
set the node number of the controller, connect the PC to an Ethernet port on the MP Baseplate,
and configure the connection in the TriStation project.
Topics include:
• Installing a Network Interface Card in a TriStation PC (page 17)
• Installing DLC Protocol on a TriStation PC (page 17)
• Directly Connecting a Trident MP to a TriStation PC (page 18)
• Connecting a Trident MP to a TriStation PC Using a Hub (page 19)
• Setting the Trident Node Number with an Address Plug (page 20)
• Configuring an MP Connection to a TriStation PC (page 21)

Installing a Network Interface Card in a TriStation PC

This procedure explains how to install a network interface card in a TriStation PC that is to be
connected to a Trident MP port.
Procedure
1 Install the network adapter card by following the manufacturer’s instructions. Do not
change the factory default settings on the network interface card.
2 Connect the network interface card directly to an MP port on the Trident controller or to
an Ethernet hub.
3 Run the diagnostics provided with the network interface card according to the
manufacturer’s instructions.
Installing DLC Protocol on a TriStation PC

These procedures explain how to install DLC protocol on a TriStation PC to be connected to a
Trident MP.
Procedure (Windows NT)

1 On the Start menu, click Settings, then click Control Panel.
2 On the Control Panel screen, double-click the Network icon.
3 On the Network screen, click the Protocols tab.
If DLC is listed under Network Protocols, this means the protocol is already installed
and you are finished with this procedure.
4 For Network Protocols, double-click Add.
5 On the Select Network Protocols screen, click DLC Protocol.
6 If you want to copy files from a specific location, such as a network drive, click OK.
7 If the required files are on a disk, insert the disk, and click Have Disk.
Procedure (Windows 2000)

1 On the Start menu, click Settings, then click Network and Dial-up Connections.
2 Right-click the network connection where you want to install DLC, then click Properties.
3 On the Networking tab, if DLC is checked on the list of installed components, this means
the protocol is already installed and you are finished with this procedure.
4 To install the DLC protocol, click Install, click Protocol, and then click Add.
5 On the Select Network Protocol screen, click DLC, and then click OK.
6 Verify the DLC check box is checked, and then click OK.

Directly Connecting a Trident MP to a TriStation PC

This procedure explains how to directly connect a TriStation PC to an Ethernet port on a Trident
MP Baseplate using a 10BaseTcross-over cable.
Procedure
1 Attach one end of the cross-over cable to one of the RJ-45 connectors on the MP
Baseplate. This is typically MP A, as shown in the figure.
2 Attach the other end of the cross-over cable to the network interface card in the PC.
Trident Controller
CM
TriStation PC Network Adapter

Card
Cross-over
Cable
RJ-45 MP
Connector
(MP A)

Connecting a Trident MP to a TriStation PC Using a Hub

This procedure explains how to connect a Trident MP to a TriStation PC using a 10BaseT
straight-through cable and a hub.
Procedure
1 Attach at least one 10BaseT straight-through cable from an RJ-45 connector on an MP
Baseplate to the hub.
Using more than one cable provides redundancy for the TriStation connection. If you
use only one cable during live operation, you have to unplug it and move it to another
RJ-45 connector if the original connection fails.
2 Attach the network interface card in the TriStation PC to the hub using another 10BaseT
straight-through cable.
Trident Controller
CM
To Ethernet
Network

Card
Straight-through RJ-45
Cable Connectors
MP
Hub
Channel A
Channel B
Channel C
Straight-through Cables

Setting the Trident Node Number with an Address Plug

This procedure explains how to set the node number of a Trident controller by installing an
address plug on the MP Baseplate.
The node number uniquely identifies a controller on a network. The node number must be
physically set on the MP Baseplate during installation, and it must match the node number that
is specified in the TriStation project.
Procedure
1 In the lower-left corner of the MP Baseplate, attach a Triconex-supplied address plug
which has the correct number.
To complete the setting, the node must be configured in the TriStation project.

Configuring an MP Connection to a TriStation PC

This procedure explains how to configure a logical connection between a Trident MP and a
TriStation PC. For detail procedures, see the Developer’s Guide for the version of TriStation
being used.
Procedure
1 In TriStation v4, go to the TriStation Communication screen; in TriStation v3, go to the
Communications tab on Project Options.
2 Specify these properties to match the physical connection.
Property Action
Main Processor Check the Main Processor Connection check box. (In v3.0, select Main
Connection Processor as the Default Connection.)
Node Number Enter the number specified by the address plug on the MP Baseplate.
Node Name Enter a name with eight or fewer characters to identify the Tricon
controller.
Main Processor Click Left, Middle, or Right to specify which MP port is connected to
Setup (Port) the TriStation PC.
NIC Index Enter the index position of the network interface card in the TriStation
(Network Adapter) PC.
3 Open the MP Setup screen and click the Network Ports tab.
4 For the port that is physically connected to TriStation PC, specify the Transceiver Mode
to match the hardware installed.
5 Click OK to save.

CM Connection to a TriStation PC
This section explains how to connect a TriStation PC to a Trident CM port. To do so, you must
install a network interface card and TCP/IP protocol on the PC, set the node number of the
controller, connect the PC to an Ethernet port on the CM, and configure the connection in the
TriStation 1131 project.
Topics include:
• Installing an NIC Card in a TriStation PC (page 23)
• Installing TCP/IP Protocol on a TriStation PC (page 23)
• Directly Connecting a Trident CM to a TriStation 1131 PC (page 24)
• Connecting a Trident CM to a TriStation PC Using a Hub (page 25)
• Setting the Trident Node Number with an Address Plug (page 26)
• Configuring a Trident CM Connection (page 27)

Installing an NIC Card in a TriStation PC

This procedure explains how to install a network interface card in a TriStation 1131 PC that is to
be connected to a Trident CM port.
Procedure
1 Install the network interface card by following the manufacturer’s instructions. Do not
change the factory default settings on the network interface card.
2 Connect the network interface card directly to a CM port on the Trident controller or to
an Ethernet hub.
3 Run the diagnostics provided with the network interface card according to the
manufacturer’s instructions.
Installing TCP/IP Protocol on a TriStation PC

These procedures explain how to install TCP/IP protocol on a TriStation PC.
Procedure (Windows NT)

1 On the Start menu, click Settings, then click Control Panel.
2 In the Control Panel window, double-click the Network icon.
3 In the Network dialog box, click the Protocols tab.
If TCP/IP is listed in Network Protocols, it means the protocol is installed and you are
finished with this procedure.
4 For Network Protocols, double-click Add.
5 On the Select Network Protocols screen, click TCP/IP Protocol from the list.
6 If you want Windows NT to copy files from a specified location, such as a network drive,
click OK.
7 If the files are on a disk, insert the disk and click Have Disk.
Procedure (Windows 2000)

1 On the Start menu, click Settings, then click Network and Dial-up Connections.
2 Right-click the network connection where you want to install TCP/IP, then click
Properties.
3 On the Networking tab, if DLC is checked on the list of installed components, it means
the protocol is installed and you are finished with this procedure.
4 Click Install, click Protocol, then click Add.
5 On the Select Network Protocol screen, click Internet Protocol (TCP/IP) on the Network
Protocol list, and then click OK.
6 Verify the Internet Protocol (TCP/IP) check box is checked, and then click OK.

Directly Connecting a Trident CM to a TriStation 1131 PC

This procedure explains how to directly connect a Trident CM to a TriStation 1131 PC using a
cross-over cable.
For a Net1 port, you must use a 10BaseT cable. For a Net2 port, you can use either a 10BaseT or
100BaseTX cable. On the CM Baseplate, you can attach the cable to an RJ-45 connector or to a
MAU connector.
Procedure
1 Attach one end of a cross-over cable to a Net1 or Net2 connector on the CM baseplate,
as shown in this figure.
Trident Controller
TriStation PC Network Adapter CM

Card
Cross-over
Cable
RJ-45
Connectors
MP
2 Attach the other end of the cross-over cable to the network interface card in the
TriStation PC.

Connecting a Trident CM to a TriStation PC Using a Hub

This procedure explains how to connect a Trident CM to a TriStation PC using a straight-
through cable and a hub.
For a Net1 port, you must use a 10BaseT cable. For a Net2 port, you can use either a 10BaseT or
100BaseTX cable. On the CM Baseplate, you can attach the cable to an RJ-45 connector or to a
MAU connection.
Procedure
1 Attach one end of a straight-through cable to a Net1 or Net2 connector on the CM
Baseplate.
2 Attach the other end of the straight-through cable to an Ethernet hub, as shown in this
figure.
3 Connect the TriStation PC to the hub using another straight-through cable.
To Ethernet
Network Trident Controller
CM

Card
Straight-through
Straight-through
Cable
Cable
RJ-45
Connectors
Hub
MP

Setting the Trident Node Number with an Address Plug

This procedure explains how to set the node number of a Trident controller by installing an
address plug on the MP Baseplate.
The node number uniquely identifies a controller on a network. The node number must be
physically set on the MP Baseplate during installation, and it must match the node number that
is specified in the TriStation project.
Procedure
1 In the lower-left corner of the MP Baseplate, attach a Triconex-supplied address plug
which has the correct number.
To complete the setting, the node must be configured in the TriStation project.

Configuring a Trident CM Connection

This procedure explains how to configure a logical connection between a Trident CM and
TriStation PC. For detail procedures, see the Developer’s Guide for the version of TriStation
being used.
Before Starting
Before starting this procedure, you must determine the IP address to use for the CM. If the
connection goes through a gateway or a router, you also need IP addresses for those devices.
Typically, you can get the necessary IP addresses from your Network Administrator or
Information Technology department.
Procedure
1 In TriStation go to the TriStation Communication or Communications screen and specify
these properties to match the physical connection.
Property Action
Network Connection Check the Network Connection check box.
Node Number Enter the number that you set with rotary switches on the ACM or
NCM.
Node Name Enter a name that contains eight or fewer characters to identify the
Tricon controller.
IP Address Enter the IP address.
NIC Index ( Enter the index position of the network interface card in the
TriStation PC.
2 Go to the CM Setup (Configuration) screen and click the Network tab.

3 Specify these properties for the Net1 or Net2 port, depending on which is connected to
the TriStation PC.
Property Action
Slot Selection Click Left Slot or Right Slot, depending on which slot contains the
module that is connected to the TriStation PC.
Mode For the TriStation connection, select Open Network from the list.
For each CM on a baseplate, you can select Open Network for either Net1
or Net2, but not for both of these ports.
Privilege Click Read or Read/Write to specify access privileges for external
devices on the network.
A TriStation application must use the Privilege option in conjunction
with the MP.REMOTE_WRT_ENBL control attribute (and possibly other
write controls) to enable writes by external devices.
Transceiver Port Click RJ-45 or MAU depending on the type of CM Baseplate port to
which you have physically attached the TriStation cable.

Property Action
Transceiver Select the Auto mode if the TriStation cable can auto-negotiate to either
Mode 10 or 100 megabits per second.
If your cable operates at only one speed, select the appropriate speed
from the list.
IP Address If using the default node number, do not change this property (leave
blank).
If using a different node number, enter the IP address that identifies the
controller on the network. This must be the same address you enter in
step 2.
IP Subnet Mask Get the subnet mask from your Network Administrator.
Default Gateway If the CM connection to the TriStation PC goes through a default
IP Address gateway, enter the IP address of the gateway.
Time Click None. This property does not apply to TriStation communication.
Synchronization

TriStation Software Installation 29
TriStation Software Installation

This section explains how to install and uninstall the TriStation 1131 software, and to verify that
the software is correctly installed. The installation automatically installs the TS1131 Install
Check software. In TriStation v4, the installation also installs the Triconex Diagnostic Monitor.
Topics include:
• Installing the TriStation 1131 Software (page 29)
• Uninstalling the TriStation 1131 Software (page 30)
• Verifying the TriStation 1131 Installation (page 30)
Installing the TriStation 1131 Software

This procedure explains how to install the TriStation 1131 software. The setup program
provided by Triconex installs all the components of the TriStation 1131 Developer’s Workbench
on your PC. If you purchased the optional CEMPLE software, it is installed at the same time.
Before Starting
If you have previously installed the TriStation 1131 software on your PC, you must uninstall it
before installing a new version of the software.
Procedure
1 Log on as an administrator or as a user with administrator privileges.
2 Close all open applications.
3 Insert the TriStation 1131 CD in the CD-ROM drive.
If the installation starts automatically, go to Step 6. Otherwise, go to the next step.
4 From the Start menu, click Settings, and then click Control Panel.
5 Double-click Add/Remove Programs.
6 On the Install/Uninstall tab of the Add/Remove Programs Properties dialog box, click
Install.
7 Follow the InstallShield Wizard instructions.
Triconex recommends installing the TriStation 1131 software in the default destination
folder, which is: C:\Program Files\Triconex\TriStation 1131 4.0\Programs.
8 To restart your PC after the installation has finished, click Yes. You must restart your PC
before running the TriStation 1131 software.
9 To complete the installation, click Finish.

Uninstalling the TriStation 1131 Software

This procedure explains how to uninstall the TriStation 1131 software. If you have installed a
previous version of the software, you must uninstall it before installing the new version.
Procedure
1 Log on as an administrator or as a user with administrator privileges.
2 From the Start menu, click Settings, and then click Control Panel.
3 Double-click Add/Remove Programs, and select TriStation 1131.
4 Click Change/Remove.
The Confirm File Deletion dialog box asks you to confirm the deletion of the selected
application and all its components.
5 Click Yes to remove the previous version of TriStation 1131.
Note If you saved projects in the default directory, (C:\Program
Files\Triconex\TriStation 1131 4.0\Programs), the uninstall program
does not remove them.
6 Click Yes or Yes to All if the Remove Shared File dialog box asks about removing unused
DLLs.
7 When the Uninstall Successfully Completed message appears, click OK.
You can now install a new version of the TriStation 1131 software.
Verifying the TriStation 1131 Installation

This procedure explains how to verify the TriStation 1131 software is correctly installed and that
associated files are not corrupted. After installing the software and before downloading an
application to the controller, you should run the TriStation 1131 Install Check program. The
Install Check software is copied to your hard drive when you install the TriStation 1131
software.
Note Running TS1131 Install Check is required for safety applications.
For more information, see the Safety Considerations Guide.
Procedure
1 From the Start menu, select Programs, Triconex, and then Install Check.
2 Click Run.
3 Click Display Details and verify that the program is validated by viewing each item in
the list.

Tagnames and Aliases

This section describes tagnames, which is the word commonly used when referring to input
points (sensors) and output points (final elements). In TriStation 1131, tagnames are references
to physical tagnames (labels) on the connected field devices or to memory points which are
locations in the controller memory. In IEC terminology, tagnames are called global variables.
For Modbus or DDE communication, tagnames must be assigned an alias number that allows
read or read/write access. An alias number is a five-digit identifier which defines the data type
and location of a point in the controller memory.
For Peer-to-Peer, OPC, or a TSAA applications, tagnames can be accessed by the tagname.
For more information about tagnames and aliases, see the TriStation Developer’s Guide.
Access by Access by
Protocol or Application
Tagname Alias
Modbus Master 3
Modbus Slave 3
Trident or Tricon Peer (in a Peer-to-Peer network) 3
OPC Server 3 3
DDE Server 3
User-Written TSAA Application 3 3

Write Access by External Devices

Write access for external devices can be allowed or restricted for memory and output points by
using system properties, communication properties, and function blocks in a TriStation
application. External devices cannot write to input points but can read input, memory, and
output points if allowed. For procedures on allowing and restricting access, see the TriStation
Developer’s Guide.
These types of read and write access are possible:
• Input, output, and memory points can be read by any external device that can
communicate with a Trident controller.
• Write access to input points is not allowed from any external device.
• Write access to a output or memory point is allowed or restricted based on the system,
communication, application, and point settings.
This table describes write access to Trident points from external devices.
Trident Write Access

Property or Feature Description
Disable Remote Changes to A system setting on the MP Operating tab that determines write
Outputs access to output points.
When checked, external devices cannot write to output points,
no matter what other settings are made.
SYS_SET_REMOTE_WRT_ENBL A Trident function block that programmatically allows or
restricts write access to output or memory read/write aliased
points when used in an application.
To allow write access, the Disable Remote Changes to Outputs
property cannot be checked.
Privilege A Trident CM module setting that determines whether network
devices using DDE, OPC, or TSAA communication have write
access to output points and read/write aliased memory points.
For Trident CM, the default is Read/Write.
This setting does not affect Modbus access.
Point Assignment A tagname setting that determines whether the output and
memory point is assigned a Read or Read/Write alias number.
For output points, all alias numbers are Read/Write.
For memory points, alias numbers can be Read or
Read/Write.

4
Client/Server Communication
Overview 34
Configuring Ethernet Ports in TriStation 36
DDE Server for Triconex 45
OPC Server for Triconex 55
Other OPC Products 59

34 Chapter 4 Client/Server Communication
Overview
Client/server communication with Triconex controllers can be done by using the DDE Server
and OPC Server applications, which use the Triconex System Access Application (TSAA)
protocol. For most process control networks, using DDE Server or OPC Server is the best
solution.
TSAA protocol can also be used to write custom applications for accessing Triconex data, such
as these:
• Control (read/write) applications for operators that need read access to Triconex status
and write access to Triconex data.
• Monitor (read-only) applications such as a sequential events recorder or a status
display that collects and records Triconex data.
For detailed protocol information, see Appendix C, TSAA Protocol.
Trident Controller Tricon Controller Trident Controller
CM CM
NET2
NET1
NET2
(NCM) NN
M M M CC
P P P MM
A B C 1 2
MP MP
Ethernet Network
To DCS
TriStation PC SOE PC DDE or OPC Server
Figure 1 Sample Trident System Configuration
Applications that use TSAA to exchange information with a Triconex controller require a
Trident CM. You can install a maximum of two CM modules in a controller. You can physically
connect one Ethernet port on each CM to an Ethernet network. Through one Ethernet port, the
controller can communicate with multiple devices on a network, such as a TriStation PC, a print
server, and a client PC.
Ethernet ports on the Trident CM are called Net1 and Net2. The Net2 ports can operate at 10 or
100 megabits per second; the Net1 ports can operate at 10 megabits only. The data transmission
rate of the device or network you connect determines which port and cabling you must use.

Overview 35
Most Ethernet devices and networks operate at 100 megabits per second, so connecting one to
a Trident controller usually means you must use Fast Ethernet (100BaseTX) cabling.
Each Ethernet port must be configured in the TriStation project, which means you must specify
the mode, access privilege, port type and speed, IP address, and time synchronization
properties. Part of physically connecting a CM port to a network is to set the IP address of the
port. The most convenient methods are to use the Triconex default address or a Reverse ARP
server. Other ways are discussed in this chapter.
A Trident controller on an Ethernet network can communicate with devices on other networks
if you specify the IP address of the default gateway or other routes in the TriStation project.
Specifying the default gateway is often sufficient, but you can specify multiple other routes if
necessary.
Another task is to specify whether external devices are to have access to the application running
on the Triconex controller. There are many levels of access including allowing general write
access while protecting specific points from write access through configuration settings. For
more information, see Trident Write Access (page 99).

Configuring Ethernet Ports in TriStation

This section explains how to specify the logical configuration of Ethernet ports in TriStation
MSW and 1131. Procedures for setting the IP address are also included.
For an Ethernet connection on an open network, the CM must be used. An open network is an
Ethernet network to which Triconex controllers and many types of Ethernet devices can be
connected, including routers and gateways to other networks.
A closed network is designed for maximum safety and includes only Triconex devices. To
configure a closed network port, see Chapter 5, Peer-to-Peer Communication.
This section includes:
• Configuring a CM Ethernet Port (page 36)
• Setting the IP Address (page 38)
Configuring a CM Ethernet Port

This procedure describes how to specify the logical configuration for a CM Ethernet port. For
detailed instructions, see the TriStation Developer’s Guide.
To configure a network port on the CM for the Peer-to-Peer communication mode, see
Chapter 5, Peer-to-Peer Communication.
Procedure
1 Open the TriStation project and go to the CM Setup (Configuration) screen.
2 Specify these properties as required by the project and installation.
Privilege
This property determines whether external devices connected to Open Network ports have
Read or Read/Write access to Trident points.
• If set to Read, external devices cannot write to any tagnames no matter what other
write access controls are used. This setting protects safety-critical tagnames from writes
by external devices on an open network.
• If set to Read/Write, external devices can write to tagnames depending on the settings
of other write access controls.
Read is the default setting.
The Privilege option must be used in conjunction with other write access controls. For more
information, see Trident Write Access (page 99).
Transceiver Port
Use the default called RJ-45 if you have attached the communication cable to an RJ-45 connector
on the CM Baseplate.

Select the MAU option if you have attached an MII MAU to a 40-pin subminiature D connector
or an AUI MAU to a DB-15 connector on the CM Baseplate. You might have to set the physical
address of a MAU before attaching it to a CM port. You must purchase MAUs from a third-party
manufacturer. For more information, see Chapter A, Communication Module Capabilities.
Transceiver Mode
Under Transceiver Mode, select Auto mode for the physical connection to TriStation if the cable
can auto-negotiate to either 10 or 100 megabits per second.
If the cable operates at only one speed, select the appropriate speed from the list under
Transceiver Mode.
TCP/IP Address
Enter the IP address of the controller on a network. If the network configuration permits, use a
Triconex default address. If not, get an address from your Network Administrator or
Information Technology department. For more information, see Setting the IP Address
(page 38).
TCP/IP Subnet Mask

Enter the subnet mask to indicate whether a default gateway is connected to the local network
or to a remote network.
Default Gateway Address

If applicable, enter the IP address of the Default Gateway to which the Trident controller is
connected. Get this address from your Network Administrator or Information Technology
department. For more information, see Specifying the Default Gateway (page 43).
Time Synchronization
This property specifies whether to use time synchronization in the network.
These options are available:
• On Net1: Synchronizes the time with the master node on the network that is connected
to Net1.
to Net2.
• None: Time synchronization is not performed by a Trident controller, but can be
performed by an external device (such as an OPC client).
For more information, see Time Synchronization (page 101).

Setting the IP Address

To enable a Triconex controller for communication with network devices, you must set the IP
addresses of CM modules on the network. If the network configuration permits the use of
Triconex default IP addresses, the addresses are set on the network when you download the
TriStation application, assuming that the correct node number and default IP addresses have
been specified in the configuration.
If you cannot use default IP addresses, there are other ways to set the IP addresses of CM
modules on a network. These methods involve asking your Network Administrator for the
intended IP addresses. The easiest way is to use a Reverse ARP (RARP) server on the subnet that
has been configured in advance with the intended addresses. Other ways entail connecting the
TriStation PC to an MP or CM port, specifying IP addresses in the TriStation project,
downloading the TriStation application, then reconfiguring the physical connection or the
project.
All of the procedures for setting the IP address are based on the assumption that the controller
includes at least one CM module with an Ethernet port connected to a network.
To use the procedures, you should know how to:
• Connect the Triconex controller to a network
• Connect the TriStation PC to the controller
• Configure the TriStation project with the node number of the controller and the IP
address
For more information, see Chapter 3, TriStation Communication.
Note Typically, Triconex controllers are located on their own subnet which is connected to a
larger network such as a DCS. Your Network Administrator can set up the subnet for
compatibility with the Triconex default IP addresses and can program any routers that
lie between the DCS and the Triconex subnet with addressing information about the
Triconex controllers.
Using the Default IP Address

This procedure explains how to use the default IP address for network communication between
a controller and a TriStation PC.
Procedure
1 Connect the controller to the network by using an Ethernet port on the CM.
2 Power up the controller.
3 Connect the TriStation PC to the network, or directly to an Ethernet port on the CM.
4 Verify the node number in the TriStation project is configured set to this IP address:
• 192.168.1.1 (Trident CM Net1)
• 192.168.2.2 (Trident CM Net2)
If the controller includes two communication modules, the default address applies to
both modules.

Note The Left CM and Right CM use the same 48-bit physical MAC address and
cannot be connected to the same network.
5 In the TriStation project, open a connection between the TriStation PC and the controller.
6 Wait about 40 seconds for the module to reset and become active.
When the module is active, its Active indicator is green.
7 Download the TriStation application to the controller.
8 Verify the setting of the default IP address on the network by opening a DOS window
and entering the command “ping <IP address>.”
If the network connection is made, the reply includes the IP address followed by byte
and time information.
If the connection is not okay, the reply is “Request timed out.”
Setting an IP Address Using a RARP Server

This procedure explains how to set the IP address of a communication module using a RARP
server on the local network. To use this procedure, the Network Administrator must program
the RARP server with the intended IP address for the controller. If this is not possible, use
another method to set the IP address.
Procedure
1 Give the Network Administrator the MAC address, which is:
40-00-00-00-x-03 (where x is the Trident controller node number)
2 Ask the Network Administrator for the IP address that is to be used for the controller.
3 Connect the controller to the network through a network port on the communication
module. Power up the controller.
During initialization, the communication module sends a request to the RARP server for
an IP address that has been mapped to its own 48-bit MAC address.
Note The Left CM and Right CM use the same 48-bit physical MAC address and
cannot be connected to the same network.
4 Verify the setting of the intended IP address on the network by opening a DOS window
5 Connect the TriStation PC to the network, or directly to network port on the
communication module.
6 In the TriStation configuration, specify the node number of the controller and its
intended IP address, if you have not already done so.
7 Open a connection between the TriStation PC and the controller.
8 Download the TriStation application to the controller.

Setting an IP Address Using a Trident MP Connection

This procedure explains how to set the IP address of the Triconex controller by initially
connecting the TriStation PC to an MP port and downloading the TriStation application. After
the address is set, you can disconnect TriStation from the MP port and reconnect it to an
Ethernet port on the CM.
Procedure
1 Ask your Network Administrator for the IP address that is to be used for the controller.
2 Connect the TriStation PC to a TriStation port on the MP Baseplate.
3 Connect the controller to the network by means of an Ethernet port on the CM.
4 In the TriStation project, configure these:
• The MP and CM ports
• The node name and node number of the controller
• The intended IP address
6 In TriStation, connect to the controller and specify which communication port is to be
used.
7 Download the TriStation application.
The CM initializes (resets) and accepts the IP address you specified in the TriStation
project.
8 Verify the setting of the intended IP address on the network by opening a DOS window
9 If the IP address is set, you can disconnect the TriStation PC from the MP port and
connect it to an Ethernet port on the CM or to the network.
Setting an IP Address Using a Trident CM Connections

This procedure explains how to set the intended IP address of the Trident controller by
temporarily configuring a default IP address for the CM and assigning a default IP address to
the TriStation PC. After the intended IP address of the CM is set, the node definition and the IP
address of the TriStation PC must be reconfigured.
Procedure
1 Ask your Network Administrator for the IP address that is to be used for the Trident
controller.
2 Connect the controller to the network using an Ethernet port on the CM.

3 Connect the TriStation PC to an Ethernet port on the CM, using a direct or network
connection.
4 On the TriStation PC, use Windows procedures to set the IP address of the PC to either
of these:
• 192.168.1.x if the PC is physically connected to a Net1 port, where x is any unused
host number.
• 192.168.2.x if the PC is physically connected to a Net2 port, where x is any unused
host number.
5 Wait for the TriStation PC to reset.
6 Open the TriStation project. Specify the node name, node number, and the default IP
address of the controller.
7 Specify the intended IP address for the Ethernet port on the CM Setup (Configuration)
screen.
9 From TriStation, open a connection to the controller and specify the CM port that is to
be used for the connection. Verify that the default IP address is displayed.
10 Connect to the controller and download the TriStation project.
11 Wait for the download to complete.
After the download is complete, TriStation displays the message, “Connection failed.”
The default IP address you specified in the node definition is invalid, and the intended
IP address of the CM is set.
12 On the TriStation PC, use Windows procedures to set the IP address of the PC to its
actual address on the network.
13 Verify that the intended IP address of the CM has been set by opening a DOS window
14 In the TriStation project, change the default IP address to the newly set IP address.
15 In TriStation, connect to the controller.
16 After the IP address is set on the network, you must reconfigure the IP address in the
TriStation project and assign a valid IP address to the TriStation PC.

Message Routing
A Trident controller on a network can communicate with devices on other networks if you
specify the IP address of the default gateway or other gateways in the TriStation project. Before
starting these procedures, get the IP addresses you will need from your Network Administrator
or Information Technology department.
Sample Network Using Default Gateway

This figure depicts a sample network using a default gateway.
CM
Centronics
Printer
JetDirect 206.32.216.84
Print Server
192.168.1.101
206.32.216.100 MP
Default
192.168.1.100 Gateway Trident Controller
NOTE: 206.32.216.100 and

192.168.1.100 are the IP addresses
of ports on the Default Gateway.
Dialog boxes in a TriStation project

are used to specify the IP
addresses of the Default Gateway
and the print server. (For this
example, no addresses are
specified on the Routing tab.)

Specifying the Default Gateway

If a Trident controller needs to communicate with devices on another network, in many cases
the default gateway can be used for message routing.
Procedure
2 Click the Network tab and select Left Slot or Right Slot depending on which CM is being
configured.
3 For the Mode property, select Open Network for Net1 or Net2 (depending on which one
is connected to an Ethernet network).
4 For the Default Gateway Address property, enter the IP address of the default gateway
that is connected to the local subnet.
Specifying Other Network Routing

If a Trident controller does not have access to a default gateway, you can specify other network
routes in the TriStation project. Each route includes an IP address for a destination outside the
network, a subnet mask, and a gateway address.

Sample Network Using Routers

This figure depicts a sample network using routers.
CM
Centronics
Printer
206.32.216.64
Route 1
206.32.216.100
JetDirect
Print Server
192.168.1.101
MP
Trident Controller
Route 2
192.168.2.101
206.32.216.101
192.168.2.1
OPC Server
Dialog boxes in a TriStation

project are used to specify
routes to other networks
without depending on the
Default Gateway.
To specify a route that includes a network, subnet, and gateway:

2 Click the Routing tab and enter an IP address under Destination Address, Subnet Mask,
and Gateway Address for each route that need to specify.

DDE Server for Triconex

This guide explains how to use the Triconex DDE Server software to communicate between
Triconex controllers (Tricons or Tridents) and DDE clients on an Ethernet network. Triconex
DDE Server is a Windows application that enables DDE-compliant clients to request data and,
if allowed, to change data in a Triconex application. A client can request data about input and
output variables, memory variables, and system attributes. Triconex DDE Server is based on a
client/server model in which a client requests information from a server and a server sends
information to a client.
Client applications use DDE protocol to communicate with a DDE Server. Any Windows
application that supports DDE protocol—such as Microsoft Excel—can use Triconex DDE
Server. Triconex DDE Server communicates with one or more Triconex controllers through
TSAA (Triconex System Access Application) protocol. To return data to clients, the DDE Server
uses DDE protocol.
The DDE Server PC must be connected to an Ethernet port on a Triconex controller. For Tricon
controllers, the Network Communication Module (NCM) or Advanced Communication
Module (ACM) must be used. For Trident controllers, the Communication Module (CM) must
be used.
This figure depicts the communication protocols used with Triconex DDE Server.
DDE Client Triconex

Application Controller
TSAA
DDE Protocol
Protocol
Triconex TSAA Triconex

DDE Server Protocol Controller
DDE
Protocol TSAA
DDE Client Protocol
Application
Triconex
Controller
Specifications for Windows PC

This list specifies the minimum PC requirements for Triconex DDE Server.
• Microsoft Windows NT version 4.0 (Service Pack 5), or Windows 2000
• Pentium™ III (minimum)
• 128 MB RAM, minimum
• CD-ROM drive
• 125 MB free space on the hard drive
• Network interface card (also referred to as network adapter card)

Installing the Triconex DDE Server

The setup program provided by Triconex installs all the necessary components of the Triconex
DDE Server on a Windows 2000 or NT PC.
To install DDE Server, you must be logged on to Windows as an Administrator or you must
have the privileges of an Administrator.
Installing on Windows 2000

1 If a previous version is installed, uninstall it.
3 Go to the Windows2000 folder and double-click the setup.exe program.
4 Follow the installation instructions.
Installing on Windows NT
1 If a previous version is installed, uninstall it.
3 Go to the WindowsNT folder and double-click the setup.exe program.
4 Follow the installation instructions.
• If the installation is successful, a message advises you to click Finish. You are
finished with the installation procedure.
• If the installation requires Factory Suite 2000 components, a message is displayed
and the DDE Server setup is closed. Continue to step 5 in this procedure.
5 Go to the FS2000 folder (under the WindowsNT folder) and double-click SETUP.bat.
You may see a warning about the Windows service pack installed on your PC. Click OK
to continue installing the Factory Suite 2000 components.
6 Follow the installation instructions. You may also be asked if you want to install Adobe
Acrobat 3.0, which is an older version of the product. Click Cancel to not install this
version, and then click OK.
7 Go to the WindowsNT folder and double-click the setup.exe program to restart the DDE
Server installation.
8 Click Finish to complete the installation. You may be required to reboot your PC.
Configuring the DDE Server Application

When you configure the DDE Server application, you specify communication properties used
by a Triconex controller (also called a host or node) to communicate with DDE clients. These
properties allow DDE clients to identify which controller to communicate with and what
communication protocol to use.
If you plan to use a redundant DDE network, you need to use DDE Server PCs and install
redundant communication modules in the controller. For more information, see Configuration
Requirements for Redundancy (page 51).

You can also modify or delete the configuration of a Triconex controller. Before modifying a
configuration, make sure it is not being used by a DDE client. If you delete a configuration, the
associated controller can no longer be accessed by a DDE client.
To allow a DDE client to change the values of Triconex variables, you must enable write access
by setting controls in the TriStation application.
Specifying Triconex Host Configuration

This procedure explains how to specify host information for the Triconex controller, which must
be done before a DDE client can access data from the controller.
Procedure
1 Start DDE Server from the Start menu by selecting Programs, then Triconex, then
Triconex DDE Server. The DDE Server main window is displayed.
2 From the File menu, click Configure. The Configuring Host Information screen is
displayed.
3 Either select an existing node and click Modify or click Add to add a host.
The Host Name Configuration screen is displayed.
4 Specify the following properties.
Host Name
The Host Name property identifies the user-defined name for a controller which must be unique
for each controller. (This name is used by the DDE client application to request data from the
controller.)
The default names are TRINODE01 (for node 1) through TRINODE16 (for node 16)

Node Number
The Node Number property identifies the Triconex node number which must be unique for
each controller.
The node number must match the physical switch settings on the MP Front Panel (Tricon) or
MP Baseplate (Trident), the ACM or NCM (Tricon) and the node address specified in the
TriStation project. The default values are 1 to 16.
Redundant
The Redundant property identifies whether there are redundant paths to the controller. You
should select this property if the physical configuration is redundant. This means that two
network interface cards must be connected to network ports on two communication modules.
• For Tricon, the Net2 port on two ACM or two NCM modules
• For Trident, the Net1 or Net2 port on two CM modules
The default is not redundant.
For more information, see Configuration Requirements for Redundancy (page 51).
Time Sync
The Time Sync property identifies whether a Triconex node (host) is to be synchronized with
the clock on the DDE Server PC. If there is more than one Triconex controller in a network, you
should select the master node for synchronization with the DDE Server PC clock. The master
node can then synchronize the time of the other Triconex controllers.
For time-critical applications, Triconex does not recommend selecting the Time Sync property
because PCs are not generally a reliable source for time synchronization.
The default is not synchronized.
Poll Time
The Poll Time property identifies how often the Triconex controller refreshes the data stored as
aliases. The polling interval must be greater than the scan time of the controller.
The default is 1,000 milliseconds (one second).
Use 802.2 (Tricon Only)

For Tricon, the Use 802.2 property identifies whether 802.2 protocol is used to communicate
with the DDE client. If you configure a node to use 802.2 protocol, you must also configure the
server properties. For more information, see Configuring Server Properties for 802.2 Protocol
(page 50). This property is only available for Tricon controllers.

These options are available:

• For Tricon v7.x and v8.x nodes, you must select use 802.2 protocol.
• For Tricon v9.x nodes, you can use either 802.2 or TCP/IP protocol.
The default is not selected which means that TCP/IP protocol is used.
First Adapter (Tricon Only)

For Tricon, the First Adapter property identifies the number of the first network adapter
(interface) card in the primary PC. This property is only available for Tricon controllers and is
only enabled if the Use 802.2 property is selected.
You can have multiple Ethernet adapters in your DDE PC. One is typical; two are needed for
redundancy.
The first adapter number is usually zero (0).
2nd Adapter (Tricon Only)

For Tricon, the 2nd Adapter property identifies the number of the second network adapter
(interface) card in the redundant PC. This property is only available for Tricon controllers and
is only enabled if the Use 802.2 and Redundant properties are selected.
The second adapter number is usually one (1).
IP Address
The IP (Internet Protocol) address property identifies the unique 32-bit network address of the
primary communication module in the Triconex controller.
For a Tricon controller, you must specify this property if the Use 802.2 property is not selected.
Redundant (IP Address)

The Redundant property identifies the IP address of the redundant communication module in
the Triconex controller. The redundant module must have the same IP address that is specified
for this property.
For a Tricon controller, you cannot specify a redundant IP address if the Use 802.2 property is
checked.
Device Type
The Device Type property identifies whether the host is a Tricon or a Trident controller.

Configuring Server Properties for 802.2 Protocol

This procedure explains how to configure the server properties, which must be specified if the
Use 802.2 property is specified for any of the hosts (controllers).
The LLC Buffer Size property must have 50,000 bytes specified for each Triconex host using the
802.2 protocol. For example, if three hosts use 802.2 protocol, the buffer must be set to 150,000
bytes.
Procedure
1 On the Host Name Configuration screen, click the Server button. The Configuring Host
Information screen is displayed.
2 Specify the following properties.
Server Poll Rate (MS)

The Server Poll Rate property specifies the rate in milliseconds at which DDE server updates
clients such as Microsoft Excel or Wonderware InTouch applications. The server poll rate must
be greater than 20 milliseconds and less than 1,000 milliseconds.
LLC Buffer Size

The LLC Buffer Size property specifies the size of the buffer (in bytes), which depends on the
number of Triconex controllers using 802.2 protocol. For each host using 802.2 protocol, a
minimum of 50,000 bytes for each host must be specified.
The default is 100,000.
LLC SAP
The LLC SAP (Service Access Point) property specifies the address for the DDE Server on the
PC, which must be a unique address.
The default is 4.
Testing a TCP/IP Connection

This procedure explains how to determine if the network connection is valid, which can be done
after configuring the Triconex hosts. You might want to test the IP addresses of the network
adapter card in the client PC, and Triconex communication modules.
Procedure
1 On a PC, from the Start menu, click the MS-DOS Command Prompt.
2 Type the word ping followed by the IP address to be tested. For example, for an IP
address of 206.32.216.43, enter this:
ping 206.32.216.43
3 If the network connection is made, the reply includes the IP address followed by byte
and time information. If the connection is not okay, the reply is “Request Timed Out”.

Configuration Requirements for Redundancy

For Tricon controllers, a redundant network can be configured using either TCP/IP protocol or
802.2 protocol. For Trident controllers, a redundant network must be configured using TCP/IP
protocol.
Typically, hardware setup is done before software configuration. This hardware is required:
• For Tricon, two NCM or ACM modules in one or more Tricon controllers.
• For Trident, two CM modules in one or more Trident controllers.
• For the DDE client PC, two network adapter cards.
For more information about Triconex features, see the TriStation 1131 Developer’s Guide.
Configuring Redundancy With TCP/IP Protocol

This procedure explains how to configure network redundancy when using TCP/IP protocol,
which can be used with Tricon version 9 controllers and Trident version 1 controllers.
The configuration procedure involves setting IP addresses. If the network topology permits, use
the Triconex default addresses. If not, get the IP addresses from your Network Administrator.
If the DDE Server PC is not on the same subnet as the Triconex controller, you must specify the
destination address during Ethernet port configuration.
Procedure
1 Install two network adapter cards and the TCP/IP protocol on the DDE Server PC.
2 On the DDE Server PC, use Windows NT procedures to set the IP addresses of the
network adapter cards. A sample IP address is:
206.32.216.x (where x = 1 to 254)
3 Connect the network adapter cards on the DDE Server PC to Ethernet ports on the
primary and redundant Triconex communication modules.
4 In TriStation, set the IP addresses for the primary and redundant communication
modules.
A sample IP address is 206.32.64.y where y is the node number. The node number is set
as follows:
• For Tricon, the number is set with physical switches on the NCM or ACM.
• For Trident, the number is set with the address plug on the MP Baseplate.
5 From the DDE server application, configure each Triconex node with a host name. You
must use the same IP address for the node configuration in DDE Server that is used in
TriStation.

Configuring Redundancy With 802.2 Protocol

This procedure explains how to configure network redundancy when using 802.2 protocol,
which can be used with Tricon version 7 and later controllers. The 802.2 protocol is only
available for Tricon controllers.
Procedure
1 Install two network adapter cards and the DLC protocol on each network card on your
DDE PC.
2 Connect the first network adapter card in the DDE PC to the left NCM or ACM.
3 Connect the second network adapter card to the right NCM or ACM.
4 In the DDE Server application, check the Redundant and Use 802.2 properties. (When
these properties are checked, it is not necessary to configure IP addresses.)
5 Set the First Adapter property to 0 (zero) and the 2nd Adapter property to 1 (one).
Requesting Data with a DDE Client Application

When you use a DDE client application to request data, you identify the DDE Server application
to use, the Triconex controller to be accessed, and the data to be accessed. This information is
referred to as the DDE address. Each DDE client application uses a three-part DDE address
format, but might use slightly different syntax.
The DDE address format includes these parts:
Application + Topic + Item
DDE Address Description

Application Identifies the Triconex DDE Server application name which is TR1DDE.
Topic Identifies the node name for a Triconex controller as configured in the DDE Server
application. The default nodes names for controllers 1-16 are TRINODE01 through
TRINODE16.
For more information on defining nodes, see Specifying Triconex Host
Configuration (page 47).
Item Identifies the alias number for the requested Triconex variable. You can identify
one or more items.
For more information on aliases, see the TriStation 1131 Developer’s Guide.
Save the address you have specified in the DDE client application and start the DDE Server
application. Both the client and server applications must be running concurrently to request or
exchange data. The DDE Server sends the request to the Triconex controller, then returns the
data to the DDE client application.
As an example, the following address could be entered in a blank cell of a Microsoft Excel
worksheet to request the value for alias 40001 in TRINODE02:
=TR1DDE|TRINODE02!‘40001’

Although you can run only one DDE Server application at a time, you can run as many DDE
client applications as allowed by the virtual memory available on your PC.
Requesting Network Status

To find out whether the network ports on a Triconex controller are receiving data, enter either
of the following commands in any client application using the following format.
=tr1dde|TRINODE01!STATUS Reads network status

=tr1dde|TRINODE01!RSTATUS Reads redundant network status
For details on syntax for the DDE address, see the user’s manual for the client application you
are using.
Monitoring Responses from the Controller

The Triconex DDE Server allows you to monitor responses from the Triconex controller which
can include alert entries as well as log entries that indicate a successful response. The entries are
logged in the order in which they occur. To view the most current entries, scroll to the bottom
of the list. If you select the Stats command on the Dump menu, older entries might appear at the
bottom of the list, as shown in this screen.
Changing View Options

To keep the DDE Server main window on top of all other windows, select the Always on Top
command on the View menu. A check mark next to the command means it is selected.

Menu Commands
The DDE Server includes these commands.
Command Menu Description

Configure... File Opens the Configure Host Information screen and allows you to
configure up to 16 controllers for use with the DDE Server application.
Exit File Closes the DDE Server application.
Always on Top View Keeps the DDE Server main window on top of other windows.
Stats Dump Displays statistics for all Triconex controllers.
Triconex DDE Help Opens the Help documentation.
Server Help
About Triconex Help Displays the current version number of the DDE Server application
DDE Server and registered owner information.

OPC Server for Triconex

The Triconex OPC Server is a Windows application which allows OPC clients to have read and
write access to Triconex program variables. OPC is a standard set of non-proprietary interfaces
used to develop client/server applications.
The OPC Server PC must be connected to an Ethernet port on a Triconex controller (Tricon or
Trident). For Tricon, the Net2 port on the ACM or NCM must be used. For Trident, the Net1 or
Net2 port on the Communication Module must be used.
OPC Server is configured by exporting an XML configuration file from a TriStation project and
opening that file in the OPC Server software. After OPC Server is configured, OPC client can ask
the OPC Server to get data from a Triconex controller.
This figure depicts the communication protocols used with the Triconex OPC Server.
OPC Client Triconex

Application Controller
TSAA
OPC Protocol
Protocol
Triconex TSAA Triconex

OPC Server Protocol Controller
OPC
Protocol TSAA
OPC Client Protocol
Application
Triconex
Controller
You can include TriStation configurations for multiple networked controllers in one XML file
by using the same file name when exporting each configuration. The information from each
TriStation configuration is appended to the file.
In OPC Server, you can edit the properties of aliases and tagnames and other aspects of the
configuration. If you change the name of the configuration or alias, a new entry is created in the
XML configuration file. If you change properties related to the entry, but do not change the
configuration or alias name, those properties are changed for the entry.
The Triconex OPC Server is available from Triconex and Matrikon. For more information on the
Triconex OPC Server and OPC client applications, see the Matrikon Web site at
www.matrikon.com.
Configuring the OPC Server

This procedure explains how to configure the OPC Server with alias information from a
TriStation project. With TriStation 1131 version 3.1 and later, alias information can be exported
to an XML file and then imported to the OPC Server. To use OPC Server with TriStation versions
earlier than v3.1, alias information must be manually entered to the OPC Server.

Procedure
1 In TriStation, assign all aliases to be accessed by OPC Server.
2 To allow an OPC client to change the values of Triconex variables, you must enable write
access in the TriStation application.
3 From TriStation, complete the application and download it to the controller.
4 Export the XML configuration file by exporting the tagnames (points).
Select the file type as Matrikon OPC XML Data Files(*.XML). Name the file using the
XML extension, using a maximum of eight characters. If you include multiple
configurations, use the same file name each time you use the export command.
5 If not already done, install OPC Server and start it. When OPC Server is loaded, a gray
Triconex icon is displayed on the status bar.
6 To open the XML configuration file, right-click the Triconex icon from the status bar and
select Configure.
The OPC Server for Triconex PLCs window is displayed.
7 From the File menu, select Open, then select the XML file you exported from TriStation.
As the file loads, statistics are displayed. When finished, you can display Server
Configuration and Alias configuration information.
8 To display Server Configuration information, select a node from the Current
Configuration pane. This screen shows the Server Configuration information. You can
make changes to these properties by entering the changes and pressing the Apply
button.
Click node to
display Server
Configuration
Specify the
properties of the
Left and Right
CM on tab 1 and
tab 2

9 Under Protocol Settings, specify the TCP/IP address and other properties of the
Triconex communication module on tab 1.
If the controller includes two communication modules, specify the properties of the left
module and the right module on tabs 1 and 2.
Do not use tabs 3 through 7.
10 To display alias information, select a node under Alias Configuration in the Current
Configuration pane. To make changes to an alias, double-click the alias row. An Edit
Alias screen is displayed, as shown in this screen.
The Name column The Item Path column

displays tagnames. displays the node, bin,
and memory offset.
Click node to
display Alias
Configuration.
Double-click
alias row to
edit an alias.
11 Repeat steps 8 through 11 for each node configuration included in the XML file.
12 If you made changes to any of the configurations and want to keep them, save the
configuration file.
13 To use OPC Server to get data from a Triconex controller, install an OPC client
application. (Matrikon sells OPC client applications.)
14 In the OPC client application, you can specify the tagnames or aliases of the data to be
accessed.
A sample tagname is DO_02, as shown in the preceding screen.
The location of the data is described as node: bin: offset in the Item Path column for the
Alias Configuration.

Redundant Configuration
OPC Server can be configured for dual redundancy by using two OPC Server PCs. Each PC
must include two Ethernet interface cards, which must be connected to a Triconex
communication module on the primary network and a Triconex communication module on the
redundant network. You must specify the properties of the redundant Triconex communication
modules on the OPC Server Configuration screen. For a figure of redundancy which includes
OPC Server, see Redundant Devices (page 8).
Adjusting System Time

An OPC client can use the Device Clock tagname to read or write the system time of a Triconex
controller. The Device Clock tagname is derived from Triconex status information in the OPC
Server Configuration. For more information, see Time Synchronization (page 101). See also the
documentation for the OPC client software.
Before you can use the Device Clock tagname to adjust the system time of a Triconex controller,
you must configure the TriStation project to allow write access by external devices on an open
network.

Other OPC Products 59
Other OPC Products

For users of OPC Server, two additional OPC products are available from Triconex and
Matrikon: the OPC Data Manager and the OPC Redundancy Broker.
OPC Data Manager

The OPC Data Manager (ODM) is an application that transfers data from one OPC server to
another. ODM is useful for sharing data between two or more control systems such as a
Triconex controller and a DCS. Traditional OPC-enabled systems share data by implementing
one application as an OPC client, and another as an OPC server. If two applications are servers
instead of clients, they cannot exchange data. ODM solves this problem by acting as a double-
headed or thin OPC client to both servers. It requests data from one OPC server and immediately
sends it to the other OPC server.
ODM includes these features:
• Support for both COM and DCOM architectures
• Support for DDE and OPC message protocols
• Operation as a Windows service or a normal application
• Real-time data monitoring
• Extensive error tracking and management
For more information, see the Matrikon OPC Data Manager User’s Manual.
OPC Redundancy Broker

The OPC Redundancy Broker (ORB) is a messaging application designed for systems that must
use redundant devices to ensure high reliability. ORB constantly monitors the primary OPC
server and redirects communication to the standby OPC server when a failure is detected. ORB
can integrate with any OPC compliant client/server configuration and can be retrofitted to
existing configurations.
ORB includes these features:
• Intuitive configuration and monitoring features
• Choice of hot, cold, or warm fail-over for each OPC Server
• Automatic fail-over notification by e-mail, fax, log file, or pager
• Extensive error tracking and diagnostic capabilities
For more information, see the Matrikon OPC Redundancy Broker User’s Manual.


5
Peer-to-Peer Communication
Overview 62
Peer-to-Peer Data Transfer Time 64
Configuring Peer-to-Peer Ports in TriStation 66
Allocating Peer-to-Peer Memory 67
Using Send and Receive Function Blocks 67
Restrictions on Data Transmission Speed 69
Monitoring Peer-to-Peer Communication 70
Sample Peer-to-Peer Programs 72

62 Chapter 5 Peer-to-Peer Communication
Overview
Triconex Peer-to-Peer protocol is designed to allow multiple Tricon and Trident controllers in a
closed network to exchange safety-critical data. (If you plan to implement a complex Peer-to-
Peer network, please contact Triconex Technical Support.) To enable Peer-to-Peer
communication, you must connect each controller to an Ethernet network by using an Ethernet
port on the CM. The controllers exchange data by using Send and Receive function blocks in
their TriStation applications.
Peer-to-Peer Network
CM CM
Tricon
Controller
NN
M M M CC
P P P MM
A B C 1 2
MP MP
Trident Controller Trident Controller
To configure a TriStation application for Peer-to-Peer communication, you must do these tasks:
• Configure the physical port connection for Peer-to-Peer mode
• Allocate memory for Send and Receive function blocks
• Add Send and Receive function blocks to the TriStation application
• Observe restrictions on data transmission speed
In addition, Triconex recommends that you calculate the data transfer time to determine
whether the control algorithms will operate correctly.
A TriStation application must use a specific Send function block to send data to a matching
Receive function block in another TriStation application. Each Send function block has a
parameter that identifies the Receive function block to which it sends data. Each Receive
function block has a parameter that identifies the Send function block from which it receives
data.
The Send and Receive function blocks can transfer data with BOOL, DINT, or REAL data types.
Some function blocks transfer 20 data values, and others transfer 32 data values. For detailed
information about the available Send and Receive function blocks, see the TriStation Libraries
Reference.
Peer-to-Peer communication speed for Tricon controllers is 10 megabits per second; Trident
controllers communication speed is 10 or 100 megabits per second. If the network includes both
types of controllers, you can run the entire network at 10 megabits per second, or you can use a
hub that converts messages from 10 to 100 megabits per second when they are transferred from

Overview 63
a Tricon to a Trident. Triconex suggests using the Net1 port on both Tricon and Trident
communication modules, because 10 megabits per second is the only speed available on Net1.
With this setup, Net2 is available for faster communication with external devices on an Ethernet
network. For more information, see Restrictions on Data Transmission Speed (page 69).
For monitoring Peer-to-Peer data exchange, TriStation provides function blocks and system
attributes to track network communication paths and verify whether the Ethernet ports are
receiving data from other controllers.
The sample programs described in this chapter on the TriStation CD. These programs show how
to send data at high speed and under controlled conditions, and how to measure the maximum
data transfer time.

Peer-to-Peer Data Transfer Time

In a Peer-to-Peer application, data transfer time includes the time required to initiate a send
operation, send the message over the network, and have the message read by the receiving
node. Additional time (at least two scans) is required for a sending node to get an
acknowledgment from the MP modules that the message has been acted on.
These time periods are a function of the following parameters of the sending and receiving
controllers:
• Scan time
• Configuration size
• Number of bytes for aliased variables
• Number of Send function blocks, Receive function blocks, printing function blocks, and
Modbus master function blocks
• Number of controllers on the Peer-to-Peer network
Send function blocks require multiple scans to transfer data from the sending controller to the
receiving controller. The number of send operations initiated in a scan is limited to 5. The
number of pending send operations is limited to 10.
A typical data transfer time (based on a typical scan time) is 1 to 2 seconds, and the time-out
limit for a Peer-to-Peer send (including 3 retries) is 5 seconds. Consequently, the process-
tolerance time of the receiving controller must be greater than 5 seconds. Process-tolerance time
is the maximum length of time that can elapse before your control algorithms fail to operate
correctly. If these limitations are not acceptable, further analysis of your process is required.
Estimating Memory for Peer-to-Peer Data Transfer Time

This procedure explains how to estimate memory for Peer-to-Peer data transfer time between a
pair of Triconex controllers. The more memory allocated for aliased points the slower the
transfer time.
Procedure
1 Open the TriStation project used for the sending controller and go to the Memory
Allocation screen.
2 Find the bytes allocated for BOOL, DINT, and REAL points.
• Add the number of bytes allocated for all BOOL input, output, and aliased memory
points.
• Repeat these steps for DINT and REAL points.
3 Open the TriStation project used for the receiving controller and go to the Memory
Allocation screen.
4 Find the bytes allocated for BOOL, DINT, and REAL points.
• Add the number of bytes allocated for all BOOL input, output, and aliased memory
points.

Peer-to-Peer Data Transfer Time 65
• Repeat these steps for DINT and REAL points.

5 Use this worksheet to estimate the transfer time.
Point Allocated
Steps Operation Result
Type Bytes
1. Enter the number of bytes for each point BOOL _________ ÷8= _________
type on the sending controller and divide or
multiply as indicated. Add the results. DINT _________ •4= _________
REAL _________ •4= _________
System Variables + 376
Total bytes of aliased points TBS = _________
2. Multiple total bytes sending TBS (step 1) by .01 TS = _________
3. Enter the number of bytes for each point BOOL _________ ÷8= _________
type on the receiving controller and divide or
multiply as indicated. Add the results. DINT _________ •4= _________
REAL _________ •4= _________
System Variables + 376
Total bytes of aliased points TBR = _________
4. Multiple total bytes receiving TBR (step 3) by .01 TR = _________
5. Get the scan time of sending node in milliseconds by viewing the SS = _________
Scan Time in the diagnostic screen or by getting the value of the
ACTUAL_SCAN_TIME parameter in the SYS_MP_EXT_STATUS
function block.
6. Get the scan time of receiving node in milliseconds by viewing the SR = _________
Scan Period in the Execution List.
7. Multiply the larger of TS or SS by 2. _________
8. Multiply the larger of TR or SR by 2. _________
9. Add the results of step 7 and 8 to get the data transfer time = DT _________
10. If the number of pending send requests in the application is greater
than 10, divide the number of send requests by 10. _________
11. Multiply the results of steps 9 and 10 to get the adjusted data Adjusted
transfer time. DT _________
12. Compare the adjusted DT to the process-tolerance time to determine if it is
acceptable.

Configuring Peer-to-Peer Ports in TriStation

This procedure explains how to configure an Ethernet port on the Trident CM for
communication with other Triconex controllers on a Peer-to-Peer network.
Procedure
1 Open the TriStation project and go to the Network tab on the CM Setup (Configuration)
screen.
Mode
Select Peer-to-Peer for Net1or Net2 Mode.
For each CM on a baseplate, you can select Peer-to-Peer for one Ethernet port. If you are using
two CM modules, you must select Peer-to-Peer for the same Ethernet port (Net1 or Net2) on
each CM.
Transceiver Port
This option describes the physical network connection. Select RJ-45 (the default) if you have
attached your communication cable to an RJ-45 connector on the CM Baseplate.
Select the MAU option if you have attached an MII MAU to a 40-pin subminiature D connector
or an AUI MAU to a DB-15 connector on the CM Baseplate. You might have to set the physical
address of a MAU before attaching it to a CM port. You must purchase MAUs from a third-party
manufacturer. For more information, see Chapter A, Communication Module Capabilities
Transceiver Mode
This option specifies whether messages are transmitted and received simultaneously (10
Megabit Full Duplex mode) or in one direction at a time (10 Megabit Half Duplex mode). Select
a mode that is compatible with the available hardware.
This option specifies whether to use time synchronization in your network. Select one of the
following:
Select one of the following options:
to Net1
to Net2
• None: Time synchronization is not performed by a Trident controller, but can be
performed by an external device (such as an OPC client)

Allocating Peer-to-Peer Memory 67
Allocating Peer-to-Peer Memory

In TriStation, memory is allocated for Peer-to-Peer functions, based on the maximum number
of Send and Receive function blocks specified in the project. To save memory and minimize scan
time, you should use the lowest possible numbers.
The maximum number does not have to be the same for Sends and Receives. For example, a
TriStation application might need to send messages to three projects, but need to receive
messages from only one project.
A change in Peer-to-Peer allocation requires a Download All command.
Using Send and Receive Function Blocks

A TriStation application must use a specific Send function block to send data of a certain type
to a matching Receive function block in another TriStation application. Each Send function
block has a parameter that identifies the Receive function block to which it sends data. Each
Receive function block has a parameter that identifies the Send function block from which it
receives data.
Send and Receive Function Blocks

The Send and Receive function blocks that you can include in a TriStation application have data
types of BOOL, DINT, and REAL. These function blocks are available.
Send Function Blocks Receive Function Blocks

TR_USEND_BOOL TR_URCV_BOOL
TR_USEND_DINT TR_URCV_DINT
TR_USEND_REAL TR_URCV_REAL
TR_USEND_BOOL_32 TR_URCV_BOOL_32
TR_USEND_DINT_32 TR_URCV_DINT_32
TR_USEND_REAL_32 TR_URCV_REAL_32
The _32 ending means that the function block can send 32 data values. Function block names
that do not include the _32 ending can send 20 data values.
All Send function blocks—and all Receive function blocks—have the same parameters, except
for the data transfer parameters which are BOOL, DINT, or REAL. For detailed descriptions, see
the TriStation Libraries Reference.

Sample Send and Receive Pair

This figure depicts a sample pair of Send and Receive function blocks. A Send function block in
one TriStation application is sending input values from the field over a Peer-to-Peer network to
a matching Receive function block in another TriStation application. The Recvid and Sendid
parameters are used to cross-reference the Send and Receive function blocks. The Recvnode and
Sendnode parameters are used to cross-reference the sending and receiving nodes (TriStation
applications).
For more information, see Sample Peer-to-Peer Programs (page 72).
TriStation Application on Sending Node 1
Send1toNode2
Identifiers for:
Sending Function Block
Receiving Node 21
Receiving Function Block Send1toNode2Status
TriStation Application on Receiving Node 2
Recv1FromNode1
Identifiers for:
Receiving Function Block
Sending Node 1
2 Recv1FromNode1Status
Sending Function Block

Restrictions on Data Transmission Speed 69
Restrictions on Data Transmission Speed

Tricon controllers do Peer-to-Peer communication at 10 megabits per second; Trident
controllers can do Peer-to-Peer communication at 10 or 100 megabits per second. If the network
includes both types of controllers, you can choose either of these solutions.
Solution Description
Run the entire network at 10 Data exchange among Triconex controllers can be effectively done at
megabits a rate of 10 megabits per second. Triconex suggests using the Net1
port on both Trident and Tricon communication modules, because 10
megabits per second is the only speed available on Net1. With this
setup, Net2 is available for faster communication with external
devices on an Ethernet network.
Convert messages from 10 to The data rate can be converted when messages are transferred from a
100 megabits Tricon controller to a Trident controller. A typical method is to
connect the Tricon and Trident controllers to a hub which can convert
from 10 to 100 megabits. For Trident controllers, another method is to
use MAU connections, which can convert from 10 to 100 megabits, to
CM ports.

Monitoring Peer-to-Peer Communication

TriStation provides function blocks and system attributes for monitoring the status of Peer-to-
Peer communication paths (routes between CM modules on the network) and the status of
Ethernet (Net1 and Net2) ports on the CM. For detailed information, see the TriStation Libraries
Reference.
Status of Communication Paths

A Peer-to-Peer network can communicate over one or two paths, depending on whether each
controller contains one or two CM modules. If there are two paths (two CM modules), then both
are used simultaneously to exchange Peer-to-Peer data. The failure of one path does not affect
Peer-to-Peer communication. To monitor the paths, use the TR_PEER_STATUS function block
in the TriStation application. Path status is updated every 30 seconds.
This figure depicts the FBD representation of a TR_PEER_STATUS function block.
Status of Ethernet (Net1 and Net2) Ports

You can determine whether the Net1 and Net2 ports are receiving Peer-to-Peer data by using
the SYS_CM_STATUS function block or CM_ system attributes in the TriStation application.
Using the SYS_CM_STATUS Function Block

The SYS_CM_STATUS function block is used to monitor the status of the Net1 and Net2 ports,
serial ports, and the print buffer on the CM. The NET1OK or NET2OK parameter is True if a
message was received by the Net1 or Net2 port in the last 15 seconds. (Most of the other
parameters in the function block are for serial ports.) The network port status is updated every
30 seconds.

Monitoring Peer-to-Peer Communication 71
This figure depicts the FBD representation of a SYS_CM_STATUS function block.
Using the CM_ System Attributes

In a TriStation application, system attributes are points which allow you to monitor the status
of system components and conditions, and control several system operations. The following
system attributes for the CM can be used to verify whether the Net1 and Net2 ports have
received messages in the last 15 seconds from other controllers in a Peer-to-Peer network.
System Attribute Name Port on the CM

CM_L.NET1_OK Net1 port on the left CM
CM_L.NET2_OK Net2 port on the left CM
CM_R.NET1_OK Net1 port on the right CM
CM_R.NET2_OK Net2 port on the right CM

Sample Peer-to-Peer Programs

The sample programs described in this chapter are on the TriStation CD. These programs show
how to send data at high speed and under controlled conditions, and how to measure the
maximum data transfer time.
Topics include:
• Fast Send to One Controller (page 72)
• Sending Data Every Second to One Controller (page 72)
• Sending Data Only When Requested (page 72)
• Fast Send of Safety-Critical Data (page 72)
Fast Send to One Controller

These programs show how to send data as fast as possible from Trident Node 2 to Trident Node
3. This technique can be used with a scan time as low as 100 milliseconds.
• PEER_EX1_SEND_FBD (for sending Trident Node 2)
• PEER_EX1_RCV_FBD (for receiving Trident Node 3)
Sending Data Every Second to One Controller

These programs show how to send data every second from Trident Node 2 to Trident Node 3.
This technique can be used with a scan time as low as 100 milliseconds.
Sending Data Only When Requested

These programs show how to use Send and Receive function blocks in a controlled way. The
programs send data only when an acknowledgment for the last send operation is received and
new data is available.
Fast Send of Safety-Critical Data

These programs show how to transfer a small amount of safety-critical data between two
TriStation applications as fast as possible. The programs also show how to measure the actual
maximum time for transferring data from the sending node to the receiving node.

Sample Peer-to-Peer Programs 73
Because safety-critical data is being transferred, each controller must have two CM modules
which are connected to redundant Peer-to-Peer networks.
The data transfer time described in this section is calculated using this equation.
DT = (2 • <Larger of TS or SS>) + (2 • <Larger of TR or SR>)
Parameter Description
DT Data transfer time in milliseconds.
TBS Total bytes of aliased variables in the sending node.
Time for sending controller to transfer aliased data over the communication bus in
TS milliseconds.
TS = (TBS ÷ 100,000) * 1000
SS Scan time of sending node in milliseconds.
TBR Total bytes of aliased variables in the receiving node.
Time for receiving controller to transfer aliased data over the communication bus in
TR milliseconds.
TR = (TBR ÷ 100,000) * 1000
SR Scan time of receiving node in milliseconds.
Sample Timing Calculations

SS = 150 milliseconds
TBS = 2000 bytes
TS = (2000/100,000) • 1000 = 20 milliseconds
SR = 250 milliseconds
TBR = 5000 bytes
TR = (5,000 ³ 100,000) • 1000 = 50 milliseconds
DT = 2 • 150 + 2 • 250 = 800 milliseconds
Process tolerance time = 4 seconds
The PEER-EX4_SEND_FBD program packs 32 BOOL values into a DWORD and sends the
DWORD with a diagnostic variable to a receiving node as fast as possible by permanently
setting the SENDFLG parameter to 1. The diagnostic variable is incremented every time a new
send operation is initiated. The receiving node verifies that the diagnostic variable has changed
from the previous value received. The receiving node also verifies that it has received at least
one sample of new data within the process tolerance time. If not, the receiving program takes
an appropriate action, such as using the last data received or using default data to make safety-
critical decisions.
If the sending controller does not receive acknowledgment from the receiving controller in 1
second, it automatically retries the last Send message a second time. Due to network collisions,
communication bus loading, or other problems, the sending controller occasionally has to retry

the send a third time. This is why the general rule for data transfer time is 1 to 2 seconds, even
though the estimated time (DT) is 800 milliseconds.
The application running in the receiving controller includes a network that measures the actual
time so that you can validate the assumed 2-second maximum transfer time. Since the process
tolerance time of the receiving node is 4 seconds, the maximum time-out limit is set to 2 seconds
(half the process tolerance time). The receiving node should get at least one sample of new data
within the maximum time-out limit. Using this criteria satisfies the basic requirement for using
Peer-to-Peer to transfer safety critical data.

6
Modbus Communication
Overview 76
Physical Features 77
Configuring Serial Ports in TriStation 82
Programming for Triconex Masters 87
Programming for Triconex Slaves 92
Sample Modbus Programs 96

76 Chapter 6 Modbus Communication
Overview
Modbus is an industry-standard master/slave protocol that is traditionally used for energy
management, transfer line control, pipeline monitoring, and other industrial processes. A serial
port on a Triconex module can operate as a Modbus master, slave, or both. A DCS, operator
workstation, or other Modbus device typically acts as the master while the Triconex serial port
acts as the slave.
Serial ports on the CM and MP provide choices for communication with Modbus devices. Each
port can operate in a point-to-point connection with a single Modbus device, or in a multi-point
serial link with several Modbus devices. For an example, see Configuration Options (page 77).
A Trident CM serial port can act as a master, slave, or combination master/slave with these
physical features:
• Point-to-point or multi-point network topology
• RS-232, RS-422, or RS-485 communication interface
• 2-wire (half duplex) or 4-wire (full duplex) cables
• Hardware handshake with or without signal delays
For a CM serial port configured as a master, the associated TriStation application can use
Modbus Read and Write function blocks to communicate with slave devices, including other
Triconex controllers. Programs in external Modbus master devices can directly access point
values in a Triconex controller if the points have aliases and if write access controls are correctly
applied.
A TriStation application normally uses alphanumeric names to identify Triconex points
(program variables). Numeric identifiers called aliases must also be used to make the point
values accessible to external Modbus devices. An alias has five digits that define its data type
and hardware address in the controller.
An MP serial port cannot be configured as a master, and the TriStation application cannot use
Modbus Read and Write function blocks. MP serial ports can act only as slaves in a point-to-
point configuration, using the RTU data format and 4-wire (full duplex) physical media. The RS-
485 or RS-232 transceiver mode can be used.
Function blocks and system attributes allow you to monitor the communication status of each
CM and MP serial port. The status information includes the number and kinds of messages
received and sent and milliseconds since the last message was received.
The sample programs described in this chapter are included on the TriStation CD. These
programs show how to use the Modbus Read and Write function blocks for transmitting aliased
data, how to set time-out and retry values for Modbus communication, and how to control the
flow of data from slave to master. For detailed information, see Chapter D, Modbus Protocol

Physical Features
When connecting a Trident CM or MP serial port to one or more Modbus devices, you can select
from these physical features.
Feature Option Use for

Network Point-to-point Connection to one Modbus device
Topology
Multi-point Connection to multiple Modbus devices
Communication RS-232 Maximum speed across distances up to 50 ft (15 m)
Interface
RS-422 Distances up to 4,000 ft (1,220 m), point-to-point only
RS-485 Distances up to 4,000 ft (1,220 m)
Cable Type 2-wire Half-duplex data transmission
4-wire Full-duplex data transmission
Hardware Default Devices that do not require signal delays
Handshake
Signal delay Devices with slow throughput, other limitations
Configuration Options
A Trident CM or MP serial port can operate in a point-to-point connection with a single Modbus
device, or in a multi-point serial link with several Modbus devices.
Point-to-Point Connection
This figure depicts a point-to-point connection, which is a direct connection between devices.
Modbus Master
Modbus Slave CM
Point-to-Point Connection
MP
Multi-Point Connection
This figure depicts a multi-point connection, which allows connections between several devices.

Modbus Master
CM
Multi-Point Connection
Modbus Slave Modbus Slave Modbus Slave
MP
Physical Media Rules

These rules apply to the communication interfaces and cables you can use with CM or MP serial
ports:
• RS-232 can be used only for point-to-point connections across distances up to 50 feet (15
meters)
• RS-422 can be used only for point-to-point connections across distances up to 4,000 feet
(1,220 meters)
• RS-485 can be used:
— for point-to-point connections or multi-point serial links
— with 2-wire or 4-wire cables
— across distances up to 4,000 feet (1,220 meters) on a multi-point serial link
Multi-Point Connection Considerations

This section includes considerations for using RS-422 multi-point connections, which are also
referred to as RS-485 with more than two connections. Also included is information on how the
wires are identified and used.
You should ensure that the connection includes the following:
• Pull-up/pull-down resistors are mandatory.
• An optional signal ground reference wire is highly advised.
The RS-422 and RS-485 standards do not define a connector pin-out, but do define each
differential twisted-pair wire as Wire A and Wire B. Some RS-422 and RS-485 suppliers rename
these as Wire + and Wire -. This means you cannot always rely on the name to identify the
polarity of the signal

To determine the polarity, do this:

1 For both the Triconex controller and DCS, ensure the send channel is on.
2 On the Triconex controller side, measure the signal ground to SDA and SDB.
The SDA will be less than 1 volt.
The SDB will be greater than 2.5 volts.
3 On the DCS side, measure the send channel.
If the channel is less than 1 volt, it is the A channel.
If the channel is greater than 2.5 volts, it is the B channel.
4 Use the following tables to determine whether the polarity is typical or reversed.
This table identifies a typical conversion with wires defined as A and B, or + and -.
Table 1 Typical Conversion

Triconex Other Suppliers
SDA = Send Data A = TX+ = Transmit Data, Positive Polarity
SDB = Send Data B = TX- = Transmit Data, Negative Polarity
RDA = Receive Data A = RX+ = Transmit Data, Positive Polarity
RDA = Receive Data B = RX- = Transmit Data, Negative Polarity
This table identifies a reverse polarity conversion.
Table 2 Reversed Polarity Conversion

Triconex Other Suppliers
SDA = Send Data A = TX- = Transmit Data, Negative Polarity
SDB = Send Data B = TX+ = Transmit Data, Positive Polarity
RDA = Receive Data A = RX- = Transmit Data, Negative Polarity
RDA = Receive Data B = RX+ = Transmit Data, Positive Polarity

Hardware Handshake Rules

Hardware handshake refers to signals transmitted back and forth between two stations to
coordinate the timing of data transmission. These rules apply to the use of hardware handshake
with Modbus devices:
• Generally, hardware handshake can be used with the RS-232 or RS-485 communication
interface.
• With a 2-wire cable, you must use hardware handshake.
• For a point-to-point configuration, you should use hardware handshake only if the
connected Modbus device requires it.
• For a multi-point configuration that uses 4-wire cables, typically the slaves use
hardware handshake but the master does not.

Valid Modbus Configurations

A valid configuration of Modbus devices must use one of these combinations of physical
features.
Valid Communication Hardware

Network Topology Physical Media
Configuration interface Handshake
Combination 1 Point-to-Point RS-232 Not applicable Optional
Combination 2 Point-to-Point RS-485 2-wire Required
Combination 3 Point-to-Point RS-485 4-wire Optional
Combination 4 Multi-Point RS-485 2-wire Required
Combination 5 Multi-Point RS-485 4-wire Optional
Modbus Communication Properties

Serial ports on the MP and CM support these properties for Modbus communication.
Option MP CM
Slave RTU 3 3
Slave ASCII 3
Master 3
Combination Master/Slave 3
Point-to-Point 3 3
Multi-Point 3
RS-232 3 3
RS-485 3 3
2-Wire Cable 3
4-Wire Cable 3
Hardware Handshake 3
Signal Delay 3
Modbus Range 3 3
Modbus Read and Write Function Blocks 3

Configuring Serial Ports in TriStation

This section explains how to configure a serial port on a CM or MP Baseplate. The properties
you specify in TriStation must match the physical properties of the Modbus device it is
connected to.
If you have a CM, Triconex recommends using the CM serial ports for Modbus communication
instead of the MP serial ports, because the CM ports are faster, have greater capacity, and
include more modes of operation. MP serial ports can act only as Modbus slaves in point-to-
point configurations.
This section includes:
• Configuring MP and CM Serial Ports (page 82)
• Setting Signal Delays for Hardware Handshake (page 85)
Configuring MP and CM Serial Ports

This procedure explains how to configure serial ports in TriStation for a Trident MP or CM.
For Trident, each MP can be separately configured to use Modbus slave RTU protocol. The serial
ports can operate independently, communicating with different Modbus masters. Or they can
operate as redundant serial ports, connected to redundant ports of the same Modbus master.
Procedure
1 Open the TriStation project and go to the EICM Setup (Configuration) screen.
Port Selection
The Port Selection property specifies the serial port to be configured. For the Left CM, select Port
1, 2, or 3. For the Right CM, select Port 6, 7, or 8.
Protocol
The Protocol property specifies the communication protocol to be used with the port. For
Modbus communication, select one of these:
• Modbus Slave ASCII (Trident CM)
• Modbus Slave RTU (Trident MP and CM)
• Modbus Master (Trident CM)
• Modbus Master/Slave (Trident CM)
For information about the ASCII and RTU modes, see Communication Modes (page 162).

Modbus Station Address

Each serial port which is connected to a Modbus master device must have a separate Modbus
Station Address. Addresses can be 1 to 247.
This property is not available if the CM serial port acts as a Modbus master.
If the CM serial port acts as a master, the station address of the slave is specified in the Modbus
Read and Write function blocks. For more information, see Programming for Triconex Masters
(page 87).
Baud Rate
The Baud Rate property specifies the data transmission speed.
Select 1200, 1400, 2400, 4800, 19200, 38400, 57600, or 115200.
Data Bits (ASCII or RTU)

The Data Bits property specifies whether the data format includes 7 bits (ASCII mode) or 8 bits
(RTU mode). This property can be set only if you have set the Protocol property to Modbus slave
mode. With other modes, the default value of RTU mode (8 bits) applies.
Stop Bits
The Stop Bits property specifies whether to transmit 1 bit or 2 bits after each character to notify
the receiving computer that the transmission of a byte of data is complete.
Parity
The Parity property specifies whether to use parity checking, which is a way to detect data
communication errors, on the transmitted data.
Odd and Even parity counts the number of 1 bits in a one-byte data item then sets the parity bit
(9th bit) to 0 or 1 to result in an Odd or Even total number of 1 bits.
Mark and Space parity (also called high/low parity) set the parity bit to 1 or 0 regardless of the
number of 1 bits in the data item.
Settings include:
• Odd sets the parity bit to 0 or 1 to make the total number of 1 bits odd.
• Even sets the parity bit to 0 or 1 to make the total number of 1 bits even.
• Mark sets the parity bit to 1 for each data item.
• Space sets the parity bit to 0 for each data item.
• None deletes the parity bit.
The default is Odd.
Transceiver (Transmission) Mode

The Transceiver (Transmission) Mode identifies the type of physical connection.

For serial connections, settings include:

• RS-232 for point-to-point communication over distances up to 50 feet
• RS-485 for multi-point communication over distances up to 4,000 feet
RS-232 Transceiver Mode with Handshake

With the Handshake property set to Hardware, the Trident CM asserts the Request to Send
(RTS) signal when it has a message to transmit. The CM begins transmission when it receives a
Clear to Send (CTS) signal from the Modbus master. The Trident CM ignores all characters
unless the Modbus master asserts the Data Carrier Detect (DCD) signal. This settings allows the
Modbus master to use half-duplex modems.
With the Handshake property set to None (typically for point-to-point connections), the Trident
CM asserts RTS at all times and ignores CTS and DCD. In other words, the CM transmits
characters even if the receiving device is not ready. This could result in an overrun state, and the
characters would have to be re-transmitted.
RS-485 Transceiver Mode with Handshake

With the Handshake property set to Hardware, the Trident CM enables its RS-485 transmit
driver only when it is sending data. Use this setting for all single-pair networks and for slave
ports in two-pair, multi-point networks.
With the Handshake property set to None, the Trident CM enables its RS-485 transmit driver at
all times. Use this setting for a Modbus slave port in a two-pair, point-to-point network.
Handshake
The Handshake property specifies whether to use signals to establish a valid connection. With
hardware handshake, a separate wire sends a signal when the receiving device is ready to
receive the signal, which ensures that a device transmits data only when the other device is
ready to receive it.
For the Trident CM, the setting of the Transceiver Mode property determines whether
hardware handshake is valid.
Specify Hardware if the physical hardware using any of these configurations:
• Any 2-wire configuration (required)
• A multi-point configuration that uses the RS-485 transceiver mode (required)
• A point-to-point configuration that uses an external modem with RS-232 transceiver
mode (optional)
The default is None.
To delay the timing of Modbus data transmission, see Setting Signal Delays for Hardware
Handshake (page 85).
Wire Type
The Wire Type property specifies the type of wire used for serial communication.

Settings include:
• 2-Wire (half duplex) if using one pair of wires for Modbus reads and writes. (Only
available when the Transceiver Mode property is set to RS-485 on the Trident CM Serial
Ports tab.)
• 4-Wire (full duplex) if using two pairs of wires—one pair for Modbus reads and the
other pair for Modbus writes. (Trident MP serial ports must use this setting.)
Modbus Range
The Modbus Range property identifies the range of five-digit numbers that can be assigned to
a point. The leftmost digit identifies the data type and the other digits identify the hardware
address in the controller.
The minimum value is –32,768; the default is 0.
The maximum value is 32,767; the default is 32,767.
Honeywell DHP uses 0 to 9,999.
The Modbus Range operates in conjunction with the Minimum and Maximum values on the
Trident MP, and Trident CM serial ports to scale values of REAL points. For more information,
see How REAL Numbers are Scaled to Integers (page 92).
Setting Signal Delays for Hardware Handshake

For Modbus devices that use hardware handshake, setting CTS and RTS signals can delay the
timing of data transmissions, which is a method of ensuring that devices are ready to receive
data.
The RTS (Request to Send) signal opens and closes the data transmission channel. The RTS pre-
delay setting specifies the number of milliseconds to wait before the data is transmitted.
The CTS (Clear to Send) signal indicates the transmitting station that it is ready to receive data.
The CTS Pre-delay setting specifies the number of milliseconds to keep the channel open after
data is transmitted.
This figure is a sample timing figure.
40001 40004
RTS CTS
Post-delay Pre-delay
RTS
Data
Parameter Action
Alias For CTS, enter 40001.
For RTS, enter 40004.

Parameter Action
Port Enter the EICM port number.
Station Enter the slave station address.
D01 Enter the delay in milliseconds; 0 to 10,000.
Setting Signal Delays on a Trident MP or CM

Signal delays are set by on the Trident MP or CM Serial Ports tab. The Signal Delay property can
be set for the CTS and RTS signal.
The settings can be from 0 to 10,000 milliseconds; the default is 0.

Programming for Triconex Masters

If you configure a serial port on a Triconex controller as a Modbus master, the TriStation
application can use Modbus Read and Write function blocks to communicate with slave devices,
including other Triconex controllers.
These Read and Write function blocks are available.
• MBREAD_BOOL • MBWRITE_BOOL
• MBREAD_DINT • MBWRITE_DINT
• MBREAD_REAL • MBWRITE_REAL
• MBREAD_REAL_TRD • MBWRITE_REAL_TRD
Read and Write function blocks of types BOOL and DINT can transmit 32 data values. Read and
Write function blocks of type REAL can transmit 25 data values.
Triconex controllers use BOOL, 32-bit DINT (double integer) and 32-bit REAL numbers,
whereas traditional Modbus protocol supports only Booleans and 16-bit integers. For this
reason, TriStation includes function blocks which convert REAL values to integers and integers
to REAL values. The sections beginning on page 88 provide guidelines for use of these function
blocks.
For detailed information on function blocks, see the TriStation Libraries Reference. For examples,
see Sample Modbus Programs (page 96).
Processing of Modbus Function Blocks

During each scan, a Triconex controller initiates up to five Modbus read or write operations for
each Modbus master port. Each Modbus master port is limited to ten outstanding requests for
a Modbus operation. A Modbus operation might require up to six scans to complete. When a
Modbus operation is completed, the controller initiates the next pending request for a Modbus
operation.
For example, with a single Modbus master port and a TriStation application that uses twelve
MBREAD function blocks and no MBWRITE or MBCTRL function blocks, the controller
initiates the first five Modbus reads during the first scan. During the second scan, the controller
initiates the sixth through tenth Modbus reads. When a Modbus read is completed, the
controller initiates the eleventh Modbus read. When the next Modbus read is completed, the
controller initiates the twelfth Modbus read. As each Modbus read is completed, the controller
initiates the next pending request for a Modbus read.
For more information, see Chapter D, Modbus Protocol on page 75.

Function Blocks for Communicating with Non-Triconex Slaves

These function blocks can be used when a Triconex master interfaces with a non-Triconex slave
device.
Data Type Function Block

Application Notes
in Slave in Triconex Master
Boolean MBWRITE_BOOL • Values are True (1) and False (0).
MBREAD_BOOL
Integer MBREAD_DINT • Although the DINT data type uses signed 32-bit
MBWRITE_DINT integers, only the least significant 16 bits are transferred.
• Values should be limited to the range of zero through
32,767.
Real MBREAD_REAL_TRD • REAL values are read from the slave as two 16-bit
MBWRITE_REAL_TRD consecutive aliases and concatenated to form a 32-bit
REAL value (see Example 2).
• 32-bit REAL values to be written to the slave are first
split into two 16-bit values which are written to two
consecutive aliases (see Example 1).
Example 1. Writing a Real Value Example 2. Reading a Real Value
Figure 2 Function Block Examples

Function Blocks for Communicating with Trident Slaves

These function blocks can be used when a Triconex master communicates with a Trident slave.

Application Notes
BOOL MBWRITE_BOOL • Values are True (1) and False (0).
MBREAD_BOOL
DINT MBREAD_DINT • Although the DINT data type uses signed 32-bit
32,767.
REAL MBREAD_REAL_TRD • Each REAL aliased variable in the Trident slave must
MBWRITE_REAL_TRD have scaling disabled in the Min/Max screen.
Function Blocks for Communicating with Tricon Slaves

These function blocks can be used when a Triconex master communicates with a Tricon slave.

Application Notes
BOOL MBWRITE_BOOL • Values are True (1) and False (0).
MBREAD_BOOL
DINT MBREAD_DINT • Although the DINT data type uses signed 32-bit
32,767.
REAL MBREAD_REAL • The SPECIAL parameter on each of these function blocks
MBWRITE_REAL should be set to False.

Sample Modbus Read Function Block

This figure depicts a sample Modbus Read function block in a TriStation application that
includes programming for CM serial port 1 (as indicated by the Port parameter). The function
block is reading values from Slave Station 2 (as indicated by the Station parameter) through CM
serial port 1 and storing the values in local variables.
Slave
Station 2
Modbus Serial Link
TriStation Programming
for Modbus Master Port
Starting Alias 1
31001
Serial Port Number 32
1
Slave Station Address 2
Because the Starting Alias is 31001, the

D01 through D32 data parameters have
aliases 31001 through 31032.

Sample Modbus Write Function Block

This figure depicts a sample Modbus Write function block in a TriStation application that
includes programming for CM serial port 1 (as indicated by the Port parameter). The function
block is writing values to Slave Station 2 (as indicated by the Station parameter) through CM
serial port 1.
Slave
Station 2
Modbus Serial Link
TriStation Programming
for Modbus Master Port
Starting Alias
Serial Port Number

Slave Station Address
Because the Starting Alias is

40251, the D01 through D32
data parameters have aliases
40251 through 40282.

Programming for Triconex Slaves

If you configure an MP or CM serial port on the Trident controller as a Modbus slave, aliases
must be assigned to tagnames that will be accessed by the external Modbus master.
Triconex controllers support BOOL, 32-bit DINT (double integer) and 32-bit REAL numbers,
whereas traditional Modbus protocol supports only Booleans and 16-bit integers. This means
that DINT and REAL values from a Triconex controller are transmitted as follows:
• For DINT tagnames in a Triconex slave, the Triconex controller transfers only the least
significant 16 bits.
• For REAL tagnames in a Trident slave, you specify whether to scale the REAL value to
a Modbus (16-bit) integer or to transfer the least significant 16 bits of the 32-bit value.
How REAL Numbers are Scaled to Integers

This section explains how 32-bit REAL scaled numbers are transmitted in Modbus protocol,
which uses 16-bit integers.
If a REAL value is scaled, these operations occur:
• When a Modbus master writes a 16-bit integer to a Triconex slave, the controller scales
the integer to a 32-bit REAL number before using it in the TriStation 1131 application.
• When a Modbus master reads a 32-bit REAL variable from a Triconex slave, the
controller scales the REAL variable to a 16-bit integer before transmitting it.
Scaling Integer Values to REAL Values

This figure depicts how a Modbus master writes an integer value to the Triconex controller
where it is scaled to a REAL value.
Triconex Controller
Modbus Master
Numeric Range: 0 to 32767 Real Value

in Alias
Modbus Write
Modbus Integer 15337 Scaling
Scaling an integer to a REAL value uses this formula:

(MaxSpan – MinSpan)
Real Value = ------------------------------------------------------------------------- × (Modbus Value – Modbus Min) + Minspan
(Modbus Max – Modbus Min)

This figure depicts how scaling is done. Values above the Max Span or below the Min Span are
clamped to the respective limit. The same principle applies to values outside the Modbus range.
Real
Value
Triconex controller scales Integer to REAL

Max Span
Min Span
16-bit Integer
Modbus Modbus (Modbus Value)
Min Max
Scaling REAL Values to Integer Values

This figure depicts how a Modbus master reads a REAL value which has been scaled to an
integer.
Triconex Controller
Modbus Master
Numeric Range: 0 to 32767 Real Value

in Alias
Modbus Read
Modbus Integer 15337 Scaling
Scaling a REAL value to an integer value uses this formula:

(Modbus Max – Modbus Min)
Modbus Value = ------------------------------------------------------------------------- × (Real Value – MinSpan) + ModbusMin
(Maxspan – MinSpan)

This figure depicts how scaling is done. Values above the Max Span or below the Min Span are
clamped to the respective limit. The same principle applies to values outside the Modbus range.
16-bit Integer
Triconex controller scales REAL to Integer

Modbus
Max
Modbus
Min
Real Value
Min Span Max Span
Scaling REAL Values to Integers

This procedure explains how to scale a REAL value to an integer. Scaling may be needed to
transmit numbers through Modbus protocol which uses 16-bit integer numbers. Numbers are
scaled by using minimum (Min Span) and maximum (Max Span) values for the point and
minimum and maximum values for the Modbus Range.
Procedure
1 Open the TriStation project and open the Setup (Configuration) screen for the
communication module to be used.
2 Specify the Modbus Range Minimum and Maximum values.
The Minimum can be -32,768 or higher; the Maximum can be 32,767 or lower.
3 Click OK to save the settings.
4 For each tagname to be scaled, open the tagname and click the Scaling (Min/Max) tab to
display the scaling properties.
5 Ensure the Disable scaling check box is not checked. By default, the option is not
checked.
6 Enter the Minimum Value to be used to scale the REAL number to an integer; must be
less than the maximum value. The default is -32768.0.
7 Enter the minimum value to be used to scale the REAL number to an integer; must be
less than the maximum value. The default is 32767.0.
8 Enter the Precision (decimal places) to display.
9 Save the settings.
10 Repeat for each REAL tagname to be scaled.

How Trident REAL Values are Transmitted Without Scaling

This section explains how 32-bit REAL unscaled numbers are transmitted in Modbus protocol,
which uses 16-bit integers. This only applies to Trident controllers.
If a REAL value is not scaled, these operations occur:
• A Modbus master reads the least significant 16 bits of a 32-bit number which is derived
from the integer and decimal parts of a 32-bit REAL value.
• A Modbus master writes a REAL value as two consecutive 16-bit integer aliases which
the Trident concatenates to form a 32-bit REAL value.
This figure depicts the standard format for REAL values, which adheres to the IEE Standard for
Binary Floating-Point Arithmetic. For more information, see IEE Std 754-1985.
Tagname
Aliases 45001 or 35001 45002 or 35002
Byte 0 1 0 1
Bit 31 22 15 0
8-bit exponent 23-bit fraction
Sign of Fraction
Disabling Scaling of REAL Values for Trident Tagnames

This procedure explains how to disable scaling on a specific REAL tagname.
The default setting is to use scaling.
Procedure
1 In TriStation go to a tagname that is not to be scaled and open the Properties screen.
2 Click the Scaling (Min/Max) tab to display the scaling properties.
3 Ensure the Disable Scaling check box is checked.
4 Save the setting by clicking Apply or OK.

Sample Modbus Programs

Sample Modbus projects are included on the TriStation CD. These programs show how to use
the Modbus Read and Write function blocks for transmitting aliased data, how to set time-out
and retry values for Modbus communication, and how to control the flow of data from slave to
master.
Reading and Writing DINT Data

These programs show how to read and write N values of type DINT from Port P, Station S,
starting at specified aliases.
• MB_EX1_READ_DINT_FBD
• MB_EX4_WRITE_DINT_FBD
Reading and Writing REAL Data

These programs show how to read and write N values of type REAL from Port P, Station S,
• MB_EX2_READ_REAL_FBD
• MB_EX5_WRITE_REAL
Reading and Writing BOOL Data

These programs show how to read and write N values of type BOOL from Port P, Station S,
• MB_EX3_READ_BOOL_FBD
• MB_EX6_WRITE_BOOL
Setting Time-Out and Retry Values

The MB_EX7_CONTROL program shows how to use the MBCTRL function block to set time-
out and retry values for the communications initiated by a Modbus master port.
Controlling the Flow of Data

The MB_EX8_FLOW_CONTROL program shows how to control the flow of data from a
Modbus slave to a Modbus master.
Counting Values and Verifying Outputs

These programs count the number of errors, reads and writes, time-outs, and other values; and
verify the consistency of outputs.
• MB_READ_TEST
• MB_WRITE_TEST

7
Related Communication Features
Overview 98
Trident Write Access 99
Printing from a Trident Controller 104

98 Chapter 7 Related Communication Features
Overview
This chapter describes the time synchronization and printing features that can be used with
Triconex controllers.
Time Synchronization protocol allows networks of Tricon and Trident controllers to be
synchronized with each other, and optionally, with external devices.
Network printing protocol allows a Trident controller to print messages by means of a print
server connected to an Ethernet port on the CM. The print server must be compatible with the
JetDirect network printing protocol, and the printer must be compatible with the print server.
An Ethernet hub might also be needed. A TriStation application must include print function
blocks to send messages to a printer.

Trident Write Access 99
Trident Write Access

This section describes the system properties, communication properties, and function blocks
that affect read and write access to memory and output points on a Trident controller.
These types of read and write access are possible:
• Input, output, and memory points can be read by any external device that can
communicate with a Trident controller.
• Write access to input points is not allowed from any external device.
• Write access to a output or memory point is allowed or restricted based on the system,
communication, application, and point settings.
This table describes write access to Trident points from external devices.
Property or Feature Description

Disable Remote Changes to A system setting on the MP Operating tab that determines write
Outputs access to output points.
When checked, external devices cannot write to output points,
no matter what other settings are made.
SYS_SET_REMOTE_WRT_ENBL A Trident function block that programmatically allows or
restricts write access to output or memory read/write aliased
points when used in an application.
To allow write access, the Disable Remote Changes to Outputs
property cannot be checked.
Privilege A Trident CM module setting that determines whether network
devices using DDE, OPC, or TSAA communication have write
access to output points and read/write aliased memory points.
For Trident CM, the default is Read/Write.
This setting does not affect Modbus access.
Point Assignment A tagname setting that determines whether the output and
memory point is assigned a Read or Read/Write alias number.
For output points, all alias numbers are Read/Write.
For memory points, alias numbers can be Read or
Read/Write.

Tagnames and Aliases

This section describes tagnames, which is the word commonly used when referring to input
points (sensors) and output points (final elements). In TriStation 1131, tagnames are references
to physical tagnames (labels) on the connected field devices or to memory points which are
locations in the controller memory. In IEC terminology, tagnames are called global variables.
For Modbus or DDE communication, tagnames must be assigned an alias number that allows
read or read/write access. An alias number is a five-digit identifier which defines the data type
and location of a point in the controller memory.
For Peer-to-Peer, OPC, or a TSAA applications, tagnames can be accessed by the tagname.
For more information about tagnames and aliases, see the TriStation Developer’s Guide.
Access by Access by
Protocol or Application
Tagname Alias
Modbus Master 3
Modbus Slave 3
Peer-to-Peer (Triconex) 3
OPC Server, OPC Data Manager, and OPC Redundancy Broker 3 3
DDE Server 3
User-Written TSAA Application 3 3

If you have multiple Triconex controllers on an Ethernet network, you can synchronize their
time with:
• The master node (the controller with the lowest node number)
• An external device, such as an OPC client, that writes time values to a TriStation project
• A combination of the master node and an external device
These sections provide more information about these strategies and instructions for setting the
Triconex controller clock and setting time synchronization properties on the communication
modules.
Master Node in a Network

In a network of Triconex controllers, the master node determines the time for all controllers that
are synchronized with it.
The master node is the controller with the lowest node number. For example, in a network of
five controllers which have node numbers 1, 2, 3, 4, and 5, Node 1 is the master node. If Node 1
goes down, Node 2 becomes the master node. When Node 1 comes back online, it again becomes
the master node.
In a typical Triconex network, the controllers are synchronized with the master node within
plus or minus 25 milliseconds. When a controller is synchronized with the master node, it rejects
time adjustment attempts from all other sources.
You must use Ethernet ports on CM modules to synchronize Trident controllers in a network
with the master node. For instructions, see Setting Time Synchronization Properties (page 103).
In a network of Triconex controllers, all controllers with low node

CAUTION numbers should be configured for time synchronization. If a Triconex
controller becomes the master node but is not configured for time
synchronization, none of the controllers in the network can be
synchronized.
Time Adjustments from External Devices

A Triconex controller can receive time adjustments from external devices such as a DCS or an
OPC client. When the OPC Server application is used, the OPC client can adjust the Triconex
clock using the Device Clock tagname which is derived from Triconex system status
information in the OPC Server Configuration. For more information, see the user’s manual for
the OPC client application you are using.
Another way for an external device to adjust the Triconex controller clock is to write aliased data
to the TIMESET or TIMEADJ function blocks in the TriStation application. This can be done
though an Ethernet port or a serial port. If you need assistance with the specialized
programming that is required, please contact Technical Support.

To allow an external device to adjust the Triconex clock, you must configure a CM for time
synchronization, and you must configure the TriStation project to allow write access. For
instructions, see these sections:
• Setting Time Synchronization Properties (page 103)
• Trident Write Access (page 99)
Combination Schemes
In a typical configuration, Triconex controllers on a network are synchronized with the master
node. In addition, the master node can accept time adjustments from an external device so that
the external time prevails for all controllers on the network. Examples of external time sources
are an OPC client and a DCS.
Guidelines for Networks

These guidelines apply to Triconex controllers in a network whose time is synchronized with
an external device:
• Every controller to be synchronized must have its Ethernet port configured for time
synchronization, including the master node.
• If a controller is synchronized with the master node, it rejects time adjustment attempts
from all other sources.
• In a redundant network of Triconex controllers that each have two CM modules
installed, you can implement redundant time synchronization by selecting the time
synchronization property for both CM modules in TriStation.
In a network of Triconex controllers, all controllers with low node

CAUTION numbers should be configured for time synchronization. If a controller
becomes the master node but is not configured, none of the controllers can
be synchronized.
Setting the Controller Clock

This procedure explains how to set the Triconex controller clock to the correct local time, which
is important if you are using time synchronization strategy. When an application is downloaded
and run, the controller automatically sets the clock to the PC time. You can reset the clock at any
time while the application is running, without having to download again. The need for accuracy
depends on the application.
Procedure
1 On the TriStation PC, ensure the time is set correctly. Usually, this is done from a setting
on the PC Control Panel.
2 In TriStation, open the project and connect to the controller.
3 From the Commands menu, select the Set Calendar Clock command and click Yes when
the prompt asks whether you want to Set Calendar Clock the current configuration.

The Triconex clock is now set to the PC time, that is, to the correct local time.
Setting Time Synchronization Properties

This procedure explains how to synchronize Triconex controllers in a network with the master
node or an external device. To do so, you can use Ethernet ports (Net1 or Net2) on CM modules.
Setting Time Synchronization for a CM

1 Open the TriStation project, go to the CM Network tabs screen, and select one of these
options for time synchronization.
On Net1 enable time synchronization with Trident master node

This option should be selected if the controller is connected to the network through the Net1
port on the CM.
On Net2 enable time synchronization with Trident master node

This option should be selected if the controller is connected to the network through the Net2
port on the CM.
None
This option applies if you do not want to synchronize the controller with the master node. If
None is selected, the controller can receive time adjustments from an external device such as an
OPC client or a DCS.

Printing from a Trident Controller

A Trident controller can send brief ASCII text messages to a printer by means of a print server
connected to an Ethernet port on a CM. The Ethernet port (Net1 or Net2) must be configured for
the Open Network mode. The print server must be compatible with the HP JetDirect network
printing protocol and the printer must be compatible with the print server.
To send messages to a printer, a TriStation application must include standard print function
blocks. Print messages are typically used for alarms, status and maintenance. A sample alarm
message might include the name of an analog input point, its timestamp and value, and a
statement that the value is out of range.
Alarm printing is an economical solution for a closed Triconex system which includes only four
or five modules. When the Triconex system is larger or connected to a DCS, alarms are typically
displayed by an operator workstation.
The printing devices you can use with a Trident controller include an HP JetDirect-compatible
print server, a printer, and a router or hub. You must use TriStation to specify a number for the
printer and a TCP/IP port address for the print server.
Printing and Scan Time

The printing feature of a Triconex controller is designed for small printing loads, that is, critical
messages which are printed only if specific events or alarms occur. Each time a message is
printed, the print function blocks in the TriStation application are executed and the scan time
increases.
Typically, the print function blocks are subject to conditional execution which means they are
not executed every scan. When you set the scan time in TriStation, make sure it includes the
execution times for all conditional statements in the application.
If the scan time is not long enough, the execution of all conditional statements (when the
conditions are true) could result in scan-time overruns. You can minimize this problem by
limiting the amount of printer output. If this is not possible due to application requirements,
you should use an event logger on a PC for printing. Triconex provides the SOE Recorder utility
for this purpose which is described in the SOE Recorder User’s Guide.

Printing Setup
If used, a print server must be connected to an Ethernet (Net1 or Net2) port on the CM that is
configured for the Open Network mode. A printer must be connected to the print server—it
cannot be connected directly to a CM port. These figures show the basic printing configurations.
Directly Connecting a Print Server to the CM
Trident Controller
Centronics-Compatible Print Server CM
Printer
Ethernet
Standard Cross-over Cable
Printer Cable
MP
Connecting a Print Server to a Hub
Print Server Trident Controller
Centronics-Compatible
Printer
Ethernet CM
Standard
Hub
Printer Cable
Ethernet Cable
Ethernet Cable
MP
Other Network
Connections
Selecting Printing Devices

At a minimum, the printing devices you can use with a Trident controller are an HP JetDirect-
compatible print server and a line printer for ASCII text.
Print Server and Cables

The print server used with the Trident controller must use the HP JetDirect print protocol and
operate at speeds of 10 or 100 megabits per second. Standard communication cables are suitable
for connecting your printing devices to the Trident controller. For information about cables
available from Triconex, see Triconex Communication Cables (page 7).

You can purchase communication cables from other manufacturers. You must purchase print
servers elsewhere because Triconex does not supply them. Black Box cables and Hewlett-
Packard print servers are examples of dependable network printing devices.
Triconex has tested the following Hewlett-Packard print servers and found them to be effective:
• HP JetDirect Ex Plus
• HP JetDirect 500X Series, model J3265A
Printers
Select a printer that is compatible with your print server. The Trident controller prints ASCII
text only, which does not include formatting or graphics, so a Centronics-compatible printer is
adequate. Laser printers are also suitable.
Installing Printer Devices

Most printers and print servers require configuration with an install program on a workstation
or other device. For each device, follow the instructions provided by the manufacturer, and run
the diagnostic routine if one is included with the package.
To print from a Triconex controller, the printer driver that comes with the printer package is not
needed. The TriStation project must identify the target printer, and the print server, using the
CM Configuration dialog box, as explained in these section.
Configuring a Trident CM for Printing

This procedure explains how to configure a Trident CM port that is connected to a print server
and printer. This should be done after you have installed the print server and printer.
Procedure
1 In the TriStation project, go to the Printer tab on the CM Network tab.
2 Specify the Slot Selection, Left or Right, where the CM is installed.
3 Specify the Modes as Open Network (Workstation TCPIP).
4 Click the Printer tab and specify these properties as needed.
Configured or Not Configured

Click the Configured for the slot where the CM is installed.
Printer Number
Enter a number from 1 to 10. This must be the same number that is declared for the PRINTER
parameter in print function blocks.

Line Width
Enter the maximum printable line width for your printer, based on the manufacturer’s
specifications.
The most typical printer widths are 80 characters and 132 characters.
Line Width
Under Print Server, enter the TCP/IP Port number that was defined by the manufacturer of the
print server.
TCP Port
Enter the TCP/IP port number that was defined by the manufacturer of the print server.
An HP JetDirect print server with one port uses TCP/IP port number 9100.
An HP JetDirect print server with three ports uses TCP/IP port numbers 9100, 9101, and
9102.
IP Address
Enter the 32-bit IP address of the print server on the network.
If the print server is not on the same subnet as the Trident controller, you must specify the
destination address on the Routing tab of the CM Setup screen.
Using Print Function Blocks

A TriStation application must use print function blocks in order to send ASCII messages to a
printer. These print function blocks are available.
Print Function Block Purpose

PRINT_BOOL Prints a three-character field containing either Off or On.
PRINT_CDT Prints the current date and time.
PRINT_CRLF Prints a new line (carriage return and line feed).
PRINT_CTOD Prints the current time of day.
PRINT_DINT Prints a DINT value.
PRINT_REAL Prints a REAL value.
PRINT_STRING Prints a string of text.
PRINTR_FLUSH Clears the print buffer.


A
Communication Module Capabilities
CM Operation 110
Physical Description 112

110 Appendix A Communication Module Capabilities
CM Operation
The CM is an optional module for the Trident controller which supports multiple message
protocols and physical media types. Ports on the CM can communicate with TriStation, other
Trident or Tricon controllers, Ethernet devices, and Modbus master and slave devices.
The Trident controller supports a left and right CM on one baseplate. The CM Baseplate must
be connected directly above or below the MP Baseplate. Two baseplate interconnects are
required to connect the MP Baseplate to the CM Baseplate. For more information about
mechanical installation, see the Trident Planning and Installation Guide.
The left and right CM operate independently. Each can be connected to a separate network, or
both can be used in a redundant configuration.
Message Handling
This figure depicts how message handling works. The CM ports communicate with the three
MP modules by means of the Comm Bus. Each CM supports two Comm Buses—a left bus and
a right bus—so that a fault on one CM does not affect the other CM.
A message received by a CM port is passed to all three MP modules over the Comm Bus. The
TriBus votes on the message before sending it to the MP modules for processing, and sends the
response back to the Comm Bus after processing is complete. The Comm Bus then forwards the
response to the CM port.
802.3 TriStation
Modbus
RS-232/RS-485
MP A
TriBus
TriBus
TriBus
MP B MP C
802.3 TriStation 802.3 TriStation

Modbus RS-232/RS-485
Modbus
RS-232/RS-485
Net 1 802.3 - 10BaseT
Left Net 2 802.3 - 10BaseT/100BaseTX
Position Serial 1
CM Serial 2
Serial 3
Comm
Bus Leg C Net1 802.3 - 10BaseT
Comm Bus Leg B Right Net 2 802.3 - 10BaseT/100BaseTX
Position Serial 1
CM Serial 2
Comm Bus Leg A Serial 3

CM Operation 111
The CM and MP modules handle message types as follows.
TriStation, Peer-to-Peer, and Time Synchronization Messages

1 Receives the message and transmits it to the MP modules over the Comm Bus
2 Votes the message request with other MP modules over TriBus
3 Receives the message from the Comm Bus, processes the message and transmits a
response
Modbus and TSAA Read Queries

1 Receives the read query
2 Gets the requested alias from the Comm Bus voted data pool
3 Transmits the response
Modbus and TSAA Write Commands

1 Receives the write request and transmits it to the MP modules over the Comm Bus
2 Votes the write request with the other MP modules over TriBus
3 Receives the message from the Comm Bus, processes the message, and transmits a write
confirmation response
Typical Message Response Time

Because most messages (excluding Modbus and TSAA read queries) require TriBus voting,
typical message response times require three or more scans to complete.

Physical Description
For the left and right CM, the CM Baseplate includes these ports:
• Three RS-232/RS-485 serial ports which are TriStation-configurable for RTU or ASCII
and Modbus master, slave, or combination master/slave
• One Ethernet (Net1) port which operates at 10 megabits per second
• One Ethernet (Net2) port which operates at 10 or 100 megabits per second
• Two connectors for Media Adapter Units (MAU) which can be used to convert media
types or extend network distances
The Debug port is for Triconex use and is not associated with either the left or right CM.
Left Module
Serial 3
Serial 2
Serial 1 PASS
FAULT
PASS
FAULT
ACTIVE ACTIVE
Right Module
Serial 3
Serial 2
NET1 Left Module
Serial 1 AUI MAU
NET1 Right Module

NET1 Left Module AUI MAU
10BaseT
NET1 Right Module LOCK LOCK
10BaseT
COMMUNICATIONS COMMUNICATIONS
TX TX
SERIAL SERIAL
RX RX
NET2 Left Module SERIAL

TX
SERIAL
TX
10BaseT/100BaseTX RX RX
TX TX
SERIAL SERIAL
NET2 Right Module RX RX
10BaseT/100BaseTX NET 1
LINK
TX NET 1
LINK
TX
RX RX
LINK LINK
NET 2 TX NET 2 TX
RX RX
CM 3201 CM 3201
Debug NET2 Right Module MII MAU
NET2 Left Module MII MAU
Figure 3 CM Baseplate

Types of Ports
Serial Ports
A CM provides three optically isolated RS-232/RS-485 serial ports which are TriStation-
configurable for point-to-point or multi-point serial connections. Transmission rates up to 115.2
kilobits per second per port can be selected.
Ethernet Ports
A CM provides two Ethernet ports with RJ-45 sockets for connection to twisted-pair cables:
• Net1—A 10BaseT connector which can operate only at 10 megabits per second.
• Net2—A 10BaseT/100BaseTX connector which can operate at 10 or 100 megabits per
second.
MAU Connections
To convert Ethernet ports to other media types or to extend network distances using fiber optic
cabling, the CM provides four MAU connections for use in place of the 10BaseTor 100BaseT
connectors. Fiber optic cabling can be directly connected to the TriStation PC or an Ethernet
device by crossing over the fiber optic cable or connecting it to a fiber optic hub. The MAU
connections allow the Net1 and Net2 ports to support the following media types and distances.
Net1 Ports
• AUI 10Base-FL single-mode fiber optic with a range of 14 kilometers
• AUI 10Base-FL multi-mode fiber optic with a range of 2 kilometers
• AUI 10Base2 thin-net 50-ohm coax with a range of 185 meters (useful for Peer-to-Peer
connection with Tricon controllers)
Net2 Ports
• MII 10BaseFX to 100BaseFX single-mode fiber with a range of 14 to 20 kilometers
• MII 1BaseFX to 100BaseFX multi-mode fiber with a range of 2 kilometers
Note When a MAU is physically installed and configured in the TriStation project, the
corresponding 10BaseT or 100BaseTX connector is disabled.

Debug Port
The CM Baseplate includes one RJ-12 connector in the lower left corner. This connector, covered
when not in use, is intended for Triconex use as a Debug port. This port provides access to
diagnostic information for both the left and right CM. For more information, contact Triconex
Technical Support.
Specifications
Parameter Description
Type RS-232 C
Connector RJ-12 with 6 pins:
Pins 1-3 — left position
Pins 4-6 — right position
Debug Baud rate 9600
Protocol ASCII
8-bit
1 stop bit
No parity
Galvanic Isolation 500 V DC

CM Front Panel
The CM front panel includes status and communication indicators. For information about the
communication indicators, see CM Communication Indicators (page 116). For information
about the other indicators, see the Trident Planning and Installation Guide.
Pass (Green)
PASS
CM Status FAULT Fault (Red)
Indicators ACTIVE
Active (Yellow)
LOCK
Unlock (Red)
COMMUNICATIONS
TX
SERIAL Serial 1 (Green/Green)
RX
TX
SERIAL Serial 2 (Green/Green)
RX
TX
Communication SERIAL Serial 3 (Green/Green)
RX
Indicators
LINK NET1 Link (Green)
NET1 TX
NET1 TX/RX (Green/Green)
RX
LINK NET2 Link (Green)

NET2 TX
NET2 TX/RX (Green/Green)
RX
CM 3201
Figure 4 CM Front Panel

CM Communication Indicators
The CM communication indicators identify the type of communication occurring on the Trident
controller. The TX light indicates the CM is transmitting a message and the RX light indicates
the CM is receiving a message.
This symbol ( — ) means the indicator is not important for this condition.
Serial 1 Serial 2 Serial 3 Net1 Net2

RX/TX RX/TX RX/TX Link RX/TX Link RX/TX Description
Green — — — — Normal response. CM is
blinking communicating with the
attached Modbus
master/slave device.
— Green — — — Normal response. CM is
attached Modbus
— — Green — — Normal response. CM is
attached Modbus
— — — Green Green — — CM is communicating
steady blinking with TriStation or with
an Ethernet device
through the Net1 port.
— — — — — Green Green CM is communicating
steady blinking with TriStation or with
an Ethernet device
through the Net2 port.

Protocols Supported by CM Ports

The CM supports these protocols on Ethernet and serial ports.
Ethernet Ports
Protocol Serial Ports
(Net1 and Net2)
TriStation 3
TSAA 3
Peer-to-Peer 3
Modbus Slave 3
Modbus Master 3
Modbus Master/Slave 3
Network Printing 3
For summary information about the protocols, see Chapter 1, Introduction For detailed
information, see the related chapter and appendices.


B
Main Processor Capabilities
MP Operation 120

120 Appendix B Main Processor Capabilities
MP Operation
A Trident controller must include a Main Processor (MP) Baseplate which holds three MP
Modules. The MP Baseplate provides three DB-9-pin ports for connecting Modbus master
devices and three 10BaseT ports for connecting to TriStation PCs.
Each MP serves as one channel of the Triple Modular Redundant (TMR) Trident controller and
consists of two CPU sections.
One section, called the System Executive (SX), does these tasks:
• Executes the downloaded TriStation application
• Manages TriBus communication and voting
• Manages TriStation and Modbus communication over MP ports
• Processes information from the Communication Module (CM)
• Performs system diagnostics
The other CPU section, called the Input/Output Executive (IOX), does these tasks:
• I/O module ASIC communication
• I/O control
• I/O diagnostics
The three MP modules communicate with each other by means of an inter-processor bus called
TriBus, which is a high-speed, fault-tolerant communication path used primarily for voting and
diagnostics. The three MP modules communicate with the I/O modules over a TMR, RS-485
I/O bus which operates at 2 megabits per second. The MP modules communicate with the CM
over an RS-485 COMM bus, processing all messages received by the CM except Modbus and
TSAA read queries.
The MP Baseplate provides redundant system alarm contacts and redundant, fused logic power
connectors for the MP and I/O modules.
For more information about MP modules, see the Trident Planning and Installation Guide.

MP Operation 121
Message Handling
This figure depicts how message handling works. The MP ports communicate with the three
MP modules by means of the TriBus. A message received from one MP port is passed to the
other MP modules over TriBus before the message is acted upon, which means communication
requests come from TriBus and are voted before they are processed. The TriStation port on MP
A is redundant with the TriStation ports on MP B and MP C. The serial port on MP A is
redundant with the serial ports on MP B and MP C. If communication redundancy is not
required, only one MP port must be connected to ensure successful TriStation or Modbus
communication among all three MP modules.
In each scan of the control program, a five-millisecond time slot is reserved for communication
message handling and other background tasks. If an MP cannot completely process a message
and generate a response within the five-millisecond time slot, it completes the message in the
next scan within the five-millisecond time slot. This strategy guarantees that variations in
communication traffic for the MP ports do not affect the scan time of the TriStation application.
802.3
TriStation
Modbus
RS-232/RS-485
MP A
TriBus
TriBus
Tribus
MP B MP C
802.3 TriStation 802.3 TriStation
Modbus Modbus
RS-2323/RS-485 RS-232/RS-485
Comm To Communication Modules

Bus Leg C
Comm Bus Leg B
Comm Bus Leg A
The MP modules manage these types of messages.
TriStation Messages
1 Receives message, transmits to other MP modules over TriBus
2 Votes message request with other MP modules over TriBus
3 Processes message and transmit response
Modbus Read Queries

1 Receives the read query
2 Gets the requested alias from TriBus voted data

3 Transmits the response
Modbus Write Commands

1 Receives the write request, transmits to other MP modules over TriBus
2 Votes the write request with other MP modules
3 Transmits write confirmation response
Typical Message Response Time

Because all messages except Modbus read queries require TriBus voting, typical message
response times require three or more scans to complete.

Physical Description
The MP Baseplate includes these ports:
• Three serial (Modbus slave) ports which can be configured for the RS-232 or RS-485
transceiver mode.
• Three Tristation ports for connecting the TriStation PC using DLC protocol.
• Three Debug ports for Triconex use.
Left Modbus Port
Middle Modbus Port
Right Modbus Port
Left, Middle, and

Right TriStation Ports
Left, Middle, and

Right Debug Ports

Serial Ports
The serial ports on the MP Baseplate consist of DB-9-pin sockets, as shown in this figure.
Left
Serial Port
Middle
Serial Port
Right
Serial Port
COMMUNICATIONS
TX
IO BUS
RX
TX TX TX
COMM BUS COMM BUS COMM BUS
RX RX RX
TX TX TX
SERIAL SERIAL SERIAL
RX RX RX
LINK LINK LINK

TRISTATION TX TRISTATION TX TRISTATION TX
1 RX RX RX
MP3101 MP3101 MP3101
Specifications
Feature Description
Socket type DB-9-pin DTE standard, shielded, located on baseplate
RS-232 maximum cable length 50 feet (15 meters)
RS-485 maximum cable length 4,000 feet (1.2 kilometers)
Transmission rates (bps) 1200, 1400, 2400, 4800, 19200, 38400, 57600, or 115200-
Configuration options Slave, RTU mode, optional parity, 1 stop bit
Galvanic isolation 500 V DC

TriStation Ports
The TriStation ports on the MP Baseplate consist of 10BaseT sockets, as shown in this figure.
Left TriStation Port RX
TX TX
COMM BUS COMM BUS
Middle TriStation Port RX RX
TX TX TX
SERIAL SERIAL SERIAL
Right TriStation Port RX RX RX
LINK LINK LINK

TRISTATION TX TRISTATION TX TRISTATION TX
Address Plug for 1 RX RX RX
TriNode Address MP3101 MP3101 MP3101
Figure 5 TriStation Ports on MP Baseplate
Specifications
Feature Description
Socket type 10BaseT, RJ-45 standard, shielded, located on baseplate
10BaseT maximum cable length 330 feet (100 meters) using category 5 twisted-pair cable
Protocol TriStation
Node address (configured in the Derived from address plug on MP Baseplate
TriStation project)
Galvanic isolation 500 V DC

Debug Ports
The debug ports on the MP Baseplate consist of RJ-12 6-pin sockets in the lower left corner, as
shown in this figure. These sockets, covered when not in use, are intended for Triconex use as
diagnostic tools. They provides access to diagnostic information for both the MP and the
associated I/O Processor. For more information, please contact Triconex Technical Support.
Left Right
Debug Port Middle Debug Port
Debug Port
Specifications
Feature Description
Socket Type RJ-12 with 6 pins:
Pins 1-3 are for the MP
Pins 4-6 are for the IOP
Transceiver Mode RS-232 C
Transmission rate (bps) 9600
Communication Option ASCII
8-bit
1 stop bit
No parity
Galvanic Isolation 500 V DC

MP Front Panel
The MP front panel includes status, mode, alarm, and communication indicators as shown in
this figure. For information about the communication indicators, see MP Communication
Indicators (page 128).
For information about the other indicators, see the Trident Planning and Installation Guide.
Pass (Green)
PASS
MP Status FAULT Fault (Red)
Indicators
ACTIVE
Active (Yellow)
MODE Remote Mode (Green)

REMOTE
System Mode Run Mode (Green)
RUN
Indicators PROGRAM Program Mode (Yellow)
HALT
Halt Mode (Yellow)
ALARMS Field Power (Red)

FIELD POWER
Logic Power (Red)
LOGIC POWER
Alarm
Indicators SYSTEM ALARM System Alarm (Red)
PROGRAM ALARM
OVER TEMPERATURE
Program Alarm (Blue)
Over Temperature (Red)
LOCK
Unlock (Red)
COMMUNICATIONS
TX
IO BUS
RX
TX/RX I/O Bus (Green/Green)
TX
COMM BUS TX/RX Communication Bus (Green/Green)
RX
Communication
Indicators TX
SERIAL TX/RX Modbus (Green/Green)
RX
LINK Link TriStation(Green)

TRISTATION TX
RX
TX/RX TriStation (Green/Green)
MP3101
Figure 6 MP Front Panel

MP Communication Indicators
The MP communication indicators identify the type of communication occurring on the
controller. The TX light indicates the MP is transmitting a message and the RX light indicates
the MP is receiving a message.
This symbol ( — ) means the indicator is not important for this condition.
I/O Bus Comm Bus Serial TriStation

RX/TX RX/TX RX/TX Link RX/TX Description
Green — — — — Normal response. MP is polling and
blinking sending responses to the I/O modules.
— Green — — — Normal response. MP is polling and
blinking sending responses to the CM modules.
— — Green — — Normal response. MP is polling and
blinking sending responses to the Modbus
master.
— — — Green Green MP is communicating with TriStation.
steady blinking
— — — No — MP is not communicating with
light TriStation or a network hub.
Note: The hub or Ethernet card in the
TriStation computer has a link
indicator that shows whether a
hardware connection has been
established with the MP.

C
TSAA Protocol
Overview 130
TSAA Messages 132
Response Codes 157

130 Appendix C TSAA Protocol
Overview
Triconex System Access Application (TSAA) protocol is a messaging protocol which provides
message formats used in application programs that read and write data to Triconex controllers.
TSAA is based on a client/server model which allows a client to request information from an
external device using a server application.
You can use TSAA to develop these types of applications:
• Control (Read/Write) Applications, such as an operator interface station, that require
access to the status of the Triconex controller and the ability to write data to the
controller
• Monitor (Read-Only) Applications, such as SOE Recorder, that receive data from the
controller
Byte Ordering in Messages

This table identifies the type of ordering used in the message fields.
Message Field Description

Frame Header Big-endian order for both Tricon and Trident.
Data Little-endian order for Tricon; big-endian order for Trident.
CRC Little-endian for both Tricon and Trident.
If the controller and PC use different ordering types, the application might need to convert data
to the appropriate order.
Little-Endian Order
In little-endian ordering, the data is ordered from right to left with the most significant bits and
bytes to the right.
Bit Ordering for Bit Fields
Bit 32 ... Bit 3 Bit 2 Bit 1 Bit 0
Byte Ordering for 16 Bit Variables
Byte 1 Byte 0
Byte 3 Byte 2 Byte 1 Byte 0

Overview 131
Big-Endian Order
In big-endian ordering, the data is ordered from the left to right with the most significant bits
and bytes to the left.
Bit Ordering for Bit Fields
Bit 0 Bit 1 Bit 2 Bit 3 ... Bit 32
Byte 0 Byte 1
Byte 0 Byte1 Byte 2 Byte 3
Symbol Table Information

The symbol table includes information about TriStation 1131 variables, Modbus alias numbers,
bin numbers, and offset. This information is required when data is read or written to the
controller. The symbol table is downloaded to the controller with the TriStation 1131
application.
Symbol table information can be retrieved in these ways:
• For Tricon and Trident, by exporting the information from TriStation 1131. For more
information, see the Export Points command in the TriStation 1131 Developer’s Guide.
• For Trident only, by retrieving the information from the controller with the TSAA
message TRICON_GET_SYMBOL_REQ.

TSAA Messages
A TSAA message is a request made by a client or a response made by the Triconex controller.
This section describes the format of TSAA messages and the available types of messages. In this
document, the words frame and message mean the same thing—a unit of data that is transmitted
through a network.
• UDP protocol is the only supported protocol.

CAUTION • The Tricon NCM and Trident CM modules use port 1500 for all TSAA
communication. Using any other port may cause problems.
Message Format
Each TSAA message adheres to a format which includes these fields:
• A frame header which identifies the message (big-endian order)
• A data area which contains the frame message (little-endian order for Tricon;
big-endian for Trident)
• A 32-bit Cyclic Redundancy Check (CRC) (little-endian order for Tricon and Trident)
Frame Header Data Area CRC

8 bytes variable length 4 bytes
Note Unless otherwise specified, fields in messages are unsigned.
Frame Header
The frame header in a TSAA message includes these fields.
Type nodeNumber seqNum version flag id length

1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 2 bytes
Type
The Type field in the frame header identifies the message type. These types of TSAA messages
are available.
Request
Triconex
Type Message Type Description from
Response
Client
TRICON_DATA Returns data in response to a
1 3
type 2 message.
TRICON_DATA_REQ Requests data from the
2 3
TriStation application.

TSAA Messages 133
Request
Triconex
Response
Client
WRITE_TRICON_DATA Requests the controller to write
3 to memory and output variables 3
in the TriStation application.
WRITE_TRICON_DATA_RSP Responds to a request to write to
4 memory and output variables by 3
a type 3 message.
READ_TRICON_CLOCK Requests the current time on the
5 3
controller clock.
READ_TRICON_CLOCK_RSP Returns the current time on the
6 controller clock in response to a 3
type 5 message.
SET_TRICON_CLOCK Requests setting of the controller
7 3
clock.
SET_TRICON_CLOCK_RSP Responds to a request to set the
8 3
clock made by a type 7 message.
ADJUST_TRICON_CLOCK Requests controller to adjust
9 3
clock forward or backward.
ADJUST_TRICON_CLOCK_RSP Responds to a request to adjust
10 the clock made by a type 9 3
message.
READ_TRICON_DATA Requests data (memory, input,
11 or output variables) to be read 3
from the TriStation application.
READ_TRICON_RSP Returns variable data in
12 3
response to a type 11 message.
TRICON_SOE_REQ Requests SOE (sequence of
13 3
events) data from the controller.
TRICON_SOE_RSP Returns SOE data in response to
14 3
a type 13 message.
TRICON_CPSTATUS_REQ Requests the TriStation
application name and version
15 number. 3
For Triconex internal use only.

TRICON_CPSTATUS_RSP Returns program information in
16 response to a type 15 message. 3
For Triconex internal use only.

Request
Triconex
Response
Client
TRICON_SOE_DATAAVAIL Sends a message to the client
when SOE data is available. The
message is sent when SOE data
17 3
is put into an empty SOE block
and every 10 seconds while there
is data available in any block.
TRICON_GET_SYMBOL_REQ Requests part of a symbol table
22 from the controller. 3
For Trident only.
TRICON_GET_SYMBOL_RSP Sends part of a symbol table as
23 requested by a type 22 message. 3
For Trident only.
nodeNumber
The nodeNumber field identifies the destination node number for the message which is the
node number for the Triconex controller.
seqNum
The seqNum field identifies the number of the message in a multiple-message response. This
field can help determine if there are missing messages.
version
The version field identifies the version number of the protocol used by the sender:
• For Tricon, the number must be 0.
• For Trident, the number must be 1.
flag
The flag field is a bit field that indicates the position of the frame in a multi-frame message, or
that the message is a single frame.
• 0x00 identifies a mid-frame of a multi-frame message.
• 0x01 identifies the first frame of a multi-frame message.
• 0x02 identifies the last frame of a multi-frame message.
• 0x03 identifies a single frame message.
id
The id field assigns a number to a request and associated response. If a client makes periodic
requests of the same message type and wants to associate them with the responses, this field can
be used to assign an identifier. The request and response use the same identifier.

TSAA Messages 135
length
The length field identifies the length of the frame excluding the CRC32 field.
TRICON_DATA (Type 1)
A TRICON_DATA message replies to a request for data made by a TRICON_DATA_REQ (type
2) message. If the client sends a data request at least once every two minutes, the controller
continues sending data responses at the interval specified by the request.
If more than one client sends a TRICON_DATA_REQ to a controller, the

CAUTION controller response changes to a UDP broadcast which is sent to all the
clients. If the client connects on a port other than 1500, broadcast data may
be lost when a second client sends a data request.
This message includes these fields.
Frame_Hdr Data_Hdr Bin (1) Header Bin (2) Header... CRC

8 bytes variable length varies varies 4 bytes
Data_Hdr
The Data_Hdr field includes these fields.
numberOfBlocks rfu SymbolTableVersion

2 bytes 2 bytes 4 bytes
reserved (Trident only)
numberOfBlocks
The numberOfBlocks field identifies the number of blocks in the data portion of the message.
SymbolTableVersion (Trident Only)

The SymbolTableVersion field identifies the TriStation application version. If the version is 1.0,
this is 0x00010000.
The SymbolTableVersion field is only available for Trident controllers.
Bin Headers
A TRICON_DATA (Type 1) message can have multiple bin headers followed by bin data. Each
bin header includes these fields.

bin rfu totalLength offset length BinTime

1 byte 1 byte 2 bytes 2 bytes 2 bytes 8 bytes
reserved (Trident only)
bin
The bin field identifies which bin holds the message data, using a numeric value to represent
the variable type and data type.
Table 3 For Tricon

Bin Aliases Variable Type Data Type
0 1 - 2000 Output BOOL (Discrete)
1 2001 - 4000 Memory BOOL (Discrete)
2 10001 - 12000 Input BOOL (Discrete)
4 30001 - 31000 Input REAL (Analog)
5 31001 - 32000 Memory DINT (Integer)
7 33001 - 34000 Memory REAL (Analog)
8 14001 - 19999 system status BOOL (Discrete)
9 39631 - 39999 system status DINT (Integer)
10 40001 - 40250 Output REAL (Analog)
13 Not applicable Number of bins
Table 4 For Trident .
Bin Variable Type Data Type

0 Output BOOL (Discrete)
1 Memory BOOL (Discrete)
2 Input BOOL (Discrete)
4 Input REAL (Analog)
5 Memory DINT (Integer)
7 Memory REAL (Analog)
10 Output REAL (Analog)

TSAA Messages 137
Table 4 For Trident

totalLength
The totalLength field indicates the length of the bin.
offset
The offset field identifies the starting position of the requested data in the bin.
• For discrete data types, the offset is the number of bits.
• For integer and real data types, the offset is the number of 32-bit words.
length
The Length field contains the length of the data returned in the message.
binTime (Trident only)

The binTime field identifies the time stamp associated with the bin data in microseconds since
1970.
The binTime field is only available to Trident controllers.
TRICON_DATA_REQ (Type 2)
A TRICON_DATA_REQ message requests one or more bins of data from a Triconex controller.
The controller responds with a TRICON_DATA (type 1) message. If the client sends a data
request at least once every two minutes, the controller continues sending data responses at the
interval specified by the request.
The data request message is designed for applications that require all of the data in one or more
bins. After the request is sent, the controller continuously sends data responses to the client at
specified intervals. The client cannot stop the controller from sending data, but the controller
will stop sending data if a data request is not received again within two minutes.
If you use TCP protocol (or UDP protocol with connect and disconnect functions), you must
leave the connection open for a minimum of two minutes after sending this request. If the
application requires specifying the range of data, use READ_TRICON_DATA (type 11).
Frame_Hdr Data_Req_Hdr CRC

8 bytes variable length 4 bytes

Data_Req_Hdr
The Data_Req_Hdr field contains these fields.
binsRequested reqTime
2 bytes 2 bytes
binsRequested
The binsRequested field is a binary mask that identifies which bins of data the Triconex
controller should send.
If the request includes an invalid bin number, the response is a bin header with no data.
Binary Mask Description

0x1fff Masks all bins
0x0001 Masks discrete output
0x0002 Masks read/write discrete
memory
0x0004 Masks discrete input
0x0008 Masks read-only discrete
memory
0x0010 Masks analog input
0x0020 Masks read-only integer memory
0x0040 Masks real input
0x0080 Masks read-only real memory
0x0100 (Tricon only) Masks discrete system status
0x0200 (Tricon only) Masks integer system status
0x0400 Masks analog output
0x0800 Masks read/write integer
memory
0x1000 Masks read/write real memory
reqTime
The reqTime field indicates the time in milliseconds between broadcasts of the requested bins.
For example, a value of 1,000 causes a Triconex controller to broadcast the data once per second.
If this value is zero (0), the controller broadcasts the data each time the ACM or NCM (Tricon)
or CM (Trident) is updated.

TSAA Messages 139
WRITE_TRICON_DATA (Type 3)
A WRITE_TRICON_DATA message requests the Triconex controller to write data to output
and memory variables in the TriStation application. These conditions must be met for the
controller to accept this request:
• The variables must be defined as read/write.
• For Tricon, the keyswitch must be in the Program or Remote position. For Trident, the
Remote mode must be enabled by setting a system attribute.
• The TriStation configuration setting (Disable Remote Changes to Outputs) which was
downloaded to the controller must allow remote changes. (This setting only affects
changes to discrete outputs and analog outputs.)
• The TriStation configuration for the ACM or NCM (Tricon) and CM (Trident) must be
configured as read/write.
If the controller cannot write the data, it sends a reject response code. For more information, see
Response Codes (page 157).
Frame_Hdr Write_Hdr Write_Data ... Write_Data CRC

8 bytes 4 bytes varies varies 4 bytes
Write_Hdr
The Write_Hdr contains these fields.
numberOfBlocks rfu
2 bytes 2 bytes reserved
numberOfBlocks
The numberOfBlocks field indicates the number of write data blocks for the message type.
Write_Data
The Write_Data field includes these fields.
binNumber rfu offset numberOfValues Values

1 byte 3 bytes reserved 2 bytes 3 bytes varies
binNumber
The binNumber field indicates the number of the bin to be changed.

offset
numberOfValues
The numberOfValues field indicates the number of variables to be written starting at the
specified offset.
Values
The Values field contains the values for the variables to be changed. Discrete variables require
one byte each for the new value (0 or 1).
WRITE_TRICON_DATA_RSP (Type 4)
A WRITE_TRICON_DATA_RSP message replies with a success or failure code to a request to
write data sent by a WRITE_TRICON_DATA (type 3) message.
Frame_Hdr responseCode subReason rfu CRC

8 bytes 1 byte 1 byte 2 bytes reserved 4 bytes
responseCode
The responseCode field indicates the success or failure of the request. A value of zero (0)
indicates the request was successfully completed.
For more information, see Response Codes (page 157).
subReason
The subReason field contains additional information about the failure of the request.
READ_TRICON_CLOCK (Type 5)
A READ_TRICON_CLOCK message requests the current time on the Triconex controller. The
controller responds with READ_TRICON_CLOCK_RSP (type 6) which sends the current time
to the client.
There are no fields specific to this message.
Frame_Hdr CRC
8 bytes 4 bytes

TSAA Messages 141
READ_TRICON_CLOCK_RSP (Type 6)
A READ_TRICON_CLOCK_RSP message sends the current controller time to the client in
response to a READ_TRICON_CLOCK (type 5) request.
Frame_Hdr Read_Clock_Resp CRC

Read_Clock_Rsp
The Read_Clock_Rsp field includes these fields.
responseCode subReason rfu relSec milliSec rfu2

1 byte 1 byte 2 bytes reserved 4 bytes 2 bytes 2 bytes
ResponseCode
subReason
relSec
The relSec field indicates the current Triconex system time expressed in relative seconds.
• For Tricon, relative seconds are seconds past 00:00 January 1, 1970 based on local time.
• For Trident, relative seconds are seconds past 1970 based on universal time (Greenwich
Mean Time). (2000 is the earliest date and 2050 is the latest date.)
milliSec
The milliSec field indicates the millisecond portion of the Triconex system time.
SET_TRICON_CLOCK (Type 7)
A SET_TRICON_CLOCK message requests the time to be set on the Triconex controller. The
controller responds with a SET_TRICON_CLOCK_RSP (type 8) message.
These conditions must be met for the controller to accept this request:
• For Tricon, the keyswitch must be in Program mode.

• For Trident, the operational mode must be set to Program.

For Tricon only, the controller does not allow an application or an external device to set the time
continuously. At least five minutes must pass before the controller responds to a
SET_TRICON_CLOCK message. If the application sends this message before five minutes pass,
the message is rejected.
Frame_Hdr Set_Clock CRC

Set_Clock
The Set_Clock field includes these fields.
relSec milliSec rfu

4 bytes 2 bytes 2 bytes reserved
relSec
The relSec field contains the controller system time expressed in relative seconds.
milliSec
The milliSec field contains the millisecond portion of the system time.
SET_TRICON_CLOCK_RSP (Type 8)
A SET_TRICON_CLOCK_RSP message replies with a success or failure code to a
SET_TRICON_CLOCK (type 7) message.
Frame_Hdr Set_Clock_Rsp CRC

Set_Clock_Rsp
The Set_Clock_Rsp field contains these fields.

TSAA Messages 143
responseCode subReason rfu

1 byte 1 byte 2 bytes reserved
responseCode
subReason
ADJUST_TRICON_CLOCK (Type 9)
An ADJUST_TRICON_CLOCK message requests the time to be adjusted on the Triconex
controller either forward or backward. The controller responds with an
ADJUST_TRICON_CLOCK_RSP (type 10) message.
These conditions must be met for the controller to accept this request:
• For Tricon, the keyswitch must be in Program mode.
• For Trident, the operational mode must be set to Program.
For Tricon only, the controller does not allow an application or an external device to set the time
continuously. At least five minutes must pass before the controller will respond to a
SET_TRICON_CLOCK message. If the application program sends this message before five
minutes pass, the message is rejected.
Frame_Hdr Adjust_Clock CRC

Adjust_Clock
The Adjust_Clock field includes these fields.
AdjustSeconds AdjustMilliseconds
4 bytes signed 4 bytes signed
AdjustSeconds
The AdjustSeconds field contains the number of seconds to adjust the controller clock either
forward or backward.

AdjustMilliseconds
The AdjustMilliseconds field contains the number of milliseconds to adjust the controller clock
either forward or backward.
ADJUST_TRICON_CLOCK_RSP (Type 10)

An ADJUST_TRICON_CLOCK_RSP message replies with a success or failure code to an
ADJUST_TRICON_CLOCK (type 9) message.
Frame_Hdr Adjust_Clock_Rsp CRC

Adjust_Clock_Rsp
The Adjust_Clock_Rsp field contains these fields.
responseCode subReason rfu

1 byte 1 byte 2 bytes reserved
responseCode
subReason
READ_TRICON_DATA (Type 11)

A READ_TRICON_DATA message requests variable data from the Triconex controller. The
controller responds with the requested data using one or more READ_TRICON_RSP (type 12)
messages depending on the amount of data requested.
Frame_Hdr Read_Hdr Read_Data CRC

8 bytes 4 bytes 6 bytes 4 bytes
Read_Hdr
The Read_Hdr field includes these fields.

TSAA Messages 145
numberOfBlocks rfu
2 bytes 2 bytes reserved
numberOfBlocks
The numberOfBlocks field indicates the number of Read_Data blocks for this message.
Read_Data
The Read_Data field includes these fields.
binNumber rfu offset numberOfValues

1 byte 3 bytes reserved 2 bytes 2 bytes
binNumber
The binNumber field contains the number of the bin to be read.
offset
If the numberOfValues field is zero (0), this field is ignored.
numberOfValues
The numberOfValues field contains the number of variables to be read from the bin. If the
number is zero (0), all of the data in the bin is returned.
READ_TRICON_RSP (Type 12)

A READ_TRICON_RSP message responds to a request to read data on the controller made by
a READ_TRICON_DATA (type 11) message. The controller sends one or more of these
messages depending on the amount of data requested.
Frame_Hdr Read_Rsp_Hdr Read_Data_Rsp Data ... CRC

8 bytes 4 bytes 12 bytes varies 4 bytes
Read_Rsp_Hdr
The Read_Rsp_Hdr field includes these fields.

responseCode subReason numberOfBlocks

1 byte 1 byte 2 bytes
responseCode
subReason
numberOfBlocks
The numberOfBlocks field indicates the number of Read_Data_Rsp blocks in the message.
Read_Data_Rsp
The Read_Data_Rsp field includes these fields.
binNumber rfu offset relSec milliSec numberOfValues

1 byte 1 byte reserved 2 bytes 4 bytes 2 bytes 2 bytes
binNumber
The binNumber field contains the number of the bin to be read.
offset
The offset field contains the number of variables from the beginning of the bin.
relSec and milliSec

The relSec field contains the controller time stamp for bin data expressed in relative seconds.
The milliSec field contains the millisecond portion of the controller time stamp.

TSAA Messages 147
numberOfValues
The numberOfValues field indicates the number of variables that are read starting at the
specified offset.
Data
The Data field contains data from the bin.
• For Tricon, the data is ordered in little-endian format.
• For Trident, the data is ordered in big-endian format.
For more information about Trident data, see Symbol Table Information (page 131).
TRICON_SOE_REQ (Type 13)

A TRICON_SOE_REQ message requests the Triconex controller to send event data collected in
an SOE block. The controller responds with a TRICON_SOE_RSP (type 14) message.
Frame_Hdr Soe_Req CRC

Soe_Req
The Soe_Req field includes these fields.
soeNumber firstFlag ackFlag rfu1 getIndex rfu2 wrapCount generation

1 byte 1 byte 1 byte 1 byte reserved 2 bytes 2 bytes 4 bytes 4 bytes
soeNumber
The soeNumber field contains the SOE block number which can be 1 to 16. (SOE blocks are
configured in TriStation.)
firstFlag
The firstFlag field indicates whether this is the first data request for this SOE block. This value
should be set to one (1) for the first request. For all subsequent requests, it should be set it to zero
(0).
ackFlag
The ackFlag field indicates whether the last TRICON_SOE_RSP message was received correctly.
If the message was received correctly, set the field to one (1). If not, set it to zero (0).

getIndex
The getIndex field is a pointer into the SOE data block that indicates the start of the data being
requested.
wrapCount
The wrapCount field indicates the number of times the buffer has been filled since the last time
the TriStation application issued an SOECLR command for this block.
generation
The generation field indicates the number of times the TriStation application has issued the
SOECLR command.
TRICON_SOE_RSP (Type 14)

A TRICON_SOE_RSP message responds to a TRICON_SOE_REQ (type 13) request by sending
data from the SOE block.
The values for the getIndex, wrapCount, and generation fields may not match the numbers
requested because their values change depending on how frequently you request data and
whether events are occurring.
Frame_Hdr Soe_Rsp Entry Entry ... CRC

8 bytes 16 bytes 8 bytes 8 bytes 4 bytes
Soe_Rsp
The Soe_Rsp field includes these fields.
soe response sub numberOf next wrap

rfu generation
Number Code Reason Entries Index Count
1 byte 1 byte 1 byte 1 byte 2 byte 2 bytes 4 bytes 4 bytes
soeNumber
The soeNumber field indicates the number of the SOE block.
responseCode

TSAA Messages 149
subReason
The subReason field identifies the subcode for the request. Used for debugging.
numberOfEntries
The numberOfEntries field indicates the number of entries in the response. There are two types
of entry: time stamp and event data. For more information, see entry (SOE Data Entry)
(page 149) and entry (SOE Time Stamp) (page 151).
getIndex
The getIndex field is a pointer into the SOE data block and is the beginning of the transferred
data stream.
nextIndex
The nextIndex field is a pointer into the SOE data block that indicates the start of the data being
requested.
wrapCount
The wrapCount field indicates the number of times the buffer has been filled since the last time
generation
The generation field indicates the number of times the TriStation application has issued the
SOECLR command.
entry (SOE Data Entry)

The entry field for an SOE data entry includes these fields.
offset dataType bin type soeNumber value

16 bits 3 bits 5 bits 3 bits 3 bits 32 bits
offset
The offset field contains the number of variables from the beginning of the bin.
dataType
The type field identifies the data type of the SOE entry with a numeric value.

Data Type Value

BOOL (Discrete) 0
DINT (Integer) 1
REAL (Analog) 2
bin
The bin field identifies which bin holds the message data, using a numeric value to represent
the variable type and data type.
For Tricon
Bin Aliases Variable Type Data Type

0 1 - 2000 Output BOOL (Discrete)
2 10001 - 12000 Input BOOL (Discrete)
8 14001 - 19999 system status BOOL (Discrete)
9 39631 - 39999 system status DINT (Integer)
10 40001 - 40250 Output REAL (Analog)
For Trident

0 Output BOOL (Discrete)
2 Input BOOL (Discrete)

TSAA Messages 151

10 Output REAL (Analog)
type
The type field indicates whether the entry is an SOE time stamp or an SOE data entry.
• If 1, the entry is a time stamp.
• If 2, the entry is a data entry.
soeNumber
The soeNumber field identifies the SOE block number.
value
The value field contains the value of the aliased variable. If On, it is 0x00000001; if Off, it is
0x00000000.
entry (SOE Time Stamp)

The entry fields for an SOE time stamp include these fields.
microseconds reason type soeNumber seconds

20 bits 4 bits 3 bits 5 bits 32 bits
microseconds
The microseconds field contains the microseconds part of the time stamp which can be from 0
to 999,999.
reason
The reason field indicates the reason a time stamp entry was made. The reasons are described
in these table.
Value Reason
1 SOESTRT command processed.
2 SOESTOP command processed or buffer full for First Out block.

Value Reason
3 SOECLR command processed.
4 Event has been detected. It can be collected from the Entry field of the TRICON_SOE_RSP
message.
type
The type field indicates whether the entry is an SOE time stamp or an SOE data entry.
• If 1, the entry is a time stamp.
• If 2, the entry is a data entry.
soeNumber
The soeNumber field identifies the SOE block number.
second
The second field contains the seconds part of the time stamp which can be from 0 to 59.
TRICON_CPSTATUS_REQ (Type 15)

A TRICON_CPSTATUS_REQ message requests the TriStation application name and version
number from the Triconex controller. This message does not require any data. The controller
responds with a TRICON_CPSTATUS_RSP (type 16) message.
This message type is for Triconex internal use only.
TRICON_CPSTATUS_RSP (Type 16)

A TRICON_CPSTATUS_RSP message replies to the request for TriStation application name and
version number made by a TRICON_CPSTATUS_REQ (type 15) message.
This message type is for Triconex internal use only.
TRICON_SOE_DATAAVAIL (Type 17)

A TRICON_SOE_DATAAVAIL message sends a message to the client when SOE data is
available. The message is sent when SOE data is put into an empty SOE block and every 10
seconds while there is data available in any block. This is a broadcast message.
Frame_Hdr SoeDataAvail CRC


TSAA Messages 153
SoeDataAvail
The SoeDataAvail field includes these fields.
putIndex firstIndex size state rfu wrapCount generation

2 bytes 2 bytes 2 bytes 1 byte 1 byte reserved 4 bytes 4 bytes
putIndex
The putIndex field contains a pointer to the last data available in the SOE data block.
firstIndex
The firstIndex field contains a pointer to the beginning of the available data in the SOE data
block.
size
The size field contains the number of entries in the block. The block size is specified in
TriStation.
state
The state field contains a number representing the status of the SOE block.
The states include:
0 Block is not defined or block is not started.
1 Block is collecting.
2 Block is stopped or cleared.
3 Block is full.
wrapCount
The wrapCount field contains the number of times the buffer has been filled since the last time
generation
The generation field contains the number of times the TriStation application has issued the
SOECLR command.
TRICON_GET_SYMBOL_REQ (Type 22, Trident Only)

A TRICON_GET_SYMBOL_REQ message requests a part of the symbol table from the Trident
controller. When the controller receives this message, it sends a TRICON_GET_SYMBOL_RSP
(type 23) message to the client.

This message type is only available for Trident controllers.

The symbol table can be large, up to 1.2 megabytes, which means you may have to download
the table in parts and then assemble the table on the client. The client can then parse the symbol
table (after correcting endian) and extract all the relevant information related to a symbol.
Frame_Hdr Tricon_Get_Symbol CRC

Tricon_Get_Symbol
The Tricon_Get_Symbol field includes these fields.
totalSize offset CRC

totalSize
The totalSize field must be set to zero (0).
offset
The offset field identifies the starting position of the requested data in the symbol table.
TRICON_GET_SYMBOL_RSP (Type 23, Trident Only)

A TRICON_GET_SYMBOL_RSP message sends symbol table data requested by a
TRICON_GET_SYMBOL_REQ (type 22) message.
This message type is not available to Tricon controllers.
To find the starting address for a tagname, use this equation:
Location of tag name = Starting_Address_of_Symbol_Table + sizeof(Tricon_Symbol_Table)
+
sizeof(Tricon_Symbol_Entry) *
Tricon_Symbol_Table::numberOfEntries) + Tricon_Symbol_Entry::nameOffset;

TSAA Messages 155
Symbol_Table Tricon_Symbol Tricon_Symbol Check

Frame_Hdr Symbol_names
_Rsp _Table _Entry sum
8 bytes 20 bytes 12 bytes each 12 bytes variable size—null 4 bytes
terminated ASCII
strings
Symbol_Table_Rsp
The Symbol_Table_Rsp field includes these fields.
responseCode subReason rfu totalSize offset length symbolVersion

1 byte 1 byte 2 bytes reserved 4 bytes 4 bytes 4 bytes 4 bytes
responseCode
subReason
The subReason field identifies the sub code for the request. Used for debugging.
totalSize
The totalSize field identifies the total size of the symbol table.
offset
The offset field identifies the starting position of the requested data in the symbol table.
Length
The Length field contains the length of the data returned.
symbolVersion
The symbolVersion field contains the version of the symbol table which is the same TriStation
application version.
After conversion to little endian format on the client PC, this is a 32 bit number with this format:
MMMMnnn: where MMMM is the 16 bit major version number and nnnn is the TriStation
application minor version number.

Tricon_Symbol_Table
The Tricon_Symbol_Table field includes these fields.
Number of Entries String Offset Checksum

4 bytes 4 bytes reserved 4 bytes reserved
Number of Entries
The number of Tricon_Symbol_Entry structures in the table.
String Offset
Reserved.
Checksum
Reserved.
Tricon_Symbol_Entry
The Tricon_Symbol_Entry field includes these fields.
Bin No Modbus
Name Offset Bin Number rfu Alias
Offset conversion Station
4 bytes 1 byte 1 byte reserved 2 bytes 1 byte 1 byte 2 bytes
Name Offset
The Name Offset field identifies the starting position of the name string for this entry.
Bin Number
The Bin Number identifies the bin number of the entry.
Bin Offset
The Bin Offset field identifies the starting position of the entry in the bin.
No Conversion
Reserved for Triconex use.
Modbus Station
Reserved for Triconex use.
Alias
The Alias field identifies the alias number for the entry.

Response Codes 157
Response Codes
Every response sent by a Triconex controller in reply to an external device includes a code which
indicates the result of the request. A response code of zero (0) indicates the message was
successful. Other codes indicate specific errors.
Code Description
0 Request was successful.
1 No buffer available to process the request. Retry the request.
2 Bin number specified in the request was not in the range from 0 to12.
3 The Tricon NCM or Trident CM module is busy processing previous
requests and cannot accept another request. This can happen if more
than four WRITE_TRICON_DATA requests are outstanding at one
time.
4 No MP is running.
5 TSX has rejected the request. The subReason field contains the specific
reason.
6 Request to TSX timed out.
7 Invalid response from TX.
8 Message was too big.
9 Offset or numberOfValues in the request was invalid.
10 No control program (TriStation application).
11 Read-only port.
236 Bad SOE number.
237 Invalid SOE type.
238 Invalid SOE state.


D
Modbus Protocol
Overview 160
Message Response Time 161
Modbus Messages 162
Modbus Functions 168
Transmission Errors and Exception Conditions 176

160 Appendix D Modbus Protocol
Overview
This appendix provides detailed information about Modbus protocol, which is a
communication protocol used with serial ports to transmit data between a Modbus master and
slave. Modbus protocol includes functions which define the message format for the query and
response.
Query-Response Sessions
Modbus communication is a query-response session, in which the Modbus master initiates a
query and a Modbus slave responds. In Modbus communication, a serial link transmits data in
both directions, but in only one direction at a time.
A query-response session consist of these actions:
• The master sends a query to a slave.
• The master starts a fail-safe timer while it waits for the slave response. Typical slave
response time is in hundreds of milliseconds.
• The slave returns a response to the master.
• The master waits until it has received the response from the slave before sending
another query.
• If there is a slave response timeout, the master will retry the query. The number of
retries and the timeout interval is configured by the MBCTRL function block.

Message Response Time 161
Message Response Time

This section explains how to estimate the message response time, which is the total time for
preparing, transmitting, receiving, and processing a Modbus query. Function blocks that are the
least and most affected by scan time increases are also identified in this section.
Topics include:
• Determining Message Response Time (page 161)
• Modbus Functions and Scan Time (page 162)
Determining Message Response Time

This table explains how to estimate the number of milliseconds required for the message
response time on a Triconex controller acting as a Modbus slave.
Modbus Operation Equation or Constraints

Prepare Query (master) Varies depending on the specific Modbus function (message) and any
other program processing
Transmit Query (master) (1000 ÷ Baud Rate) x Bits per Characters x Number of Characters
Receive and Process Query Tricon EICM slave:
Writes: 3 x Scan Time
Reads: 10 milliseconds
Trident MP slave:
Reads: 2 x Scan Time
Trident CM slave:
Reads: 10 milliseconds
Transmit Response (slave) (1000 ÷ Baud Rate) x Bits per Characters x Number of Characters
(in milliseconds)
Process Response (master) Depends on customer provided equipment performance.
(in milliseconds)
Time-Out and Retry Values Varies depending on settings for the MBCTRL function block, which
determines the time-out and retry values which can increase the
message time.
Message Response Time = the sum of all the results.

Modbus Functions and Scan Time

Modbus performance degrades slightly as the scan time of the controller increases.
When the controller acts as a slave, the functions most affected by scan time increases are:
• Force Single Coil (Function Code 05) (page 171)
• Preset Single Register (Function Code 06) (page 172)
• Force Multiple Coils (Function Code 15) (page 174)
• Preset Multiple Registers (Function Code 16) (page 175)
The functions least affected by scan time increases are:
• Read Coil Status Function (Function 01) (page 168)
• Read Input Status (Function 02) (page 169)
• Read Holding Registers (Function Code 03) (page 170)
• Read Input Registers (Function Code 04) (page 170)
Modbus Messages
This section describes the Modbus messages (query and response functions) supported by
Triconex communication modules. The serial ports on Triconex communication modules
support several Modbus message formats and functions (queries and responses).
Topics include:
• Communication Modes (page 162)
• Function Names and Aliases (page 163)
• Modbus Message Formats (page 163)
• Sample Query and Response Messages (page 165)
• Modbus Message Lengths (page 166)
Communication Modes
A Modbus serial link must use either the Remote Terminal Unit (RTU) or ASCII mode of
communication. If both modes are available, you should choose RTU because it is more efficient
and robust than ASCII. Each serial port can use a different communication mode, assuming that
each port is connected to a separate Modbus master or slave device. If you configure a port for
combination Modbus master and slave operation, you must use RTU mode.
RTU Mode
In RTU mode, data is sent in 8-bit binary characters. Gaps between characters cannot exceed
three character times (the time it takes to send a character). RTU mode uses a 16-bit cyclic
redundancy check (CRC) to detect transmission errors.

Modbus Messages 163
ASCII Mode
In ASCII mode, data is transmitted in pairs of ASCII characters. The first character is the ASCII
representation of the most significant 4 bits of the corresponding RTU character. The second
character is the ASCII representation of the least significant 4 bits of the corresponding RTU
character. For example, the RTU character 010011112 (4F16)is sent as the two ASCII characters 4
and F (3416 and 4616). Each ASCII message has a colon at the beginning and a carriage return and
line feed at the end. Gaps between characters in an ASCII message are not significant.
Function Names and Aliases

The starting address field of a Modbus message ranges from 0 to one less than the number of
coils or registers available.
A Trident CM or MP serial port maps the Modbus starting address field to an alias by adding a
constant determined by the function code, as shown in this table.
Function Name Code Coil or Register Constant

Read Coil Status 01 Coil 1
Read Input Status 02 Coil 10001
Read Holding Registers 03 Register 40001
Read Input Registers 04 Register 30001
Force Single Coil 05 Coil 1
Preset Single Register 06 Register 40001
Read Exception Status 07 Coil n/a
Loop Back Diagnostic Test 08 Register n/a
Force Multiple Coils 15 Coil 1
Preset Multiple Registers 16 Register 40001
Modbus Message Formats

For each Modbus function, the message formats for RTU and ASCII modes are depicted as
shown in these figures.
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station Function
Data Data CRC
Address Code
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station Function
: Data Data LRC CR LF
Address Code

Message Header Field (ASCII Only)

The Message Header in ASCII mode is a colon (:) and is required. There is no message header
in RTU mode.
Station Address Field

The Station Address field identifies the station to which a query is directed or the station that is
sending a response. In RTU mode, the station address has one character (eight bits). In ASCII
mode, the station address has two characters.
The range for station addresses is 1 through 247. Each station connected to a Modbus serial link
must have a unique address. Station address 0 (zero) is the broadcast address and addresses all
slaves. When a slave receives a query with the broadcast address, the slave processes the query
but does not send a response.
Function Code Field

The Function Code field identifies the operation to be performed (the query), or the operation
that was performed (the response). If the most significant bit of the function code in a response
is 1, the response is an exception response. For more information, see Exception Responses
(page 177).
Data Fields
The Data fields contain information that is specific to the query or response. The length of the
data varies, depending on the function code.
Checksum Field (CRC or LRC)

The Checksum field is a 16-bit word which is a CRC in RTU mode or an LRC in ASCII mode.
The error check is performed by both the transmitting and the receiving units to detect
transmission errors. For more information about error checking, see Transmission Errors
(page 176). These sections describe the error check calculations that are performed for CRC and
LRC.
CRC Error Check — RTU Mode

During a CRC error check, the CRC-16 polynomial is used to compute a checksum for the entire
message. The CRC-16 polynomial is:
x16 + x15 +x2 + 1
The CRC is computed across the station address, the function code, and the data and appended
to the end of the message.
LRC Error Check — ASCII Mode

The LRC checksum is an eight-bit binary number represented and transmitted as two ASCII
hexadecimal characters. The checksum is produced in this manner:

Modbus Messages 165
• The hex characters that comprise the content of a message are converted to binary
notation. The colon, carriage return, and line feed are ignored.
• The binary characters are summed without wrap-around carry.
• The resulting sum is negated.
This table shows how to calculate the LRC for the sample message presented earlier in this
chapter.
Table 5 Sample LRC Checksum Calculation
Message Content Checksum Calculation
Address 0 2 0000 0010
Function Code 0 1 0000 0001
Starting Address (H.O.) 0 0 0000 0000
Starting Address (L.O.) 1 3 0001 0011
Quantity of Points (H.O.) 0 0 0000 0000
Quantity of Points (L.O.) 2 5 + 0010 0101
0011 1011
One’s-Complement: 1100 0100
Add 1: + 0000 0001
Two’s-Complement: 1100 0101
Error Check C 5
CR Field and LF Field (ASCII Only)

The CR field contains an ASCII carriage return and the LF field contains an ASCII line feed.
Sample Query and Response Messages

This table shows the content of a sample query and response in RTU and ASCII modes. The
query is a Read Input Status (Function 02) requesting 37 (2516) points starting at point 20 (1316 +
1). The response packs the 37 points into five 8-bit bytes, and clears the three high-order bits of
the last byte.
Query Message RTU ASCII

Header None :
Station Address 0000 0010 0 2
Starting Address (High Order) 0000 0000 0 0
Starting Address (Low Order) 0001 0011 1 3

Query Message RTU ASCII

Number of Points (High 0000 0000 0 0
Order)
Number of Points (Low Order) 0010 0101 2 5
Error Check 0000 1100 C 5
0010 0111
Trailer None CR LF
Response Message RTU ASCII

Header None :
Station Address 0000 0010 0 2
Byte Count 0000 0101 0 5
Data Byte 1 11001 11012 C D
Data Byte 2 0110 1011 6 B
Data Byte 3 1011 0010 B 2
Data Byte 4 0000 1110 0 E
Data Byte 5 0001 1011 1 B
Error Check 0000 0100 E 5
1111 1111
Trailer None CR LF
1. The underscored digit indicates that Coil #27 is in the On state.

2. The underscored digit indicates that Coil #20 is in the On state.
Modbus Message Lengths

The length of a Modbus message depends on the function being used and whether the message
is a query or a response.
Function Number of RTU Number of ASCII

Query
Code Characters Characters
01 Read Coil Status 8 17
02 Read Input Status 8 17
Read Holding
03 8 17
Registers
Read Input
04 8 17
Registers

Modbus Messages 167

Query
05 Force Single Coil 8 17
Preset Single
06 8 17
Register
Force Multiple
15 9 + (1 per 8 coils) 19 + (2 per 8 coils)
Coils
Preset Multiple 19 + (4 per
16 9 + (2 per register)
Registers register)

Response
01 Read Coil Status 5 + (1 per 8 coils) 11 + (2 per 8 coils)
02 Read Input Status 5 + (1 per 8 coils) 11 + (2 per 8 coils)
Read Holding 11 + (4 per
Registers register)
Read Input 11 + (4 per
Register register)
05 Force Single Coil 8 17
Preset Single
06 8 17
Register
Force Multiple
15 8 17
Coils
Preset Multiple
16 8 17
Registers

Modbus Functions
This section includes details on Modbus functions.
Functions include:
• Read Coil Status Function (Function 01) (page 168)
• Read Input Status (Function 02) (page 169)
• Read Holding Registers (Function Code 03) (page 170)
• Read Input Registers (Function Code 04) (page 170)
• Force Single Coil (Function Code 05) (page 171)
• Preset Single Register (Function Code 06) (page 172)
• Read Exception Status (Function Code 07) (page 173)
• Loop-Back Diagnostic Test (Function 08) (page 173)
• Force Multiple Coils (Function Code 15) (page 174)
• Preset Multiple Registers (Function Code 16) (page 175)
Read Coil Status Function (Function 01)
Query Format
The Read Coil Status query requests the On/Off status of a group of logic coils from a station.
You can request the status of as many as 2,000 coils with each query, but some Modbus devices
have lower limits. The coils are numbered starting at 0; for example, coil 0 is alias 1, coil 1 is alias
2, and so forth.
The Read Coil Status query is also known as the Read Output Status query.
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
0000 0001 Starting Address Number of Coils CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: Address 0 1 Starting Address Number of Coils LRC CR LF
Response Format
The Read Coil Status response data is packed with one bit for each coil, where 1=On, and 0=Off.
The low-order bit of the first RTU character contains the status of the first coil. For coil quantities
that are not even multiples of eight, the last RTU character is zero-filled at the high-order end.

RTU Mode
Bytes
1 2 3 4 n n+1 n+2
Station 0000 0001 Data Length Data CRC
Address Data
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2 n+3 n+4
: Station 0 1 Data Length Data Data LRC CR LF

Address
Read Input Status (Function 02)
Query Format
The Read Input Status function operates in the same manner as Read Coil Status (Function Code
01), except that the status of digital inputs is obtained. Inputs are also numbered starting at 0.
For example, input status 0 is alias 10001, input status 1 is alias 10002, and so forth. You can
request the status of as many as 2,000 coils with each query, but some Modbus devices have
lower limits.
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station 0000 0010 Number of Input Points CRC
Address Starting Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: Address 0 2 Starting Addresses Number of Input Points LRC CR LF
Response Format
RTU Mode
Bytes
1 2 3 4 n n+1 n+2
Station
Address 0000 0010 Data Length Data Data CRC
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2 n+3 n+4
Station
: Address 0 2 Data Length Data Data LRC CR LF

Read Holding Registers (Function Code 03)
Query Format
The Read Holding Registers query requests the binary content of holding registers from a
station. You can request the status of as many as 125 registers with each query, but some
Modbus devices have lower limits. The registers are numbered beginning with 0. For example,
register 0 is alias 40001, register 1 is alias 40002, and so forth.
The Read Holding Registers query is also known as the Read Output Registers query.
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
Address 0000 0011 Starting Address Number of Registers CRC
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: Address 0 3 Starting Address Number of Registers LRC CR LF
Response Format
The Read Holding Registers response data consists of two bytes for each register queried, with
the binary content right-justified. The leftmost character includes the high-order bits, and the
rightmost character includes the low-order bits.
RTU Mode
Bytes
1 2 3 4 n n+1 n+2
Station
Address
0000 0011 Data Length Data Data CRC
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2 n+3 n+4
Station
: Address 0 3 Data Length Data Data LRC CR LF
Read Input Registers (Function Code 04)
Query Format
The Read Input Registers function operates in the same manner as the Read Holding Registers
query (Function Code 03), except that it obtains the status of input registers. You can request the
status of as many as 125 registers with each query, but some Modbus devices have lower limits.
The registers are numbered beginning with 0. For example, register 0 is alias 30001, register 1 is
alias 30002, and so forth.

RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station 0000 0100 Number of Registers CRC
Address Starting Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: Address 0 4 Starting Address Number of Registers LRC CR LF
Response Format
RTU Mode
Bytes
1 2 3 4 n n+1 n+2
Station
Address 0000 0100 Data Length Data Data CRC
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2 n+3 n+4
Station
: Address
0 4 Data Length Data Data LRC CR LF
Force Single Coil (Function Code 05)
Query Format
The Force Single Coil function turns a single coil On or Off, depending on its current state.
Because the slave is actively scanning, it can also alter the state of the coil (unless the coil is
disabled). Coils are numbered beginning with 0; for example, coil 0 is alias 1, coil 1 is alias 2, and
so forth.
A coil value of 65,280 (FF0016) turns the coil On, and a coil value of zero (000016) turns the coil
Off. All other values are illegal and do not affect the coil. If the query contains legal values, the
slave responds after the coil state has been altered.
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station 0000 0101 Coil Value CRC
Address Address to Modify
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
: Station 0 5 Address to Modify Coil Value LRC CR LF

Address

Response Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station 0000 0101 Coil Value CRC
Address Modified
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
: Station 0 5 Address Modified Coil Value LRC CR LF

Address
Preset Single Register (Function Code 06)

The Preset Single Register function modifies the content of one holding register. Because the
slave is actively scanning, it can also alter the register’s content. Register values are 16 bits.
Holding registers are numbered starting at 0; for example, register 0 is alias 40001, register 1 is
alias 40002.
Query Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station 0000 0101 Register Value CRC
Address Address to Modify
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
: Station 0 5 Address to Modify Register Value LRC CR LF

Address
Response Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
0000 0110 Address to Modify Register Value CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: 0 6 Address to Modify Register Value LRC CR LF
Address

Read Exception Status (Function Code 07)
Query Format
The Read Exception Status function returns the status of eight coils from the slave application
running in the controller. Which coils and what they represent depends on the slave. When a
serial port, configured as a slave, responds to this query, it sends the status of the first eight coils
(aliases 00001 through 00008) defined in the application. Coils are numbered from 0; for
example, coil 0 is alias 1, coil 1 is alias 2, and so forth. The status of each coil is packed in the data
field, one bit for each coil (1=On, 0=Off). You can program these coils to hold any type of
information; for example, machine on or off, heads retracted, safeties satisfied, and receipt-in-
process error conditions.
Note A CM serial port configured as a Modbus master cannot use the Read Exception Status
function.
RTU Mode
Bytes
1 2 3 4
Station
0000 0111 CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9
Station
: 0 7 LRC CR LF
Address
Response Format
RTU Mode
Bytes
1 2 3 4 5
Station Coil Data
0000 0111 CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11
Station
: 0 7 Coil Data LRC CR LF
Address
Loop-Back Diagnostic Test (Function 08)
Query Format
The Loop-Back Diagnostics Test query tests the communications link between the Modbus
master and slave. This query does not affect point values in the slave. When the serial port
acting as a slave receives this query, it re-transmits the query as the response.

RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
0000 1000 Data CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: 0 8 Data LRC CR LF
Address
Response Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
0000 1000 Data CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: 0 8 Data LRC CR LF
Address
Note A CM serial port configured as a Modbus Master cannot use the Loop-Back Diagnostic
Test function.
Force Multiple Coils (Function Code 15)
Query Format
The Force Multiple Coils query sets each coil in a consecutive block of coils to the specified state
(On or Off) regardless of whether the coils are enabled or disabled. Because the slave is actively
scanning, it can also alter the state of a coil (unless it is disabled). Coils are numbered from 0; for
example, coil 0 is alias 1, coil 1 is alias 2, and so forth. The status of each coil is packed in the data
field, one bit for each coil (1=On, 0=Off).
A single Force Multiple Coils query can set a maximum of 128 coils. The query-response time
required by some Modbus masters might require a much smaller quantity.
RTU Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2
Station Starting Byte Coil Coil
0000 1111 Quantity CRC
Address Address Count Data Data
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 n n+1n+2 n+3 n+4
: Address
0 F
Address
Quantity
Count
LRC CR LF
Data Data

Response Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 n n+1n+2 n+3 n+4
: Address
0 F
Address
Quantity
Count
LRC CR LF
Data Data
Preset Multiple Registers (Function Code 16)
Query Format
The Preset Multiple Registers query can change the contents of a maximum of 60 consecutive
holding registers, however, some Modbus devices have lower limits. Because the slave is
actively scanning, it can also alter the state of the registers (unless they are disabled). The values
are provided in binary code up to the maximum valid register value of the controller (16-bit for
Trident). Unused high-order bits must be set to zero. The registers are numbered beginning
with 0; for example, register 0 is alias 40001, register 1 is alias 40002, and so forth.
RTU Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2
Station Starting Byte Register Register
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 n n+1n+2 n+3 n+4
: Address
1 0
Address
Quantity
Count
LRC CR LF
Data Data
Response Format
RTU Mode
Bytes
1 2 3 4 5 6 7 8
Station
0001 0000 Starting Address Quantity CRC
Address
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Station
: 1 0 Starting Address Quantity LRC CR LF
Address

Transmission Errors and Exception Conditions

During Modbus communication, transmission errors and exception conditions can occur.
Transmission errors do not cause exception conditions and are not acknowledged by Modbus
slaves. Programming and operation errors do cause exception conditions which elicit exception
responses from slaves.
Topics include:
• Transmission Errors (page 176)
• Exception Conditions (page 176)
• Exception Responses (page 177)
Transmission Errors
The most frequent cause of transmission errors is noise. Noise sources include improperly
installed or broken connectors, damaged cables, electrical equipment such as generators and
elevators, and lightning. Transmission errors can be detected through the use of character
framing, parity checking, and redundancy checking.
When a slave detects a transmission error, it does not act on or respond to the message. The
master assumes a communications error has occurred if there is no response within a specified
time, usually three seconds.
Parity checking helps detect single-bit transmission errors. However, if there are two errors
within a single character, parity checking cannot detect a change. For example, if 1100 0100 is
distorted to 1111 0100, the number of 1 bits in the data is still odd.
Modbus protocol provides several levels of error checking in order to assure the accuracy of
data transmission. To detect multiple bit errors, the system uses cyclic redundancy check (CRC)
for RTU mode, or longitudinal redundancy check (LRC) for ASCII mode. For more information,
see Checksum Field (CRC or LRC) (page 164).
Exception Conditions
If a master detects an exception in a response to a query or does not receive a response, it takes
appropriate actions which usually include re-transmitting the query. This table lists exception
conditions that are returned by the slave if a programming or operation error causes a master
to send an incorrect query.
Exception Condition Description

Query Message CRC or The slave does not respond, because the error could be in the station
LRC Error address. The master uses its response fail-safe timer to recover.
Query Function Code The slave sends an Illegal Function (01) response code when it detects an
Error error in the function code field.
Query Address Error The slave sends an Illegal Data Address (02) response code when it detects
an error in the starting address field.

Transmission Errors and Exception Conditions 177
Exception Condition Description

Query Data Error The slave sends an Illegal Data Value (03) response code when it detects an
error in the data field.
Main Processors Not This exception applies only to serial ports which are configured as slaves.
Communicating If the slave port receives a query requiring a data exchange and it cannot
communicate with the Main Processors, it sends a Busy, Reject Message
(06) response code and turns off the Active indicator on the communication
module.
Remote Write Disabled The slave port sends a Busy, Reject Message (06) response code if a master
sends one of these queries and the slave port is not enabled for remote
(external) writes:
• Force Single Coil (Function Code 05)
• Preset Single Register (Function Code 06)
• Force Multiple Coils (Function Code 15)
• Preset Multiple Registers (Function Code 16)
Exception Responses
When a slave detects an exception condition, it sends a response message to the master
consisting of the slave’s station address, function code, error code, and error-check fields. To
indicate that the message is an exception response, the slave sets the high-order bit of the
function code to 1. The example shows an exception response to a Preset Multiple Registers
query.
Sample Query
RTU Mode
Bytes
1 2 3 4 5 6 7 8 n n+1 n+2
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 n n+1n+2 n+3 n+4
: Address
1 0
Address
Quantity
Count
LRC CR LF
Data Data

Sample Exception Response

RTU Mode
Bytes
1 2 3 4 5 6
Station Exception
1001 0000 CRC
Address Code
ASCII Mode
Bytes
1 2 3 4 5 6 7 8 9 10 11 12 13
Station Exception
: 9 0
Code
LRC CR LF
Address
Exception Response Codes

This table lists exception response codes which are sent by the slave after an invalid query.
Code Name Description

01 Illegal Function The requested function is not in the slave’s repertoire.
02 Illegal Data Address The alias in the query does not exist in the slave.
03 Illegal Data Value The value is not in the range allowed for the alias.
Failure in Associated Device The slave failed to respond to a message or an error that
04 occurred in the controller. When a master receives this
response code, it must issue a supervisory alert.
05 Acknowledge A slave port does not send this exception response code.
Busy, Rejected Message The query was received without error, but the slave cannot
06
comply.
07 Negative Acknowledge A slave port does not send this exception response code.
08 Memory Parity Error A slave port does not send this exception response code.

Glossary
10Base2
The standard for an Ethernet LAN capable of transmitting 10 megabits of data per second
through thin coaxial cables, to a maximum distance of 656 feet (200 meters).
10BaseT
The standard for an Ethernet LAN capable of transmitting 10 megabits of data per second
through twisted-pair wire.
100BaseTX
The predominant standard for a Fast Ethernet LAN capable of transmitting 100 megabits of data
per second through Category 5 twisted-pair cable only.
AUI
Attachment Unit Interface. A coaxial cable connected to a transceiver that plugs into a 15-pin
socket on the network interface card (NIC), to a maximum distance of 328 feet (100 meters).
ARP
Stands for Address Resolution Protocol which is a TCP/IP protocol used to obtain the physical
address of a node on an Ethernet network. A client station broadcasts an ARP request onto the
network with the IP address of the target node it wants to communicate with. The node with
that address responds by sending back its physical address so that packets can be transmitted
to it.
Centronics
A standard 36-pin parallel interface for connecting printers and other devices to a computer.
client/server
An architecture in which the client (PC or workstation) is the requesting machine and the server
is the supplying machine, both of which are connected by means of a local area network (LAN)
or wide area network (WAN).
closed network
A network designed for maximum safety which includes only Triconex devices. A Peer-to-Peer
network is an example of a closed network.
communication path
The route between any two nodes. Same as line, channel, link, or circuit.
communication protocol
Hardware and software standards that govern data transmission between two computers or
communications devices. There are several layers (levels) of functionality in a protocol. Each

180 Glossary
layer may be available as a separate software component, or several layers may be combined
into one.
CTS signal
In Modbus communication, an RS-232 signal sent from the receiving station to the transmitting
station which indicates it is ready to accept data.
data bits
The number of bits used to represent one character of data. When a Modbus slave transmits
ASCII text, either seven or eight bits can be used. When a Modbus master or slave uses the RTU
mode, eight data bits are required.
data transfer time

In a Peer-to-Peer network, the time required to initiate a send operation, send the data over the
network, and get an acknowledgment from the receiving controller.
default gateway
A router that forwards all messages not addressed to stations within the local subnet.
duplex
See full duplex and half duplex.
Ethernet
A type of computer network which is defined by the IEEE 802.3 standard. An Ethernet network
is typically a shared media LAN. All stations on the segment share the total bandwidth, which
is either 10 megabits (Ethernet), 100 megabits (Fast Ethernet) or 1,000 megabits (Gigabit
Ethernet) per second.
exception condition
In Modbus communication, a programming or operation error which involves an illegal or
illogical query by the master.
exception response
In Modbus communication, the response of a slave to a programming or operation error.
Fast Ethernet
Another name for 100BaseTX Ethernet communication. Fast Ethernet transmits data at 100
megabits per second rather than 10 megabits per second as in regular Ethernet. Fast Ethernet
operates in a LAN (local area network) that shares the 100 megabit per second bandwidth with
all transmitting stations.
full duplex
Serial communication using two pairs of wires—one pair for Modbus reads and the other pair
for Modbus writes. Called 4-wire in TriStation.
gateway
A computer that performs protocol conversion between different types of networks or
applications. For example, a gateway can convert a TCP/IP packet to a NetWare IPX packet and
vice versa.

Glossary 181
GPS
Stands for Global Positioning System which is a system of 24 satellites for identifying earth
locations, launched by the U.S. Department of Defense. The GPS is used for navigation and is
the most accurate time source for a local clock.
half duplex
Serial communication using one pair of wires to transmit Modbus reads and writes. Called 2-
wire in TriStation.
hardware handshake
Signals transmitted back and forth between two stations to coordinate the timing of data
transmission.
hub
A connecting device in a network that joins communication lines together in a star
configuration. Passive hubs are connecting units that add nothing to the data passing through
them. Active hubs (multi-port repeaters) regenerate the data bits to maintain a strong signal.
Intelligent hubs provide added functionality.
IP address
The unique 32-bit address of a computer attached to an Ethernet network. Every client and
server in an Ethernet network requires an IP address which is either permanently assigned or
dynamically assigned at startup.
JetDirect
A print server for LaserJet printers from HP which is available as an internal card or external
unit. It supports its own proprietary printing protocol and several others, depending on the
model. The JetAdmin printer management software is used to configure and control the
JetDirect print server.
MAC address
The unique physical address of a network device that is burned into the Network Interface Card
(NIC) of the device when it is manufactured.
master
In Modbus communication, a device that initiates all query and response exchanges with the
slave devices.
MAU
Stands for media adapter unit which is a device used to convert one type of Ethernet media to
another. In a Trident system, a MAU can be used to convert a CM port to another Ethernet
media type or to extend network distances.
message response time

For a TSAA client/server or Modbus master/slave data exchange, the time required to initiate
and send a query and get a response from the receiving controller.

182 Glossary
MII
Stands for media independent interface which is a bus used between network controllers and
physical interfaces that is based on the MII interface specification.
Modbus protocol
An industry-standard master/slave protocol that is traditionally used for energy management,
transfer line control, pipeline monitoring, and other rugged industrial processes. A Modbus
communication link can use either the Remote Terminal (RTU) or ASCII mode of transmission.
multi-point
In Modbus communication, a link that interconnects three or more master or slave devices.
network topology
In a network, the pattern of interconnection between nodes; for example, a bus, ring or star
configuration.
NIC
Stands for Network Interface Card which is a printed circuit board that plugs into both a client
and a server device and controls the exchange of data between them. Also called a network
adapter card.
node
In computer communication, a node is a network junction or connection point. For example, a
Trident controller in an Ethernet network is a node. A terminal connected to a minicomputer or
mainframe is a node.
open network
An Ethernet network to which Triconex controllers and other Ethernet devices, including
routers and gateways to other networks, can be connected.
OPC
Stands for OLE for Process Control which is a standard set of non-proprietary interfaces used
to develop client/server programs. OPC supports interoperability between field devices and
applications for process control, factory automation, and business.
parallel port
A socket on a computer used to connect a printer or other parallel device to the computer's
parallel interface.
parity checking
An error detection method that tests the integrity of digital data during transmission over a
serial communication path. Parity checking counts the number of 1 bits in a one-byte data item
and sets the parity bit (the ninth bit) to 0 or 1, resulting in an odd or even total number of bits.
path
In computer communication, the route between any two nodes. Also called line, channel, link,
or circuit.

Glossary 183
print server
A hardware device with multiple Ethernet ports that enables a printer to be located anywhere
in an Ethernet network.
Peer-to-Peer protocol
An Ethernet-based Triconex protocol that allows two applications running on separate Triconex
controllers to exchange a limited amount of process control data. Because a Peer-to-Peer
network is restricted to Triconex controllers, the cable can be isolated and protected more
securely than an Ethernet cable. A Peer-to-Peer network requires the use of Ethernet ports on
CM modules.
point-to-point
In Modbus communication, a link that connects one master or slave device to another.
process-tolerance time
The maximum length of time that can elapse before the control algorithms in a TriStation
application fail to operate correctly.
protocol
Rules that govern transmitting and receiving of data. See communication protocol.
RARP
Stands for Reverse Address Resolution Protocol which is a TCP/IP protocol used by a diskless
workstation to obtain its IP address.
redundancy
The practice of using a spare device in parallel with a primary device so that, if the primary
device fails, the spare device is easily or automatically placed into service. Examples are
redundant modules which protect against internal faults, redundant cables which protect
against cable breakage, and redundant workstations which protect against network failures.
router
A device that forwards data packets from one local area network (LAN) or wide area network
(WAN) to another. Based on routing tables and routing protocols, routers read the network
address in each transmitted frame and decide how to send it based on factors like network
traffic, speed, or bad lines.
RS-232
Stands for Recommended Standard 232 which is a standard interface approved by the
Electronic Industries Association (EIA) for connecting serial devices in point-to-point
configurations.
RS-422
Electronic Industries Association (EIA) for connecting serial devices in point-to-point
differential configurations.

184 Glossary
RS-485
Electronic Industries Association (EIA) for connecting serial devices in multi-point differential
configurations.
RTS signal
In Modbus communication, an RS-232 signal sent from the transmitting station to the receiving
station requesting permission to transmit.
scan surplus
A component of the scan time of a controller, the scan surplus is the time left after the executable
elements and communication messages have been processed. The scan surplus should be
positive. If the scan surplus is negative, the scan time should be increased.
scan time
The time required by a controller for the cycle of required control functions. The scan time
includes input poll time; execution time for all executable elements in the TriStation project;
processing time for TriStation and Peer-to-Peer messages, TSAA writes, and Modbus writes;
and output poll time.
slave
In Modbus communication, a device that is controlled by another device called the master. The
master initiates all query and response exchanges, and the slave can only respond.
station
A computer, workstation or terminal in a network. Also called a node.
subnet
A division of a network into an interconnected, but independent, segment (domain) to improve
performance and security. Typically, Triconex controllers are configured in a subnet that is part
of a large network for process control.
subnet mask
The addressing method used to split networks into subnets. The mask is a binary pattern that
subdivides a single IP address into a subnet number and a new host number. A typical subnet
mask is 255.255.255.0, which means that 254 Class C addresses are available.
TCP/IP
Stands for Transmission Control Protocol/Internet Protocol which is the global standard
communication protocol for the Internet. Can also be used for private networks such as
corporate intranets and distributed control systems.
TCP/IP is a routable protocol, which means that all messages contain not only the address of
the destination station, but the address of a destination network. This allows TCP/IP messages
to be sent to multiple networks within an organization or around the world, hence its use in the
Internet.

Glossary 185
time synchronization
A Triconex protocol used to establish and maintain a synchronized, network-wide time basis.
A controller’s time can be synchronized with the master node in a network of Tricon or Trident
controllers, or with a Distributed Control System (DCS).
TSAA
Stands for Triconex System Access Application, a protocol that enables client/server
communication between Triconex controllers and PCs. Two client/server programs, OPC
Server and DDE Server, use TSAA protocol to exchange data with Triconex controllers. TSAA
protocol can also be used to write other programs for accessing Trident points.
transceiver
A transmitter and receiver of analog or digital signals, such as a transponder or network
adapter.
TriStation protocol
A Triconex master/slave protocol in which the master (a TriStation PC) communicates with the
slave (a Triconex controller) over an Ethernet network. TriStation communicates with the Main
Processors in order to download the application to the Triconex controller and upload
diagnostic information.

186 Glossary

Index
Numerics Centronics printing

printing setup, 104, 106
100BaseTX, defined, 179
using EICM parallel port, 103
10Base2
defined, 179 client/server, defined, 179
client/server communication
10BaseT, defined, 179
DDE Server, 45
10BaseT cables, description, 15 overview, 34
2-wire configuration, 84 using OPC Server, 55–58
clock. See controller clock
A closed network, 36
adapter card. See network interface card. defined, 179
address plug, Trident MP, 20, 26 CM
ADJUST_TRICON_CLOCK message, 143 baseplate, 112
communication indicators, 116
ADJUST_TRICON_CLOCK_RSP message, 144
configuring an Ethernet port, 36
aliases configuring Peer-to-Peer ports, 66
defined, 31 configuring serial ports, 82
overview, 100 front panel, 115
ARP, defined, 179 operation, 110
ASCII mode, defined, 163 port limitations, 4
protocols supported, 2, 117
AUI, defined, 179
serial port physical features, 77
AUI MAU connections, media type and range, 113 types of ports, 113
AUI MAUs valid Modbus configurations, 81
configuration, 36 COMM Bus, 110
media type and distance, 10
communication
cables available from Triconex, 7
B cables for printing devices, 105
baseplate interconnects, 110 indicators on CM front panel, 116
baud rate property, 83 indicators on MP front panel, 128
modes for Modbus protocol, 82
big-endian order, 131
non-Triconex hardware, 6
bins (TSAA)
communication path, defined, 179
binary mask used to identify, 138
requesting data, 137 communication protocol, defined, 179
bit and byte ordering, 130 control programs (TSAA), 34
controller clock, setting, 102
C CTS Pre-Delay setting, 85
cables CTS signal, defined, 180
description, 15 customer support, x
Triconex products, 7
Centronics, defined, 179 D
data bits, defined, 180

188 Index
data bits property, 83 F

data transfer time Fast Ethernet, defined, 180
calculated for sample program, 73
Force Multiple Coils function, 174
defined, 180
estimating for Peer-to-Peer, 64 Force Single Coil function, 171
Peer-to-Peer, 64 full duplex, defined, 180
typical for Peer-to-Peer network, 74 full duplex wire type, 84
DB-pin adapter, Triconex product, 6 function blocks
DDE Modbus reads and writes, 87
address format, 52 Peer-to-Peer, 67
network redundancy, 51 time adjustment, 101
DDE Server
configuring application, 46 G
configuring Triconex host, 47 gateway, defined, 180
installation, 46
Global Positioning System. See GPS
overview, 3, 45
global variables, See Tagnames, 31
DDE., See also DDE Server
global variables. See tagnames
debug port
CM specifications, 114 GPS
MP specifications, 126 defined, 181
redundant configuration, 102
default gateway
time adjustments, 102
defined, 180
time synchronization protocol, 4
option for CM serial port, 37
sample network, 42
specifying in TriStation, 42 H
described, 32 half duplex, defined, 181
Device Clock tagname, 58, 101 half duplex wire type, 84
DLC protocol, installing on Windows NT PC, 17 hardware, Triconex products, 6
dual redundancy, OPC Server, 58 hardware handshake
defined, 181
rules, 80
E
hardware handshake property, 84
EICM
configuring printer port, 106 HP JetDirect. See network printing
setting switches, 82 hub, defined, 181
signal delays, 85 hubs, description, 15
errors, Modbus data transmission, 176
Ethernet, defined, 180 I
Ethernet adapter. See network interface card. IEEE standard for real numbers, 95
Ethernet ports on ACM or NCM, overview, 34 indicators
Ethernet ports on CM CM front panel, 116
frequency of status updates, 70 MP front panel, 128
overview, 35 Input/Output Executive. See IOX
physical description, 113 installing TriStation, 29
TriStation configuration, 36
IOX, operation, 120
even parity, 83
IP address
exception condition (Modbus), defined, 180 defined, 181
exception conditions, Modbus, 176 methods for setting, 38
exception responses, Modbus, 177–178 using CM to set, 40
exeption response (Modbus), defined, 180 using default, 38

Index 189
IP address (continued) Modbus devices

using MP to set, 40 RTU and ASCII modes, 162
using RARP server to set, 39 valid configurations, 81
IP address of CM, property of CM port, 37 Modbus function blocks
IP protocol, installing on TriStation PC, 23 for Triconex master, 87
processing, 87
sample programs, 96
L using with non-Triconex slaves, 88
little-endian ordering, 130 using with Tricon slaves, 89
longitudinal redundancy check. See LRC checksum. using with Trident slaves, 89
Loop-Back Diagnostic Test function, 173 Modbus function names, listing, 163
LRC checksum, calculation, 165 Modbus functions, supported by serial ports, 162
Modbus protocol
M DINT and REAL values from Triconex slave, 92
exception conditions, 176
MAC address, defined, 181
exception responses, 177–178
mark parity, 83 function blocks, 87
master (Modbus), programming instructions, 87 master programming instructions, 87
master node, defined, 101 message format, 163–165
MAU, defined, 181 message lengths, 166
overview, 160
MAU connections, using with CM, 113 performance considerations, 162
MAUs, media types and distances, 10 sample query and response, 165
MAUs, converting transmission speeds, 69 Modbus Range property, 85
MBCTRL function block, 96 Modbus Slave Address property, 83
Media Adapter Units., See MAUs, 10 module, communication capabilities, 4
media conversion devices, 10 monitor programs (TSAA), 34
message monitoring
handling, CM and MP, 111 Peer-to-Peer communication, 70
routing instructions, 42, 44 Trident response in DDE Server, 53
message handling MP
description, 110 baseplate physical description, 123
MP modules, 121 communication indicators, 128
message response time, 161 configuring serial ports, 82
front panel, 127
MII, defined, 182
operation, 120
MII MAU connections, media type and range, 113 protocols supported, 2
MII MAUs types of ports, 123
brief description, 10 multi-point, defined, 182
setting physical address, 36
multi-point configuration, 77
Modbus with hardware handshake, 84
determining response time, 161
reading REAL values, 93
scaling REAL values, 94 N
signal delays, 85 NCM, configuring Peer-to-Peer ports, 66
Tricon and REAL numbers, 92 network connection, testing, 50
Triconex slaves, 92 network port status, update frequency, 70
writing REAL values, 92
network printing
Modbus communication basic configurations, 105
noise sources, 176
cables used, 105
overview, 3, 76
overview, 104
table of properties, 81

190 Index
network redundancy port selection, property, 82

description, 8 Preset Multiple Registers function, 175
for DDE Server, 51
Preset Single Register function, 172
OPC Server, 58
print function blocks
network routing, 42
listing, 107
network topology, defined, 182 scan time increases, 104
networks, open or closed, 36 print server
NIC, defined, 182 basic printing configuration, 105
NIC card, installing, 17, 23 requirements for use, 105
node, defined, 182 printers
Centronics-compatible, 11
node number, master node, 101
characters per line, 106
compatibility with print server, 106
O lines per page, 106
odd parity, 83 printing
OPC, defined, 182 configuring on CM, 106
OPC Data Manager (ODM), 59 overview, 4
OPC Redundancy Broker (ORB), 59 printing devices
basic setup, 104
OPC Server
installing, 106
configuration procedure, 55–57
selecting, 105
network redundancy, 58
overview, 3, 55 process tolerance time
using with multiple controllers, 55 defined, 183
in Peer-to-Peer sample program, 73
open network, 36
defined, 182 protocol
defined, 183
ordering of bits and bytes in Triconex controllers, 130
property, 82
P R
parallel port, defined, 182
RARP, defined, 183
parallel printing, overview, 103
Read Coil Status function, 168
parity checking, defined, 182
Read Exception Status function, 173
parity checking property, 83
Read function blocks, for Modbus master, 87
path (communication), defined, 182 Read function blocks (Modbus)
PC redundancy, OPC Server, 58 sample, 90
Peer-to-Peer sample programs, 96
configuring ports, 66 Read Holding Registers function, 170
data transfer time, 64 Read Input Registers function, 170
function blocks, 67
monitoring communcation, 70 Read Input Status function, 169
Peer-to-Peer communication READ_TRICON_CLOCK message, 140
overview, 3, 62 READ_TRICON_CLOCK_RSP message, 141
speed restrictions, 63, 69 READ_TRICON_DATA message, 144
using Send and Receive function blocks, 67–68 READ_TRICON_RSP message, 145
Peer-to-Peer protocol, defined, 183 real values
performance, Modbus functions, 162 IEEE standard, 95
points, overview, 31, 100 transmitting with scaling, 92
point-to-point, defined, 183 Recvid input parameter, 68
point-to-point configuration, 77 Recvnode input parameter, 68

Index 191
redundancy, defined, 183 serial ports

redundancy testing, 9 physical features, 77
setting switches, 82
redundant DDE networks, required hardware, 51
serial ports on CM Baseplate
redundant devices
physical description, 113
description, 8
specifications, 113
testing for hardware failures, 9
two NCMGs and GPS, 102 serial ports on MP Baseplate
workstations, 9 DB-9-pin sockets illustrated, 124
specifications, 124
remote access, 32
serial ports, properties for CM and MP, 81
response codes, TSAA, 157
SET_TRICON_CLOCK message, 141
RJ-45 connectors
CM Baseplate, 36 SET_TRICON_CLOCK_RSP message, 142
disabled when MAU is used, 10 signal delays
router, defined, 183 Tricon EICM, 85
Trident MP or CM, 86
routers in sample network, 44
signal delays property, 85
RS-232
defined, 183 slave (Modbus), defined, 184
RS-232 setting, 83 SOE
availability of data (TSAA), 152
RS-232 transceiver mode, rules, 78
block status (TSAA), 153
RS-422 time stamp in TSAA message, 151
defined, 183
space parity, 83
RS-485
special aliases
defined, 184
processing Modbus integers as real values, 92
RS-485 setting, 83 reading real values, 92
RS-485 transceiver mode, rules, 78 table, 92
RST signal, defined, 184 writing real values, 92
RTS Pre-Delay setting, 85 Special parameter, Modbus function blocks, 89
RTU mode, defined, 162 status, update frequency for Ethernet port, 70
status, Peer-to-Peer communication paths, 70
S stop bits property, 83
safety-critical applications, guidelines, 2 subnet, defined, 184
sample programs subnet mask, defined, 184
Modbus communication, 96 subnet mask option for Ethernet port, 37
Peer-to-Peer communication, 72 symbol table
scaling getting with TSAA, 153
integers to REALs, 92 sending requested data (Trident), 154
REALs to integers, 93 symbol table (TSAA), information retrieval, 131
scaling REAL values, described, 92
SYS_CM_STATUS function block, 70
scan surplus, defined, 184
system aliases, 100
scan time
system attributes, for Ethernet ports on CM, 71
affect on Modbus performance, 162
defined, 184 System Executive (SX), operation, 120
effect of conditional statements, 104 system time (TSAA), 141
Sendid input parameter, 68 adjusting, 143
Sendnode input parameter, 68
T
sequential events recorder (TSAA), 34
tagname, defined, 31

192 Index
tagnames, overview, 31, 100 Trident

TCP/IP, defined, 184 communication capabilities, 4
write access, 32, 99
TCP/IP protocol, for DDE network redundancy, 51
Trident CM
technical support, x
configuring TriStation connection, 27
time direct connection to TriStation, 24
adjusting (TSAA), 143 hub connection to TriStation, 25
requesting for controller (TSAA), 140 printer configuration, 106
setting on controller (TSAA), 141 signal delays, 86
time stamp (TSAA), 146 Trident MP
associated with bin data, 137 address plug, 20, 26
time stamp in TSAA message, 151 configuring TriStation connection, 21
time synchronization direct connection to TriStation, 18
defined, 185 hub connection to TriStation, 19
GPS time adjustments, 102 node number, 20, 26
guidelines for networks, 102 signal delays, 86
overview, 101 Trimble, Acutime 2000 Synchronization Kit, 102
property of CM port, 37 TriStation
protocol defined, 3 connection to Trident MP, 18
setting properties for a CM, 103 hub connection to Trident CM, 25
setting properties for ACM, 103 installing, 29
setting properties for an NCM or NCMG, 103 installing DLC protocol, 17
TIMEADJ function block, 101 Trident CM connection, 24
TIMESET function block, 101 Trident MP configuration, 21
Trident MP using a hub, 19
TR_PEER_STATUS function block, 70
uninstalling, 30
TR_PORT_STATUS function block, 70 verifying the installation, 30
training, x TriStation 1131
transceiver, defined, 185 installing TCP/IP protocol, 23
transceiver mode, for Ethernet port on CM, 37 TriStation communication, overview, 14
transceiver mode property, 83 TriStation ports
Transceiver Port option, CM Ethernet port, 36 10BaseT sockets illustrated, 125
specifications for MP port, 125
transfer time, Peer-to-Peer, 64
TriStation protocol
transmission errors, Modbus, 176
defined, 185
TriBus overview, 2
defined, 120
TSAA, defined, 185
voting, 110
TSAA client/server communication
Tricon, special alias numbers, 92
data and CRC ordering, 130
TRICON_CPSTATUS_REQ message, 152 message format, 132–135
TRICON_CPSTATUS_RSP message, 152 overview, 3
TRICON_DATA message, 135 response codes, 157
using DDE Server, 45
TRICON_DATA_REQ message, 137
using OPC Server, 55–58
TRICON_GET_SYMBOL_REQ message, 153
TRICON_GET_SYMBOL_RSP message, 154 U
TRICON_SOE_DATAAVAIL message, 152 uninstalling TriStation, 30
TRICON_SOE_REQ message, 147
TRICON_SOE_RSP message, 148 V
Triconex contact information, x verifying aTriStation installation, 30
Triconex hardware products, 6 view options, DDE Server, 53

Index 193
W
Wire Type property, 84
write access
by tagname or alias, 31, 100
configuring CM port, 36
Trident, 32, 99
Write function blocks, for Modbus master, 87
Write function blocks (Modbus)
sample, 91
sample programs, 96
WRITE_TRICON_DATA message, 139
WRITE_TRICON_DATA_RSP message, 140

194 Index

Communication Guide, Trident v1

Uploaded by

Copyright:

Available Formats

Communication Guide, Trident v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Communication Guide, Trident v1

Uploaded by

Copyright:

Available Formats

Trident Version 1 Systems

© 2004 Invensys Systems, Inc. All Rights Reserved.

Document No. 9720079-003

Chapter 2 Communication Hardware 5

Chapter 3 TriStation Communication 13

Communication Guide for Trident v1 Systems

Chapter 4 Client/Server Communication 33

Communication Guide for Trident v1 Systems

Chapter 5 Peer-to-Peer Communication 61

Chapter 6 Modbus Communication 75

Communication Guide for Trident v1 Systems

Chapter 7 Related Communication Features 97

Appendix A Communication Module Capabilities 109

Appendix B Main Processor Capabilities 119

Appendix C TSAA Protocol 129

Communication Guide for Trident v1 Systems

TRICON_DATA_REQ (Type 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Appendix D Modbus Protocol 159

Communication Guide for Trident v1 Systems

Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

Product and Training Information

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

For guidelines on using Triconex communication protocols in safety-critical applications, see

Communication Guide for Trident v1 Systems

Triconex OPC Server

Triconex DDE Server

Triconex Time Synchronization

Communication Guide for Trident v1 Systems

Module Capabilities and Usage

Type of Connection MPs Only One CM Two CMs

Ethernet Port Connections

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

In hazardous indoor locations, apparatus used with Triconex

Communication Guide for Trident v1 Systems

Triconex Communication Cables

Cable Type Use Part Number

Communication Guide for Trident v1 Systems

Redundant OPC Server

Tricon Controller MP Tricon Controller

Primary Ethernet Network To DCS

TriStation PC SOE PC Primary OPC Server

Communication Guide for Trident v1 Systems

PC Redundancy for TriStation and SOE Recorder

Testing for Hardware Failures

Communication Guide for Trident v1 Systems

Media Conversion Devices

Media Adapter Units (MAUs)

Net1 MAU Connectors

Net2 MAU Connectors

Communication Guide for Trident v1 Systems

Print Servers and Printers

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

Communication Guide for Trident v1 Systems

In hazardous indoor locations, apparatus used with Triconex