发表于:2005-10-04 21:52:00
4楼
ControlLogix Gateway Communication Between DH+ Networks
Data Highway Plus (DH+ or PCL (Peer Communications Link)) was released by Rockwell Automation (Allen-Bradley) in 1986. DH+ is an old architecture relative to Ethernet and ControlNet used with the CLX Gateway. The DH+ protocol/architecture is not capable of containing all the of information necessary to navigate the CLX Gateway alone, this is the reason for the 1756-GTWY software. The 1756-GTWY configuration software provides additional information to the DHRIO module describing the networks available so a path can be established for DH+ messages.
What is Required by DH+ Devices to Utilize the CLX Gateway
As a general rule devices that communicate through the ControlLogix Gateway from DH+ must have the ability to Remotely message and make use of Link ID's. When determining if your device will communicate through the CLX Gateway look at the product being used. Does its DH+ port have a parameter or dip switch available to configure a Link ID for that channel? Does the product have the capability with it's communications or in its messaging command to Remotely message? Look for the key words Remote and Link to determine if your product can make use of the CLX Gateway.
The fundamental purpose of a Link ID is to number each Data Highway Plus when multiple DH+ networks exist. The Link ID provides a way for the CLX Gateway to determine what DH+ network a message should go to. Ideally, all devices on a DH+ network should have matching Link ID parameters. When a device is not capable of specifying its Link ID, by default it is 0 or undefined (that portion of the DH+ data packet is not filled out). A device without a Link ID can exist on a network with devices that have a Link ID parameter. Devices without a Link ID parameter will not be able to initiate a message through the ControlLogix Gateway and only have the capability to message with the devices on that immediate network. Note: SLC-5/04 processors PassThru Link ID on Channel 1 must match the Link ID value set on the corresponding DHRIO module that is is connected to.
Remote messaging capability provides the ability for a device to message from the Local DH+ network, through a Bridge or Gateway, to another Remote network of some type. The main difference between a Local message and a Remote is the use of an additional parameter referring to a Local Bridge node address which is used to access the remote network. A remote message can also require the Link ID of the remote network and, in some cases, specify a network type like Data Highway (not DH II or Other). Some older revisions of processor firmware can have problems remotely messaging with the newer technology. It would be prudent to have a PLC-5 NP5 Series A, B, and C at revision M firmware or later; A SLC-5/04 to be at least OS401 FRN 5 or later.
As an additional note on DF1 interfaces like the 1770-KF3, 1747-KE, 1770-KF2 and 1785-KE, the DF1 protocol as stated in Publication 1770-6.5.16 does not support remote addressing. So these devices can not communicate through the CLX Gateway to other remote networks. Remember: the key words in the criteria for using the DHRIO mentioned are Remote and Link. You will see neither device, 85KE or KF2, completely complies.
Configuring the 1756-DHRIO module with the 1756-GTWY software
The 1756-GTWY software is supported to run with Win NT only. RSLinx 1.7 or later is used by the 1756-GTWY software to connect to the CLX Gateway to configure the routing table in the DHRIO modules. RSLinx will run under Win NT/98/95, so after the gateway is configured (using Win NT), RSLinx can run under Win 95/98 also to access processors and other devices through the CLX Gateway for data acquisition, editing ladder logic, etc. When using RSLinx 1.7 the configuration of the SuperWho to view the other networks may be cumbersome, we suggest you use document number 10600 for assistance. RSLinx version 2.0 is much more user friendly when navigating through the networks (no SuperWho screen configuration is required). An issue with 1756-GTWY version 1.8 and RSLinx 2.0 software exists where the user sometimes can not connect to a DHRIO module to configure it. This is resolved by downgrading to RSLinx 1.7 or upgrading the 1756-GTWY version 1.9 software.
How to Navigate Multiple Data Highway Plus with the ControlLogix Gateway
Now that we understand the criteria required for a device to utilize the CLX Gateway, we'll discusses how to configure the ControlLogix Gateway to join multiple DH+. The core example for this document consists of three different links, one DH+ is common to two CLX Chassis, the Initiator is connected to a DH+ associated with the first CLX Chassis (designated by the RSLinx terminal), and the target is connected to a DH+ associated with the second CLX Chassis (designated by the PLC). The Initiator (on Link 51) will communicate through the first CLX Chassis, onto the shared DH+ (Link 12) into the second CLX Chassis, and access the target on the third network (Link 13) .
System used for Disscussion
Backplane 91 BackPlane 90 Backplane 92
1756-DHRIO Slot 7 1756-DHRIO Slot 2 1756-DHRIO Slot 4
A = Node 46, Link 51 A = Node 51, Link 11 A = Node 31, Link 13
B = Node 47, Link 12 B = Node 52, Link 12 B = Node 32, Link 32
1756-DHRIO Slot 5
A = Node 53, Link 13
B = Node 54, Link 14
ControlLogix Gateway Chassis DHRIO Module Configurations
Based on the diagram above, we will now complete the routing table for each DHRIO module involved in our communications path (for Chassis Backplanes 90 and 91) using the configuration software (i.e. RSLinx 2.2 or 1756-GTWY). It is important to understand the complete network path, associated node addresses, and Link ID of each device. It is necessary to have a network diagram of the proposed network to keep track of what Links are assessable from each chassis to eliminate mistakes. Notice that a unique Link ID is assigned to each channel of the DHRIO. Remember: The node address for each channel is set with the hardware switches on the bottom of the DHRIO module. Since we don't see the node address information with the configuration (i.e. RSLinx 2.2 or 1756-GTWY) software, this is another reason for drawing a network diagram which includes all devices, their node address, and link ID. It is also a good idea to establish a standard of some sort for assigning a Link ID. This will help reduce confusion when navigating the communications path.
Using RSLinx 2.20 or later
With the release of RSLinx 2.20 software, the Gateway software was assimilated. The look and feel is slightly different, but the functionality remains very similar. From the superwho screen, right mouse Click on the respective Gateway module.
A similar following drop down meu appears where we select Configuration or Module Configuration
General and fault information is available:
Routing table as with 1756-GTWY:
Likewise, channel configuration for the default ControlLogix controller slot in the case ot receiving a local message:
Using the 1756-GTWY Software
If your software is pre-RSLinx 2.20, you will need to use the origional 1756-GTWY configuration tool. The last release was version 1.9 (or 1.91 with software patch) When connecting to the DHRIO module with 1756-GTWY software, from the menu select file, browse networks, and a call to RSLinx is made to select the DHRIO module you intend to cofigure the routing table.
Routing Table for DHRIO in ControlLogix Chassis 1
From the example network shown above, the RSLinx terminal resides on DH+ Link 51 and is connected to the first CLX Chassis by a 1756-DHRIO module in slot 7, using channel A, node 46. Channel B contains the common DH+ network (Link 12) with the DHRIO node 52 in the second CLX Chassis we plan to access. To provide a path to the second chassis, we must indicate on the routing table that we are creating a bridge to the other CLX Chassis. This is done by right mouse clicking on Channel B, adding a DH+ Bridge, and specifying what Link ID's are available from the second ControlLogix Chassis (DH+, ControlNet, and Ethernet Link ID's). Another reason to have a network diagram is to see what Links are accessible from other CLX Chassis. Once the routing table is configured, remember to press the apply button to send the new configuration information to the DHRIO module. The next step is to connect to a DHRIO module in the second
Routing table for both DHRIO modules in ControlLogix Chassis 2
Notice that the DHRIO module (Channel B) in slot 2 also has a DH+ Bridge defined indicating a path back to the 1st CLX Chassis listing the accessible Link ID from that chassis. Each chassis must have a bridge referring to the other chassis, this is necessary for the communications to be successful between the networks. A communications path must exists in both direction. After the second routing table is completed for the DHRIO in the second chassis, the apply button is pressed, you notice that the 1756-GTWY software asks you if you only want one or both DHRIO updated. You want to press the select all button so both DHRIO modules are selected. Both modules in the second CLX Chassis have the same routing table, that is, each module will have knowledge of the other 1756-DHRIO added to its routing table description.
Once all the DHRIO modules are configured correctly an application (RSLinx, PLC, SLC, etc...) can now make use of the Gateway.
Configuring RSLinx 1.7 SuperWho screen on Network 1 to view devices on Network 3
To access the remote DH+ with the target PLC with RSLinx 1.7 the SuperWho needs to be configured (right mouse click on the SuperWho screen) as described below:
We suggest using a Station Update mode of Normal because Graphical (default) may cause confusion and in some cases not work correctly. Since we are looking at a Remote network, the Remote radio button is selected and then the Configure button is pressed to complete the Remote Routing Configuration. The bridge device is the 1756-DHRIO, referring to the remote DHRIO, and the path describes to RSLinx how to navigate from network 1 to the DHRIO in slot 5 of CLX Chassis 2.
Remote Routing Details Explained
0 = KT/KTx/PCMKCard to Data Highway Plus
38 = Octal node address 46 (Decimal 38). The first CLX Gateway entry point, channel A on the first DHRIO module in Chassis One.
3 = Exit the DHRIO Channel B (2 represents channel A and 3 represents channel B)
42 = Octal node address 52 (Decimal 42). The DH+ bridge (second entry point) channel B on the second DHRIO module in Chassis Two.
1 = Represents the ControlLogix backplane. This is necessary to access the second DHRIO module in the second chassis.
5 = Zero based slot number of the second DHRIO module.
The rest of the routing details is basically filling in the blank describing the DHRIO port (in Chassis 2) that has the target PLC. The path we provide take us to the third or last DHRIO module, and then we only need to indicate what channel to exit and specify what Link and Node address is assigned to that channel. After each dialog box is closed you will see the nodes on DH+ network 3 (Link 13). RSLogix can then be used to go on-line to the processor. One nice feature when Using RSLinx 1.7 and the communications path is entered into the RSLinx 1.7 software, if there is a minor error in the routing table, RSLinx 1.7 can still navigate through the gateway and communicate with the target device. This at least verifies correct wiring.
Configuring RSLinx 2.0 SuperWho screen on Network 1 to view devices on Network 3
Configuration of the Superwho screen on RSLinx 2.0 is not necessary, as long as the routing tables are configured correctly, RSLinx 2.0 can navigate both the CLX Chassis to the desired network. The following is a capture of RSLinx 2.0 showing the network path used in the example:
For our first PLC message example, we are going to simplify the network and only negotiating one ControlLogix Chassis (Backplane Link 91). We will add a SLC-5/04 processor to the same DH+ where the RSLinx terminal is located. The message path consists of leaving a SLC-5/04 (Node 24) Channel 1, entering the 1756-DHRIO (Node 46) Channel A, exiting the same DHRIO module (Node 47) Channel B, and arriving at a PLC-5/40 (Node 2) on Link 12. This scenario is only using half of our system configuration above for reasons pointed out later in this document, the messaged used is captured below. From looking at the RSLinx screen apture above, the target PLC-5/40 would be located on the DH+ where the DHRIO's nodes 47 and 52 are indicated.
Initiating a Message from a SLC-5/04 on Link 51 to a
PLC-5 on the Link 12 (Navigate one CLX chassis)
Initiator 5/04 on Link 51, Target 5/40 on Link 12, using DHRIO bridge node 46
We chose to use a PLC-5 typed read, the message type you use will be based on what is supported on each processor platform. Here a Remote message is used, we specify a local bridge address of 46, which is the 1756-DHRIO or ControlLogix Gateway, and the routing table in the DHRIO routes the message to the appropriate network (Link 12) where the PLC-5/40 resides. Notice that the Remote Bridge Address parameter is not used. This demonstration does not navigate all 3 networks, but it does show that devices on any network defined in the routing table can be accessed. This was a relatively simple path, jumping across one DHRIO module in one chassis, in the following examples we'll see that the message instruction does not change much when navigating more complex systems. In our next example, we come back to the original configuration. Note: When messaging with the SLC-5/04 processor make sure the firmware is at the latest revision. We've found that past versions like OS401 FRN 2 can not message remotely through the gateway.
Initiating a Message from a SLC-5/04 on Link 51 to a
PLC-5/40 on Link 13 (Navigate two CLX chassis)
This next example uses the whole network configuration created above, the SLC-5/04 to initiate the message across all 3 DH+ networks as shown by the RSLinx 2.0 screen capture above. Notice that the only difference in the message instruction is the Link ID parameter. The target stays the same (because we moved it to Link 13, the third network). Also notice that the Remote Bridge Address field is still not used as from our first example that only used one CLX Gateway chassis.
Initiator 5/04 on Link 51, Target 5/40 on Link 13, using DHRIO bridge node 46
Initiating a Message from a PLC-5/40 on Link 51 to a
PLC-5/40 on Link 13 (Navigate two CLX chassis)
This next example will use our complete system configuration, it consists of a PLC-5/40 processor on Link 51, initiatiing a message through both CLX Chassis, to the PLC-5/40 on Link 13. The PLC-5/40 would be on the same network as the RSLinx terminal shown above, and initiating a message across 3 DH+ networks. This is the same thing that we did with the 5/04 in the previous example.
Initiator 5/40 on Link 51, Target 5/40 on Link 13, using DHRIO bridge node 46
Initiating a Message from a Logix 5550 on Link 13 to a
PLC-5/40 on Link 51 (Navigate two CLX chassis)
This example uses a Logix 5550 controller to initiate a message on the same network (Link 13) as the target PLC-5/40. We've placed another PLC-5/40 as our target with the RSLinx station (Link 51) as shown in the original diagram at the top of the page.
In the Logix 5550 chassis, the processor initiating the message is in (zero based) slot 1, and the DHRIO card is in slot 4. From the communications configuration of the Logix 5550, the chassis backplane is the first network considered relative to the Logix 5550. This means that the routing table in the DHRIO that the Logix 5550 is using as it's DH+ port, needs to reference the other two CLX Chassis used in our example. See the routing table below for our example that adds a third chassis. This is the routing table we used to successfully communicate with the Logix 5550 processor, through our 2 Chassis CLX Gateway as we did with the PLC-5/40 and SLC-5/04.
From our Logix 5550 message example, we are reading the seconds byte from the PLC-5 on link 51.
Using PLC-2 Typed Messages
There are several third party devices that communicate with Allen-Bradley PLC's using the PLC-2 type or Unprotected (read/write) messaging format. When communicating with devices that are using PLC-2 type messaging format there are two primary concerns:
1) Does the device support remote addressing! An, MMI, DCS, or other device that interfaces to a DH+ using RS-232 (DF1) by means of a 1770-KF2 or 1785-KE/C will not be capable of remotely addressing as mentioned earlier. Use the rules stated earlier.
2) Since the PLC-2 message structure does not specify the file (i.e. N7:0) in a PLC-5 to access, here the (octal) node address of the initiator is used to determine the decimal file in the PLC-5 that is accessed. On SLC processors the PLC-2 Compatibility file is always file 9.
This message was used to communicate with a PLC-5/40C (ControlNet) processor residing on DH+. The initiator was Node 24, a SLC-5/04 processor, so the data was read from file N20:4 (octal node 24 with a byte offset of 8). Even though the bridge was the device the message came from on that network, it was node address of the initiator of the message that is used to determine what file in the PLC-5 is accessed. On ControlNet processors the processor Status contains a section for defining the PLC-2 Compatibility file, this is only relative to ControlNet. When accessing a ControlNet processor on DH+, it will behave in the same manner as the other DH+ processors and use the node address of the messages initiator.
When communicating with an actual PLC-2 using the 1785-KA3 to interface it to a DH+, the KA3 module is capable of responding to a message sent through the CLX Gateway; However the PLC-2 will not be able to initiate a message through the CLX Gateway. The PLC-2 (1785-KA3) can only be accessed from another device initiating communications.
Adding a third, fourth, etc... CLX Chassis
This example uses a third ControlLogix Chassis to add one more level of complexity to the system. The reason for doing this is to demonstrate how critical having a correct routing table is to successful communications. The message instructions remain the same (except for Link ID), we now have to maintain 3 separate routing tables across 4 DHRIO modules. If one Link ID is wrong or left out, the communications will not work. The following are the routing tables used to remotely message across CLX Chassis or 4 DH+ networks:
The original network model was used as shown above. We added the third CLX Chassis to Link 13, moved the PLC-5/40 onto its Link 32, and once again successfully communicated the SLC-5/04 by using the correct Link ID settings.
RSLinx 2.0 Screen capture of all three CLX Chassis and 4 DH+ networks
Initiating a Message from a PLC-5/40 on Link 32 to a
SLC-5/40 on Link 51 (Navigate three CLX chassis)
The PLC-5 successfully initiated a SLC-500 type message from remote Link 32 to the SLC-5/04 on Link 51. We've used a different type of message command, notice that the only major difference is the Link ID.
This is a nice way to extend the DH+ beyond the 10,000 ft limitation. Each network theoretically supports 10,000 ft maximum length in this last example we've create a DH+ bridged network with a potential distance of 40,000 ft (Theoretically speaking, barring propagation delays and other considerations). Now that you can see what can be done with DH+ networks, review the concepts and understand them well, because the best use of the CLX Gateway is to communicate between DH+, ControlNet, and Ethernet.
Initiating a Message from a Logix 5550 on Link 92(13) to a
1770-KF2 (CH 0 of PLC-5/40) on the Link 13
This example makes use of the 1770-KF2 to show that it can be used to communicate with from a Logix 5550 processor; However, the communications tab of it message instruction must be set up differently than shown above. Since the KF2 does not reference Link ID's, by default it's Link ID setting is 0 or undefined. In this example we put a Logix 5550 processor in slot one of the third CLX Chassis shown in the routing table configuration above. The DHRIO module is in slot 4. The Configuartion section of the message instruction remins the same as our previous example above when negotiating 2 CLX chassis. In this Local message example (relatively speaking) we omit the reference to Link ID's.
Since the 1770-KF has no Link ID reference, we must set the Source Link and Destination Link to 0. We are relying on the message communication path to route the command to the 1770-KF2 and the DHRIO channel configuration (controller slot parameter) for the reply back to the Logix 5550 processor from the KF2. If this configuration does not work for you, be sure that the controller slot for the respective channel in the DHRIO points to the correct Logix 5550 processor.