ABT-CCP164-TIM 2008-07

DeviceNet

and

RSNetWorx Configuration and Troubleshooting

Instructor Guide

Important User Information This documentation, whether, illustrative, printed, “online” or electronic (hereinafter “Documentation”) is intended for use only as a learning aid when using Rockwell Automation approved demonstration hardware, software and firmware. The Documentation should only be used as a learning tool by qualified professionals. The variety of uses for the hardware, software and firmware (hereinafter “Products”) described in this Documentation, mandates that those responsible for the application and use of those Products must satisfy themselves that all necessary steps have been taken to ensure that each application and actual use meets all performance and safety requirements, including any applicable laws, regulations, codes and standards in addition to any applicable technical documents. In no event will Rockwell Automation, Inc., or any of its affiliate or subsidiary companies (hereinafter “Rockwell Automation”) be responsible or liable for any indirect or consequential damages resulting from the use or application of the Products described in this Rockwell Automation does not assume responsibility or liability for damages of any kind based onDocumentation. the alleged use of, or reliance on, this Documentation. No patent liability is assumed by Rockwell Automation with respect to use of information, circuits, equipment, or software described in the Documentation. Except as specifically agreed in writing as part of a maintenance or support contract, equipment users are responsible for: •

properly using, calibrating, operating, monitoring and maintaining all Products consistent with all Rockwell Automation or third--party provided instructions, warnings, recommendations and documentation; • ensuring that only properly trained personnel use, operate and maintain the Products at all times; • staying informed of all Product updates and alerts and implementing all updates and fixes; and •

all other factors affecting the Products that are outside of the direct control of Rockwell Automation.

Reproduction of the contents of the Documentation, in whole or in part, without written permission of Rockwell Automation is prohibited. Throughout this manual we use the following notes to make you aware of safety considerations: Identifies information about practices or circumstances that can cause an explosion in a hazardous environment, which may lead to personal injury or death, property damage, or economic loss.

Identifies information that is critical for successful application and understanding of the product.

Identifies information about practices or circumstances that can lead to personal injury or death, property damage, or economic loss. Attentions help you: • identify

a hazard a hazard • recognize the consequence • avoid

Important User Information Labels may be located on or inside the drive to alert people that dangerous voltage may be present.

Labels may be located on or inside the drive to alert people that surfaces may be dangerous temperatures.

Summary of Changes Pre-Course Setup

This class requires setup time to review the workstation configuration and to prepare for the exercises. It is critical to complete the steps in the General Setup section of the Setup Information document before day one. Detailed checklists are provided.

Feedback

Until the next scheduled update for this course, the FTI Feedback Database will contain information on any other instructor-generated feedback. Please check the database for new entries each time you prepare to teach this course. We welcome additional comments.

Tip " Overview of Changes

Rev. July 2008

See the General Setup for specific workstation information.

The following specific changes were made: •

The exercise files (i.e., controller and network files) have been updated to RSLogix 5000 software version 17 and RSNetWorx for DeviceNet version 9.

•

The information, graphics, exercise s, and demonstrations in this course have been updated to reflect the latest enhancement s in RSNetWorx for DeviceNet software version 9.

E 2008 Rockwell Automation, Inc. All rights reserved.

b

Summary of Changes


Rev. July 2008

Comment Form

Email: [email protected] or Fax:

440.646.4425

Page 1 of Date:

Contact Information: Name: Company and Location: Phone:

Email:

Comments (include lesson title, if applicable): Course or Product Name (Important):

Page 2

Table of Contents

Introduction Course Overview CourPsuerpose ......... ........ ......... ......... ......... ......... ........ WhSohouAldttend ......... ........ ......... ......... ......... ......... ..... Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MeetingCourseObjectives ........ ......... ......... ......... ........ ......... . StudeM ntaterials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hands-OEnxercises ......... ......... ......... ......... ........ ......... ....

I I II II III IV IV

Lessons Identifying DeviceNet Network Components WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... NetLinxOpenArchitecture ......... ......... ......... ........ ......... ....... NetworHkierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DeviceNeNtetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BenefitsofaDeviceNetNetwork ........ ......... ......... ........ ......... .... DeviceNetNetworkApplications ........ ......... ......... ........ ......... .... DeviceNeN t etworkComponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PowSeur pply ......... ......... ......... ......... ........ ......... ....... DeviceNC etable ......... ........ ......... ......... ......... ......... ..... DeviceNeW t ireFunction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TerminatingResistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T-PToartp ......... ........ ......... ......... ......... ......... ........ DeviceBoTxap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PowerTaTpap ......... ........ ......... ......... ......... ......... ..... DevicePoTrat p ......... ......... ......... ......... ........ ......... .... Open-StyTleap ......... ......... ......... ......... ........ ......... .... InsulationDisplacementConnectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KwikLinkOpen-StyleConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KwikLinkMicroConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ScanneMrodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ScanneM r oduleLocation ........ ......... ......... ........ ......... .......

1-- 1 1-- 1 1-- 1 1-- 1 1-- 1 1-- 3 1-- 4 1-- 4 1-- 5 1-- 6 1-- 6 1-- 8 1-- 9 1-- 9 1-- 10 1-- 10 1-- 10 1-- 11 1-- 12 1-- 12 1-- 13 1-- 14 1-- 15 1-- 16

ii

Table of Contents

Device(sNodes) ........ ......... ......... ......... ........ ......... ...... EtherNet/IPtoDeviceNetLinkingDevice ........ ......... ......... ......... .... Absolute Multi-Turn Encoder 842D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E3Solid-StateOverloadRelay ......... ......... ......... ......... ......... . PowerFle4xD 0 rive ........ ......... ......... ......... ......... ......... . 871TMInductiveProximitySensor ......... ......... ........ ......... ......... ArmorBlock MaXum I/O Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PoinIt/ODeviceNeA t dapter ........ ......... ......... ......... ......... .... PanelViewPlusOperatorInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1770-KFM D odule ........ ......... ......... ......... ........ ......... ... RSNetWorxforDeviceNetSoftware ........ ......... ......... ......... ......... . RSLinxClassicSoftware ......... ......... ......... ........ ......... ......... RSLogix5,RSLogix 500,andRSLogix5000Software ......... ........ ......... ...... HerH e’osw ........ ......... ......... ......... ......... ........ ......... ...

1 - 17 1-- 17 1--18 1 - 18 1-- 19 1 - 19 1--20 1-- 20 1-- 21 1-- 21 1 - 21 1-- 22 1-- 22 1-- 22

Exercise: Identifying DeviceNet Network Components ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 23 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-- 24 ExercBise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 24 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-- 26 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1--28 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 28 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 28

Designing a DeviceNet Cable System WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... RouCndable ......... ......... ......... ......... ........ ......... ...... FClatble ........ ......... ......... ......... ........ ......... ......... TrunLkinCeable ........ ......... ......... ......... ........ ......... ...... MaximumTrunkLineDistance ......... ......... ......... ........ ......... ... DroLpinCeable ......... ......... ......... ......... ........ ......... ...... CumulativeDropLineLength ......... ......... ......... ........ ......... ... Device(N s odes ) ........ ......... ......... ......... ........ ......... ...... CATNechnology ......... ......... ......... ......... ........ ......... ... DevicCeomponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . InsulationDisplacementConnectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PowSerupplies ......... ......... ......... ......... ........ ......... ...... PowerSupplyRequirementCalculation ......... ......... ......... ......... ....

2-- 1 2-- 1 2-- 1 2-- 2 2-- 2 2-- 3 2- 4 2-- 4 2-- 5 2-- 5 2-- 6 2-- 6 2-- 7 2-- 8 2-- 9

TerminatingResistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GroundingRequirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SinglePowerSupplyGroundingRequirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MultiplePowerSupplyGroundingRequirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-- 9 2-- 10 2-- 10 2-- 11

iii

Table of Contents

HerH e’osw Example HerH e’osw Example HerH e’osw Example Example

......... ......... ........ ......... ......... ......... ......... .. ......... ......... ......... ......... ......... ........ ......... .... ......... ......... ........ ......... ......... ......... ......... .. ......... ......... ......... ......... ......... ........ ......... .... ......... ......... ........ ......... ......... ......... ......... .. ......... ......... ......... ......... ......... ........ ......... .... ......... ......... ......... ......... ......... ........ ......... ....

2-- 11 2-- 12 2-- 13 2-- 13 2-- 14 2-- 14 2-- 15

Exercise: Designing a DeviceNet Cable System E HxoDewYridcoDAiusoe? . . . . . . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. 2-- 221-- 19 ExercBise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-- 21 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-- 23 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2--24 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-- 24 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-- 24 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-- 24

Creating a DeviceNet Network Configuration WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... DeviceNeDtrivers ......... ......... ......... ......... ........ ......... .... NetworPkroperties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetworkConfigurationOptions ......... ......... ......... ........ ......... .... OfflineNetworkConfiguration ........ ......... ......... ......... ......... ..... OnlineNetworkConfiguration ........ ......... ......... ......... ......... ..... UploadingandDownloading ........ ......... ......... ........ ......... ....... BrowsinNagetwork ........ ......... ......... ......... ........ ......... .... HerHeo’sw ......... ......... ........ ......... ......... ......... ......... ..

3-- 1 3-- 1 3-- 1 3-- 2 3-- 4 3-- 5 3-- 5 3-- 6 3-- 7 3-- 8 3-- 9

Exercise: Creating a DeviceNet Network Configuration ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 11 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-- 14 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3--16 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-- 16

iv

Table of Contents

Commissioning Nodes on a DeviceNet Network WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... DRaatate ........ ......... ......... ......... ........ ......... ......... NodAeddresses ......... ......... ......... ......... ........ ......... ... NodeCommissioningMethods ........ ......... ......... ......... ......... .... PanelViewPlusNodeCommissioning ......... ......... ........ ......... ...... DeviceHardwareNodeCommissioning ........ ......... ......... ......... .......

4-- 1 4-- 1 4-- 1 4-- 1 4-- 2 4-- 2 4-- 3 4-- 3

S 4-4- 4-- 6 Poofintwt-atore-NPoodineC C t oom mm miissssiioonniinngg . .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. . .. . .. .. .. .. .. .. .. . .. . .. .. .. .. NodeCommissioningConsiderations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-- 7 Example: Commissioning Nodes with Unique Node Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4-- 7 HerHeo’sw ........ ......... ......... ......... ......... ........ ......... ... 4-- 8

Exercise: Commissioning Nodes on a DeviceNet Network ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-- 9 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-- 10 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4--12 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 12

Configuring a 1756-DNB DeviceNet Scanner Module WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... ....

5-- 1 5-- 1

BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... ScannerModuleCommunicationswithaController ......... ......... ......... ....... 1756-DNBScanneM r odule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DiscreteInputandOutputDataTransfers ........ ......... ......... ......... .... ScannerModuleConfiguration ........ ......... ......... ......... ......... .... NodeAddressandDataRate ......... ......... ......... ........ ......... ... InterscaDnelay ......... ........ ......... ......... ......... ......... .... ExpecteP d ackeRt ate ........ ......... ......... ........ ......... ......... ForegroundtoBackgroundPollRatio ........ ......... ......... ......... ....... Scanlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ElectronicKeyingCriteria ......... ......... ......... ........ ......... ...... SlaMvoede ......... ......... ......... ......... ......... ........ ......... ExampleS: lavM e ode ......... ......... ......... ......... ........ ......... ShareIndputs ......... ........ ......... ......... ......... ......... ....... ScanneM r oduleRunMode ........ ......... ......... ......... ......... ....... 1756-DNBScannerModuleRun/IdleBit ......... ......... ......... ......... .... HerH e’osw ........ ......... ......... ......... ......... ........ ......... ...

5-- 1

5- 2 5-- 3 5- 3 5-- 4 5-- 5 5-- 5 5-- 5 5-- 6 5-- 7 5-- 7 5-- 8 5-- 9 5 - 10 5 - 12 5-- 13 5-- 14

Table of Contents

v

Exercise: Configuring a 1756-DNB DeviceNet Scanner Module ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 15 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 16 ExercBise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 16 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 17 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5--18 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 18 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 19 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-- 19

Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... 6-- 1 WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... 6-- 1 BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... 6-- 1 MessageTypeandI/OSizes ........ ......... ......... ........ ......... ....... 6-- 2 PolleMdessages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 3 StrobeM d essages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 4 Change-of-StateMessages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 5 CyclM icessages ........ ......... ......... ......... ........ ......... .... 6-- 5 DaMtaP aplan ......... ......... ......... ......... ........ ......... ....... 6-- 7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 7 Automatic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6--8 Automatic Mapping Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6--8 ManuM alapping ......... ........ ......... ......... ......... ......... ..... 6-- 9 MaSpegmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 10 Example: PowerFlex 40 Drive Map Segmentation in a 1756-DNB Scanner Module . . . . . . . . . . 6--11 Address Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6--12 1756-DNB Mapping in RSNetWorx for DeviceNet Software and ControlLogix Addresses inRSLogix5000Software ........ ......... ......... ........ ......... .... 6-- 12 DeviceDataStructure ........ ......... ......... ......... ........ ......... . 6-- 13 Example: Data Structure of an ArmorBlock MaXum Input Module ........ ......... ..... 6--1 4 HerH e’osw ......... ......... ........ ......... ......... ......... ......... .. 6-- 14 HerH e’osw ......... ......... ........ ......... ......... ......... ......... .. 6-- 15 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 15 Step 1: Identify RSNetWorx for DeviceNet Input Data Map ......... ........ ......... . 6-- 15 Step2:IdentifyRSLogix5000InputTags ......... ......... ........ ......... .... 6-- 16 Step3:IdentifyDeviceDataStructure ......... ......... ......... ......... ..... 6-- 17

vi

Table of Contents

Exercise: Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 19 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 22 ExercBise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 22 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-- 24 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6--26 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 26 ExercB ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 32 ExercB ise

......... ......... ........ ......... ......... ......... ......... .

6 - 32

Managing DeviceNet EDS Files WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... 7-- 1 WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... 7-- 1 BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... 7-- 1 EDFSiB leenefits ........ ......... ......... ......... ........ ......... ...... 7-- 2 EDFSiLleibrary ......... ......... ......... ......... ........ ......... ...... 7-- 3 EDFSiNleumber ........ ......... ......... ......... ........ ......... ...... 7-- 3 Example:PowerFlex40DriveEDSFileNumber ......... ......... ......... ....... 7-- 4 Example:E3OverloadRelayEDSFileNumber ......... ......... ........ ......... 7-- 5 ThEeDWSizard ........ ......... ......... ......... ........ ......... ...... 7-- 6 HerHeo’sw ........ ......... ......... ......... ......... ........ ......... ... 7-- 6

Exercise: Managing DeviceNet EDS Files ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-- 7 HoDw YidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-- 8 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7--10 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10

Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... 8-- 1 WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... 8-- 1 BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... 8-- 1 ConfigurationRecovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 2 Auto-Address Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8--2 ScanneM r oduleFunction ........ ......... ......... ........ ......... ......... 8-- 2 ElectronK iceying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-- 3 Automatic Device Recovery Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8--5 HerHeo’sw ........ ......... ......... ......... ......... ........ ......... ... 8-- 6

Table of Contents

vii

Exercise: Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-- 7 HoDw YidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-- 8 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8--10 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-- 10

Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix Platform WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... 9-- 1 WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... 9-- 1 BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... 9-- 1 ExplicitMessagingvs.I/OMessaging ......... ......... ......... ......... ........ 9-- 2 TheDeviceNeO t bjecM t odel ........ ......... ......... ........ ......... ....... 9-- 2 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 2 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 3 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 3 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9--4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 4 Class,Instance,Attribute,andServiceCodeLookup ......... ........ ......... ....... 9- 8 ExpliciM t essagingTypes ........ ......... ......... ......... ......... ........ 9-- 8 Explicit Messaging Using a ControlLogix Controller and a 1756-DNB Scanner Module . . . . . . . . . 9--8 MSGInstructionConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 9 Peer-to-PeerExplicitMessaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 11 UCMM(UnconnectedMessageManager) Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 11 MethodoCf onfiguration ......... ......... ......... ......... ........ ....... 9-- 11 Example: PanelView Peer-to-Peer Explicit Message Configuration . . . . . . . . . . . . . . . . . . . . . 9--1 2 HerH e’osw ......... ......... ........ ......... ......... ......... ......... .. 9-- 13

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix Platform ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 15 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-- 17 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9--18

Integrated Practice - Modifying a DeviceNet Network Configuration WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... ....

Exercise: Integrated Practice - Modifying a DeviceNet Network Configuration ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10-- 1 10-- 1

10-- 3 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-- 5 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10--6 ExercA ise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-- 6

viii

Table of Contents

Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... ErrIcoor ns ......... ......... ......... ......... ......... ........ ......... DeviceMismatchIcon ......... ......... ......... ......... ........ ......... MissinD g evicIecon ......... ........ ......... ......... ......... ......... . Error,Warning,andStatusMessages ......... ......... ......... ......... ....... DevicPearameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11-- 1 11-- 1 11-- 1 11-- 1 11-- 2 11-- 3 11-- 3 11-- 4

lee:M M TheE Dxeavm icepN t DToonoitloring I/O. S . .ta. t.u.s. f.o.r a.n. A. .rm . .o.r.B.lo.c.k.M. a. .X.u.m. I/.O. .M. o. d. .u.le. . . .. .. .. .. .. .. . .. . .. .. .. .. .. .. .. . . . 11-- 611--5 HerH e’osw ........ ......... ......... ......... ......... ........ ......... ... 11-- 7

Exercise: Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-- 9 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-- 11 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-- 12 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11- 13 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11--14 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-- 14 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-- 14

Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators WhaYtoW u Lillearn

........ ......... ......... ......... ........ ......... ......

WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... StatusIndicators(LEDs) ......... ......... ......... ........ ......... ......... 1756-DNBScannerModuleStatusIndicators ......... ......... ........ ......... ... DeviceNetworkStatusIndicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . StatusIndicatorInterpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ScannerModuleNumericandAlphanumericCodes ........ ......... ......... ....... HerH e’osw ........ ......... ......... ......... ......... ........ ......... ...

12-- 1 12-- 1 12-- 1 12-- 1 12 - 2 12-- 3 12 - 3 12-- 4 12-- 5

Exercise: Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-- 7 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-- 9 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12--10 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-- 10 TroubleshootingTips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-- 11

Table of Contents

ix

Troubleshooting a DeviceNet Network Using RSLogix 5000 Software WhaYtoW u Lillearn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 1 WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... 13-- 1 BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... 13-- 1 Relationship Between an RSNetWorx for DeviceNet Software Data Map and I/O Points inRSLogix5000Software ........ ......... ......... ......... ......... ..... 13-- 1 RSNetWorxforDeviceNetSoftwareDataMap ......... ......... ......... ........ 13-- 2 DeviceDataStructure ........ ......... ......... ......... ........ ......... . 13-- 3 RSLogix5000SoftwareTagsDatabase ........ ......... ......... ......... ..... 13-- 5 ScannerModuleStatusRegister ........ ......... ......... ........ ......... .... 13-- 8 1756-DNB Scanner Module Module-Defined Status Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 9 HereH’sow ......... ......... ........ ......... ......... ......... ......... .. 13-- 10 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 10 Tracing I/O Points through a 1756-DNB Scanner Module ......... ........ ......... .... 13-- 10 Step1:DetermineOutputMapping ........ ......... ......... ......... ........ 13-- 10 Step2:DetermineDataStructure ......... ......... ......... ........ ......... . 13-- 11 Step 3: Determine I/O Point Location in RSLogix 5000 Software Tags Database . . . . . . . . . . . . 13--11 Step 4: Verify the Addressing of the Ladder Logic Instruction Controlling the I/O Point . . . . . . . . 13--12 HereH’sow ......... ......... ........ ......... ......... ......... ......... .. 13-- 12

Exercise: Troubleshooting a DeviceNet Network Using RSLogix 5000 Software ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 13 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 16 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13--18 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-- 18

Troubleshooting Duplicate Node Addresses on a DeviceNet Network WhaYtoW u Lillearn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-- 1 WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... 14-- 1 BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... 14-- 1 DuplicateNodeAddresses ......... ......... ......... ........ ......... ....... 14-- 1 DuplicateNodeAddressRecognition ......... ......... ......... ......... ........ 14-- 2 FaultedAddressRecoveryWizard ........ ......... ......... ......... ......... .. 14-- 2 ManuaN l odeAddressRecovery ........ ......... ......... ........ ......... .... 14-- 4 HerH e’osw ......... ......... ........ ......... ......... ......... ......... .. 14-- 5

Exercise: Troubleshooting Duplicate Node Addresses on a DeviceNet Network ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-- 7 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-- 8 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14--10 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-- 10 ExerciseTroubleshootingTips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-- 10

x

Table of Contents

Integrated Practice: Restoring a Malfunctioning DeviceNet Network to Normal Operation WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... ....

15-- 1 15-- 1

Exercise: Integrated Practice - Restoring a Malfunctioning DeviceNet Network to Normal Operation ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-- 3 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-- 4 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15--6 ExercA ise

......... ......... ........ ......... ......... ......... ......... .

15-- 6

Configuring a 1747-SDN DeviceNet Scanner Module WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... 16-- 1 WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... 16-- 1 BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... 16-- 1 ScannerModuleCommunicationswithaProcessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 2 1747-SDNScanneM r odul e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 3 1747-SDNScannerModuleDataTransferTypes ......... ........ ......... ......... 16-- 3 M1FileReads/M0FileWrites ......... ......... ......... ........ ......... ... 16 - 3 FMiTleransfer ........ ......... ......... ......... ........ ......... ...... 16-- 5 DiscreteInputandOutputDataTransfers ........ ......... ......... ......... .... 16-- 6 ScannerModuleConfiguration ........ ......... ......... ......... ......... .... 16-- 7 NodeAddressandDataRate ......... ......... ......... ........ ......... ... 16-- 8 InterscaDnelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8 ExpectedPackeRt ate ........ ......... ......... ........ ......... ......... 16 - 8 ForegroundtoBackgroundPollRatio ........ ......... ......... ......... ....... 16-- 9 Scanlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 10 ElectronicKeyingCriteria ......... ......... ......... ........ ......... ...... 16-- 10 SlaM veode ......... ......... ......... ......... ......... ........ ......... 16-- 11 ExampleS: laveMode ......... ......... ......... ......... ........ ......... 16-- 12 ShareIndputs ......... ........ ......... ......... ......... ......... ....... 16 - 13 ScanneM r oduleRunMode ........ ......... ......... ......... ......... ....... 16-- 15 1747-SDNScannerModuleRun/IdleBit ......... ......... ......... ......... .... 16-- 16 HereH’sow ........ ......... ......... ......... ......... ........ ......... ... 16-- 17

Exercise: Configuring a 1747-SDN DeviceNet Scanner Module ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 19 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 20 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 20 H oDwYidoDuo? . . . . . . . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. .. .. . .. .. . .. .. .. .. 16- 21 16--22 Answers ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 22 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 23 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-- 23

Table of Contents

xi

Mapping Inputs and Outputs to a 1747-SDN Scanner on a DeviceNet Network WhaYtoW u Lillearn ......... ........ ......... ......... ......... ......... ..... WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... MessageTypeandI/OSizes ........ ......... ......... ........ ......... ....... PolleM d essages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . StrobeM d essages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change-of-StateMessages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CyclM ic essages ........ ......... ......... ......... ........ ......... ....

17-- 1 17-- 1 17-- 1 17-- 2 17-- 3 17-- 4 17-- 5 17-- 5

D tpaapPpilnagn . . . . . .. .. .. .. . .. .. .. .. . .. .. .. .. . .. .. .. .. . .. .. .. . .. .. .. .. .. . .. .. .. . .. .. .. .. .. . .. .. .. . .. .. .. .. .. . .. .. .. . .. .. .. .. . .. .. .. .. . .. .. 17-- 717-- 7 MaaM Automatic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17--8 Automatic Mapping Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17--8 ManuM alapping ......... ........ ......... ......... ......... ......... ..... 17-- 9 MaS p egmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 10 Example: PowerFlex 40 Drive Map Segmentation in a 1747-SDN Scanner Module . . . . . . . . . . 17--11 Address Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17--12 1747-SDN Mapping in RSNetWorx for DeviceNet Software and SLC 500 Addresses inRSLogix500Software ......... ......... ......... ........ ......... .... 17-- 12 DeviceDataStructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 16 Example: Data Structure of an ArmorBlock MaXum Input Module . . . . . . . . . . . . . . . . . . . . . . 17--1 6 HereH’sow ......... ......... ........ ......... ......... ......... ......... .. 17-- 17 HereH’sow ......... ......... ........ ......... ......... ......... ......... .. 17-- 18 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 18 Step 1: Identify RSNetWorx for DeviceNet Input Data Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 18 Step 2: Identify RSLogix 500 Input Data File or RSLogix 5000 Input Tags ......... ....... 17--1 9 Step3:IdentifyDeviceDataStructure ......... ......... ......... ......... ..... 17-- 19

Exercise: Mapping Inputs and Outputs to a 1747-SDN on a DeviceNet Network ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 21 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 24 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 24 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 26 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17--28 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 28 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 34 ExerciBse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-- 34

xii

Table of Contents

Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... ExplicitMessagingvs.I/OMessaging ......... ......... ........ ......... ......... TheDeviceNeO t bjecM t ode l ......... ......... ......... ........ ......... ...... Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18-- 1 18-- 1 18-- 1 18-- 2 18-- 2 18-- 2 18-- 3

IAttribute nstance . .. .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. . .. . .. .. .. .. .. .. .. . .. . .. .. .. .. .. .. .. . .. . .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. .. . . .. .. .. .. .. .. .. .. . . 18-- 318--4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 4 Class, Instance, Attribute,and Service CodeLookup ........ ......... ......... ....... 18-- 8 ExpliciM t essagingTypes ........ ......... ......... ........ ......... ......... 18-- 8 Explicit Messaging Using an SLC 500 Processor and a 1747-SDN Scanner Module . . . . . . . . . . . 18--8 Explicit Message Transaction Blocks in SLC 500 Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 10 TransactionHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 10 TransactioBnody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 11 Example: Explicit Message Format for an SLC 500 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 11 Peer-to-PeerExplicitMessaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 12 UCMM (Unconnected MessageManager) Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 12 MethodoCf onfiguration ........ ......... ......... ......... ......... ....... 1 8 - 13 Example: PanelView Peer-to-Peer Explicit Message Configuration . . . . . . . . . . . . . . . . . . . . . 18--1 3 HereH’sow ........ ......... ......... ......... ......... ........ ......... ... 18-- 14

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-- 15 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 18 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18--20

Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators WhaYtoW u Lillearn ........ ......... ......... ......... ........ ......... ...... 19-- 1 WhyTheseSkillsAreImportant ........ ......... ......... ......... ......... .... 19-- 1 BeforYeoBuegin ......... ........ ......... ......... ......... ......... ....... 19-- 1 StatusIndicators(LEDs) ......... ......... ......... ........ ......... ......... 19-- 1 1747-SDNScannerModuleStatusIndicators ......... ......... ........ ......... ... 19-- 2 DeviceNetworkStatusIndicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-- 3 StatusIndicatorInterpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 3 ScannerModuleNumericandAlphanumericCodes ........ ......... ......... ....... 19-- 4 HerH e’osw ........ ......... ......... ......... ......... ........ ......... ... 19-- 5

xiii

Table of Contents

Exercise: Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators ExercAise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-- 7 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-- 9 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19--10 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-- 10 TroubleshootingTips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-- 11

Troubleshooting a DeviceNet Network Using RSLogix 500 Software WhaYtoW u Lillearn

......... ........ ......... ......... ......... ......... .....

20-- 1

WhyTheseSkillsAreImportant ......... ......... ......... ........ ......... .... 20-- 1 BeforYeoBuegin ......... ......... ......... ......... ........ ......... ....... 20-- 1 Relationship Between an RSNetWorx for DeviceNet Software Data Map and I/O Points inRSLogix500Software ........ ......... ......... ......... ........ ....... 20-- 1 RSNetWorxforDeviceNetSoftwareDataMap ......... ......... ......... ........ 20-- 2 DeviceDataStructure ........ ......... ......... ......... ........ ......... . 20-- 3 RSLogix500SoftwareDataFiles ......... ......... ......... ........ ......... . 20-- 5 ScannerModuleStatusRegister ........ ......... ......... ........ ......... .... 20-- 7 HerH e’osw ......... ......... ........ ......... ......... ......... ......... .. 20-- 8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-- 8 Tracing I/O Points through a 1747-SDN Scanner Module ......... ........ ......... .... 20-- 8 Step1:DetermineOutputMapping ........ ......... ......... ......... ........ 20-- 8 Step2:DetermineDataStructure ......... ......... ......... ........ ......... . 20-- 9 Step 3: Determine I/O Point Location in RSLogix 500 Software Output Data File . . . . . . . . . . . . 20--9 Step 4: Verify the Addressing of the Ladder Logic Instruction Controlling the I/O Point . . . . . . . . 20--10

Exercise: Troubleshooting a DeviceNet Network Using RSLogix 500 Software ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-- 11 HoDwYidoDuo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-- 14 Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20--16 ExerciAse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-- 16

Appendices Scanner Module Master Data Maps 1756-DNBScannerModuleMasterDataMap 1747-SDNScannerModuleMasterDataMap

........ ......... ......... ......... ..... ........ ......... ......... ......... .....

A-- 1 A-- 2

Decimal to Hexadecimal Conversion Table DecimaltoHexadecimalConversionTable

......... ......... ........ ......... .......

B-- 1

PowerFlex 40 Drive Data Structure PowerFlex40DriveDataStructure

........ ......... ......... ........ ......... ....

C-- 1

xiv

Table of Contents

Course Overview

Opening Comments:

I

Course Overview

Welcome students. Give administrative details: 1. Class hours 2. Break times 3. Cafeteria information 4. Telephones 5. Restroom locations Ask each student to share: 1. Name and title 2. Company and location 3. How they use DeviceNet on the job

Course Purpose

Optional lessons are available in the back of the course that use the 1747-SDN scanner module and the SLC 500 processor.

This course prepares you to successfully design and configure an efficient DeviceNet network using components for the ControlLogix platform. To meet this objective, you will begin by designing a cable system, and then configuring a driver, a scanner module, and network devices. This course also prepares you to troubleshoot a malfunctioning DeviceNet network and return it to normal operation with minimum downtime. You will first verify proper network installation and then perform both hardware and software--based tasks used to isolate DeviceNet problems. You will also practice the tasks necessary to add and replace network devices. The specific hardware compone nts used in the course include DeviceNet round and flat cable, taps, connectors, power supplies, scanner modules, and DeviceNet-compatible devices such as photoelectric sensors, operator interfaces, packaged I/O, and drives. The software components include RSNetWorx for DeviceNet, RSLinx, and RSLogix 5000 (or RSLogix 500 if arranged before class) software.

Who Should Attend

Rev. July 2008

Individuals responsible for designing and configuring a new DeviceNet network should attend this course. Individuals responsible for isolating and correcting problems or performing basic maintenance on a DeviceNet network should also attend this course.

E 2008 Rockwell Automation, Inc. All rights reserved. ov2i100

II

Course Overview

Prerequisites

To successfully complete this course, the following prerequisites are required:

Poll the class at this time to determine the amount of DeviceNet experience the students have. If the class has a significant amount of DeviceNet experience, the exercises in the course may take less time than indicated.

•

Experience operating a personal computer within a Microsoft r Windowsr environment

•

Completion of the RSLogix 5000 Level 1: ControlLogix System Fundamentals (CCP146) course or knowledge of common ControlLogix terminology and the ability to program and interpret basic ladder logic instructions in RSLogix 5000 software Or

•

Agenda

-5/SLC 500 and RSLogix Fundamentals Completion of theorPLC(CCP122) course knowledge of common programmable controller terminology and the ability to program and interpret basic ladder logic instructions in RSLogix 500 software

This course consists of the following lessons : Day 1 85 minutes

•

Identifying DeviceNet Network Components

150 minutes

•

Designing a DeviceNet Cable System

60 minutes

•

Creating a DeviceNet Network Configuration

45 minutes

•

Commissioning Nodes on a DeviceNet Network

65 minutes

•

Configuring a 1756-DNB DeviceNet Scanner Module

65 minutes

•

Optional: Configuring a 1747-SDN DeviceNet Scanner Module

Day 2 140 minutes

•

Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network

140 minutes

•

Optional: Mapping Inputs and Outputs to a 1747-SDN Scanner Module on a DeviceNet Network

40 minutes

•

Managing DeviceNe t EDS Files

45 minutes

•

Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network

120 minutes

•

Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix Platform

120 minutes

•

Optional: Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform

45 minutes

•

Integrated Practice: Modifying a DeviceNet Network Configuration


Rev. July 2008 ov2i100

Course Overview

III

Day 3 70 minutes

•

Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software

60 minutes

•

Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators

60 minutes

•

Optional: Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators

90 minutes

•

Troubleshooting a DeviceNet Network Using RSLogix 5000 Software

90 minutes

•

Optional: Troubleshooting a DeviceNet Network Using RSLogix 500 Software

60 minutes

•

Troubleshooting Duplicate Node Addresses on a DeviceNet Network

65 minutes

•

Integrated Practice: Restoring a Malfunctioning DeviceNet Network to Normal Operation

Meeting Course Objectives

The following course structure is generally used to facilitate your ability to meet the course objectives: •

One lesson is devoted to each task.

•

Typical lesson includes most or all of these sections:

-- “What You Will Learn” -- lesson objectives -- “Before You Begin” -- preparatory material -- “Here’s How” -- demonstration of procedures -- “Exercise” -- opportunity to perform new skills, often in a hands-on lab environment

-- “How Did You Do?” -- where to go for feedback on performance

-- “Answers” -- answers to exercises •

Rev. July 2008

Integrated practices provide an opportunity to perform tasks using the skills obtained during the training.

E 2008 Rockwell Automation, Inc. All rights reserved. ov2i100

IV

Course Overview

Student Materials

Hold up a Procedures Guide. Take a moment to show the Table of Contents, one or two procedures, and the Glossary. Note that this guide will be a good reference when students are completing tasks on the job.

Open the Documentation Reference Guide from the CD. Take a moment to show a list of publications available on the CD.

Hands-On Exercises

To enhance and facilitate your learning experienc e, the following materials are provided as part of the course package: •

Student Manual, which contains the key concepts, definitions, and examples presented in the course and includes the hands-on exercises.

•

DeviceNet and RSNetWorx Troubleshooting Guide, which contains easy-to- use flowcharts and graphics to help you complete the troubleshootin g tasks presented in class. The guide covers five DeviceN et scanner modules and is also an ideal resource for most troubleshoot ing situations in the plant environment. DeviceNet and RSNetWorx Procedures Guide, which contains clear and concise step-by- step procedures for performing the tasks addressed in class, as well as other tasks associated with maintaining and troubleshooting a DeviceNet network.

•

•

DeviceNet Documentation Reference Guide, which contains several different technical publications in electronic format.

Throughout this course, you will have the opportunity to practice the skills you have learned through a variety of hands-on exercises. These exercises focus on the skills introduced in each lesson. You will also have the opportunity to combine and practice several key skills by completing integrated practices. To complete the exercises and the integrated practices , you will use a DeviceNet workstation.


Rev. July 2008 ov2i100

Lesson

1

Identifying DeviceNet Network Components What You Will Learn

After completing this lesson, you should be able to identify DeviceNet network components.

Why These Skills Are Important The ability to identify DeviceN et network components is important because it will allow quick and accurate recognition for troubleshooting purposes.

Before You Begin Explain that this and the following sections are intended as an overview to provide students with a basic understanding of the DeviceNet network and how it fits into the overall network structure.

NetLinx Open Architecture The DeviceNet network is one of three industrial communications networks that fall under the NetLinx open architecture . The NetLinx open architecture allows easy interconnectivity between networks through the implementation of common communicatio ns protocol and interfaces. The following major industrial communications networks are part of the NetLinx open architecture:

? Does anyone have experience with

•

DeviceNet

any of the other networks in the

•

ControlNet

hierarchy?

•

EtherNet/IP

Network Hierarchy

Network hierarchy is a term used to describe the levels of functionality of each of the major communications networks within the NetLinx open architecture. The networks are organized into the following hierarchical layers, each of which offers a unique type and level of control: Point out that though DH+ and Remote I/O are control layer networks, they are not considered part of the NetLinx open architecture since they do not employ the protocol and interfaces common to NetLinx networks.

Rev. July 2008

•

Information Layer: Gives higher-level computing systems access to plant-floor data.

•

Control Layer: Allows intelligen t automation high-speed control devices to share information.

•

Device Layer: Offers high-speed acces s to plant-floor data from a broad range of plant-floor devices.

E 2008 Rockwell Automation, Inc. All rights reserved. CMPib100

1--2


The following graphic shows the three layers of the NetLinx architecture: Computing Systems

Information Layer Ethernet Network EtherNet/IP Network

Processors and Computing Systems

Control Layer ControlNet Network EtherNet/IP Network

Processors and Devices

Device Layer DeviceNet Network FOUNDATION Fieldbus Network

Operator Interface


Photoelectric Sensor Limit Switch

Drive

Rev. July 2008 CMPib100

1 -- 3


DeviceNet Network A DeviceNet network connects industrial devices to a processor or controller and application software without the need for hardwiring. Devices may include limit switches, photoelectric sensors, pushbuttons, bar code readers and drives: Processor or Controller Chassis with Scanner Module ArmorBlock MaXum I/O Module

RediSTATION t Operator Interface Photoelectric Sensors

1794-ADN Flex I/O t Adapter Module and I/O Modules

Bulletin 160 Drive

RS-232 Cable Host Computer with RSNetWorx for DeviceNet Software

1770-KFD Module

Point out that the non-DeviceNet network uses a separate connection for each individual device, whereas, on the DeviceNet devices connected network, to a common bus.are Theall DeviceNet network eliminates extensive wiring and installation labor.

The following graphic shows the same devices on a Remote I/O network, which requires that each device be individually wired to the control chassis:

Processor Chassis ArmorBlock I/O Module

Remote I/O Network

I/O Operator Interface

DH+ Network

Rev. July 2008

Sensors

Drive

Host Computer with Programming Software


1--4


Benefits of a DeviceNet Network Using a DeviceNet network provides the following benefits: •

Simplified wiring

•

Support for both “smart” and standard devices

between smart and standard devices?

•

Answer: Smart devices provide several protective and control functions, including status information for diagnostic and troubleshooting purposes.

Choice of performing device configuration from a computer or at the device itself

•

Support for network-powered (sensors) and self-powered (actuators) devices

•

Support for the removal and/or replaceme nt of devices under power (“plug-and- play” capability) without breaking the network connection

•

Support for real-time control data exchange

•

Support for interchangeabil ity of devices from multiple vendors

? Can anyone explain the difference

Point out the 871TM inductive proximity sensor is one example of a “smart” device because its capabilities include providing target range information by means of an analog signal.

DeviceNet Network Applications

? Why was a DeviceNet network chosen for implementation at the plant where you work? Which of these characteristics are met by the application at the plant where you work?

Poll the class to get a sense of the types of applications DeviceNet networks are being used for at students’ places of employment.


DeviceNet networks are best-suited for applications with the following characteristics: •

Applications that would otherwise require extensive hardwiring

•

Applications with a large number of devices connected to multiple I/O points (distributed or rack-based)

•

Applications that require a quick start-up

•

Applications for which downtime to add and replace devices is not an option

•

Applications that require extensive preventative diagnostic capabilities

•

Applications with small devices that are distant from each other

•

Applications with devices that are not wired individually to a control panel

•

Applications that use multiple short and simple data packets



1 -- 5

DeviceNet Network Components Tell students that most of the individual components mentioned in this section will be covered in detail in later lessons. This and the ensuing sections are only meant to familiarize students with general DeviceNet components and terms.

A DeviceNet network is comprised of both hardware and software components. The following hardwar e components make up a DeviceNet network: •

Power supply

•

DeviceNet cable (flat, thick or thin):

-- Trunk line cable -- Drop line cable •

Terminating resistors

•

Taps:

-----•

T-Port tap DeviceBox tap PowerTap tap DevicePort tap Open-style tap

Insulation displacement connectors (IDCs):

-- Open-style -- Micro •

Connectors:

-- Sealed -- Open-style •

Scanner module

•

Explain that, since the DeviceNet network is an open network, software programs developed by various vendors can be used to access and configure DeviceNet devices. Note that a device manufactured by Rockwell Automation can be configured using a software program developed by another vendor as long as an appropriate EDS (electronic data sheet) file exists for the device. The same is true for configuring third party devices using Rockwell software programs.

Rev. July 2008

Devices (nodes) The following software components are required to access, configure, and maintain a DeviceNet network: •

Network configuration software such as RSNetWorx for DeviceNet software

•

Linking software such as RSLinx software

•

Programming software such as RSLogix 5, RSLogix 500, or RSLogix 5000 software


1--6


Power Supply A DeviceNet network requires its own 24 V DC power supply with current limit protection. Depending upon the current draw and positioning of network devices, more than one power supply may be needed per network.

Tell students that the power supply used in the DeviceNet workstations is secured behind the front panel and is therefore not visible.

1606-XLS Power Supply

DeviceNet Cable A specific type of cable is required for DeviceNet networks and falls into one of the following two main categories: Round

Flat

DeviceNet round cable has the following general characteristics:


•

Two power wires, two signal wires, and a bare (drain) wire

•

A yellow or gray exterior



1 -- 7

The following graphic shows a cross-segment of round cable: Vinyl Jacket

Beldfoil Aluminum/Polyester Shield

Polypropylene Fillers

Blue & White Data Pair

Point out that only the thick version of KwikLink flat cable is really “flat.” The thinner version, often used on drop lines, is similar in appearance to round thin cable, except that it sometimes has a gray exterior.

65% Coverage

Strained Drain Wire

Tinned Copper Braid Shield

Tinned Copper

Red & Black DC Power Pair

DeviceNet KwikLink flat cable has the following general characteristics: •

Two power wires and two signal wires (no drain wire)

•

A gray exterior

The following graphic shows a cross-segment of KwikLink flat cable: Gray Exterior Jacket

Power and Signal Wires

Each of the two DeviceNet cabling options has unique benefits, as shown in the following table: Explain that devices can be “clamped” directly onto a KwikLink flat cable trunk line, thereby eliminating the need to sever it in order to install a device.

Rev. July 2008

Round Cable Benefits

KwikLink Flat Cable Benefits • Allows

• Provides

good noise immunity • Lends itself to quick network breakdown for troubleshooting purposes

connectors to be attached virtually anywhere on the network without the need to sever the trunk line • Supports both 4 A (Class 2) and 8 A (Class 1) current ratings • Has physical keying to help prevent wiring mishaps


1--8


DeviceNet round and KwikLink flat cable can be further divided into the following categories:

Point out that it is sometimes difficult to distinguish between trunk line and drop line cable on DeviceNet network installations, especially when the same gauge of cable is used for both the trunk line and the drop line. However, it’s very important to be able to distinguish between the two for troubleshooting purposes.

•

Trunk Line: The main cable from which devices are connected via drop lines. Trunk line cable is considered the “backbone” of a DeviceNet network.

•

Drop Line: The cable that connects devices on the network to the trunk line. It is typically smaller in diameter than trunk line cable and carries less current.

The following graphic shows trunk line and drop line cable on a DeviceNet network that uses round cable: Trunk Line

Drop Line Drop Line

DeviceNet Wire Function Tell students it’s important to recognize and understand the specific function of each DeviceNet cable wire component, since opens and shorts on these wires

DeviceNet cable consists of several distinct wires. Each wire performs a specific function and has unique characteri stics, as shown in the following table:

are often the root of network problems. Explain that the DeviceNet network is actually a three wire differential voltage network. Communication occurs when the CAN_H (white) wire’s signal is switched with the CAN_L (blue) wire’s signal relative to the V -- ( black) power wire.

Tip "


This color wire . . .

Is called the . . .

And performs this function . . .

Black

V--powerwire

Supplies V-- power to the network

Red

V+powerwire

Supplies V+ power to the network

White

CAN_Hsignalwire

Carries the high communications signal

Blue

CAN_Lsignalwire

Carries the low communications signal

Bare (round cable only)

Drain wire

Provides noise immunity

KwikLink flat cable does not contain a bare (drain) wire, as it is unshielded cable.



1 -- 9

Terminating Resistors Point out a terminating resistor on a workstation. To help students understand the concept of signal reflection on a network, compare it to an echo in human language. Explain that though communication can still occur if an echo exists, it may not be clear and the message being sent can easily be lost or misunderstood.

Terminating resistors are essential components of a DeviceNet network, as they reduce communica tions signal reflection. By providing an endpoint for communications data on the network, they prevent the DeviceNet signal from being “bounced” back through the line and distorted. The following graphic shows examples of terminating resistors used with round cable and with KwikLink flat cable:

Female Terminating Resistor Used with Round Cable Male Terminating Resistor Used with Round Cable

Tip "

Terminating Resistor with End Cap Used with KwikLink Flat Cable

Male and female terminating resistors used with round cable can be easily distinguish ed by their color alone: male terminating resistor s are gray and the female terminating resist ors are black.

Taps Stress that taps are only used with round cable to connect drop lines to the trunk line.

Rev. July 2008

Taps are used with round cable to connect a drop line to the trunk line. The following types of taps are available for use on DeviceNet networks: •

T-Port tap

•

DeviceBox tap

•

PowerTap tap

•

DevicePort tap

•

Open-style tap


1--10


T-Port Tap Point out a T-Port tap on a workstation.

T--Port taps connect to trunk and drop lines and provide right or left keyways (cable attachments) for device positioning purposes:

? Why are right and left keyways beneficial? Answer: They enable devices that are attached directly to the trunk line (zero drop) to be positioned facing in the right direction.

Trunk Line Connection

Trunk Line Connection

Drop Line Connection

DeviceBox Tap If available, pass around samples of these taps.

DeviceBox taps connect devices directly to a round cable trunk line and drop line connections for as many as eight devices:

Stress that taps are not considered nodes on a DeviceNet network. Trunk Line Connection

Drop Line Connections

PowerTap Tap

PowerTap taps are mounted directly on a trunk line and connect a network to a power supply. PowerTap taps offer the following benefits: Make students aware that PowerTap taps are sometimes used to replace a single, higher current power supply when national or local codes limit the maximum rating of a power supply. Stress that problems can arise on a network if the proper rules are not followed for this type of configuration.

•

Provide overcurrent protection to thick trunk line cable

•

Can be used with fuses to connect multiple power supplies to the trunk line without back-feed ing between supplies

Refer students to the Documentation Reference Guide for detailed information. E 2008 Rockwell Automation, Inc. All rights reserved.


1--11


The following graphic shows a PowerTap tap:

Fuse Connection

DC Power Supply

PowerTap Tap

Fuse Connection

Tip "

Trunk Line

When using a PowerTap tap to feed cable only on one side of the tap, remove the unused fuses. DevicePort Tap

If available, point out the eight connections on the tap.

DevicePort taps are multiport taps that connect to a round or KwikLink flat cable trunk line via drop lines. One DevicePort tap can connect as many as eight devices to a network at a time:

Point out that DevicePort taps are beneficial because they reduce the number of drop lines on a DeviceNet network. Remind students that a DevicePort tap itself does not count as a node on a DeviceNet network. Only the devices attached to it count as nodes.

Trunk Line

Drop Line

DevicePort Tap

Connections for Devices

Rev. July 2008

Connections for Devices


1--12


Open-Style Tap Point out an open-style connector on one of the classroom workstations.

Open-style taps connect drop lines to the trunk line and contain exposed wires for flexibility: Trunk Line

Open-Style Tap

Device Drop Line

? Why do you think it’s so important for

Important:

Open-style taps must be protected by an enclosure.

open-style taps to be placed in enclosures? Answer: Their exposed wires lend themselves to noise that can disrupt the communications signal.

? To which network component that has already been discussed can insulation displacement connectors be compared and why? Answer: Insulation displacement connectors are comparable to the taps used with round cable, because they also connect drop lines to a trunk line.


Insulation Displacement Connectors KwikLink flat cable systems use insulation displacement connectors to connect drop lines to the trunk line and to connect devices directly to the trunk line. The following insulatio n displacement connectors are available: • •

KwikLink open-style connector KwikLink micro connector

KwikLink insulation displacement connectors have the following features: •

A hinged, two-piece base that snaps easily around the flat cable

•

The capability to be attached at any point on the trunk line

•

Screws that drive the contacts through the cable jacket and directly into the conductors


1--13


The following graphic shows a KwikLink flat cable system with devices attached to the trunk line using insulation displacement connectors: KwikLink Open-Style Connectors KwikLink Micro Connector

Power Supply

Drop Line

Trunk Line KwikLink Micro Connectors

Terminating Resistor Processor Chassis

? Why is the ability of a KwikLink connector to attach directly to a segment of flat cable so useful? Answer: It allows maintenance and repair work to be completed with minimum disruption to plant operations, since the entire network does not need to be shut down for an extended amount of time while the cable is dismantled and

Terminating Resistor

Enclosure

KwikLink Open-Style Connector

KwikLink open-style connectors attach devices directly to a KwikLink flat cable trunk line and contain exposed wires for flexibility: KwikLink Open-Style Connector

Exposed Wire Connection

re-connected. Note that open-style connectors are useful because their exposed wires make voltage checks easier. KwikLink Flat Cable Trunk Line

KwikLink open-style connector s must be protected by an enclosure.

Rev. July 2008


1--14


The following graphic shows a KwikLink flat cable segment with an open-style connector: CAN_H (White) Signal Wire Screw Terminal

CAN_L (Blue) Signal Wire Screw Terminal

V+ (Red) Power Wire Screw Terminal

V- (Black) Power Wire Screw Terminal KwikLink Open-Style Connector

KwikLink Flat Cable Trunk Line

KwikLink Micro Connector Note that this type of connector is sometimes referred to as a “vampire clamp”, since it has “teeth” that attach directly to the trunk line cable.

KwikLink micro connectors attach devices directly to a KwikLink flat cable trunk line: KwikLink Micro Connector





1--15

The following graphic shows a KwikLink flat cable segment with three micro connectors: KwikLink Micro Connectors

Drop Line Cable


Scanner Module Do not go into detail about scanner module function or about the different types of scanner This information will bemodules. addressed in a later lesson.

Rev. July 2008

A scanner module is an interface between network devices and the processor or controller that is controlling them. Since data cannot pass directly from a processor or controller to a device, nor from a device directly to a processor or controller on a DeviceNet network, a scanner module organizes the data and stores it in data tables where it can be easily accessed by a processor or controller and devices.


1--16


The type of scanner module that is used on a DeviceNet network depends upon the processor or controller platfor m being employed. The following graphic shows four of the types of scanner modules Rockwell Automation manufactures for use on DeviceNet networks:

1771-SDN Scanner Module For Use with the PLC-5 Platform

1747-SDN Scanner Module For Use with the SLC 500 Platform

1756-DNB Scanner Module For Use with the ControlLogix Platform

1784-PCIDS Scanner Card For Use with the SoftLogix 5800 Platform

Scanner Module Location Tell students that, since they are used with “soft” controllers, 1784-PCIDS scanner cards are not installed in a

A DeviceNet scanner module is generally located in the chassis with the processor or controller being used on the network. The following

hardware rather computer. in the PCI expansionchassis, slot of a but personal

graphic a ControlLogix chassis withina slot ControlLogix controller in slot 0 shows and a 1756-DNB scanner module 1:

Do not go into detail about scanner module function; it will be covered in a later lesson. 1756-DNB ControlLogix Controller


Scanner Module


1--17


Devices (Nodes)

? Think back to the beginning of this lesson. Which two wires in the DeviceNet cable transmit the DeviceNet signal? Answer: The CAN_H (white) and CAN_L (blue) wires.

To be DeviceNet-compatible, a device must have specific communications circuitry. The following table lists the general categories of DeviceNet-compatible devices and specific examples of devices manufactur ed by Rockwell Automation that fall into each category: Device Category

Packaged I/O Modular I/O

Examples • ArmorBlock

MaXum I/O I/O

• CompactBlock • 1794 Flex I/O

• 1734 POINT I/O • SmartSight 9000 photoelectric sensor

Sensors

• RightSight photoelectric sensor • 871TM inductive proximity sensor • PanelView Plus

Consult the DeviceNet Selection Guide for the latest information on DeviceNet-compatible devices manufactured by Rockwell Automation.

Operator interfaces

• 800E

operator interface pushbutton station

• 855T control tower stack light

Power and energy management devices

• Powermonitor I

and Powermonitor 3000 power

quality meters • Bulletin 100 DSA (DeviceNet starter auxiliary)

Motor starters and protectors

• E3 solid-state overload relay • Bulletin 2100 IntelliCENTER Motor Control

Center

(MCC) • Bulletin 160 drive

Drives

• Bulletin 1305 AC drive • PowerFlex 70 AC drive

Motion control devices

• ULTRA

3000 and ULTRA 5000 servo drives

EtherNet/IP to DeviceNet Linking Device

The 1788-EN2DN linking device allows for bridging from EtherNet/IP to DeviceNet networks and also acts a master scanner on the DeviceNet network:

Connection to DeviceNet Network

Rev. July 2008

Connection Network to EtherNet/IP


1--18


Explain to students that the following section is meant to familiarize them specifically with the devices included in the DeviceNet workstations.

Absolute Multi-Turn Encoder 842D

An encoder converts a signal or data to code. The Multi--Turn Encoder can be identified by its white--faced knob and small crank.

E3 Solid-State Overload Relay Mention that the E3 solid-state overload relay is especially important for maintenance and troubleshooting, since it can alert a user to dangerous conditions before they cause damage.

An E3 solid-state overload relay is a motor protector that monitors motor performance and provides crucial diagnostic information for damaging conditions such as thermal overload, phase loss, stall, jam, underload, and current imbalance:

Motor Contactor

E3 Solid-State Overload Relay Connection to DeviceNet Network




1--19

PowerFlex 40 Drive Tell students that the PowerFlex 40 drive contains many diagnostic parameters that can be used when troubleshooting.

A PowerFlex 40 drive is a compact and highly functional speed controller. When used on a DeviceNet network, a DeviceNet communications adapter is affixed to the front of the PowerFlex 40 drive for controlling and monitoring purposes :

PowerFlex 40 Drive

DeviceNet Communications Adapter


871TM Inductive Proximity Sensor Point out that one of the features of the 871TM inductive proximity sensor is the fact that it can sense exactly how close or far away a target is.

Like the RightSight photoelec tric sensor, an 871TM inductive proximity sensor is a “smart” device and is able to provide a significant amount of diagnostic information about itself:


Rev. July 2008


1--20


ArmorBlock MaXum I/O Module

Depending upon the option chosen, an ArmorBlock MaXum I/O module can support as many as eight separate I/O connections from one location. Among the module’s advanced capabilities is the ability to provide point-level diagnost ics for the devices attached to it:

Explain that the ArmorBlock MaXum modules on the DeviceNet workstations used in class are input modules only.

I/O Connections

I/O Connections

DeviceNet Flat Cable

Point I/O DeviceNet Adapter Point out the 1734-ADN behaves as a slave device on the main DeviceNet network and a master on the Point I/O subnet. This allows all of the Point I/O modules on the subnet to count only as one node number on the DeviceNet main network.

The 1734-ADN Point I/O DeviceNet adapter interfaces between DeviceNet network and Point I/O modules. Each type of communication interface supports a maximum of 13 to 17 modular Point I/O modules:

Connection to DeviceNet Network Point I/O Modules




1--21

PanelView Plus Operator Interface Note that PanelView Plus operator interfaces are very popular DeviceNet-compatible devices and are often used to display specific device fault and diagnostic information. Tell the class that this capability will be explored in a later lesson.

A PanelView Plus operator interface is a sophisticated operator control terminal with advanced graphics capabilities :

DeviceNet Connection (In Back of Terminal)

1770-KFD Module Note that the 1770-KFD driver is a software subroutine, while the 1770-KFD (or RS-232) module is a physical module used to implement a connection to a DeviceNet network via the 1770-KFD driver.

A 1770-KFD (RS-232) module is used to connect a computer that contains RSNetWorx for DeviceNet software to a physical DeviceNet network using a 1770-KFD driver:

Network Status Indicator RS-232 Status Indicator

Module Status Indicator

Power Switch RS-232 Connector to Computer Serial Port

If you have not already done so, hold up a copy of the Procedures Guide and tell or remind students that step-by-step instructions to complete the RSNetWorx for DeviceNet software-based tasks addressed in class are included in the guide.

Rev. July 2008

Power Supply Connector

RSNetWorx for DeviceNet Software RSNetWorx for DeviceNet software is the main software program sold by Rockwell Automation used to configure, maintain, and troubleshoot DeviceNet networks. RSNetWorx for DeviceNet software allows you to perform the following maintena nce and troubleshooting tasks: •

View a graphic repres entation of the network and its status

• •

Determine which devices are and are not communicating on the network Monitor device parameters

•

Determine device-specific faults

•

Configure newly added or replacement devices E 2008 Rockwell Automation, Inc. All rights reserved. CMPib100

1--22


RSLinx Classic Software RSLinx Classic software “links” a personal computer with RSNetWorx for DeviceNet software to a physical DeviceNet network so that a graphic representation of the network can be viewed and monitored online. This is accomplished through the use of software subroutines called drivers, which define the link that is used to access a physical network.

RSLogix 5, RSLogix 500, and RSLogix 5000 Software The type of processor or controller on a DeviceNet network determines the type of programming software used. The following table lists the three main Windows-based programming software programs sold by Rockwell Automation and the processor or controller platform(s) used with each: Tell students they will be using RSLogix 5000 software (or RSLogix 500 software if it has been arranged) in this class.

Software Program

RSLogix 5 RSLogix 500

Processor or Controller Platform • PLC-5 • SoftLogix

5

• SLC

500 • MicroLogix • ControlLogix • FlexLogix

RSLogix 5000

• CompactLogix • SoftLogix

5000

• DriveLogix

Here’s How On your workstation, briefly point out the major DeviceNet components addressed in this lesson.


To identify DeviceNet network components. As your instructor demonstrates this procedure, follow along on your DeviceNet workstation.


Exercise: Identifying DeviceNet Network Components

1--23

Exercise: Identifying DeviceNet Network Components Exercise A

In this exercise, you will practice identifying DeviceNet network components.

Context: You must be able to identify the hardware and software components that make up the plant’s Devic eNet network before you can begin performing troubleshooting and maintenance tasks.

Directions: Identify componen ts on the DeviceNet worksta tion and complete the required information below. 1. Identify each of the following components and place a check in the box next to each one as you locate it:

-

Round cable KwikLink flat cable Flat cable terminating resistor 1756-DNB scanner module Absolute Multi-turn encoder E3 overload relay 1734--ADN Point I/O ArmorBlock MaXum input module PowerFlex 40 drive 871TM inductive proximity sensor PanelView Plus operator interface

2. Identify all of the types of insulation displacement connectors found on the workstation:

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. CMPe100

1--24


3. Match the DeviceNet cable wires to the appropriate descript ion: A. Black wire B. Red wire C. White wire D. Blue wire E. Bare (round cable only)

CAN_H signal wire V+ power wire V- power wire Drain wire CAN_L signal wire

How Did You Do?

Turn to the Answers section.

Exercise B

In this exercise, you will practice identifying cable system components on a DeviceNet network.

Context: A DeviceNet network will be used to run the oven line and cooling rack portions of the production line. A scanner module and devices to be used on the line have already been selected, but the appropriate cable system components must still be identified. Since a combination of flat and round cable will be used on the line, you must be familiar with the cable components used with both of these options.

Directions: Identify the types of cables, taps, and connectors numbered on the following two graphics. Space is provided after the graphics for recording answers.


Rev. July 2008 CMPe100


1--25

1 2 4

3

Round (Thick) Trunk Line Cable

5

8 9 6

7

Enclosure

Enclosure KwikLink Flat Cable Trunk Line

10

11

1.

2.

3.

Rev. July 2008


1--26


4.

5.

6.

7.

8.

9.

10.

11.

How Did You Do?





Rev. July 2008

1--27


1--28


Answers

Exercise A 2. The DeviceNet workstatio n contains both open-style and micro insulation displacement connectors. 3. C. CAN_H signal wire, carries the high communications signal B. V+ power wire, supplies V+ power to the network A. V-- power wire, supplies V- power to the network E. Drain wire, provides noise immunity D. CAN_L signal wire, carries the low communications signal

Exercise B 1. Terminating resistor 2. T-Port tap 3. PowerTap tap 4. DevicePort tap 5. Trunk line 6. Drop line 7. DeviceBox tap 8. Open-style direct connector 9. Terminating resistor 10. KwikLink micro connector 11. KwikLink open-style connector



Lesson

2

Designing a DeviceNet Cable System What You Will Learn

After completing this lesson, you should be able to design a DeviceNet cable system by performing the following tasks: •

Determine maximum trunk line distance and verify that it falls within specification

•

Determine cumulative drop line length and verify that it falls within specification

•

Determine the requirements for supplying power to a network using the look-up method

•

Determine the requirements for supplying power to a network using the full-calculation method

Why These Skills Are Important Accurate design of a DeviceNet cable system and its components is important for the following reasons:

Before You Begin If available, show students examples of the cables.

Rev. July 2008

•

Incorrect cable configuration can cause downtime on the network. If the cable system is not configured according to the specifications, erratic network operation may result and the network may need to be reconfigured.

•

Correct design results in faster, more efficient communications on the network.

DeviceNet Cable A DeviceNet cable system requires specific cable types . Depending on the application, two basic categories of cable may be used: •

Round cable

•

Flat cable

E 2008 Rockwell Automation, Inc. All rights reserved. CBLib100

2--2


Round Cable

Round cable can be divided into the following categories: Round Cable Category

Description • Is typically used for trunk line, but

Thick

• Has an 8 A

current rating

• Is typically used for drop lines, but

Thin

may be used for trunk line

• Is more flexible than thick cable •

Note that Rockwell Automation round (thick) cable power conductors are sized to handle at least 8 A, but the NEC regulations limit the cable to 4 A because of the type of insulation that is used on the CAN_H and CAN_L wires.

may also be used for drop

lines • Has an outside diameter of 12.2 mm (0.48 in)

Has an outside diameter of 6.9 mm (0.27 in)

National Electric Code (NEC) and Canada Electric Code (CEC) dictate that any DeviceNet installation in North America using thick (round) trunk line cable and thin drop line cable must be a Class 2 installation, thereby imposing a current limit of 4 A on these installations, regardless of the fact that the cable actually has an 8 A rating.

The NEC and CEC limitations for round (thick) cable used in North America do not apply to round (thick) cable use in networks that are part of DeviceNet MCCs (Motor Control Centers).

Flat Cable Point out that KwikLink is a brand of flat cable manufactured by Rockwell Automation.

KwikLink flat cable is another DeviceN et cabling option. The following are general characteris tics of KwikLink flat cable: •

Physical flexibility

•

Physical keying to prevent wiring mishaps

•

Cable length flexibility

Explain that devices can be “clamped” directly onto a KwikLink flat cable trunk line, thereby eliminating the need to sever the cable in order to install a device.

•

Support for connections anywhere on the network

•

Ease of device installation without severing trunk line or shutting down the network

•

Support for both 4 A (Class 2) and 8 A (Class 1) power supplies

Tell students that it is possible to use 8 A on a Class 2 flat cable, but the power supply must be placed directly in the middle of the line, with 4 A feeding each side.

•

Un-shielded wiring

•

Availability of four conductors that are not twisted pairs


Rev. July 2008 CBLib100


Note that lack of a shield wire in KwikLink cable reduces materials costs and helps make it a less expensive cabling option.

2 -- 3

Note that although KwikLink flat cable is unshielded, the power and signal wires are in a horizontal configur ation with the two power wires at opposite ends from one another. This feature helps inhibit noise coupling from the power wires to the signal wires, even though no shield is present.

KwikLink flat cable can be divided into the following categories: KwikLink Flat Cable Category

Description • Is used with Class 1 power

supplies an 8 A rating

• Has

Class 1

• Is typically used for trunk line when

flexible cable or modular design is needed • Is used with Class 2 power

Thick

supplies a 4 A rating • Is typically used for trunk line when flexible cable or modular design is needed • Has

Class 2

• Is used with Class 1 power

Auxiliary Power Cable

supplies an 8 A rating auxiliary power bus to output devices

• Has

• Is used to run an

Drop

• Is only used as drop line with

KwikLink flat cable systems

• Is an un-shielded 4 conductor cable

Trunk Line Cable Point out the trunk line on a workstation.

Rev. July 2008

The trunk line is the backbone of the network because it connects all devices to each other. A DeviceNet trunk line must meet the following requirements: •

For round and Class 1 KwikLink flat cable systems, must not carry more than 8 A of current

•

For Class 2 KwikLink flat cable systems, must not carry more than 4 A of current

•

Must not exceed the length allowable based on the data rate of the network


2--4


Maximum Trunk Line Distance Do not present examples now. Maximum trunk line distance calculation will be demonstrated in the Here’s How section.

The distance between any two points on a DeviceNet network cannot exceed the maximum trunk line distance for the data rate used, as shown in the following table:

Inform students that the information in the table is also included in the Documentation Reference Guide.

Tip "

Point out that the term “maximum trunk line distance” is often used interchangeably with the term “maximum cable distance.” The former term is used consistently in this course.

Data Rate

Maximum Distance (KwikLink Flat Cable)

Maximum Distance (Round Thick Cable)

125k bit/s

420 m (1378 ft)

500 m (1640 ft)

250k bit/s 500k bit/s

200 m (656 ft) 75 m (246 ft)

250 m (820 ft) 100 m (328 ft)

Maximum Distance (Thin Cable)

100 m (328 ft) 100 m (328 ft) 100 m (328 ft)

In most cases, the maximum allowable trunk line distance will be the same as the distance between each end of the network (i.e., between terminating resistors) . However, if the distance from a trunk line tap to the farthest device on the network is greater than the distance from that tap to a terminating resistor, the drop line length must be included as part of the total cable length. If using a combination of round and flat cable on a trunk line, the maximum trunk line distance for the entire network should be calculated using the flat cable guidelines.

Drop Line Cable Point out a drop line on a classroom workstation. Tell students that sometimes devices are connected directly to the trunk line without a drop line in between. Do not go into detail about these types of connections as they will be covered later in this lesson.

Tip "


A drop line connects devices on the network to the trunk line and typically uses thin cable. A drop line must meet the following specifications: •

Current capability must not exceed 3 A

•

Length must not exceed 6 m (20 ft) from the farthest device on a drop line to the trunk line

More than one device can be connected to a drop line by means of “branches,” but the length from the farthest device on a branch to the trunk line still must not exceed 6 m (20 ft).



2 -- 5

The following graphic shows a cable configuratio n with branching and non-branching drop lines:

Maximum of 6 m (20 ft)

Maximum of 6 m (20 ft)

Cumulative Drop Line Length

The cumulative drop line length refers to the sum of all drop lines in the cable system. This sum cannot exceed the maximum cumulative length allowed for the data rate used, as shown in the table below: Inform students that the information in the table is also included in the Documentation Reference Guide.

Data Rate

Cumulative Drop Line Length

125kbit/s

156m(512ft)

250kbit/s

78m(256ft)

500kbit/s

39m(128ft)

Mention that the Allen-Bradley MediaChecker is a good tool to verify proper DeviceNet cable installation.

The maximum data rate for a network must be determined based on the length of the trunk line as well as the cumulative drop line length.

Devices (Nodes)

? Does your computer count as a device on the network? Answer: Yes, the computer/communications driver is counted as a device.

Consider discussing the benefits of using a simple I/O device, such as a RightSight photoelectric sensor, vs. a more complicated I/O device, such as ArmorBlock I/O. Explain that a sensor is only a one-for-one I/O connection, while ArmorBlock I/O can accommodate several devices at one node.

Rev. July 2008

A DeviceNet device is any device on the network that is addressable and contains the DeviceNet communications circuitry. Devices are often referred to as “nodes” on a DeviceNet network. Some examples of devices commonly used on DeviceNet networks include the following devices: •

I/O adapters

•

Photoelectric sensors

•

Operator interfaces

•

Drives

•

Motors

•

Bar code readers

•

Pushbuttons


2--6


Note that not all DeviceNet-compatible devices are DeviceNet-certified by ODVA. To ensure reliability in operation, advise students to make sure the devices they invest in are, in fact, certified.

DeviceNet-compatible devices are manufactured by many different vendors but must all meet a certain set of criteria to be deemed DeviceNet-compliant by ODVA (Open DeviceNet Vendor Organization). Devices that pass ODVA conformance testing receive the Conformance Te sted Service Mark shown in the following graphic:

CAN Technology

Communication between devices on a DeviceNet network occurs through the use of CAN (Controller Area Network) technology . Simply stated, communication is accomplished by differentiating between a dominant signal (the voltage difference betwee n the CAN_H wire and the CAN_L wire must be within certain limits) and a recessive signal (the voltage differe nce between the CAN_H wire and the CAN_L wire should be as close to 0 volts as possible):

Device Components

To communicate on a DeviceNet network, a device must contain the following physical components:

Tip "


•

Transceiver: A component that allows the transmission and reception of CAN signals between a device and a network.

•

Connector: A component that is used to attach a device to DeviceNet cable.

•

Miswiring Protection Circuitry: A component that prevents any of the four DeviceNet power and signal wires from being inserted through the improper slot of a connector.

•

Regulator: A component that reduces the amount of voltage a device receives from a network to the amount actually needed to

power the device. A device can draw power from the network itself, from an external power source, or from a combination of both.


2 -- 7


DeviceNet devices must meet the following requirements: Make sure everyone understands that 64 nodes are supported on the network, but the highest node number that can be assigned is 63, since nodes are counted from 0 to 63.

Tip "

•

The distance between the trunk line and the device (i.e., the length of the drop line) cannot exceed 6 m (20 ft).

•

Devices must be DeviceNet-compatible.

•

Devices may not be rated for more than 3 A of current draw based on cable length requirement s

•

Each device must be assigned a unique node address.

64 devices (nodes) can be supported on one network.

Insulation Displacement Connectors KwikLink flat cable systems use insulation displacement connectors to connect drop lines to the trunk line and to connect devices directly to the trunk line. The following insulati on displacement connectors are available: If available, pass around examples of these connectors.

•

KwikLink open-style connector

•

KwikLink micro connector:

-- NEMA rated 6P connector -- NEMA rated 1 connector

? Why is the ability of an insulation

KwikLink insulation displaceme nt connectors have the following features: •

A hinged, two-piece base that snaps easily around the flat cable

displacement connector to snap directly

•

The capability to be attached at any point on the trunk line

onto a trunk line so useful?

•

Screws that drive the contacts through the cable jacket and directly into the conductors

Answer: It allows devices to be added to a network without severing the trunk line and shutting down production for extended periods of time.

The following graphic shows a KwikLink flat cable system with devices attached to the trunk line using insulation displacement connectors:

KwikLink Open-Style Connectors KwikLink Micro Connector

Power Supply

Trunk Line

KwikLink Micro Connectors

Terminating Resistor Processor Chassis Rev. July 2008


Enclosure


2--8


KwikLink open-style connecto rs must be protected by an enclosure.

KwikLink micro connectors are further divided into the following subcategories: •

NEMA 6P rated

•

NEMA 1 rated

Inform students that the difference between the two types of KwikLink micro connectors is the fact that the NEMA 1 rated connectors support fewer environmental conditions than the 6P rated connectors.

The NEMA 1 rated connector is not protected from circulating dust or any type of liquid.

Neither the 6P rated nor the 1 rated connector is protected from oil or coolant.

Power Supplies The following rules apply to power supplies on a DeviceNet network: •

The power supply must have its own current limit protection.

•

The power supply must be placed as close to the center of the network as possible.

•

Fuse protection must be provided for each segment of the cable system.

•

The power supply must be sized to provide each device with its required power.

•

Maximum current must be calculated based on drop line length.

The following table shows the allowable current for several drop line lengths: Inform students that the information in the table is also included in the Documentation Reference Guide.

Drop Line Length

1.5m(4.9ft) 2m(6.6ft) 3m(9.8ft)


Allowable Current

3A 2A 1.5A

4.5m(14.8ft)

1A

6m(19.7ft)

0.75A



Show students how to search for the look-up charts in the Documentation Reference Guide. It is not necessary to explain the charts. The Here’s How section of this lesson is used to demonstrate power requirement calculations. Stress that the look-up method provides the most conservative calculation. A system that does not fall within specifications using the look-up method may still meet specifications using the full-calculation

2 -- 9

Power Supply Requirement Calculation

Certain specifications exist for power requirements on a DeviceNet network. To determine the power requirements of a system, one of the following methods is used: •

The Look-Up Method: Power supply requirements are determined using look-up chart s. This method is used whe n an initial evaluation finds that no section of the cable system is overloaded.

•

The Full-Calculation Method: Power supply requirements are

method.

determined usingfinds an equation. This method is usedsystem whe nisan initial evaluation that one section of the cable overloaded or when the configuration is not covered by the charts in the look-up method.

Tip "

The look-up method is typically used first and provides the most conservative power supply calculation. If the look-up method result indicates that a power supply does not fall within specification, it is possible that the full-calculatio n result will indicate otherwise.

Terminating Resistors To help students understand the concept of signal reflection on a network, compare it to an echo in human language. Explain that though communication can still occur if an echo exists, it may not be clear and the message being sent can easily be lost or misunderstood.

Terminating resistors are used to reduce the reflection of communications on the network. In other words, they provide an endpoint for communications data on the network so that the communications signal is not “bounced” back through the line. Terminating resistors must comply with the following specifications: • Must be installed on both ends of the network (trunk line) •

Must be 120/121

Ω

1/4 W resistors

No more and no less than two terminating resistors must be installed on a network. Terminating resistors are selected based on the type of cable and connector being used, as shown in the following table: And the end device uses this tap. . .

If the cable is . . .

Round Flat

Then this terminating resistor is used . . .

T-Porttap

Sealed

Open--s tyle tap

Open-style

N/A

A snap-on cap for the flat cable connector (available in sealed and unsealed versions)

Rev. July 2008


2--10


If terminating resistor s are not attached to both ends of a network, the network will not operate properly. A terminating resistor’s point of attachment on a network depends on its type, as shown in the following table: This type of terminating resistor . . .

Attaches to . . .

Trunk line ends T-Port taps Open-style taps Trunk lines that use terminating blocks

Sealed Open-style Sealed snap-on Open snap-on

An insulation displacement connector base

Grounding Requirements Grounding is the act of shielding a network from electrostatic damage and excess noise. Proper network grounding is necessary to ensure that a network will function reliably. Slightly different guidelines apply to networks with a single power supply vs. networks with multiple power supplies. Single Power Supply Grounding Requirements

The following grounding requirements apply to networks with a Stress the importance of checking that additional grounding does not occur when a non-isolated device is attached to a network or external connections are made. Tell students to check the documentation that ships with a device to avoid this problem when adding a non-isolated device to a network.

? Why is only the V-- wire grounded for KwikLink flat cable? Answer: KwikLink flat cable does not contain a shield, or “bare” wire.

Stress the importance of properly grounding a network that uses KwikLink flat cable. Since KwikLink flat cable does not contain a shield wire, proper grounding is absolutely essential to avoid noise problems.


single power supply: • Cable must be grounded at only one location (preferably at the power supply). •

If round cable is used, the V-- (black) power wire, shield (bare). and drain wires must be grounded at one place.

•

If KwikLink flat cable is used, the V-- (black) power wire must be grounded at only one place.

•

The grounding connection must be made using a 25 mm (1 in) copper braid or #8 AWG wire no longer than 3 m (10 ft) in length. Even a network with only one power supply can inadvertently be grounded in more than one location if a non-isolated device is mounted on the network or when external connections are made to a non-isolated device.



2--11

The following graphic shows grounding wiring schematics for two single power supply networks, one using round and the other using KwikLink flat cable: Flat Cable Wiring Terminal Block (Open-Style Connector)

Round Cable Wiring Terminal Block CAN_H (White) Signal Wire CAN_L (Blue) Signal Wire Drain Wire V- (Black) Power Wire V+ (Red) Power Wire

CAN_H (White) Signal Wire CAN_L (Blue) Signal Wire V-(Black) Power Wire V+ (Red) Power Wire

V-

L1 L2 grd

V+

Power Supply

120 V AC (Typical)

V-

V+

Power Supply Enclosure

Tip "

A micro style connector may be used for power supply connections requiring less than 4 A. Use open-style connectors for up to 8 A. Multiple Power Supply Grounding Requirements

The following grounding requirements apply to networks with more than one power supply: Point out that a common grounding-related mistake on networks with multiple power supplies is the connection of more than one power supply to an earth ground.

•

Cable must be grounded at only one location.

•

The V-- (black) wire of only one power supply must be grounded.

•

The V+ (red) power wire must be broken between power supplies.

Stress the importance of breaking the V+ power wire between the power supplies.

•

Each power supply’ s chassis must be connected to the common earth ground.

•

The grounding connection must be made using a 25 mm (1 in) copper braid or #8 AWG wire no longer than 3 m (10 ft) in length.

The following graphic shows grounding wiring schematics for a network with multiple power supplies that uses KwikLink flat cable:

Tip "

Here’s How Use a marker board to recreate the following examples and perform the calculations necessary to determine maximum trunk line distance. Rev. July 2008

Additional information about network grounding can be found in the Documentation Reference Guide.

To determine maximum trunk line distance and verify that it falls within specification: As your instructor demonstrates this procedure using the following example, follow along in the associated job aid(s).


2--12


Flat Cable Wiring Terminal Blocks (Open-Style Connector) Jumper

CAN_H (White) Signal Wire CAN_L (Blue) Signal Wire V-(Black) Power Wire V+ (Red) Power Wire

V+ (Red) Power Wire Broken Between Power Supplies V-

V+

Only One Earth Ground

V+

V-

Power Supply

Power Supply

Enclosure

Example

Maximum Trunk Line Distance Calculation In the following example, the maximum trunk line distance is equal to the distance of each segment on the trunk line since no drop line is longer than the distance between its tap and a terminating resistor: 2 m (6.6 ft)

2 m (6.6 ft)

6 m (19.7 ft)

T1

T2 1 m (3.3 ft.) n1

3.5 m (11.5ft)

Trunk Line Distance: 2 + 2 + 6 = 10 m (33 ft)

n2

In the following example, the maximum trunk line distance is equal to the total of the two trunk line cable segments that are 2 m long as well as the 3.5 meter (11.5 foot) drop line: 2 m (6.6 ft)

2 m (6.6 ft)

3 m (9.8 ft) T2

T1 1 m (3.3ft.) n1 3.5 m (11.5ft)

n2


Trunk Line Distance: 2 + 2 + 3.5 = 7.5 m (24.6 ft)


2--13


Tip "

Here’s How Use the following example to demonstrate how to calculate cumulative drop line length and verify that it falls within specification the data rate used on the samplefor network.

Example

The 3.5 m (11.5 ft) drop line is included in the total cable length calculation instead of the 3 m (9.8 ft) trunk line segment since the distance between the device at the end of the drop line and the connector is longer than the distance of the last segment before the terminating resistor.

To determine cumulative drop line length and verify that it falls within specification: As your instructor demonstrates this procedure using the following example, follow along in the associated job aid(s).

Cumulative Drop Line Length Calculation In the following example, the cumulative drop line length of the sample network is 23 m (75.9 ft). Therefore, this network can run at a data rate of 500k bit/s (as long as this rate is also within specifications for the maximum trunk line distance): Terminating Resistor

2 m (6.6 ft)

3 m (10 ft) 4m (13.2 ft)

4 m (13.2 ft)

1 m (3.3 ft) 4 m (13.2 ft)


1 m (3.3 ft)

Rev. July 2008

4 m (13 ft)


2--14


Here’s How

To design a DeviceNet cable system by performing the following tasks:

Demonstrate how to use the look-up method by referring students to the Documentation Reference Guide charts and finding the sample network lengths and number of power supplies in the charts. Then, cover the same example using the full-calculation method.

Example

•


•


As your instructor demonstrates these procedures using the following examples, follow along in the associated job aid(s).

Look-Up Method Power Supply Calculation The following graphic shows a DeviceNet network with an end-connected power supply and four devices for which maximum allowable current must be determined: Power Supply

80 m (262 ft)

40 m (131 ft) TR

120 m (394 ft)

100 m (328 ft)

T

T

D1

D2

PT

0.25 A

0 . 1 5A

T

T

D3

D4

0 .5 0 A

1.25 A

TR

TR = terminating resistor T = T-Port tap PT = PowerTap tap D = device

In the example above, the network is configured as follows: •

The total length of the network is 120 m (394 ft).

•

Round (thick) cable is used for the trunk line.

•

There is one end-connected power supply on the network.

•

There are four devices on the network with the following currents:

-----


0.25 A 0.15 A 0.50 A 1.25 A



2--15

The following steps are taken to determine if the total current on the network is within the maximum allowable range based on the network configura tion and power supply placement: 1. The currents of each of the four network devices are added together and it is determined that the total current for the network is 2.15 A (0.25 A + 0.15 A + 0.50 A + 1.25 A = 2.15). Refer students to the Documentation Reference Guide for the table that should be used to calculate the answer in this example.

2. The maximum allowable current for the network is determined by consulting the appropriate look-up table, which can be found in the Documentation Reference Guide. 3. Based on the look-up table, it is determined that the maximum current allowed on a 120 m (394 ft) long network with one end-connected power supply is 2.47 A. 4. Since the total current on the network does not exceed the maximum allowable current, it can be inferred that the network will operate properly.

Example

Full-Calculation Method Power Supply Calculation The maximum allowable current for the same network used in the previous example can also be determined using the full-calculati on method. The following graphic shows the example network for which maximum allowable current is to be determined: Power Supply

40 m (131 ft) TR

PT

80 m (262 ft)

120 m (394 ft)

100 m (328 ft)

T

T

D1

D2

0.25 A

0 . 1 5A

T

T D3

TR

D4

0 . 5 0A

1.25 A

TR = Terminating Resistor T = T-Port Tap PT = PowerTap Tap D = Device

Rev. July 2008


2--16


In the example, the network is configured as follows: •

The total length of the network is 120 m (394 ft).

•

Round (thick) cable is used for the trunk line.

•

There is one end-connected power supply on the network.

•

There are four devices on the network with the following currents:

-- 0.25 A -- 0.15 A -- 0.50 A -- 1.25 A Note that if it had been determined that the power supply on the example network was within the allowable range using the look-up method, the full-calculation method would not need to be employed.

The following steps are taken to verify that the example network’s power supply configuration meets specification s using the full-calculation method: 1. The appropriate equation is selected based on the type of cable being used on the network and the placement of the power supply. For the example network, which has one end-connected power supply and uses round (thick) cable, the following equation is used:

Note that this example uses meters as the primary unit of measurement. Remind students that .015 ohms per meter of cable is substituted with .0045 ohms per foot of cable when using the English measurement system.

SUM{[(Ln x (0.015)) + (Nt x (0.005))] x I n } < 4.65V

T ell studentsofthat table describing each component the afull-calculation equation in detail is provided in the documentation reference guide.

• •

• • •

•

Ln: The length of cable ( in meters) between power supply and node 0.015: Ohms per meter of cable Nt : The number of taps between the power supply and node n 0.005: Ohms of contact resistance per tap In: The current draw from the network for node n 4.65V: The maximum common mode voltage drop allowed

The following calculation uses meters as the primary unit of measurement.

The equation used for the following calculation applies only to round (thick) cable.

Tip "

See the Documentation Reference Guide for the appropriate equations to be used with other cable types. 2. For each device on the network, the distance between the device and the power supply is multiplied by 0.015 (meters) as follows: • • • •


D1: {[(40 x (0.015)) + (N t x (0.005))] x I n } D2: {[(80 x (0.015)) + (N t x (0.005))] x I n } D3: {[(100 x (0.015)) + (N t x (0.005))] x I n } D4: {[(120 x (0.015)) + (N t x (0.005))] x I n } Rev. July 2008 CBLib100


2--17

3. The number of taps between the device being evaluated and the power supply is multiplied by 0.005 as follows: • • • •

D1: {[(.6) + ( 1 x 0.005 )] x In } D2: {[(1.2) + (2 x 0.005 )] x In } D3: {[(1.5) + (3 x 0.005 )] x In } D4: {[(1.8) + (4 x 0.005 )] x In }

4. For each device, the values determined in steps 2. and 3. are added together and multiplied by the amount of current the device draws from the network to determine the device’s voltage as

follows: • D1: {[.6 + 0.005] x .25 A } • D2: {[1.2 + 0.01] x 0.15 A } • D3: {[1.5 + 0.015] x 0.50 A } • D4: {[1.8 + 0.02] x 1.25 A } 5. The voltage for each device (as determined in step 4.) is added together as follows:

0.15125 V + .1815 V + .7575 V + 2.275 V = 3.36525 V 6. If the total voltage of each device does not exceed 4.65 V, it can be determined that the network will function properly .

Since the total voltage of the devices on the example network is less than the maximum allowable voltage ( 3.36525 V 4.65 V ), it can be determined that the network in this example will function properly.

Rev. July 2008


2--18




Exercise: Designing a DeviceNet Cable System

2--19

Exercise: Designing a DeviceNet Cable System Exercise A

In this exercise, you will practice designing a DeviceNet cable system by performing the following tasks: •

Determine maximum trunk line distance and verify that it falls within specification

•

Determine cumulative drop line length and verify that it falls within specification

Context: Now that the necessary cable system components have been identified, you must determine the cable system configuration that will be most appropriate for the network application, taking into account maximum trunk line distance and cumulative drop line length, as well as the data rate at which the network should run.

Directions: The following graphic represents the DeviceNet network. Use the graphic to answer the questions that follow . For the purposes of this exercise, assume that the network uses round (thick) trunk line cable.

Answers should be calculated in meters.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. CBLe100

2--20



5m (16.4 ft)

4 m (13.1 ft) 29 m (95.1 ft)

Round (Thick) Trunk Line Cable 6 m (20 ft) 36 m (118.1 ft)

5 m (16.4 ft) 120 m (393.7 ft) 190 m (623.3 ft)

Cookie Production Line

t)f 3 2 ( m 7

85 m ( 278.8 ft)

200 m (656 ft) 110 m (360 ft)


80 m (262.4 ft)

10 m (32.8 ft)

2m (6.5 ft) 4 m (13.1 ft)

1. What is the length of the trunk line?

2. What is the cumulative drop line length for this network?

3. What is the maximum data rate that could be used on this network?


Rev. July 2008 CBLe100


2--21

4. If the drop line length for the first device on the network was changed from 4 m (13 ft) to 6 m (20 ft), how would the trunk line length be affected?

5. What would the length of the trunk line have to be to run the network at a data rate of 500k bit/s?

How Did You Do?


Exercise B

In this exercise, you will practice designing a DeviceNet cable system by performing the following tasks: •


•


Context: You have verified that the trunk line distance and cumulative drop line length of the network meet specifications and must now verify that the network power supply meets specifications.

Directions: The graphic on page 2--22 represents the network. Use it to answer the questions that follow: The network in the graphic uses round (thick) cable on the trunk line.

Rev. July 2008


2--22


Device 4


Device 3

Device 5

Round (Thick) Trunk Line Cable 0.10 A

5m (16.4 ft)

0.15 A 0.30 A 36 m (118.1)

29 m (95.1 ft)

120 m (393.7 ft) 190 m (623.3 ft)

Tap

Power Supply

Tap

Tap

Cookie Production Line


)t f 3 (2

85 m (278.8 ft)

Tap

Tap

m 7

200 m (656 ft) 11 0m( 3 6 0f t )

8 0m( 2 6 2 .4f t )

10 m (32.8 ft)

0.10 A Device 1

0.20 A Device 2

1. Determine the requirements for supplying power to the network above using the look-up method. 2. Based on look-up method results, does the power supply on this network fall within specification? Why or why not?

Tip "


Keep in mind that the network uses round (thick) cable and has a single, end-connected power supply.



2--23

3. Based on the look-up method results, should the power requirements be calculated again using the full-calculation method? Why or why not?

4. Determine power supply requirements for this network using the full-calculation method. Does the power supply configuration

meet specifications when the full-calculatio n method is used?

How Did You Do?

Rev. July 2008



2--24


Answers

Exercise A 1. The trunk line length is 482 m (1581 ft). 2. The cumulative drop line length for this network is 21 m (69 ft). 3. The maximum data rate that could be used on this network is 125k bit/s. Even though the cumu lative drop line len gth falls within specifications to run the network at 500k bit/s, the network can not use a data rate faster than 125k bit/s because of the length of the trunk line. 4. This length would need to be included in the total trunk line length since it is longer than the distance to the nearest terminating resistor. 5. The trunk line would have to be 100 m (328 ft) or less to accommodate a 500k bit/s data rate.

Exercise B 1. No, based on look-up method results, the power supply for this network does not fall within specification . The total power supply requirement for the devices on the network is 0.85 A, but a network whose devices require 0.85 A can be no longer than 360 m (1181 ft). Since this network is 482 m (1581 ft) in length, it does not fall within specification. 3. Yes, because the look-up method result does not fall within

specification. Since the look-up method is the most conservative method for determining power supply requirements, the network may still fall within specification based on full-calculation method results. 4. Yes, the power supply does fall within specification when the full-calculation method is used. Based on full-calculation method results, the total voltage requirement is 4.3565 V, which is under the 4.65 V limit.

Tip "


If the power supply were moved to the middle of the network, the network may fall within specificat ion.


Lesson

3

Creating a DeviceNet Network Configuration What You Will Learn

After completing this lesson, you should be able to create a network configuration by performing the following tasks: •

Configure a DeviceNet driver

•

Configure network properties

•

Create an offline network configuration

•

Go online to a network

•

Upload a device or network configuration

•

Browse a network

Why These Skills Are Important Correct configuration of a network ensures that all devices on the network are communicating. If one or more devices are not able to communicate on the network, data cannot be exchanged.

Before You Begin

Drivers

Make students aware that there are

A driver is the software interface to the hardware device that allows

different drivers that can be configured for a DeviceNet network. This course covers going online with either a 1770KFD driver or an Ethernet driver.

RSLinx Classic softwa re to communicate with your PLC. A properly configured driver makes it possible to view a software representation of an active network and make configuration changes and adjustments.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. NETib100

3--2


Drivers used with Rockwell Software programs are configured using RSLinx Classic software:

DeviceNet Drivers The following drivers can be used to go online to a DeviceNet network: •

1770-KFD Driver: Used in conjunction with an 1770-KFD (RS-232) module, which provides a point-to-point connection from a computer to a DeviceNet network.

For the 1770-KFD driver to be configured, a 1770-KFD module must be connected to the DeviceNet network and to the computer from which the driver is being configured via the computer’s serial port.

Tip "


•

1784-PCD Driver: Used in conjunction with a 1784-PCD card, which fits into the PCMCIA slot of a laptop computer. The 1784-PCD driver is used to connect a laptop computer directly to a DeviceNet network.

•

1784-PCID Driver: Used in conjunction with a 1784-PCID card for the PCI bus of a personal computer. The 1784-PCID driver is used to connect a personal computer directly to a DeviceNet network.

RSLinx Classic softwa re comes with a variety of drivers already installed. However, the 1784-PCID driver must be installed separately.

Rev. July 2008 NETib100

3 -- 3


Tip "

•

1771-SDNPT Pass Through Driver: Used to connect to a DeviceNet network on a PLC-5 platform through the backplane of the chassis in which a PLC-5 processor and companion 1771-SDN scanner module reside.

•

1747-SDNPT Pass Through Driver: Used to connect to a DeviceNet network on an SLC 500 platform through the backplane of the chassis in which an SLC 500 processor and companion 1747-SDN scanner module reside.

A connection to a DeviceNet network using either of these two pass through drivers is much slower than a direct connection and is therefore not recommended for use on a regular basis. •

Tip "

Ethernet Driver: Used to go online to a DeviceNet network via the ControlLogix backplane.

Not exclusively a DeviceNet driver , an Ethernet driver can be used to access a variety of networks through a ControlLogix backplane. The following graphic shows the RSLinx Classic window where a 1770-KFD driver is configured:

Node Address Data Rate

Note that if the incorrect network data rate is selected for the driver, the driver will not accept it.

Rev. July 2008

The data rate assigned to a DeviceNet driver must be the same as the data rate assigned to all other devices on the network.


3--4


Network Properties Note that once an online path is defined for a network configuration, that path will automatically be used to go online to the network without prompting.

Network properties define a DeviceNet network in order to distinguish between networks. This is particularly helpful if more than one DeviceNet network exists in a plant. The following properties can be defined for a DeviceNet network: •

Network name

•

Network description

•

Online path (the path or driver to be used to go online to the network)

Network properties can be viewed in the following RSNetWorx for DeviceNet software window:

Field to Enter Network Description

Command Button to Set Online Path

Tip "


Only the Description field can be changed in this window. The Name field will become active after the network configur ation has been saved.



3 -- 5

Network Configuration Options A network configuration is a graphic representation of a DeviceNet network that displays devices and their node addresses in RSNetWorx for DeviceNet software. The network configuration is the point from which all other configuratio n takes place. Network configurations can be created in either of the following ways: •

Offline

•

Online

Offline Network Configuration

? When might offline network configuration be most beneficial? Possible Answer: In order to begin work on a configuration when devices are not yet available, it may be beneficial to create an offline network configuration to save time once devices are installed (unless the device configuration is not yet known).

An offline network configuration is created in RSNetWorx for DeviceNet software when access to the physical network is not possible. RSNetWorx for DeviceNet software contains a hardware view to which devices are added from a list of available devices:

Hardware View Hardware List

Point out that to appear in the hardware list, a device must be registered to the computer running the RSNetWorx for DeviceNet software program.

Rev. July 2008


3--6


Note that in some cases, when a device in RSNetWorx for DeviceNet software does not match its physical counterpart, a “device mismatch” icon will appear over the device. Point out that this mismatch can be resolved using a procedure in the Procedures Guide.

Devices added to an offline network configur ation in RSNetWorx for DeviceNet software must exactly match the physical devices they represent. If the network configurati on in RSNetWorx for DeviceNet software does not match the physical network, it will not be possible to obtain data from or send data to network devices once they are online.

Do not go into detail about node address assignment. This subject will be addressed in a later lesson.

If a device is assigned a node address in an offline network configurat ion, unless a hardware node address has been assigned at the device itself, the address will not be valid until the node is commissioned online.

Tip "

Point out that configuration can be performed offline if devices are not available (as covered in the previous section). However, configuration is much faster and easier if done online. Stress the fact that simply going online never automatically uploads the network configuration and device data. Even if a prompt to upload or download opens, no data is uploaded or downloaded by simply accepting the prompt. Once online, it is necessary to manually upload the entire network in order to view the true online network configuration.


You can find devices quickly by placing your mouse pointer over any area of the hardware list, right-clicking, and then selecting Find Hardware.

Online Network Configuration Once devices are connected to the physical network and a driver has been configured, RSNetWorx for DeviceNet software can be used to go online and upload a network configuration:

Online Icon



3 -- 7

Online network configuration provides the following benefits: •

The ability to view all devices that are available and communicating on the network before making any changes

•

The ability to view devices that are no longer communicating on the network

Point out that mismatched devices and devices no longer communicating on the network appear in the online configuration with appropriate error icons displayed above them.

•

The ability to view and resolve mismatches betwee n devices in the network configuration and actual network devices

•

A choice to upload current device data from devices to the network configura tion or download device data from the network

Explain that if the default network preference settings are not changed in the software, when the network is placed online, it will automatically be browsed once and a prompt to either upload or download the network configuration will open. If these settings are disabled, the network must be browsed manually, as well as uploaded or downloaded manually.

•

configuration to devices Diagnostic capabilities To view an online network configuration, it is necessary to upload the network configuration after going online. Devices may show up in the network configurat ion before it is uploaded, but an upload must be performed to access configuration data.

Uploading and Downloading Tell students it’s a good idea to save an uploaded network configuration under a different name before making and downloading any changes. This way, a record is retained of the srcinal network configuration for later reference.

To successfully create and work with an online network configuration, it’s important to understand the implications of uploading and downloading: •

Uploading: The process of obtaining data from a physical network and displaying it in a software program.

•

Downloading: The process of sending data from a software program to a physical network .

Use extreme caution when downloading changes to an online network configurati on. Incorrect configuration of devices online can cause erratic device behavior, injury to personnel or damage to equipment.

Rev. July 2008


3--8


Keep the following considerations in mind when uploading from or downloading to a network: •

Uploading and downloading can only be performed when a network is online.

•

Going online to a network does not automatically upload the network.

•

In order for any changes made in an online network configuration to take effect, the configuration must be downloaded to the network.

•

It is possible to or download upload configuration data to or from a single device the entireornetwork.

Browsing a Network Browsing is a way to determine the devices that are present on a DeviceNet network and their status. A network browse provides the following information: •

A graphic representation of all devices detected on the network at the time of the browse

•

The node addresses of the detected devices

•

Basic device status and identity information A network browse does not provide device configuration data.

? What do you think are some of the

The following two browsing options exist: •

Single Pass Browse: A way to search for all devices present on a network during a single interval (i.e., all possible node addresses are scanned once).

•

Continuous Browse: A way to continuously search for network devices (i.e., when all possible node addresses have been scanned, the process of scanning for devices begins again).

benefits and drawbacks of both browsing options? Possible Answer: A single pass browse will not slow down the network as much as continuous browsing, but if a device goes offline or a fault occurs, it may not be detected until the network is browsed again. Continuous browsing can slow down the network, but device faults can be immediately detected.


Do not confuse browsing a network with uploading a network. A network browse can only indicate which devices are present on the network, provide basic status information, and node addresses . Uploading a network provides specific device configuration details and a means to edit them.



3 -- 9

The following graphic shows the RSNetWorx for DeviceNet menu where browsing, uploading, and downloading options are selected:

Here’s How

To create a network configura tion by performing the following tasks:

Perform the following demonstration:

•

Configure a DeviceNet driver

1. Configure the 1770-KFD driver using RSLinx software.

•

Configure network properties

•

Create an offline network configuration

•

Go online to a network

•

Upload device and network properties

•

Browse a network

2. In RSNetWorx for DeviceNet open a new (empty) network configuration and enter a network name, description, and online path. 3. Create an offline network configuration, but do not save it. 4. Open an empty (new) network configuration and go online to the existing network using the 1770-KFD driver, then go offline and go online again using the Ethernet driver.

As your instructor demonstrates these procedures, follow along in the associated job aid(s).

5. Demonstrate both possible browsing options (continuous and single pass). 6. Upload and download the properties of a single device, then of the entire network.

Rev. July 2008


3--10




Exercise: Creating a DeviceNet Network Configuration

3--11

Exercise: Creating a DeviceNet Network Configuration Exercise A

In this exercise, you will practice creating a network configuration.

Context: You have installed the cable system for your DeviceNet network. You are now ready to create a network configuration that will define the devices to be used on the network. This network configuration can then be used to go online to the network for future configuration tasks. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Using RSLinx software, RSNetWorx for DeviceNet software, and the steps below, create a network configuration for your DeviceNet workstation. 1. Disconnect the 871TM inductive proximity sensor from the network. 2. online If you are the 1770-KFD module, configure a driver to go to ausing DeviceNet network as outlined in the following table: For this parameter . . .

Select this option . . .

Port Select (in the Serial Port Setup panel)

The serial port on your computer

Data Rate (in the Serial Port Setup panel)

The highest rate available

Node Address (in the DeviceNet Port Setup panel)

62

Data Rate (in the DeviceNet Port Setup panel)

125

3. Open a new (empty) offline network configuration in RSNetWorx for DeviceNet software. 4. Configure networ k properties as outlined in the following table: For this property . . .

Tip "

Rev. July 2008

Enter or select this . . .

Description

Fast Foods DeviceNet network

Online path

The 1770-KFD driver or the Ethernet driver

The software will not allow you to enter a network name in the Name text box at this time. When you save the network configuration for the first time, you can specify a network name in the File name text box.

E 2008 Rockwell Automation, Inc. All rights reserved. NETe100

3--12


5. Create an offline network configuration as outlined in the following table: Node Address

Device Name

1756-DNB(MajorRev07)

00

Absolute multi-turn encoder

871TM unshielded 18mm with micro

E3(0.4-2A)(MajorRev03)

01

02

03

1734-ADN PointIO DeviceNet adapter (Major Rev 03)

PowerFlex401P110V .50HP

04

20

1792D--4BV0D 4input (ArmorBlock MaXum input module)

PVPlusDeviceNet

Tip "

30

40

You can find devices quickly by placing your mouse pointer over any area of the hardware list, right-clicking, and then selecting Find Hardware. 6. Open a new (empty) network configuration .

When prompted, do not save the existing offline network configuration. 7. Go online to the network by using the 1770-KFD or ethernet driver.

Tip "

If using the SLC 500 platform, you must use the 1770-KFD driver

8. Upload the network configuratio n.


Rev. July 2008 NETe100

3--13


9. Verify any devices that are present in the online network configuration and write the node address of each device in the following table: Device Name

Node Address

1756-DNB (Major Rev 07)



E3 (0.4-2A) (Major Rev 03)


PowerFlex 40 1P 110V .50 HP


PV Plus DeviceNet

10. Which device in the offline network configuration is not present in the online network configuration? Why not?

11. Attach the right-hand 871TM inductive proximity sensor to the network.

Rev. July 2008


3--14


12. Does the 871TM inductive proximity sensor show up in the online network configuration? Why or why not?

13. Perform a single pass browse to display the 871TM inductive proximity sensor in the online network configuration. 14. Enable the continuous browsing option. 15. Disconnect the 871TM inductive proximity sensor. 16. What happens after about a minute? Why?

17. Disable the continuous browsing option. 18. Delete the icon for the disconnected 871TM inductive proximity sensor. 19. Save the network configuratio n. 20. Close RSNetWorx for DeviceNet software.

How Did You Do?





Rev. July 2008

3--15


3--16


Answers

Exercise A 2. The configuration for your 1770-KFD driver should look similar to the following:

RSLinx Software

9. The following devices with their correspondin g node addresses should appear in the online network configuration: Node Address

Device Name

1756-DNB(MajorRev07)

00



E3(0.4-2A)(MajorRev03)

01

X

03


PowerFlex401P110V .50HP

04

20


PVPlusDeviceNet


30

40



3--17

10. The 871TM inductive proximity sensor is not present in the online network configuration because it is not connected to the network. 12. The 871TM inductive proximity sensor does not show up in the online network configuratio n because the network has not been browsed since the sensor was connected. Therefore , the sensor’s presence on the network has not yet been detected. 16. The 871TM inductive proximity sensor disappea rs from the online network configuration (as evidenced by the error icon)

because is being continuously browsed and any changes the are network immediately detected.

Rev. July 2008


3--18




Lesson

4

Commissioning Nodes on a DeviceNet Network What You Will Learn

After completing this lesson, you should be able to commission nodes on a DeviceNet network by performing the following tasks: •

Commission a node using device hardware

•

Assign a node address and data rate using the Node

•

Commissioning tool Assign a node address through the hardware view

•

Assign a node address through the General property page

Why These Skills Are Important Node commissioning is important for the following reasons:

Before You Begin

•

Every device must be assigned a unique node address to be able to communicate on a network.

•

Incorrect commissioning of one node can affect the functioning of other nodes, thus affecting proper operation of the entire network.

Node Commissioning Node commissioning is the process of preparing a device to communicate on a network. Node commissioning involves the following two components: •

Data rate assignment

•

Node address assignment

Data Rate Note that data rate is also sometimes referred to as baud rate.

Rev. July 2008

The data rate associated with a device is the rate at which the device communicates on the network and can be set for most devices using RSNetWorx for DeviceNet software. For communications to occur, the data rate of all devices on a network must be the same. The following data rates can be used: •

125 k bits/second

•

250 k bits/second

•

500 k bits/second

E 2008 Rockwell Automation, Inc. All rights reserved. NODib100

4--2


Data rates for devices should not be changed while devices are connecte d to the network because erratic operation may result.

Tip " Note that the autobaud parameter makes the step of dataTip rate assignment virtually invisible to a user. Mention that the autobaud parameter is generally set by factory-default. Tip

Most devices are factory-com missioned with a default data rate of 125 k bits/second.

"

Many devices come with an autobaud parameter , which enables to automatically adjust to the data rate of other network devices asthem soon as they are connected to the network.

"

The higher the data rate, the faster the devices will communicate on the network. However , the data rate must be consistent with the cable system requirements and the rest of the devices on the network. Node Addresses

A node address is a unique number assigned to a device to identify it on a network. The following rules apply to DeviceNet node addresses: •

Explain that the concept of priority in this context refers to the order in which devices are allowed to communicate on a network.

A maximum of 64 nodes (0 to 63) are allowed on a DeviceNet network.

•

Node 0 is recommended for a DeviceNet scanner module.

•

Node 63 is the factory default for a new device.

Why should the scanner module have the lowest node address?

?

•

Duplication of node addresses is not allowed.

•

The lower the node address is set, the higher its priority becomes.

Answer: The scanner module should have the lowest node address because it coordinates the communications of all other network devices and therefore has the highest priority on the network.

•

The network interface and all other devices on a DeviceNet network require a node address assignment.

Node Commissioning Methods Point out a workstation device to which a node address can be assigned at the device itself. Mention that rotary switches, pushwheels, and dip switches are just a few examples of the ways node addresses are assigned using device hardware.


A node is commissioned according to the device type and situation. Nodes can be commissioned by any of the following methods: •

Using device hardware

•

Using RSNetWorx for DeviceNet software

•

Using a point-to-point connection

Rev. July 2008 NODib100


4 -- 3

PanelView Plus Node Commissioning Note that the PanelView Plus operator interface is the only device included in the classroom workstations that must be commissioned using its own software program.

PanelView Plus operator interfaces must be commissioned using RSView Studio software. The following graphic shows the communications setup windows within RSView Studio used to commission a PanelView Plus 600 operator interface:

PanelView Plus DeviceNet Scanner Node Address

Tip "

The PanelView Plus operator interface on the DeviceNet workstation must be commissioned using RSView Studio software.

Device Hardware Node Commissioning Mention that many devices, such as the PowerFlex 40 drive and the ArmorBlock MaXum input module can be commissioned using either device hardware or RSNetWorx for DeviceNet software. In most cases where a device can be commissioned using either software or hardware, DIP switches, rotary switches, pushwheels, etc. are factory-set at a position that enables the device to be commissioned using software by default.

Hardware node commissioning is performed using DIP switches, rotary switches, pushwheels, etc. The data rate and node address for a device are set using one of these features before the device is attached to the network. The following graphic shows a device and the DIP switches used to set both its node address and data rate:

PowerFlex 40 DeviceNet Communications Adapter DIP Switches

Rev. July 2008


4--4


Tip "

Once the network is online, a device with a hardware-assigned node address shows up with its address already assigned.

Software Node Commissioning If a device supports softwa re node commissioning, it can be assigned a node address using any one of the following RSNetWorx for DeviceNet software resources:

Stress that the hardware view and General property page can only be used to set a node address, not the data rate. Therefore, a device must already be on the network and running at the same data rate as other devices for these features to work.

•

The Node Commissioning tool

• •

The hardware view A device’s Property/General tab page Software node commissioning can only be performed when a network is online.

The Node Commissioning tool can be used to set both a node address and data rate, but the hardware view and General property page can be used only to set a node address.

If several nodes are being connected to the network with factory defaults of 63, each must be commissioned one at a time or manually.

Explain that the Faulted Address Tip " Recovery wizard eliminates the need to place devices with factory-default addresses of 63 online one at a time because it can detect any devices that have duplicate node addresses and assign them new, unique addresses once they are online.


Some devices that support software node address assignment can also be commissioned using an RSNetWorx for DeviceNet software feature called the Faulted Address Recovery wizard. The wizard detects duplicate node addresses and reassigns unique addresses after devices are online. Refer to a device’s docume ntation or the RSNetWorx for DeviceNet online Help system to see if it supports Faulted Address Recovery.



4 -- 5

The following graphic shows the RSNetWorx for DeviceNet window where node commissioning is performed using the Node Commissioning tool:

Node Address Spin Box Data Rate Assignment Spin Box

Point out that assigning a node address using the hardware view simply entails typing a new node address over the existing one.

The following graphic shows the RSNetWorx for DeviceNet hardware view through which node addresses can be assigned:

Double-Click Here to Assign a New Node Address

Rev. July 2008


4--6


The following graphic shows the Properties/General tab page for a device that can be used to assign a node address:

Node Address Spin Box

Explain that there are different devices that can be used for point-to-point connection. However, for the purposes of this course, only the 1770-KFD module is covered. Point out that this method of node commissioning can also be used as a troubleshooting tool. If a device will not show up in an online network configuration with other devices, it will likely show up when removed from the configuration and viewed using a point-to-point connection. It can then be assigned a unique node address and data rate to match other devices and placed back on the network. Point out that the 1770-KFD plug-in power supply is required to provide necessary power Device to Be for the target device. Commissioned


Point-to-Point Commissioning When a software-configurable device that has the same node address as an existing network device must be added to a network, the device must be commissioned using a point-to-point connection. Point-to-point commissioning is the process of commissioning a node using a direct connection between a device and a computer that contains RSNetWorx for DeviceNet software. In the following graphic, a 1770-KFD module acts as an interface between the computer from which a node address is assigned and the device to which it is being assigned:

RS-232 Cable

1770-KFD Module

Computer with RSNetWorx for DeviceNet Software



4 -- 7

An external AC adapter must be connected to the power jack on the side of the 1770-KFD module when it is used to commission nodes using a point-to-point connection.

Tip "

One of the most common ways of commissioning a node using a point-to-point connection involves the use of a 1770-KFD module connected to the serial port of a computer that contains RSNetW orx for DeviceNet software.

Node Commissioning Considerations Point out that typing node addresses into RSNetWorx for DeviceNet software while thesoftwareisofflinewillnotactuallycommission any nodes. Stress that since the factory default address of the node being commissioned must not conflict with the address of any other node on the network, no more than one new device with a factory default address of 63 can be connected to the network at a time.

The following consideratio ns must be taken into account when commissioning a node using any of the RSNetWorx for DeviceNet software node commissioning resources: •

The network must be online.

•

The factory default address of the node being commission ed must not conflict with that of any other node already on the network.

•

The node address to which the device is commissioned must not conflict with that of any other node on the network. When a new node address is applied to a device using the Node Commissioning tool, it immediately overwrites node When address data currently specified in thethe device. reassigning node addresses, consider the order of commissioning so every node will have a unique node address.

Example: Commissioning Nodes with Unique Node Addresses Use this example to stress the importance of taking notice of all node addresses on the network before commissioning a new node.

The following device with its corresponding node address exists on a DeviceNet network: 800E Pushbutton Station

Node 6

Rev. July 2008


4--8


The following device is to be added to the network from a storage bin and has the same node address as the 800E pushbutton station: RightSight Photoelectric Sensor

Node 6

If the RightSight photoelectric sensor is added to the network with its current node address of 6, the address will conflict with that of the 800E DeviceNet pushbutton station and one or both of the devices will be unable to communicate. To avoid this situation, the following action should be taken: •

Here’s How Perform the following demonstration: 1. Assign a new hardware node address to the ArmorBlock input module at your workstation.

" First unscrew the ArmorBlock from its base to set the hardware node address. 2. First, commission one of the devices in your online network configuration with the Node Commissioning tool; second, recommission it through the device’s Properties/General tab page; finally, use the RSNetWorx for DeviceNet hardware view.


The 800E pushbutton station can be commissioned to another node address before the RightSight photoelectric sensor is added.

Perform the following tasks to commission nodes on a DeviceNet network: •

Commission a node using device hardware

•

Assign a node address and data rate using the Node Commissioning tool

•

Assign a node address through the hardware view

•

Assign a node address through the General property page

As your instructor demonstrates these procedures, follow the steps in the associated job aid(s).


Exercise: Commissioning Nodes on a DeviceNet Network

4 -- 9

Exercise: Commissioning Nodes on a DeviceNet Network Exercise A

In this exercise, you will practice assigning nodes on a DeviceNet network.

Context: All ODVA compliant DeviceNet devices ship with a factory-commissioned node address of 63. In order to add a new device to the network, you must be able to assign the appropriate node address to the device. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Follow the steps below to commission the 1734-ADN Point I/O DeviceNet adapter, the 871TM inductive proximity sensor , and the ArmorBlock MaXum I/O module. 1. Assign the 1734-ADN Point I/O adapter to node 10 using the adapter’s node address thumbwheels. 2. Cycle workstation power. 3. Go online to the network. 4. Verify that the 1734-ADN Point I/O adapter module appears in the online network configuration at node address 10. 5. Assign the 1734-ADN Point I/O adapter back to node 4 using the adapter’s node address thumbwheels (hardware). 6. Cycle workstation power. 7. Connect the left 871TM inductive proximity sensor to the network. 8. Browse the network to display the sensor at its factory-commissioned node address of 63. 9. Assign a node address using the Node Commissioning Tool : Assign the 871TM inductive proximity sensor to node 2. 10. Browse the network to verify that the 871TM inductive proximity sensor has been assigned to node address 2. 11. Delete the icon representing the 871TM inductive proximity sensor at its old node address of 63. Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. NODe100

4--10


12. If you do not see the ArmorBlock MaXum input module in your online configuration, browse the network to display the ArmorBlock MaXum input module at its current node address. 13. Assign a node address through the Hardware View: Assign the ArmorBlock MaXum Input module to node 35. 14. Browse the network to verify that the ArmorBlock MaXum input module has been assigned to node address 35. 15. Assign a node address through the General Property page : Assign the ArmorBlock MaXum input module to node 30. 16. Browse the network to verify that the ArmorBlock MaXum input module has been assigned to node address 30. 17. What would have happened if two devices with the same node address were connected to the network at the same time?

18. Save the network configuratio n. 19. Close RSNetWorx for DeviceNet software.

How Did You Do?



Rev. July 2008 NODe100


Rev. July 2008

4--11


4--12


Answers

Exercise A 9. The 871TM inductive proximity sensor should now be commissioned to node 2:

13. If you properly changed the node address of the ArmorBlock input module from the hardware view you should receive the following prompt:

15. Your General properties page for the ArmorBlock MaXum input module should now look similar to the following:




4--13

17. If two devices with the same node address had been connected to the network at once, one or both of the devices would have been unable to communicate on the network and would not have been detected in the network configuration.

Rev. July 2008


4--14




Lesson If you are using SLC 500 hardware, use the alternative lesson, Configuring a 1747-SDN DeviceNet Scanner Module .

What You Will Learn

5

Configuring a 1756-DNB DeviceNet Scanner Module After completing this lesson, you should be able to configure a DeviceNet scanner module by performing the following tasks: •

Configure a 1756-DNB scanner module

•

Create a scanlist

•

Configure a scanner module for slave mode

•

Enter ladder logic instructions to place a 1756-DNB scanner module in Run mode

Why These Skills Are Important Being able to configure a scanner module correctly is important for the following reasons:

Before You Begin Point out to students that DeviceNet networks are compatible with a number of platforms, each of which uses a different scanner module. This lesson covers configuration tasks associated with the scanner modules used with ControlLogix platforms.

Rev. July 2008

•

A scanner module is responsible for the exchange of information between devices and the processor or controller . If it is incorrectly configured, communications will not occur.

•

Correct scanner module configurati on ensures that the scanner module is aware of the status of network devices and can provide valuable informati on for isolating faults.

Scanner Module Communications with Devices A scanner module acts as an interface between devices on a DeviceNet network and a processor or controller. Specifically, a scanner module performs the following actions: •

Reads input data from devices and makes it available to a processor or controller

•

Writes output data from a processor or controller to devices

•

Downloads configuration data from the software to devices

•

Uploads configur ation data from the devices to the software

•

Monitors the operational status of devices

E 2008 Rockwell Automation, Inc. All rights reserved. SCNib100

5--2


Scanner Module Communications with a Controller

? Does anyone have experience working with scanner modules? If so, what kind of tasks have you performed using a scanner module?

Scanner module communica tions with a controller consists of two general steps: •

Data received from devices (input data) is organized by the scanner module and made available to the processor or controller .

•

Data received from the controller (output data) is organized in the scanner module and sent to devices.

The following graphic shows the flow of data between a controller, a scanner module, and a device on a DeviceNet network: Controller Output to Device

Controller Output to Device

Device Input Controller

Device Input to Controller

Controller

Device

Scanner Module

Scanner Modules

Note that configuration of a 1771-SDN or 1769-SDN scanner module is not practiced in this course, but that information specific to the configuration of this module can be found in the procedures guide and the documentation reference guide.

Tip "


A different scanner module is used depending upon the type of processor or controller being used with a network. The following table shows four of the Rockwell Automation scanner modules most often used on DeviceNet networks and their correspondin g processor or controller types: Scanner Module

Processor or Controller

1771-SDN

PLC --5

1747-SDN

SLC500

1756-DNB

ControlLogix

1769-SDN

CompactLogix

An additional scanner module, the 1784-PCIDS scanner card, can be used to connect most applications to a DeviceNet network via a personal computer.

Rev. July 2008 SCNib100


5 -- 3

1756-DNB Scanner Module Stress that, unlike 1771-SDN scanner modules (used with PLC-5 processors) and 1747-SDN scanner modules (used with SLC 500 processors), 1756-DNB scanner modules do not require special copy or block transfer instructions to pass large amounts of data back and forth between a controller and devices.

A 1756-DNB scanner module has the following characteristics:

Add that in the RSLogix 5000 program used in this class, the 1756-DNB scanner module has already been added to the hardware configuration.

Discrete Input and Output Data Transfers

Tip "

Rev. July 2008

•

Communicates with up to 62 commissioned nodes

•

Resides in a ControlLogix chassis

•

Transfers all data using discrete transfers To communicate with a ControlLogix controller, a 1756-DNB scanner module must be added to the hardware configuration in RSLogix 5000 software. Adding the 1756-DNB to the hardware configuration automatically creates the input and output data tags that will be associated with DeviceNe t devices.

All data passed between a device and a controller via a 1756-DNB scanner module is transferred discretely. Discrete data can take only certain values. Discrete input and output data in a 1756-DNB scanner module can be described as follows: •

Discrete Input Data: Data 124 words in length (double words of 32 bits each) that is sent from network devices to a controller.

•

Discrete Output Data: Data 123 words in length (double words of 32 bits each) that is sent from a controller to network devices.

No special ladder logic is necessary to transfer discrete input and output data between a 1756-DNB scanne r module and a controller.


5--4


The following graphic shows the discrete data transfer process between a 1756-DNB scanner module and a ControlLogix controller: 1756-DNB Scanner Module

ControlLogix Controller

Discrete Input Image

Discrete Input Table

A

A

B

A

B

B

D

C D

C D

C E

E Input from Device

E

Discrete I/O Transfer

Discrete Output Image X

X

Y

Y

Z

Z

A

X

4

5

Discrete Output Table Z Discrete I/O Transfer

Y X

Output to Device

Scanner Module Configuration The following general settings must be configured in a DeviceNet scanner module:


•

Node address and data rate

•

Interscan delay time

•

Foreground to background poll ratio



5 -- 5

Node Address and Data Rate

Like other network devices, a scanner module must be assigned a node address and data rate to communicate on the network. Depending upon scanner module type, the node address and data rate can be assigned using RSNetWorx for DeviceNet software or the scanner module itself. Point out the manual configuration button on the front of the 1756-DNB scanner module at your workstation.

Tip "

The node address and data rate for the 1756-DNB scanner module can be assigned using RSNetWorx for DeviceNet software or a manual configuration button on the front of the module. The recommended node address for a scanner module is the lowest address available. Interscan Delay

? Why would it not be advisable to set the interscan delay to a very high value? Answer: The data coming from devices may change frequently and the scanner module will not receive this data as often if the value is set high. Therefore, important device information may not be received when needed.

The interscan delay is the time delay between consecutive I/O scans. During this time, the scanner module performs non-time-critic al communications on the network (e.g., communicat ions with software). Settings for interscan delay can be described as follows: •

The interscan delay can be set from 2 to 9000 milliseconds (10 is the default.)

•

If set low, the time required for the scanner to respond to RSLinx software and configuration functions is increased.

•

If set high, the data is not scanned as often and a change in data may take longer to be noticed.

Expected Packet Rate

When a scanner opens an I/O connection it sets a gross timeout into the device. If the device does not receive a packet from the scanner in this time period, then the device drops the connection. If the scanner does not receive a packet from the slave in this time period, it will drop the connection and attempt to open a new connection periodically. This timeout value is called the Expected Packet Rate (EPR):

Rev. July 2008

•

The default EPR is 75 times 4 = 300 ms for polled and strobed messaging.

•

The gross network timeout for COS messaging is 4 times the heartbeat rate.

•

Gross network timeout for a CYCLIC device is 4 times the send rate.


5--6


The interscan delay should always be set to a value lower than the expected packet rate to help prevent messaging timeouts. Foreground to Background Poll Ratio Mention that this feature is often used to conserve network bandwidth, since it reduces the amount of traffic on a network at a given time.

The foreground to background poll ratio sets the frequency of I/O messages to a device in relation to the number of I/O scans (e.g., if the ratio is four, the scanner module communic ates with the device every five scans). This feature allows a user to determine whether or not a device will communicate with a scanner during every scan cycle. Interscan delay and foreground to background poll ratio are configured using the following RSNetWorx for DeviceNet software property page:

Interscan Delay Foreground to Background Poll Ratio




5 -- 7

Scanlist Make sure students understand how important it is to create a scanlist. If the scanlist is not configured, the scanner module will not be able to communicate with devices on the network.

A scanlist is a list of devices on a network with which a scanner module will communicate . A scanlist must exist in a scanner module for communications to occur between devices and a processor. The scanlist provides the scanner module with the following informati on: •

Which devices to scan

Point out that simply adding a device to a scanlist does not automatically define all of these variables. Additional configuration (such as specification of message type and I/O sizes, level of electronic keying, and mapping) must also be performed.

•

How to scan each device

•

How closely a device in the scanlist must match the physical device on the network

•

How often each device is to be scanned

•

Where data can be found in each device’s memory

If this lesson is being taught as part of a standard school (e.g., not a part of a Tailored Training curriculum, mention that these tasks will be performed in the lesson on mapping.

•

The size of input and output data

•

Where input and output data is to be mapped in the scanner module in order for the processor or controller to read it

Electronic Keying Criteria

Note that electronic keying is integral to the Automatic Device Recovery (ADR) feature. If this lesson is being taught as part of a standard school (e.g., not part of a Tailored Training curriculum), mention that the topic will be covered in detail in the lesson on Automatic Device recovery.

“Electronic Keying” is a feature that automatically compares the expected module (as shown in the I/O Configuration tree) to the physical module before I/O communications begin. Using electronic keying can help prevent communications to a module that does not match the type and revision expected. For each module in the I/O Configuration tree, the user-selected Keying Option determines if and how an electronic keying check is performed. Typically three keying options are available, though for some specific module types fewer options are available. The three options are: •

Exact Match

•

Compatible Keying

•

Disable Keying

Each option has benefits and implications that the user must carefully consider when selecting between these options.

Rev. July 2008


5--8


For help understanding these options see the Glossary definitions for Electronic Keying, Compatible Module Keying, Disabled Keying, and Exact Match Keying in your Procedures Guide.

Point out the Node Active check box in the graphic below and note that when this check box is cleared for a device,

The following graphic shows the RSNetWorx for DeviceNet property page where a scanlist is created and electronic keying criteria are specified:

the device will not scan be included in the it is scanner module’s even though in the scanlist. Point out that the electronic keying criteria selected in the following graphic apply to the E3 solid-state overload relay, since this is the device c urrently selected in the scanlist. If another device were selected, the electronic keying Scanlist criteria for that device would be displayed.


Slave Mode DeviceNet scanner modules also have the capability of acting as “slaves” to another scanner module on the same network. Part of a scanner module’s configuration includes specifying whether or not the module will operate in slave mode. For network operation in slave mode to occur, the following conditions must exist: •

More than one scanner module must exist on the network.

•

One scanner module must operate as the “master.”

•

Scanner modules other than the “master” scanner module must be considered “slaves” on the network and can only exchange information through the “master” scanner module.



5 -- 9


Example: Slave Mode

The following graphic shows an example of the use of slave mode on a DeviceNet network: Node 0 Scanner Module (Master)

Node 1 Scanner Module (Slave to Node 0)

Node 8

In this example, the following conditions exist:

? Why might you put two scanner

•

modules on a network?

•

Possible Answer: To speed up network traffic. • •

? How would you know the size of the inputs and outputs to be transferred by a scanner module in slave mode? Answer inputofand output would be: The the total inputs andsizes outputs being read from network devices by the scanner module in slave mode.

Rev. July 2008

Node 9

There are two scanner modules on the network. The scanner module at node 0 has its own scanlist and is a master to several nodes on the network, including the scanner module at node 1. The scanner module at node 1 has its own scanlist and can be a master to other nodes on the network Data gathered by the scanner module at node 1 is then collected by the scanner module at node 0.

If a scanner module is configured for slave mode, the following additional parameters must be specified: • •

The message type that will be used to communicate with the master scanner module The size of inputs and outputs that will be transferred


5--10


Once the Slave Mode is enabled, you may configure the message type and input and output sizes.

Check Box to Enable Slave Mode

Area Where Message Type and Size Are Specified (Default Sizes Shown)

Shared Inputs

? In what kind of situation would the shared input option be useful? Possible Answer: When another processor or controller must use data from devices, but does not need to send them data.


When more than one scanner module exists on a network, it is possible to include devices that are already slaves to one scanner module in another scanner module’s scanlist as “shared inputs.” Only input data from these devices is consumed by the module and stored in its input area. The following conditions must exist for shared inputs to be enabled in a scanner module: •

More than one scanner module must exist on a network.

•

A scanlist with mapped devices must exist in the scanner module acting as the network master.

•

The scanner module that is to share inputs must support the shared inputs option.



Remind students that even though more than one scanner can receive device inputs, outputs can be controlled by only one processor and scanner module.

5--11

On some scanners the option is View All Inputs rather than Share Inputs. The following graphic shows an RSNetWorx for DeviceNet software Scanlist property page where the shared inputs function has been selected:

Once shared inputs have been enabled for a scanner module, the devices whose inputs the module will be sharing with another scanner module are designated with a special icon:

Rev. July 2008


5--12


Icon Designating a Shared Input on some scanners.

Even with the shared inputs function enabled, a slave device still can have only one master.

If the Automatic Device Recovery feature has been enabled in a scanner module, the shared inputs function cannot be enabled for that scanner module.

Scanner Module Run Mode A scanner module will not communicate with network devices until it is placed in Run mode. This action must be performed using the scanner module’s command register, which is accessed via the programming software being used to control network devices.

Tip "


A scanner module’s operating mode is reflected in the module’s status register, also accessed via the programming software.



5--13

A scanner module’s command and status registers can be defined in the following way: Refer the class to the detailed information about scanner module command registers in the Documentation Reference Guide and point out where the command register is located in a 1756-DNB scanner module.

•

Command Register: The area in a scanner module’s memor y where commands specific to the scanner module are entered. Each bit in the command register executes a unique command. The following bits are examples of commands that can be sent to the scanner module:

------

Tip "

Refer the class to the detailed information about scanner module status registers in the documentation reference guide and point out where the status register is located in a 1756-DNB scanner module.

Tip "

Run/idle Fault network Disable network Halt scanner Reboot/reset scanner

Command register location and format for 1771-SDN, 1747-SDN, and 1756-DNB scanner modules can be found in the Documentation Reference Guide. •

Status Register: The area in a scanner module’s memor y where scanner module status is reflected. Each bit in the status register represents a scanner module mode. The following bits are examples of scanner module modes that can be reflected in the status register:

-----

Run/idle Network fault Network disable Device failure

------

Autoverify failure Communications failure Duplicate node address failure DeviceNet power failure (1756-DNB scanner module only) Explicit message program control (1747-SDN scanner module only)

Status register location and format for 1771-SDN, 1747-SDN , and 1756-DNB scanner modules can be found in the Documentation Reference Guide. 1756-DNB Scanner Module Run/Idle Bit

A 1756-DNB scanner module’s command and status registers are 32-bit assemblie s automatically created when the scanner module is added to the hardware configuration in RSLogix 5000 software. A 1756-DNB scanner module’s Run/Idle bit is the first bit (bit 0) of the “O.CommandRegister” assembly.

Rev. July 2008


5--14


The following graphic shows a 1756-DNB scanner module’s command and status register tags in RSLogix 5000 software:

Run/Idle Bit 1756-DNB Status Register

Run/Idle Bit

1756-DNB Command Register

The following graphic shows a sample ladder logic instruction used to turn on the Run bit in a 1756-DNB scanner module:

Here’s How Perform the following demonstration: 1. Configure one of the scanner modules at your workstation by setting an interscan delay value, a foreground to background poll ratio, and creating a scanlist. 2. Configure the other scanner module (PanelView Plus) at your workstation for slave mode. 3. Demonstrate how to place each scanner module in turn in Run mode.


To configure a DeviceNet scanner module by performing the following tasks: •


•

Create a scanlist

•


•

Enter ladder logic instructions to place a 1756-DNB scanner module in Run mode



Exercise: Configuring a 1756-DNB DeviceNet Scanner Module

5--15

Exercise: Configuring a 1756-DNB DeviceNet Scanner Module Exercise A

In this exercise, you will practice configuring a scanner module by performing the following tasks: •


•

Create a scanlist

•


Context: Configuring the network’s master scanner, the 1756-DNB module determines which devices will communicate with it and how they will communicate. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 5000 software, consult the Start Pages or the online Help.

Directions: Follow the steps below to configure a 1756-DNB scanner module: 1. Open your network configurati on. 2. Go online to the network. 3. Upload the network configurati on. 4. Monitor the PanelView Plus scanner module configuration . It should be configured for slave mode with the following properties: • • •

Tip "

Cyclic 4 bytes of input 4 bytes of output

If you receive an error that the processor is in Run mode, press the GoTo Config button on the screen of the PanelView Plus terminal. 5. Configure the scanner module, the 1756-DNB, as outlined in the following table: Parameter

InterscanDelay

Rev. July 2008

Setting

8milliseconds

Foreground to Background Poll Ratio

2

Slot

Slotlocationofscannermodule E 2008 Rockwell Automation, Inc. All rights reserved. SCNe100

5--16


6. Download the device configura tion to the scanner module. 7. On the Scanlist tab of the 1756-DNB properties dialog box, verify that the Automap on Add check box is not selected. If it is, clear it. 8. Create a scanlist that includes all the devices on the network.

Tip "

If prompted that either or both of the 1734-ADN Point I/O module or PanelView Plus operator interface contains no I/O data, click OK to the Scanner Configuration Applet dialog box. 9. Download the device configura tion to the scanner module. 10. Save the network configuratio n.

How Did You Do?


Exercise B

In this exercise, you will practice entering ladder logic instructions to place a scanner module in Run mode.

Context: You have configured the scanner module that is to act as the network master for the DeviceNet network. Y ou now need to write the necessary ladder logic to place the scanner in Run mode so it can begin communicatin g with the controller and network devices.

Tip "


Directions: Follow the steps below to place the scanner module in Run mode. 1. Open exercise file SCN_N100_B1.acd. 2. In the main routine, enter ladder logic instructions to place the scanner in Run mode. 3. Verify the rung. 4. Download the program to the controller. 5. Change the controller’s operatin g mode to Run. 6. Verify that the scanner module is in Run mode by accessing the Run bit in the scanner module’s status regis ter and verifying that it is on.

Tip " E 2008 Rockwell Automation, Inc. All rights reserved.

will also be periodically displayed on the front of the scanner module. RUN

Rev. July 2008 SCNe100


5--17

7. Change the controller’s operat ing mode to Program.

How Did You Do?

Rev. July 2008


E 2008 Rockwell Automation, Inc. All rights reserved. SCNe100

5--18


Answers

Exercise A 4. If you have correctly configured the PanelView Plus DeviceNet scanner module for slave mode, the Slave Mode dialog box for that scanner module should look like the following graphic:

5. If you have correctly configured the 1756-DNB scanner module that is to act as the network master for your workstation, the Module property page will look like the following graphic:




5--19

8. If you have correctly created a scanlist, the Scanlist property page for the scanner module that is to act as the network master for your workstation will look like the following graphic:

Exercise B 2. If you correctly entered ladder logic instructions to place the 1756-DNB scanner module in Run mode, you should have a

rungRSLogix of ladder5000 logicsoftware near the program beginningthat of the main routine the resembles the in following graphic:

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. SCNe100

5--20




Lesson If you are using SLC 500 hardware, use the alternative lesson, Mapping Inputs and Outputs to a 1747-SDN Scanner Module on a DeviceNet Network .

What You Will Learn

6

Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network After completing this lesson, you should be able to map inputs and outputs on a DeviceNet network by performing the following tasks: •

Edit device message type and I/O sizes

•

Map device input and output data automatically

•

Map device input and output data manually

•

Identify DeviceN et addresses in a ControlLogix controller

Why These Skills Are Important Mapping is important because the location of inputs and outputs in a controller must be correctly specified in a scanner module for communications to occur between the controller and network devices. Well-organized inputs and outputs in a scanner module can also improve the efficiency of network communica tions and facilitate future maintenance and troubleshooting tasks.

Before You Begin

? Does anyone have experience mapping input and output data? If s o, what have you found to be the most challenging aspect of this task? Since this is often a confusing concept for students, emphasize the fact that inputs and outputs on a DeviceNet network are defined from the point of view of the controller.

Rev. July 2008

Inputs and Outputs To correctly map inputs and outputs, it is important to understand the perspective from which inputs and outputs are defined on a DeviceNet network. The following definitions apply to inputs and outputs on a DeviceNet network: •

Input data is data received by a controller from a device via a scanner module (read).

•

Output data is data sent to a device from a controller via a scanner module (write).

E 2008 Rockwell Automation, Inc. All rights reserved. MAPib100

6--2


Input and output data on a DeviceNet network are defined from the point of view of the controller, not the devices with which it communicates.

Message Type and I/O Sizes

Do not go into detail about each of these message types now. They will be explained in the ensuing pages.

Tip " If this course is being taught in its standard format (i.e., it is not part of a Tailored Training curriculum), do not go into detail about EDS files; they will be covered in a later lesson.

•

Polled

•

Strobed

•

Change-of-state

•

Cyclic

Not all devices support all message types. The message type(s) that are supported by a given device can be determined by accessing the I/O Data property page, the device’s EDS (electronic data sheet) file, or the data sheets that ship with the device. In addition to the types of messages used by the scanner module, the following message size parameters must be set:

Tip "

Mention that if an output bit is Tip ever configured for a strobed device, it usually contains status data.

Device message type and I/O sizes must be edited to determine the manner in which data will be transmitted to and from a scanner module and how much data will be transmitted. One of the following message types must be specified for each device in a scanner module’s scanlist:

"


•

Input Size: The number of bytes of data being sent from a device to a controller via a scanner module in an I/O message.

•

Output Size: The number of bytes of data that a controller will send to a device via the scanner module in an I/O message.

The range of valid values for input and output sizes differs depending upon the type of message being sent (i.e., strobed, polled, change-of-state, or cyclic). Strobed messages do not have an output size parameter because they are not generally capable of receiving data from a controller via the scanner module.

Rev. July 2008 MAPib100


6 -- 3

The following graphic shows the RSNetWorx for DeviceNet software window where message type and I/O sizes are edited for a device:

Message Type I/O Sizes

Polled Messages

Polled messages operate on a network in the following manner: 1. A poll rate (the rate at which the scanner module will request data

from an assigned device) is configured. Unless the foreground to background poll ratio is set for a longer time interval between scans, poll commands are issued during every scan cycle.

Explain that since poll commands are issued during every scan cycle, configuring a device that seldom has new data to report for polled messaging needlessly slows down network performance.

Rev. July 2008

2. A poll command containing output data is sent from a scanner module to each polled device. 3. Upon receipt of the command, the device transmits a response containing input data.


6--4


The following graphic shows a scanner module communica ting with devices via polled messaging:

Scanner Module Poll Command



Device Response

Device 1

Scanner Module

Scanner Module

Scanner Module

Device 2

Device Response

Device Response

Device 3

Device 1

Device 2

Device 3

Device 1

Device 2

Device 3

Strobed Messages

Strobed messages operate on a network in the following manner: Emphasize that even though both poll and strobe commands are issued during every scan cycle, the difference is that polled devices receive input data and send output strobed data, but, with a do fewnot exceptions, devices receive any output data.

1. A strobe command is transmitted by a scanner module to all devices in its scanlist. 2. Only those devices configure d for strobed messaging respond

with their input data. Strobe commands are issued during every scan cycle.

Tip "


Strobed messages are used for devices that have input data to send to a controller, but do not receive output data from the controller.


6 -- 5


The following graphic shows a scanner module communic ating with devices via strobed messaging: Scanner Module

Scanner Module Strobe Command

Scanner Module Strobe Command Device Response

Device 1

Device2

Device3

Device4

Device Response

Device5

Change-of-State Messages

Devices configured for change-of-state messaging only send data to a scanner module when they have new data to report (i.e., the data has changed since the last time it was sent) or at a user-configured “heartbeat” rate. A scanner module does not(i.e., solicit data devicesduring configured for change-of-state messaging they arefrom not polled every scan cycle).

Tip "

? Why do you think a heartbeat rate is necessary if a device only sends information on a change-of-state basis?

Tip "

Answer: Because it allows a scanner module to distinguish between a change-of-state device whose data has not changed and a change-of-state device that has become non-operational.

Rev. July 2008

Devices configured for change-of-state messaging can be configured to send a scanner module data at a user-configured “heartbeat” rate regardless of whether or not their data has changed since the last change-of-state message was sent. Devices configured for change-of-state messaging can still receive output data from a scanner module. Cyclic Messages

Cyclic messages are similar to change-of-state messages, but they are sent only at a user-config ured rate. Therefo re, a cyclic message may be sent by a device even if the device’s data has not changed since the last time it was sent.


6--6


Tip " Suggest that change-of-state and cyclic messaging should be used whenever they are appropriate to a device’s function on a network, since they are the most efficient forms of messaging.

Tip " Note that in the following graphic,which illustrates change-of-state and cyclic

Both change-of-state and cyclic messages greatly reduce network traffic and allow faster scanner module respons e time since they do not require the scanner module to scan every device during a scan. These types of messages work well for devices with data that does not change often. Devices configured for cyclic messaging can still receive output data from a scanner module. The following graphic shows a scanner module communica ting with devices via change-of-sta te and a device cyclic messaging:

messaging, devices senda data to afor scanner module without request data from the scanner module.

Scanner Module

Device’s Change-of-State Message to Scanner Module

Device 1

Device 2

Device’s Cyclic Message to a Scanner Module

Device 3

Device 4

Device 5

The following table provides an overview of the relationship between a scanner module and devices configured for each of the four message types from the point of view of the scanner module: If a device is configured for this message type . . .

Then the scanner module . . .

And . . .

Polled

Sends data to the device and receives data from the device

Scans the device during every scan cycle

Strobe

Does not send data to the device, but does receive data from the device


Sends data to the device Change-of-state

Cyclic


and receives data from the device

Does not scan thecycle device during every scan


Does not scan the device during every scan cycle



6 -- 7

Data Map Plan It’s important to give careful considerat ion to where device input and output data is to be mapped in a scanner module so that no devices overlap each other and space is provided for future additions, if necessary. Planning a configuration before mapping data can help ensure that the following needs are met: Make sure everyone understands what is meant by the term “bandwidth.”

•

Memory and bandwidth are used efficiently.

•

Device-specific needs and requirements are acknowledged.

•

Priority is given to critical I/O transfers.

•

Room is left for expansion.

•

Device data does not overlap.

To ensure that the above considerations are addresse d, you should be familiar with the following variables specific to your network and devices:

Note that data structure of devices will be discussed in detail later in this lesson.

•

Communications requirements

•

Size and importance of the inputs and outputs sent and received by each device

•

Data structure of devices

•

Frequency of the message

•

Plans for the addition of devices or changes to the network

Mapping Explain that the input and output data map in a scanner module is comparable to a road map that helps a controller to find the location of device input and output data in a scanner module.

Rev. July 2008

Mapping is the software function by which device input and output data locations are specified in a scanner module. Mapping enables communications between network devices and a controller to occur by determining the following variables : •

Where discrete input data from devices will be located in a controller

•

Where discrete output data from a controller will be located in a scanner module so that it may be sent to network devices


6--8


Automatic Mapping

? How would you define data optimization? Answer: The use of each bit of data in the scanner module’s data table (i.e., if one device does not use every bit in one word of data, the next device will begin where the one before it left off). This may not necessarily happen if automatic mapping is used.

Data is often mapped using the automatic mapping feature in RSNetWorx for DeviceNet software. The following facts should be taken into consideration when the automatic mapping feature is used: •

Automatic mapping does not allow much control (i.e., data organization cannot be optimized or consolidated).

•

Automatic mapping does not align input and output data with input and output addresses in a processor or controller.

•

If all devices on a network are mapped simultaneously using the automatic mapping feature, the software will map devices based on their node addresses. The device with the lowest node address will be assigned to the first available word, and so on.

Verify that students have an understanding of byte, bit, and word lengths. If not, spend a few minutes reviewing these terms.

Even though a device’s node address roughly determines where the device will be automapped, the word to which a device is automapped is not a one-to-one match (i.e., a device with a node address of 2 will not necessarily be automapped to word 2). •

If devices are automatically mapped individually as they are added to a network, the software will assign word numbers based on the order in which the devices are mapped (e.g., the first device will be mapped to word 1, etc.).

•

Future changes (e.g., addition of devices, removal of devices) may not be easily addressed.

Automatic Mapping Options

Mapped data can be organized using the following alignment options:

Point out that since the first two devices mapped in the following graphic both contain only one byte of input data, the pack alignment and byte alignment options line up the data in the same way.


•

Pack Align: Allows data to be mapped on a byte, word, or double-word boundary or to be efficiently grouped without alignment (pack).

•

Byte Align: Ensures that data is used as efficiently as possible to the byte level (two devices can share the same word location).

The following graphic illustrates the pack and byte alignment options in a 1756-DNB scanner module:



•

In the graphic that illustrates the word alignment option, point out that input mapping for each device begins at a new word, even through the individual devices do not all send an entire word of input data.

6 -- 9

Word Align: Ensures that each device is mapped to a unique word.

The following graphic illustrates the word alignment option in a 1756-DNB scanner module:

•

In the graphic that illustrates the double-word alignment option, point out that input mapping for each device begins at a new double-word, even though no individual device sends an entire double-word of input data.

Double-Word (DWord) Align: In a 1756-DNB scanner module, ensures that each device is mapped to a different double-wo rd.

The following graphic illustrates the double-word alignment option in a 1756-DNB scanner module:

The double-word alignment option is only available for 1756-DNB scanner modules used with ControlLogix controllers.

Manual Mapping

? If you know that in the future you will

Data can also be mapped manually (i.e., a user can specify exactly where a controller should look for device data in a scanner module) using RSNetWorx for DeviceNet software. The following considerations should be taken into account when data is mapped manually:

have a device at node 8, how would you map the current device data?

•

Data can be organized and optimized.

•

Room can be left for future expansion.

Answer: So that that scanner module’s map table is empty at word 8 (or that enough room is left for the device data).

•

Manual mapping can be more time-consuming than automatic mapping.

Rev. July 2008

Tip "

To map data manually, it is necessary to deactivate the automatic mapping feature that is set up in the software by default.

Tip "

A combination of manual and automatic mapping can also be used (i.e., inputs and outputs can be automatically mapped and then fine tuned using the manual mapping feature).


6--10


Take the following facts into consideration when mapping data manually:

? Why might you configure a device to

•

The type of data transmitted (e.g., status, I/O data, and configuration data) varies with each device.

•

All data sent to devices from a controller (output data) is in byte length (i.e., even if a controller produces two bits of information, an entire byte will be sent to the device).

•

Data sent by devices to a controller (input data) can be less than one byte.

send less than one byte of data to a controller? Answer: If all bits in a byte are not being used, data table space can be conserved by sending only those bits

that are used. Note that map segmentation will be discussed in greater detail later in this lesson. Remind students that the Input tab in the following graphic represents the area where inputs from devices to a controller are mapped.

•

Bits can be mapped to separate memory locations (i.e., map segmentation).

The following graphic shows the RSNetWorx for DeviceNet software property page where input data is entered for a 1756-DNB scanner module: The First Controller Input Word to which Devices Will Be Mapped

The Device Being Mapped The Second Double-Word of the Double-Word Offset

The First Double-Word of the Double-Word Offset

The Scanner Memory Area to which the Device Will Be Mapped The Double-Word Offset

Map Segmentation Mention the 871TM inductive proximity

The process of mapping data for a single device to different areas of

sensormap as an example of aisdevice which segmentation useful.for Since the sensor’s analog signal is the entire second byte of input data sent by the sensor to a controller, it is easier to access the data in a ladder logic program if the byte containing the analog data is mapped to its own word.

a scanner module’s memory is called map segmentation. Map segmentation is most often used when it is necessary to isolate bits pertaining to specific functions of a device so they can be easily accessed in the ladder logic program.



6--11


Example: PowerFlex 40 Drive Map Segmentation in a 1756-DNB Scanner Module

A PowerFlex 40 drive is configured to receive four bytes (two words) of output data from a ControlLogix controller via a 1756-DNB scanner module, as shown in the following graphic of the drive’s selected output assembly: Logic Command/Status Words First Output Word

Byte

Bit7

Bit6

Bit5

Bit4

Bit 2

Bit3 Clear Faults

Jog

Bit 1 S t a rt

B it 0 St o p

Speed Reference RPM (Low Byte)

Second Output Word

Speed Reference RPM (High Byte)

The drive’s speed reference is two bytes, or one word.

Note that if the drive’s output map had not been segmented, all of the output data would be mapped to one double-word and the speed reference would only be accessible if ladder logic was written to mask the first 32 bits.

Since the drive’s speed refere nce is the entire second word of output data, the second output word is mapped to its own double-word in the 1756-DNB scanner module so that it can be easily accessed in the ladder logic that controls the drive, as shown in the following graphic:

The PowerFlex 40 drive’s output data is mapped to two separate double-word locations. PowerFlex 40 Logic Feedback Word

PowerFlex 40 Speed Reference Word

Rev. July 2008


6--12


Address Identification Note that the addresses to which inputs and outputs are mapped in a scanner module are arbitrary as long as the ladder logic to control the devices has not yet been written.

Tip "

Explain that since this is not a programming course, the workstation ladder logic is already provided. Point out that knowledge of bit functions within a device is essential when writing ladder logic to correspond to input and output data maps in RSNetWorx for DeviceNet software.

Being able to identify Device Net addresses in a controller is important because the ladder logic to control the devices must use the addresses to which the devices have been mapped. It’s a good idea to document where inputs and outputs have been mapped in a scanner module so their locations can be referenced when ladder logic is written. Addresses are identified by comparing the location where a device is mapped in a scanner module to the corresponding area in the controller that is to control the device. All of the following tools are used to identify addresses: •

The logic programming software for the application (e.g., RSLogix 5000 software, RSLogix 500 software, etc.)

•

RSNetWorx for DeviceNet software

•

The device’s documentation manuals

1756-DNB Mapping in RSNetWorx for DeviceNet Software and ControlLogix Addresses in RSLogix 5000 Software

For ControlLogix controllers , DeviceNet data is stored in tags that are automatically created when a 1756-DNB scanner module is added to a hardware configuration in RSLogix 5000 software. Since all data passed between a 1756-DNB scanner module and a ControlLogix controller is discrete, all input and output data is stored in the following locations : •

Input tags

•

Output tags

The format of these input and output tags is similar to that of local inputs and outputs, as shown in the following graphic:

Local:1:I.Data[0].0 Local Chassis


Slot Number of 1756-DNB Scanner Module

Word Input

B it

Member



6--13

The following graphic shows the relationship between the input data map for a 1756-DNB scanner module and the input data tags in the corresponding ControlLogix controller: 1756-DNB OutputData Map

ControllerTag Database

PanelView inputs mapping begins at input word 4 in the 1756-DNB scanner module.

PanelView inputs show up starting at input word 4 in the controller tag database.

Device Data Structure Explain that, even if it is known that inputs for an operator interface are mapped to input word one in a controller, it is necessary to determine which of those bits represents the “start” button.

Knowledge of a device’s data structure is necessary to properly identify Device Net addresses in a controller because even if the general address location of a device is known, ladder logic cannot be written to properly control the device without specific information about individual bit function. The data structure of a device can be determined using any one of the following resources: •

The I/O Data property page for the device (called the I/O Defaults property page for some devices)

If this course is being taught in its standard format (i.e., it is not a part of a Tailored Training curriculum), do not explain EDS files in detail; they will be

•

The device’s EDS file (which can be accessed using the EDS File property page)

•

Documentation that ships with the device

addressed in the Managing EDS Files lesson.

•

The RSNetWorx for DeviceNet software Help system

Rev. July 2008


6--14


Example: Data Structure of an ArmorBlock MaXum Input Module

The data structure of an ArmorBlock MaXum 4 input module configured for change-of-state messaging is shown in the following graphic:

Point out that the data structure information in the following example was accessed using the I/O Defaults property page in RSNetWorx for DeviceNet software.

Input Data Byte 1 Bit 7

4 ArmorBlock Input Module

Bit 0

Circuit Detection for Connectors A-D

Inputs 0- 3


Bit 0

Unused

? How would the information about the

Offwire Detection for Connectors A-D

When configured for change-of-state messaging, the ArmorBlock MaXum 4 input module sends 2 bytes of input data and does not send any output data. The first byte of input data sent contains the following bits:

data structure of the ArmorBlock MaXum I/O module in this example help when mapping inputs and outputs? Possible Answer: Scanner module space could be conserved by only mapping those bytes that are essential to the module’s operation in a specific

• • •

application.

• • • • •

Bit 0 is an input bit corresponding to input 0. Bit 1 is an input bit corresponding to input 1. Bit 2 is an input bit corresponding to input 2. Bit 3 is an input bit corresponding to input 3. Bit 4 indicates an input short circuit for connector A. Bit 5 indicates an input short circuit for connector B. Bit 6 indicates an input short circuit for connector C. Bit 7 indicates an input short circuit for connector D.

The second byte of input data contains the following bits: • • • • •

Here’s How Perform the following demonstration: 1.Using the 1756-DNB scanner module, edit the message type and I/O sizes for any device on your workstation. 2.Map data automatically for the device, then unmap it and map again manually. E 2008 Rockwell Automation, Inc. All rights reserved.

Bit 0 is an offwire detection bit corresponding to connector A. Bit 1 is an offwire detection bit corresponding to connector B. Bit 2 is an offwire detection bit corresponding to connector C. Bit 3 is an offwire detection bit corresponding to connector D. Bits 4 to 7 are not used.

To map device inputs and outputs on a DeviceNet network by performing the following tasks: • Edit device message type and I/O sizes •


•

Map device input and output data manually Rev. July 2008 MAPib100


6--15


Here’s How Perform the following demonstration: 1. Access the I/O data structure for the 871TM sensor in the Online Help system and point out the sensor’s output bit.

To identify DeviceNet addresses in a ControlLogix controller. As your instructor demonstrates this procedure, refer to the following example:

2. Based on the input data table for the sensor in RSNetWorx software, point out the bit in the ControlLogix controller’s input data table that should be affected if an object is placed in front of the photoelectric sensor. 3. Test this conclusion by touching the sensor to a metal object and monitoring the appropriate bit in the RSLogix 5000 input data table.

Example

DeviceNet Address Identification Step 1: Identify RSNetWorx for DeviceNet Input Data Map

The following graphic shows RSNetWorx for DeviceNet software input maps for an 871TM inductive proximity sensor in the scanlists of a 1756-DNB scanner module: 1756-DNB Input Data Map Sensor Inputs (Two Bytes or One Double-Word)

In the example, the input data table in RSNetWorx for DeviceNet software is used to determine in the 1756-DNB scanner module, two bytes (one word) of sensor input are mapped to the lower half of double-word 0.

Rev. July 2008


6--16


Step 2: Identify RSLogix 5000 Input Tags

The following graphic shows the RSLogix 5000 software input tags associated with the 1756-DNB scanner module: RSLogix 5000 Input Tag

Sensor Inputs

In the example, input data from the 871TM inductive proximity sensor is traced to the areas in the ControlLogix controller based on input data mapping in RSNetWorx for DeviceNet software.




6--17

Step 3: Identify Device Data Structure

The following graphic shows the data structure of the 871TM inductive proximity sensor used to determine the function of each input bit mapped for the sensor:

In the example above, the RSNetW orx for DeviceNet online Help system is used to determine the function of individual input bits mapped for the 871 inductive proximity sensor in RSNetWorx for DeviceNet software.

Tip "

Rev. July 2008

Access the online Help topic list by selecting Contents from the Help menu in the main RSNetWorx for DeviceNet software window.


6--18




Exercise: Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network

6--19

Exercise: Mapping Inputs and Outputs to a 1756-DNB Scanner Module on a DeviceNet Network Exercise A

In this exercise, you will practice mapping inputs and outputs on a DeviceNet network by performing the following tasks: •


•


•


Context: You are now ready to map the device input and output data for your DeviceNet network to define how the devices on your network will communicate with the controller. You have received specifications on where the devices should be mapped so that ladder logic to control the production line could be written accordin gly. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Follow the steps below to map device inputs and outputs: 1. Open a new network configuration . 2. Go online to the subnetwork of the 1734-ADN module:

1734-ADN Subnetwork

3. Upload the network configurati on.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. MAPe100

6--20


4. Access the Scanner Module window for the 1734-ADN Point I/O scanner module. 5. Automatically map device input and output data for all Point I/O nodes on the 1734-ADN scanner’ s (node 00) subnetwork. 6. Save the network configuration as ADN_Subnet.dnt. 7. Close the ADN_Subnet configuration. 8. Open a new network configuration . 9. Go online to the main network. 10. Upload the network configuratio n. 11. Access the properties of the 1734-ADN Point I/O adapter and associate the ADN_Subnet.dnt file you created with the adapter. 12. Access the PanelView Plus properties dialog box. 13. Automatically map device input and output data on the Input and Output tabs of the PanelView Plus properties dialog box.

Tip "

Make sure your mapping settings are set to Pack Align. 14. Access the Scanner Module window for the scanner module that is acting as the master for your network, the 1756-DNB module. 15. Edit device message type and I/O sizes as outlined in the following table: Device Absolute multi--turn Encoder

871TM inductive proximity sensor

E3overloadrelay 1734-ADN Point I/O adapter PowerFlex40Drive


Message Type Strobed

Input Size

Strobed " Be sure to deselect the default message type (change-of-state) Polled

Output Size N/A

4

2

8

Change-of-state (250 ms Heartbeat) Polled

N/A

1 8

4

5 4

ArmorBlock MaXum input module

Change-of-state (250 ms Heartbeat)

2

0

PanelView Plus operator interface

Cyclic Heartbeat rate (Sendrate 1000ms)

4

4

Rev. July 2008 MAPe100

6--21


PanelView Plus I/O sizes must also be configured at the device itself using RSView Studio software. I/O sizes have already been configured for you at the PanelView Plus terminal.

16. Download the device configurat ion to the scanner module. 17. Manually map device input and output data in the 1756-DNB scanner module as outlined in the following table: Device

Input Data Mapping • Assembly


• DWord: 0 • Bit:

Output Data Mapping

Data N/A

0

• Number of bits: 32 • Assembly


• Bit:

0 • Number of bits: 16 • Assembly

E3 overload relay

1734-ADN Point I/O adapter module

PowerFlex 40 drive

Data

N/A • Assembly

• DWord: 2

• DWord: 2

• Bit:

0 • Number of bits: 64

• Bit:

• Assembly

• Assembly

Data

• DWord: 4

• Bit:

• Bit:

0

Data


• DWord: 4

Data

0

• Number of bits: 64


Segment 1: Map From: • Message: Polled • Byte: 0 • Bit: 0 Map To: • Assembly Data • DWord: 6 • Bit: 0 • Number of bits: 16 Segment 2: Map From: • Message: Polled • Byte: 2 • Bit: 0 Map To: • Assembly Data • DWord: 7 • Bit: 0 • Number of bits: 16


• Assembly


Data

• DWord: 1

Data


N/A

0


PanelView Plus 600 operator interface

Data

• DWord: 9

• Bit:

• Bit:

0


Rev. July 2008

• Assembly

• DWord: 9

Data

0



6--22


18. Download the device configura tion to the scanner module. 19. Save the network configuratio n.

How Did You Do?


Exercise B

In this exercise, you will practice identifying DeviceNet address es in a ControlLogix controller.

Context: You have mapped input and output data in the 1756-DNB scanner module acting as the master on the DeviceNet network. You now need to identify DeviceN et addresses in the corresponding ControlLogix controller so that ladder logic to control these devices can be written accordingly. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "


Directions: Using RSNetWorx for DeviceNet and RSLogix 5000 software, identify DeviceNe t addresses in the ControlLogix controller and answer the following questions: 1. Change the controller’s operatin g mode to Run. 2. Open your network configuratio n. 3. Go online to the network. 4. Identify the input address(es) where the analog values from the 871TM inductive proximity sensor should show up in the Controller Tags window of the ControlLogix controller:

Tip "


Use either the EDS file for the 871TM inductive proximity sensor or the 1756-DNB properties dialog box to determine the sensor’s data structure:



Tip "

6--23

Remember that the 871TM inductive proximity sensor has been configured for strobed messaging, which is not the default message type supported by the sensor. 5. Test your conclusion by performing the following actions: A. Start RSLogix 5000 software. B. Go online to the ControlLogix controller. C. Change the controller’s operatin g mode to Run. D. Monitor the controller’s input data tag values through the Controller Tags window while moving a metal target (such as a key or coin) towards and away from the 871TM inductive proximity sensor. The bits at the addresses you identified in Step 3. should turn on and change as the target moves towards the sensor.

Tip "

For help going online to the ControlLogix controller, changing the controller’s operating mode, or monitoring the controller’s input tag values, refer to the Start Pages or online Help. 6. Identify the input address where pushbutton DI0 (wired to to input point 0 on the first input sink of the 1734-ADN Point I/O adapter) on the workstation should show up in the controller’s Controller Tags window:

7. Test your conclusion by performing the following actions: A. Press the DI0 push button on workstation to start the motor while monitoring input tag values in the Controller Tags window. The bit that goes on when this button is pressed should be the bit that was identified in Step 6. B. Press the DI1 pushbutton to stop the motor. 8. Identify the address of the third ArmorBlock input bit:

9. Test your conclusion by pressing pushbutton IN2 on the workstation while monitoring input tag values in the Controller Tags window. The bit that goes on when this button is pressed should be the bit that was indentified in Step 8. 10. PowerFlex Identify the 40 output address drive’s Startthat bit:reflects the status of the

Rev. July 2008


6--24


Tip "

Use the PowerFlex 40 Drive Data Structure appendix to determine the data structure of the PowerFlex 40 drive. Data structure information for the drive is located in the user manual of the drive’s DeviceNet communications module, not the drive’s EDS file. 11. Test your conclusion by performing the following actions: A. Press the DI0 pushbutton on the workstation to start the motor in workstation. B. Monitor output tag values in the Controller Tags window. The bit identified in Step 10. should be on. C. Press the DI1 pushbutton on the workstation to stop the motor. 12. Change the controller’s operati ng mode to Program. 13. Minimize RSLogix 5000 software. 14. Close RSNetWorx for DeviceNet Software.

How Did You Do?





Rev. July 2008

6--25


6--26


Answers

Exercise A 5. On the Scanlist tab of the 1734-ADN Point I/O scanner module’s scanner window make sure Automap is selected and move all Point I/O nodes to the scanlist:

Add All

Automap

11. You should have accessed the Device Bridging tab of the

1734-ADN Point I/O adapter’s propertie s page and associated the ADN_Subnet.dnt file with module:




6--27

13. The input and output tabs of the PanelView Plus properties window should look similar to the following:

15. If you have correctly edited input and output parameters for the E3 overload relay, the Edit I/O Parameters window for the E3 overload relay will look like the following graphic:

Rev. July 2008


6--28


If you have correctly edited input and output parameters for the Absolute Multi-Turn Encoder, the Edit I/O Parameters window for the RightSight photoelectric sensor will look like the following graphic:

If you have correctly edited input and output parameters for the PowerFlex 40 drive, the Edit I/O Parameters window for the PowerFlex 40 drive will look like the following graphic:




6--29

If you have correctly edited input and output parameters for the 871TM inductive proximity sensor, the Edit I/O Parameters window for the 871TM inductive proximity sensor will look like the following graphic:

If you have correctly edited input and output parameters for the 1734-ADN Point I/O adapter, the Edit I/O Parameters window for the 1734-ADN Point I/O adapter will look like the following graphic:

Rev. July 2008


6--30


If you have correctly edited input and output parameters for the ArmorBlock MaXum input module, the Edit I/O Parameters window for the ArmorBlock MaXum input module will look like the following graphic:

If you have correctly edited input and output parameters for the PanelView Plus operator interface, the Edit I/O Parameters window for the PanelView Plus operator interface will look like the following graphic:




6--31

17. If you have correctly entered input data manually, the input data table for the 1756-DNB scanner module will look like the following graphics:

If you have correctly entered output data manually, the output data table for the 1756-DNB scanner module will look like the following graphics:

Rev. July 2008


6--32


Exercise B 4. The analog values from the 871TM inductive proximity sensor should show up in the Controller Tags window of the ControlLogix controller at input word 1, bits 8 to 15 (Local:2.I.Data[1].8--15). 6. The address bit for pushbutton DI0 should show up in the Controller Tags window of the ControlLogix controller at input word 4, bit 16 (Local:2.I.Data[4].16). 8. The address of the first ArmorBlock input bit is input word 8, bit 2 (Local:2.I.Data[8].2). When the ArmorBlock input module is configured for change-of-sta te messaging, the first input bit in its data structure controls the first ArmorBlock input connection. In the 1756-DNB scanner module, the module’s input map begins at word 8, bit 0. Therefore, this is the bit that corresponds to the ArmorBlock module’ s third input. 10. The output address that reflects the status of the PowerFlex 40 drive’s Start bit is output word 6, bit 1 (Local:2:O.Data[6].1). The drive’s Start bit is the second output bit received by the drive from the controller. In the 1756-DNB scanner module, the output map for the drive begins at output word 6, bit 0. Therefore, the drive’s Start bit is located at output word 6, bit 1.



Lesson

7

Managing DeviceNet EDS Files What You Will Learn

After completing this lesson, you should be able to manage DeviceNet EDS (electronic data sheet) files by performing the following tasks: •

Determine a device’s EDS file number

•

Register an EDS file

Why These Skills Are Important Devices require EDS files to be registered in RSNetWorx for DeviceNet software in order to be configured. RSNetWorx for DeviceNet software will only be able to display a device with the parameters and options it supports (and that are needed to correctly configure the device) if an EDS file for the device has been registered to the computer on which RSNetWorx for DeviceNet software is installed.

Before You Begin

EDS Files EDS files are ASCII files created by device manufacturers and supplied with a device that provide the following information about a device: • Manufacturer and device type

Note that not all EDS files contain device data structure information. Devices that have a number of possible input and output assemblies, (such as an 800E pushbutton station, an E3 overload relay, and a Bulletin 160 drive) do not always list this information in the EDS file. In these cases, the data structure can be found in the documentation that ships with the device.

Rev. July 2008

•

Major revision

•

Minor revision

•

Message types supported by the device

•

Input and output sizes

•

Device data structure

•

Device-configurable parameters

•

Class, instance, and attribute data

•

Differentiating features

E 2008 Rockwell Automation, Inc. All rights reserved. EDSib100

7--2

Managing DeviceNet EDS Files

EDS File Benefits Explain that if no EDS file is provided for a device, the only way to access the information needed to properly configure the device would be to send it a series of explicit messages requesting it to upload its configuration data.

EDS files provide the following benefits :

Note that the information in a device’s Parameters and I/O Data property pages is drawn from the EDS file registered to the device.

Tip "

•

The ability to easily configure devices for which EDS files are provided using RSNetWorx for DeviceNet software

•

Easy access to class, instance, attribute codes and data formatting information needed to perform explicit messagi ng

•

Context-specific Help screens with device data size, structure, and parameter information

Once an EDS file has been registered to a device, the device is included in the RSNetWorx for DeviceNet software hardware list and its EDS file can be accessed directly through the device’s EDS File property page. The following graphic shows the RSNetWorx for DeviceNet software property page where the EDS file for an absolute multi-t urn encoder is accessed:

Command Button to Open EDS File


Rev. July 2008 EDSib100


7 -- 3

EDS File Library Explain that an EDS file library is automatically created when RSNetWorx for DeviceNet software is installed on a computer and all the EDS files that are available for Rockwell Automation devices at the time of the software release are included in the library. These devices should Tip " automatically show up in RSNetWorx for DeviceNet software.

An EDS library is a collection (database) of EDS files that has been added to the system directory of the computer that contains RSNetWorx for DeviceNet software. All configuration information for devices with EDS files is contained in this database.

Tip " Tell students which directory EDS files have been saved to on their workstations so they can access them for the lab exercise associated with this lesson.

EDS files from various device manufacture rs can be downloaded from the ODVA (Open DeviceNet Vendor Association) Web site to your EDS library by accessing http://www.odva.org.

EDS files for Rockwell Automation devices can be downloaded from the Rockwell Automation Web site to your EDS library by accessing http://www.ab.com/networks/eds.

EDS File Number EDS files for Rockwell Automation devices are organized by number. Since an EDS file does not actually bear the name of the device for which it contains data, the device’ s EDS file number must be determined in order to locate the file and add it to the database. An EDS file number is generated from the values assigned to the device’s vendor, device type, product, and revision level. Based on this information, the following steps are taken to determine an EDS file number: 1. The numbers are listed in the following order: • Vendor • Device type • Product • Revision level 2. The numbers are converted into hexadecimal code. 3. Leading zeroes are placed in front of each numeral with less than four digits.

Rev. July 2008


7--4


Note that if no EDS file is registered to a device on a computer, a yellow question mark icon will be displayed in the RSNetWorx for DeviceNet software network configuration instead of the device’s icon. However, the window needed to determine the device’s vendor, device type, product, and revision codes will still be accessible by double-clicking the question mark icon.

The following graphic shows the RSNetWorx for DeviceNet software window where the values needed to determine a device’s EDS file number are located:

Vendor Device Type Product Revision

Example: PowerFlex 40 Drive EDS File Number

The following graphic shows the RSNetWorx for DeviceNet software window where the PowerFlex 40 drive’s vendor, device type, product, and revision level values are located:




7 -- 5


First the value in each block is converted to a hex value or EDS file segment. Then the four hex values are combined to form the EDS file number. The following table shows the makeup of the EDS file for the PowerFlex 40 drive based on the values assigned to the drive’s vendor, device type, product, and revision: Vendor

If the revision level of the PowerFlex ? 40 drive was 5.00, what would the EDS file number be?

Answer: 0001007E82280500.

Device Type

Product

Revision

Value

1

126

33,320

3.003

EDS File Segment

0001

007E

8228

0300

The PowerFlex 40 drive’s vendor , device type, product, and revision level values are 1, 126, 33,320, and 3.003, respectivel y. Therefore, the PowerFlex 40 drive’s EDS file number is 0001007E82280300. Example: E3 Overload Relay EDS File Number

The following graphic shows the RSNetWorx for DeviceNet software window where the E3 overload relay’s vendor, device type, product, and revision level values are located:


The following table shows the makeup of the EDS file for the E3 overload relay is based on the values assigned to the scanner module’s vendor, device type, product, and revision: Vendor

Rev. July 2008

Value

1

EDS File Segment

0001

Device Type

3

Product

29 0003

Revision

3.003 001D

0300


7--6


The E3 overload relay’s vendor, device type, product, and revision level attribute values are 1, 12, 29, and 3.003, respectively. Therefore, the E3 overload relay’s EDS file number is 00010003001D03 00.

Remind students that since a device’s vendor, device type, product, and revision attribute codes must be converted to hexadecimal code, a device’s EDS file number may c ontain letters.

The EDS Wizard Do not go through the steps of registering EDS files now. This will be covered in the Here’s How section of this lesson. Point out that EDS files created using the EDS Wizard are often called “stub” files because they contain the minimum amount of information about a device necessary to configure it for operation on a DeviceNet network.

RSNetWorx for DeviceNet software provides a tool for working with EDS files. The EDS Wizard in the Tools menu allows users to perform the following actions with EDS files: •

Register EDS-based devices

•

Create EDS files

•

Remove a device from the registry

•

Change the graphic image associated with a device In the Windows NT environment, a user must be logged on with administrative privileges to register EDS files.

Here’s How Remove the EDS file from a device in the workstation and show how to register it.

To manage EDS files by performing the following tasks: •

Determine a device’s EDS file number

•

Register an EDS file




Exercise: Managing DeviceNet EDS Files

7 -- 7

Exercise: Managing DeviceNet EDS Files Exercise A

In this exercise, you will practice managing EDS files.

Context: You have performed the basic tasks associated with configuring the DeviceNet network that is to run the cookie production line. However, you have been unable to configure one of the network devices, an absolute multi-tur n encoder, because there is no EDS file for it registered to your computer. Consequently, when the network is browsed, a question mark icon is displayed in RSNetW orx for DeviceNet software where the sensor should be, indicating that it is an unrecognized device. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Follow the steps below to register the appropriate EDS file for the absolute multi-turn encoder: 1. Determine the EDS file number for the absolute multi-turn

Tip "

encoder. For help converting decimals to hexadecimal code, refer to the Decimal to Hexadecimal Conversion Table appendix. 2. Remove the EDS file for the absolute multi-turn encoder from Rockwell Software’s EDS file registry.

Tip "

If your network configurat ion is open, close and restart RSNetWorx for DeviceNet. 3. Open your network configurati on. 4. Go online to the network. 5. Verify that the icon representing the absolute multi-turn encoder has been replaced by a question mark, indicating that no EDS file is registered for the encoder. 6. Close RSNetWorx for DeviceNet software 7. Register the EDS file for the absolute multi-turn encoder . 8. Open your network configurati on. 9. Go online to the network.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. EDSe100

7--8


10. Verify that RSNetWorx for DeviceNet software recognizes the absolute multi-turn encoder. 11. Save the network configuratio n. 12. Close RSNetWorx for DeviceNet software.

How Did You Do?



Rev. July 2008 EDSe100


Rev. July 2008

7 -- 9

E 2008 Rockwell Automation, Inc. All rights reserved. EDSe100

7--10


Answers

Exercise A 1. You should have determined that the EDS file for the absolute multi-turn encoder is 00010073002E0400.eds. 2. You should have selected the absolute multi-turn encoder from the registry:


Rev. July 2008 EDSe100

Lesson

8

Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network What You Will Learn

After completing this lesson, you should be able to configure the Automatic Device Recovery (ADR) feature in RSNetWorxt for DeviceNet software by performing the following tasks: •

Enable the Automatic Device Recovery feature

•

Test the Automatic Device Recovery feature

Why These Skills Are Important If the Automatic Device Recovery feature is configured on a DeviceNet network, network devices can later be replaced quickly and efficiently, preventing excessive downtime. The Automatic Device Recovery feature also ensures that a replacement device will function in the same manner as the device it is replacing.

Before You Begin

Automatic Device Recovery Automatic Device Recovery is a feature of RSNetWorx for

Has anyone had the opportunity to use the Automatic Device Recovery feature? What did you like or dislike about it? Is there anything you wish you would have known prior to using this feature for the first time?

?

Rev. July 2008

DeviceNet network softwarewith that enables a device to be replaced on a intact. DeviceNet its srcinal configuration and address The Automatic Device Recovery feature consists of the following two parts: •

Configuration Recovery (CR)

•

Auto-Address Recovery (AAR)

E 2008 Rockwell Automation, Inc. All rights reserved. ADRib100

8--2


Configuration Recovery

? Which devices on the workstation would not support Configuration Recovery? Why not? Possible Answer: The 1734--ADN Point I/O adapter module and the PanelView Plus operator interface because not all of their parameters are configurable through RSNetWorx for DeviceNet software.

Tip " Tip "

Configuration Recovery enables the srcinal configuration of a device (i.e., device paramete rs, message type, I/O sizes, etc.) that is replaced on a DeviceNet network to be retained when a replacement device is installed. The following requirements must be met for Configuration Recovery to be successfully enabled: •

The device must support electronic configuration (i.e., it can be configured using RSNetWorx for DeviceNet software).

•

The device must be assigned to a scanner module that supports

the Automatic Device Recovery feature. A device can be configured just for Configuration Recovery or for both Configuration and Auto-Address Recovery. Configuration Recovery cannot be enabled for a device that has no writable parameters. Auto-Address Recovery

Auto-Address Recovery enables the node address of a device that is replaced on a DeviceNet network to be retained when a replacement device is installed. The following requirements must be met for Auto-Address Recovery to be successfully enabled: •

The device must support automatic node commission ing (i.e., node commissioning using RSNetWorx for DeviceNet software).

•

Configuration Recovery must already be enabled for the device.

• •

The63. replacement device’s factory-configured node address must be The device must be assigned to a scanner module that supports the Automatic Device Recovery feature.

Scanner Module Function The Automatic Device Recovery feature is enabled in the scanner module to which a device is assigned. The device recovery data is stored in the scanner module so that it can be loaded into a replacement device. The feature is available for the following scanner modules:


•

The 1734-ADN scanner module, version 1.001 or later

•

The 1747-SDN scanner module, revision 4.015 or higher.

•

The 1756-DNB scanner module, revision 3.001 or higher.

• •

The 1784-CPCIDS scanne r module, version 2.001 or later The 1784-PCIDS scanner module, version 2.001 or later

•

The 1784-PCDS scanner module, version 1.001 or later

•

The 1788-CN2DN scanne r module, version 1.001 or later Rev. July 2008 ADRib100

8 -- 3


Tip " Point out that the ADR property page also serves as a quick reference to find out which devices have been enabled for Automatic Device Recovery. It also shows how much ADR space remains in a scanner module.

Most scanner modules have approximatel y 65,408 bytes of space allocated for Automatic Device Recovery data. The following graphic shows the RSNetWorx for DeviceNet software property page where Automatic Device Recovery is enabled:

The device at node 2 is the only device in this scanner module for which Automatic Device Recovery has been enabled.

Number of ADR bytes Remaining in the Scanner Module

Electronic Keying Electronic keying is a mechanism that enables a scanner module to identify whether devices in its scanlist actually match the devices on a DeviceNet network. Since electron ic keying allows a user to specify how closely a replacement device matches a replacement, it relates closely to the Automatic Device Recovery feature. ADR can recover data only if the replacement device has a compatible address and/or configuration structure. Electronic keying for the following criteria can be enabled for each device on a scanner module’s scanlist:

Rev. July 2008

•

Device type

•

Vendor

• •

Product code Major revision

•

Minor revision


8--4


For Configuration Recovery and Auto-Address Recovery to be successful, at minimum, the Device type electronic keying criteria must be selected.

Tip "

Tip " Discuss the graphic and note that the electronic keying criteria displayed are for the 871TM inductive proximity sensor. Point out that if Automatic Device Recovery were enabled for the sensor, the replacement sensor would have to match the srcinal sensor at least up to the vendor criteria.

The electronic keying criteria options are selectable only in hierarchical descending order . For example, electron ic keying for a vendor match cannot be selected for a device unless electronic keying for the device type is selected first, and so on. Both the Configuration Recovery and Auto--Address Recovery options must be selected to enable Automatic Address Recovery. The following graphic shows the RSNetWorx for DeviceNet software property page in which electronic keying criteria are selected:

Mention that if the Vendor criteria were not selected, the replacement sensor could be from a vendor other than Rockwell Automation.



Rev. July 2008 ADRib100


8 -- 5

Automatic Device Recovery Considerations It is not recommended that the Automatic Device Recovery feature be enabled in the following circumstances:

Rev. July 2008

•

When there is more than one device with the same electronic keying data assigned to a scanner module.

•

When there are multiple scanner modules on a DeviceNet network to which multiple devices with the same electronic keying data but different node addresses are assigned.


8--6


Here’s How Perform the following demonstration: 1. Enable the Automatic Device Recovery feature for the right-hand 871TM proximity sensor. 2. Configure the left-hand 871TM proximity sensor to node 63 3. Disconnect the 871TM proximity sensor from the workstation and delete the icon representing the sensor at node 63.

To configure the Automatic Device Recovery feature by performing the following tasks: •

Enable the Automatic Device Recovery feature

•

Test the Automatic Device Recovery feature


4. Perform a single-pass browse to verify the 871TM proximity sensor is no longer in the configuration. 5. Connect the left-hand 871TM proximity sensor and perform another single-pass browse. 6. Verify the 871TM proximity sensor has accepted the node address.


Rev. July 2008 ADRib100

Exercise: Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network

8 -- 7

Exercise: Configuring the Automatic Device Recovery (ADR) Feature for a DeviceNet Network Exercise A

In this exercise, you will practice configuring the Automatic Device Recovery feature.

Context: You have successfully configured all of the devices to be used to run your DeviceNet network. You now want to provide and test a safety mechanism that enables a device that is removed from the network to be replaced with its srcinal configura tion and address intact. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Follow the steps below to configure the Automatic Devic e Recovery feature. 1. Open your network configurati on. 2. Go online to the network. 3. Assign the left 871TM inductive proximity sensor node address to the network as node 63 using the Node Commissioning tool. 4. Disconnect the left 871TM inductive proximity sensor from the network. 5. Delete the icon representing the 871TM inductive proximity sensor at its old node address of 63.

Tip "

The left 871TM now represents an “out-of-the- box” device that will be added to the network later. 6. Connect the right 871TM inductive proximity sensor to the network. 7. Perform a single-pass browse of the network. 8. Enable electronic keying at least up to the device type level for the 871TM inductive proximity sensor in the scanlist of the scanner module that is acting as the network master . 9. Enable the Automatic Device Recovery feature for address recovery for the 871TM inductive proximity sensor in the scanner module that is acting as the network master.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. ADRe100

8--8


10. Test the Automatic Device Recovery feature by performing the following actions: A. Disconnect the DeviceNet cable from the right 871TM inductive proximity sensor. B. Perform a single pass browse to confirm the 871TM inductive proximity sensor is missing from the network. C. Verify that the controller is in Run mode or place the controller in Run mode. D. Connect the left 871TM inductive proximity sensor to the network. E. Perform a single pass browse. F. Confirm the left 871TM inductive proximity sensor accepts node 2 as its address. 11. Change the controller’s operati ng mode to Program.

How Did You Do?



Rev. July 2008 ADRe100


Rev. July 2008

8 -- 9

E 2008 Rockwell Automation, Inc. All rights reserved. ADRe100

8--10


Answers

Exercise A 9. The ADR tab of your master scanner’s properties window should look similar to the following:

3. Auto-Address Recovery Enabled 4. theDownload Scanner to

2. Enable Both ADR Settings

1. Load the Prox Switch’s Configuration


Rev. July 2008 ADRe100

Lesson If you are using SLC 500 hardware, use the alternative lesson, Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform.

What You Will Learn

9

Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix Platform After completing this lesson, you should be able to communicate on a DeviceNet network using explicit messaging by performing the following tasks: •

Identify class, instance, attribute, and service codes

•

Format an explicit message in a ControlLogix controller

Why These Skills Are Important

? Are any of you currently using explicit messaging in your plant? If so, what kind of function is it performing? What devices are involved?

Before You Begin If this lesson is being taught as part of a standard school (i.e., it is not part of a Tailored Training curriculum), point out that the action of monitoring device parameters in the lesson on device configuration was actually a form of explicit messaging, because specific data (i.e., the status of an output, operating mode, etc.) was being requested from and returned by the devices.

? If the scanner module LED already displays the numbers of faulted nodes, why would you want to send a faulted device an explicit message requesting fault information? Answer: To find out the exact nature of the fault.

Explicit messaging is important because it is a means to transfer very specific device data, such parameter values , that is not available via polled, strobed, change-of- state, or cyclic I/O messaging. In some cases, such as when no EDS (electronic data sheet) file is available, explicit messaging is the only way to configure a device.

Explicit Messaging Explicit messagin g is a method of transmitting commands, responses to commands, requests for data, and responses requests on DeviceNet network. Explicit messaging is usedtotodata accomplish thea following tasks: •

Obtain device data when no EDS file exists

•

Make automatic runtime adjustments to device parameter s according to changes detecte d by a controller

•

Send configuration data to a device

•

Retrieve detailed status and diagnostic information from a device

A device communicating using explicit messaging falls into one of the following categories: •

Explicit Client: The device from which an explicit message request srcinates. In an explicit message between a controller and a device, the controller is always the explicit client.

•

Explicit Server: The device from which an explicit response is being requested. In an explicit messag e between a controller and

a device, the device is always the explicit server. In an explicit message between two devices, either device can be the explicit server.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. EXPib100

9--2


Explicit Messaging vs. I/O Messaging An explicit message differs from a standard I/O message sent on a DeviceNet network in the following ways:

? Why do you think that explicit messages have a lower priority than I/O messages on a DeviceNet network? Answer: Because they are meant to transfer non-time critical data.

ExplicitMessage

Contains specific information describing nature of data being requested Requires a response Has a low priority on a DeviceNet network

I/OMessage

Contains limited device data Does not require a response Has a high priority on a DeviceNet network

The DeviceNet Object Model The object model is comprised of various entities that describe specific aspects of a DeviceNet product. Each of these entities addresses increasingly more specific variables of the product and is represented by a numeric or hexadecimal value. These values make up the body of an explicit message. The DeviceNet object model is made up of the following major entities: •

Object

•

Class

T4:10.ACC:

•

Instance

S

•

Attribute

Use the following PLC-based analogy to help students understand the concepts of class, instance, and attribute:

S S

“T4” is class “10” is instance “ACC” is attribute.

Note that an object corresponds roughly to a PLC-5 data table element. The main difference is that an object has a defined behavior as well as a defined data structure.


•

Service

Object

Object is a general term that describes some function of a DeviceNet product. An object is made up of the following entities: •

Attributes: Information about variable portions of an object (i.e., data elements that can be written to or read from).

•

Services: Functions that an object performs upon request (i.e., getting an attribute, setting an attribute, etc.).

•

Behaviors: The manner in which an object responds to events that it recognizes (e.g., receiving service requests, detecting internal faults, etc.).

•

Connections: Application connections supported by the object.

Rev. July 2008 EXPib100


9 -- 3

The following list includes example s of DeviceNet objects: •

Device/identity object

•

Connection object

•

Message router object

•

Timer events object

•

Wall clock time object

•

Parameter object

Class Note that class corresponds roughly to a file in a PLC or SLC processor. For example, the “counters” class could be said to consist of the C5 file and the behavior of the CTU, CTD, and RES instructions.

Class is the most general category in the DeviceNet object model. A class is a subset of objects that behave in a similar way but contain different data in their respective variables. By this definition, several objects containing common characteristics can fall into one class. Each object class has a unique hexadecimal identifier called a class code. The following table lists a few examples of DeviceNet object classe s for a PowerFlex 40 drive: Class

Continuing with the counter example, note that instances would be C5:1 and C5:42.

Rev. July 2008

Object

01

Identity

05

Connection

0F

ParameteTr able

Instance An instance is a specific occurrence of a given object. Since there can be several occurrences of the same object within a model, each instance is designated by a numeric value.


9--4


Attribute

An attribute is one of many possible data elements in a given DeviceNet object or class that can be written to or read from in an explicit message. Each attribute is assigned a unique numeric ID. The following table lists examples of attributes and their respective numeric IDs supported by the class 0F Parameter T able object for a PowerFlex 40 drive: Class 0F Instance Table AttributeID

AttributeName

1

Tip "

OutpuFt requency

2

CommandedFrequency

3

OutpuCt urrent

4

OutpuVt oltage

5

DCBuV s oltage

Note that each of the attributes listed in the table is actually a parameter in the drive. Not all attributes are parameters , but parameters are some of the most common attributes that explicit messaging is used to access.

Note that the actions of getting and setting attributes are commonly used services. Getting an attribute is simply the action of requesting the value of an object variable; setting an attribute is the

Service

action of sending a new value to an object variable.

object. Each service is assigned a hexadecimal code called a service code.

Cite examples of attributes that are commonly sent to (“set”) and retrieved from (“get”) DeviceNet objects:

S

Input and output values

S

Operating mode

S

Angle (limit switches)

S

Speed reference (drives)


A service refers to a function that an object performs as the result of an explicit request. Services that are supported vary from object to

The following table lists a few of the most common services supported by the PowerFlex 40 drive: ServiceName

ServiceCode

Example

Get_Attribute_Single

0E hex

Upload a single parameter value from a device

Set_Attribute_Single

10 hex

Download a single parameter value to a device



Remind students that though the following graphic shows only instance attributes, there are also attributes that apply to all objects in the same class.

9 -- 5

The following graphic shows the basic structure of the DeviceNet object model:

Class

Object A Instance 1

Attribute Attribute

Attribute

Object A Object A Instance 2

Attribute Attribute

Object B Instance 1

Attribute Attribute

Attribute Attribute

Attribute

Object B Object B Instance 2

Rev. July 2008

Attribute Attribute

Attribute Attribute


9--6


Point out that the following graphic only uses PLC-based terms to illustrate the concepts of class, instance, and attribute. The examples given are not true Class classes, instances, or attributes. (Counters)

The following graphic shows the basic structure of the DeviceNet object model using a PLC-based analogy to illustrate key concepts:

Attribute (DN) Instance 1 (C5:0)

Attribute (PRE)

Attribute (ACC)

Object Attribute (DN) Attribute (PRE)

Attribute (ACC)

Instance (C5:1) 2




Point out that the following graphic only shows two of fourteen instance attributes supported by each of the Connection objects in the PowerFlex 40 drive.

9 -- 7

The following graphic shows the basic structure of the DeviceNet object model as applied to the class 0F Parameter Table object of the PowerFlex 40 drive:

Class 0F

Attribute 1 (Output Frequency) Instance 1

Attribute 2 (Commanded Frequency) Attribute 3 (Output Current) Attribute 4 (Output Voltage)

Parameter Table Object

Rev. July 2008

Attribute 5 (Bus Voltage)


9--8


Class, Instance, Attribute, and Service Code Lookup Knowledge of specific class, instance, attribute, and service codes is necessary to format an explicit message. The class, instance, and attribute codes supported by Rockwell Automation devices can generally be found using one or both of the following resources:

Note that in all Rockwell Automation EDS files, the intervening numbers (20, 24, and 30) in the class, instance, and attribute sequence are “spacers” and are not part of the class, instance, and attribute data. Parameter Number

•

A device’s user manual (usually Appendix B)

•

A device’s EDS file

The following graphic shows the portion of the EDS file for the PowerFlex 40 drive that contains class, instance, needed to access parameter 29 (Torque Current):and attribute data Instance Code

Class Code Parameter Name Attribute Code

The service code needed to format an explicit message must be accessed using documentation manuals. Service codes are generally listed in table format in Appendix B of the device’s user manual.

Explicit Messaging Types Explicit messages can take place in one of the following ways: Do not go into detail about peer-to-peer explicit message connections now, as this will be covered later in the lesson.

•

Between a controller, scanner module, and devices

•

Directly between devices (peer-to-peer)

Explicit Messaging Using a ControlLogix Controller and a 1756-DNB Scanner Module Ladder logic is used in a ControlLogix controller to send explicit messages between devices. As with standard I/O messaging, a 1756-DNB scanner module acts as the interface between devices and the controller. Note that a 1756-DNB scanner module must be added to the Controller Organizer to perform any messaging,

The following configuration requirements must be met in order to accomplish explicit messaging on a DeviceNet network with a

simplecontroller I/O messaging between aincluding ControlLogix and DeviceNet devices.

ControlLogix controller and a 1756-DNB scanner module: 1. A 1756-DNB scanner module must be added in the Controller Organizer (this automatically creates all of the necessary logic and status tags, as well as the explicit message transfer area).




Make sure everyone understands the term “controller-scoped tag.”

9 -- 9

2. A controller-scoped tag of the Message data type must be created and the data to be sent must be entered in this tag. 3. Explicit messaging logic must be written using an MSG (message) instruction. 4. The explicit message must be configured and the communications path must be specified in the MSG instruction.

Note that explicit message instructions can be conditional or unconditional. In the following graphic, an XIO instruction

The following graphic shows an example of an MSG (message) instruction in RSLogix 5000 software:

that examines is used to makethe themessage messagecontrol word continuous.

MSG Instruction Configuration

Configuration of the MSG instruction needed to perform explicit messaging between a ControlLogix controller and DeviceNet devices consists of the following steps: 1. Formatting the Configuration tab in the MSG instruction 2. Defining the communications path in Communications tab of the MSG instruction.

The following parameters must be configured in the Configuration tab of the MSG instruction:

Rev. July 2008

•

Message type (always CIP Generic)

•

Service code (automatically selected when CIP Generic message type is selected)

•

Class code

•

Instance code

•

Attribute code

•

Source (tag that contains data to be sent to the specified instance of the object)

•

Number of elements that will be used from the source tag

•

Destination (tag that will store data that is to be requested from the specified instance of the object)

•

The path the message will take through the ControlLogix backplane


9--10


In the following graphic, point out all of the parameters that must be configured in the MSG instruction for an explicit message.

The following graphic shows the Configuration tab of an MSG instruction used to format an explicit message:

Note that the easiest and most accurate way to select the communication path for an explicit message is to use the Browse command button to find the scanner module through which the explicit message connection will be made.

The following graphic shows the Communication tab of an MSG instruction used to specify the path an explicit message will take:

After the scanner module through which the explicit message connection will be made is selected, you must add the number “2,” a comma, and then the node address of the device to which the explicit message will be sent to define the communications path.




9--11

Peer-to-Peer Explicit Messaging

? What might be one reason for establishing a peer-to-peer explicit message connection between devices on a DeviceNet network? Possible Answer: To enable faster transfer of time-critical data through the scanner module by decreasing the number of devices with which the scanner module must communicate.

Peer-to-peer explicit messaging is accomplished via a direct connection between two devices without the use of a scanner module as an intermediary. UCMM (Unconnected Message Manager) Capability

To communicate using a peer-to-peer explicit message connection, both devices must be UCMM-capable. UCMM connectivi ty is a feature that enables a device to communicate with another UCMM-capable device on a DeviceNet network without the need for a scanner module. The following list includes example s of Allen-Bradley devices that are UCMM-capable:

Tip "

•

PanelView operator interface

•

Flex I/O

•

POINT I/O

•

MicroLogix adapter

•

Scanport adapter

•

1398 ULTRA 10 servo drive

•

Bulletin 150 SMC AC dialog plus

•

193 E3 solid-state overload relay

•

1336 AC drive

• •

1557 Medium Voltage drive Powermonitor II

Not all DeviceNet-compatible devices are UCMM-capable. To find out if a device is UCMM capable, acces s its DeviceNet Statement of Compliance, which is normally located in Appendix B of the device’s user manual. Method of Configuration

The manner in which a device is configured for peer-to-peer explicit messaging differs depending upon the device. However, the following basic steps are generally followed: Ask a student to review the meanings of the terms “explicit server” and “explicit client.”

1. One device is designated the explicit server and the other device is designated the explicit client. 2. Class, instance, and attribute codes are used to specify the data

that is to be read or written. 3. The size and location of the data to be read or written is specified.

Rev. July 2008


9--12


Example: PanelView Peer-to-Peer Explicit Message Configuration

The following graphic shows the PanelBuilder software window where peer-to-peer explicit messaging is configured:

PanelView Operator Interface Function (Explicit Client)

Class, Instance, and Attribute Codes

Explicit Server Node Address Location and Size of Data

In the example above, the following elements required for the PanelView operator interface to communicate using peer-to-peer explicit messaging are specified: • • • •

The function of the PanelView operator interface (either explicit server or explicit client) The node address of the device with which the PanelView operator interface is to communicate (explicit server) The location and size of the data to be exchanged The class, instance, and attribute codes that specify the data to be exchanged. The configuration shown in the example above applies only to the PanelView operator interface. Though the main elements needed to configure a peer-to-peer explicit message are similar, the method of configuration varies from device to device.




Here’s How Perform the following demonstration: 1. Identify the class, instance, attribute, service, and command codes needed to change the operating mode of the E3 overload relay sensor.

" Use the E3 overload relay’s EDS file to identify the necessary class, instance, and attribute codes, and the documentation reference guide to identify the command and service

9--13

To communicate on a DeviceNet network using explicit messaging by performing the following tasks: •

Identify class, instance , and attribute codes

•

Format an explicit message in a ControlLogix controller


codes. 2. Format an explicit message in RSLogix 5000 software to change the operating mode of the E3 overload relay. 3. Format an explicit message in RSLogix 5000 software to change the operating mode of the 871TM inductive proximity sensor.

Rev. July 2008


9--14




9--15

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the ControlLogix Platform Exercise A

In this exercise, you will practice communic ating on a DeviceNet network using explicit messaging.

Context: You have completed all of the essential configuration tasks for the DeviceNet network and the network is operational. However, you would like to use explicit messaging to enable the count up function of the 871TM inductive proximity sensor using an input from the PanelView Plus operator interface instead of having to reconfigure this parameter in RSNetWorx for DeviceNet software every time the count up function is needed. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "


Directions: Perform the steps below and answer the following questions : 1. Open your network configurati on. 2. Identify the class, instance, and attribute codes needed to write to the 871TM inductive proximity sensor parameter and list them in the following table: Device Variable or Parameter

Class Code

Instance Code

Attribute Code

Counter (parameter 15)

Tip "

Use the 871TM inductive proximity sensor’ s EDS file to determine class, instance, and attribute codes. 3. Open exercise file EXP_N100_A1.acd. 4. Access rung 0 of the Oven_Line routine. 5. Click the

Rev. July 2008

inside the MSG (message) instruction on rung 0. E 2008 Rockwell Automation, Inc. All rights reserved. EXPe100

9--16

Exercise: Communicating on a DeviceNet Network Using Explicit Messagin g with the ControlLogix

6. Format an explicit message in the ControlLogix controller to enable the Counter configuration paramete r (parameter 15) in the 871TM inductive proximity sensor.

Tip "

The Service Code field is automatically select ed when the message type (CIP Generic) is selected.

Tip "

The Source Element tag should already be selected as expl_data_1. 7. Access the Communication tab of the Message Configuration window for the MSG instruction in rung 0 of the Oven_Line

routine. 8. What does the second “2” stand for in the Path text box?

9. Access rung 1 of the Oven Line routine. 10. Click the

inside the MSG instruction on rung 1.

11. Format an explicit message in the ControlLogix controller to disable the Counter configuration paramete r in the 871TM inductive proximity sensor.

Tip "

The Source Element tag should already be selected as expl_data_2. 12. Access the Controller Tags window. 13. Edit the value of the expl_data_1 tag to enable the 871TM inductive proximity sensor’s Count Up Enabled parameter. 14. Edit the value of the expl_dat_2 tag to disable the 871TM inductive proximity sensor’s Count Up Enabled parameter. 15. Download the program to the controller. 16. Change the controller’s operatin g mode to Run. 17. Test the explicit message by performing the following actions: A. Select Run Application on the PanelView Plus terminal. B. Once the application has started, press Prox on the PanelView Plus screen to navigate to the 871TM inductive proximity sensor screen . C. Touch the Enable Counter pushbutton and hold for a moment on the PanelView Plus screen. D. Touch a metal object (such as a a coin or key) to the sensing end of the 871TM inductive proximity sensor. The PanelView Plus counter should increment by one every time a metal object is sensed.


Rev. July 2008 EXPe100


9--17

E. Touch the Disable Counter pushbutton and hold for a moment on the PanelView Plus screen. F. Touch a metal object (such as a coin or key) to the sensing end of the 871TM inductive proximity sensor. The PanelView Plus counter should no longer increment every time a metal object is sensed. 18. Save the RSLogix 5000 program. 19. Close RSLogix 5000 software. 20. Close RSNetWorx for DeviceNet software.

How Did You Do?

Rev. July 2008


E 2008 Rockwell Automation, Inc. All rights reserved. EXPe100

9--18


Answers

Exercise A 2. If you correctly identified the class, instance, and attribute codes needed to write to the 871TM inductive proximity sensor parameters, your table will look like the following: Device Variable or Parameter


Instance Code

Class Code

ee

01

Attribute Code

01

6. If you correctly formatted an explicit message to enable the Count Up Enabled parameter in the 871TM inductive proximity sensor, the Configuration tab of the Message Configuration window for the MSG instruction in rung 0 of the Oven_Line routine should look like the following graphic:

8. The second “2” in the Path text box of the Communication tab of the MSG instruction in rung 0 of the Oven_Line routine

stands for the node address of the target device (the 871TM inductive proximity sensor).




9--19

11. If you correctly formatted an explicit message to disable the Count Up Enabled parameter in the 871TM inductive proximity sensor, the Configuration tab of the Message Configuration window for the MSG instruction in rung 1 of the Oven_Line routine should look like the following graphic:

13. If you correctly edited the value of the expl_data_1 tag to enable the Count Up Enabled parameter in the 871TM inductive proximity sensor, the tag value should equal “1” and look like the following graphic:

14. If you correctly edited the value of the expl_data_2 tag to disable the Count Up Enabled parameter in the 871TM inductive proximity sensor, the tag value should equal “0” and look like the following graphic:

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. EXPe100

9--20




Lesson

10

Integrated Practice -- Modifying a DeviceNet Network Configuration What You Will Learn

After completing this lesson, you should be able to modify a DeviceNet network configuration by performing the following tasks: •

Assign a node address through the hardware view

•

Edit device parameters

•

Edit a scanlist

•


•

Go online to a DeviceNet network

•

Map device input data manually

•

Identify DeviceN et addresses in a ControlLogix controller

•

Upload a device or network configuration

Why These Skills Are Important Modifying a DeviceNet network configuration provides an opportunity to perform all actions associate d with network configuration at once. It is important to understand configuration as an entire process instead of separate skills since configuration on the job will require performance of the entire process to create a working network.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. INTib100

10 -- 2

Integrated Practice -- Modifying a DeviceNet Network Configuration


Rev. July 2008 INTib100

Exercise: Integrated Practice -- Modifying a DeviceNet Network Configuration

10 -- 3

Exercise: Integrated Practice -Modifying a DeviceNet Network Configuration Exercise A

In this exercise, you will practice modifying a DeviceNet network configuration. This exercise can be completed using either the 1756-DNB or 1747-SDN scanner module.

Context: You have completely designed and configured a DeviceNet network. However, management has decided to add another 871TM inductive proximity sensor to the oven line portion of the network to help track and pace produce as it enters the conveyor line. You want to modify the DeviceNet network configuratio n to accommodate the device before it arrives at the plant so that it can be immediately brought online. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 5000 or RSLogix 500 software, consult the Start Pages or the online Help.

Directions: Follow the steps below to modify the DeviceNet network configuration: 1. Open your network configurati on. 2. Create an offline network configuration by performing the following: add an additional 871TM inductive proximity sensor to your offline network configuration . 3. Assign a node address through the Hardware View by performing the following: Assign the 871TM proximity sensor a node address of 35 to give it a lower priority on the network. 4. Edit device parameters for the new 871TM inductive proximity sensor as follows: For this parameter . . .

7 (On-Delay Timer Enabled)

Rev. July 2008

Enter or select this option or value . . .

On-Delay

9 (On-Delay Preset)

5

20 (No Motion Detect Timer)

5 ms

21 (Learn/Teach Mode)

Learn Target

26(Autobaud)

Enabled E 2008 Rockwell Automation, Inc. All rights reserved. INTe100

10 -- 4


5. Verify that the Automap on Add check box in the Scanlist property page of the Scanner Module Configuration window for the scanner module acting as the master for your network has not been selected, or clear the Automap on Add check box. 6. Edit the scanlist of the scanner module that is acting as the network master by adding the new 871TM inductive proximity sensor. 7. Verify device message type and I/O sizes for the new 871TM inductive proximity sensor as follows: MessageType

Strobed

InputSize

2

OutputSize

N/A

8. Choose the appropriate option: If you are using this scanner module as the network master . . .

Then . . .

1756-- DNB

GotoStep9.

1747-SDN

GotoStep10.

9. Manually map device input data for the 871TM inductive proximity sensor in the 1756-DNB scanner module as follows: • •

Assembly Data Word: 10 Bit: 0

•

Number of bits: 16

•

10. Manually map device input data for the 871TM inductive proximity sensor in the 1747-SDN scanner module as follows: •

•

Segment 1: -- Discrete -- Word: 15 -- Bit: 8 -- Number of bits: 8 Segment 2: -- Discrete -- Word: 16 -- Bit: 8 -- Number of bits: 8

11. Identify the address in the ControlLogix controller or SLC 500 processor where the sensor’s Motion Output bit will show up:

12. Save the network configuratio n. E 2008 Rockwell Automation, Inc. All rights reserved.

Rev. July 2008 INTe100


10 -- 5

13. Close RSNetWorx for DeviceNet software.

How Did You Do?

Rev. July 2008


E 2008 Rockwell Automation, Inc. All rights reserved. INTe100

10 -- 6


Answers

Exercise A 11. In the ControlLogix controlle r, the 871TM inductive proximity sensor’s Motion Output bit will show up at input word 10, bit 7. The sensor’s Motion Output bit is bit 7 of the first input byte the sensor sends. In the 1756-DNB scanner module, the input data map starts at word 10, bit 0. Therefore, the sensor’s Motion Output bit will show up at input word 10, bit 7.

In the SLC 500 processor, the 871TM inductive proximity sensor’s Motion Output bit will show up at input word 15, bit 14. The sensor’s Motion Output bit is bit 6 of the first input byte the sensor sends. In the 1747-SDN scanner module, the first input byte is mapped to input word 15, bits 8-15. Therefore, the Motion Output bit will show up at input word 15, bit 14.


Rev. July 2008 INTe100

Lesson

11

Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software What You Will Learn

After completing this lesson, you should be able to troubleshoot a DeviceNet network using RSNetWorx for DeviceNet software by performing the following tasks: •

Interpret software error icons and messages

•

Resolve a device mismatch

•

Monitor device parameters

•

Diagnose a network using the DeviceNet MD tool

Why These Skills Are Important The ability to troubleshoot a DeviceNet network using RSNetWorx for DeviceNet softwar e is important for the following reasons : •

RSNetWorx for DeviceNet software is the main “window” to a physical DeviceNet network and can provide a lot of information regarding the health of the network in one concentrated area.

•

Many DeviceNet devices are “smart” devices with significant internal diagnos tic parameters that can only be accessed using RSNetWorx for DeviceNet software.

Before You Begin Note that the two error icons discussed in this section are a “starting point” for troubleshooting. Explain that they should be used in conjunction with other software and hardware indicators to gain a clearer picture of a network’s status.

Error Icons The following two error icons are displayed in RSNetWorx for DeviceNet software for maintenance and troubleshooting purposes: •

Device mismatch icon

•

Missing device icon These error icons are only displayed in an online network configuration.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. SFTib100

11--2


The error icons are displayed just above the graphic represe ntation of a device in a network configuration:

Device Mismatch Icon

Missing Device Icon

Device Mismatch Icon Point out that a device mismatch icon is only displayed when a device is recognized by the software but does not match its counterpart on the network exactly (i.e., a device mismatch icon would never appear for a device that is completely unrecognizable).

?

you think device mismatches are Why oftendo encountered by maintenance technicians?

A device mismatch icon is displayed when the identity information for a device that is in the software network configuration does not match the identity information for the physical device that it represents. Identity information can include any of the following items: •

Device vendor

•

Device type

•

Device name

• •

Device catalog number Device revision level

Answer: Maintenance Tip " technicians often replace network devices. If a replacement device has slightly different identity information than its predecessor, it will cause a device mismatch to appear in the software network configuration.

The most common reason why a mismatch icon is displayed above a device is a discrepancy between the revision number of the device in the software network configuration and the device on the network.

Tell students to record any custom configured parameters for a device before deleting it from the software network configuration so that they can be downloaded to the new or replacement device.

•

Resolving the mismatch using the appropriate menu option in RSNetWorx for DeviceNet software

•

Deleting the device from the software configura tion and uploading the parameters from the device on the physical network to the software network configuration


A device mismatch can be cleared by performing any of the following actions:

Rev. July 2008 SFTib100


11--3

Missing Device Icon

A missing device icon is displayed when a device in a software network configura tion is not detected on the physical network when an online connection is established. The following examples are just a few of the many different causes of this error: •

A compromised physica l connection between the device and the network

•

Absence of the physical device on the network

•

Node address discre pancy between the physical device and its

•

software representation Misconfiguration

Point out that the use of numeric and alphanumeric codes to troubleshoot a network will be covered in a later lesson.

Often the cause of a missing device icon can be determined by referring to scanner module numeric or alphanumeric codes.

Error, Warning, and Status Messages Note that, like all RSNetWorx for DeviceNet software tools, error warnings and messages should be used in conjunction with other troubleshooting tools, such as hardware status indicators and scanner module numeric and alphanumeric codes.

RSNetWorx for DeviceNet software provides numerous error, warning, and status messages for various conditions as they are detected on the network. The messages can provide any of the following types of information: •

A recap of minor network status changes (e.g., network mode being changed to online, DeviceN et MD diagnostic test

•

performed, etc.) Warnings of configuration and/or communications problems

•

Diagnostic findings from the DeviceNet MD tool

RSNetWorx for DeviceNet software error and warning messages are displayed in the message view:

Rev. July 2008

Tip "

Double-clicking a message in the message view will display more detailed informati on about the message.

Tip "

The message view can be hidden or exposed using the options under the View → Messages menu in RSNetWorx for DeviceNet software. E 2008 Rockwell Automation, Inc. All rights reserved. SFTib100

11--4


Device Parameters Significant diagnostic information can be obtained for many devices by monitoring their parameters using RSNetWorx for DeviceNet software. Parameters are accessed and monitored through a device’s Parameters property page. Device parameters can only be monitored when a network is online.

Tip " Point out the various diagnostic parameters, such as input and output status, that can be monitored in the E3 overload relay.

The option of monitoring a single parameter or all parameters associated with a device is available. The following graphic shows the Parameters property page for a E3 solid-state overload relay: Drop-Down List Where Monitoring Options Are Selected Icon Used to Start and Stop Parameter Monitoring

Available Parameters

Since the parameters supported by a device vary with each device, the types of diagnostic param eters supported by a device also vary. The following examples show some diagnostic paramete rs that can be monitored for various devices:


•

State of inputs and outputs (packaged and modular I/O)

•

Sensing status (sensors)

•

Voltage, frequency, temperature, etc. (drives) Rev. July 2008 SFTib100


11--5

Example: Monitoring I/O Status for an ArmorBlock MaXum I/O Module

The following graphic shows the Parameters property page for an ArmorBlock input module, where the following diagnostic parameters can be monitored: Explain that the Input Values parameter can be used to verify that input devices are operational and wired to the appropriate c onnector.

•

Point out that the Connector Diagnostic parameters must be activated for the Connector Fault Status parameters to reflect wire status.

•

Input Values: This parameter shows the status of the four input points supported by this module as a binary bit pattern. When an input is on, the bit representing that input goes to a “1” in the Input Values parameter. Connector Fault Status: This parameter indicates wiring faults for the ArmorBlock input points. For each input point supported by the module, there is a Connector Fault Status parameter in the Parameters property page.

Input Values Parameter Connector FaultStatus Parameters

Tip "

Rev. July 2008

On an ArmorBlock MaXum module that also supports output points, additional parameters such as “no load” detection can be monitored.


11--6


The DeviceNet MD Tool The DeviceNet MD tool is an optional feature of RSNetW orx for DeviceNet software that allows a user to obtain very specific diagnostic information from network devices: Point out that the DeviceNet MD tool can provide diagnostic information to be used in preventative maintenance (such as a warning that a sensor’s operating margin is dangerously low) before an actual “error” is displayed for a device in other areas of the software or on the device’s hardware status indicators.

In the following screen capture, point out the numbers associated with the diagnostic readings and explain that the number “248” indicates the total number of healthy “instances” on the network, not the total number of healthy devices. Explain that the same rule applies to the total number of warnings, errors, and “no reads.”


•

It provides diagnostic information that cannot always be discerned by visual inspectio n of hardware status indicators or scanner numeric and alphanumeric codes.

•

It organizes diagnostic inform ation according to its level of urgency (e.g., “normal,” “warning,” or “error”).

•

It enables a user to obtain basic status information for an entire network at-a-glance through the use of unique and colorful icons.

•

It provides suggestions for troubleshooting many of the problems that are diagnosed.

•

It enables a user to select the speed at which a network will be diagnosed, as well as the type of icons that will be used to show diagnostic information. A separate activation must be purchased to enable use of the DeviceNet MD tool.

DeviceNet MD diagnostics cannot be performed while a network is being browsed using the single-pass or continuous browsing options.


11--7


The following graphic shows an active Diagnostic view in RSNetWorx for DeviceNet software: Command Buttons to Start/Stop Diagnostics

Warning Indication for the Network

Legend

Warning Indication for a Single Device

Here’s How

To troubleshoot a DeviceNet network using RSNetWorx for DeviceNet software by performing the following tasks:

Perform the following demonstration: 1. Create software error icons (missing device and device mismatch) on your workstation, then interpret and resolve them.

•

•

Resolve a device mismatch Monitor device parameters

2. Point out and discuss the messages that appear in the message view.

•

Diagnose a network using the DeviceNet MD tool

3. Monitor a few parameters in one of the workstation devices.

As your instructor demonstrates these procedures, follow along in the Scanner Module Master Data Maps appendix and the associated job aid(s).

4. Use the DeviceNet MD tool to diagnose the network and point out any errors or Tip warnings that are indicated.

Rev. July 2008

"

•


If there are device mismatch icons in the software network configuration, the Scanner Module Master Data Maps appendix can be used to determine the actual revision level of a device.


11--8




Exercise: Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software

11--9

Exercise: Troubleshooting a DeviceNet Network Using RSNetWorx for DeviceNet Software Exercise A

In this exercise, you will practice troublesho oting a DeviceNet network using RSNetWorx for DeviceNet software by performing the following tasks: •


•

Resolve a device mismatch

•

Monitor device parameters

Context: You recently made some changes to the network by replacing and adding devices. While online to the network, you notice a few error icons and messages in RSNetWorx for DeviceNet software and suspect they may be related to the recent changes you made. Y ou begin troubleshooting the network using RSNetWorx for DeviceNet software. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: 1. Open the SFT_N100_A1.dnt network configuration file.

Tip "

If you are using the SLC 500 platform, open the SFT_N100_A3.dnt network configuration file. 2. Go online to the network. 3. Interpret the error icons that are displayed for several of the network devices.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. SFTe100

11--10


4. Write the name of each device showing an error icon, the type of error icon that is displayed, and the reason for the error icon in the following table: Device

ErrorIcon

Reason

5. Perform the corrective actions necessar y to clear the error icons. 6. If there are any error messages displaye d in the message view, write the message(s) displayed below:

7. Access the Parameters property page for the E3 overload relay.

When prompted, upload device parameters.

8. Monitor device paramete r 11 (Current Imbalance) of the E3 overload relay. 9. Adjust the Phase Imbalance dial on the workstation and watch the value of parameter 11 increase and decrease as you adjust the current imbalance. 10. Monitor device parameter 6 (Position Value) of the absolute multi-turn encoder. 11. Adjust the position of the flywheel attached to the absolute multi-turn encoder and confirm the value of parameter 6 changes.

Tip "

If you tripped a fault condition on the E3 overload relay, adjust the Phase Imbalance dial until the value of parameter 11 is 0. Then press the blue Reset button on the front of the E3 overload relay. 12. Stop monitoring parameter 11. 13. Close the properties window for the 871TM inductive proximity sensor. 14. Access the device configuration tab of the property page for the ArmorBlock MaXum Input module.


Rev. July 2008 SFTe100


11--11

When prompted, upload device parameter s.

15. Verify that the Offwire Diagnostic Inactive option is selected for parameters 9 and 10 (Connector A Diagnostic and Connector B Diagnostic, respectively) or select it. 16. Verify that the Offwire Diagnostic Active option is selected for parameters 11 and 12 (Connector C Diagnostic and Connector D Diagnostic, respectively) or select it.

Tip "

Since there are no inputs that are supposed to be connected to connectors 0 and 1 (A and B) on the ArmorBlock MaXum input module, it’s a good idea to disable the offwire diagnostic for these connections to prevent unnecessa ry error LEDs. 17. Download the device configurat ion to the ArmorBlock MaXum input module. 18. Disconnect the DeviceNet cable from input connector 2 (on the bottom left) of the ArmorBlock MaXum input module. 19. Monitor device parameter 7 (Connector C Fault Status) of the ArmorBlock MaXum input module. 20. What is the status of input 2 (Connector C) as reflected by parameter 7? What conclusions may be drawn based on this indication?

21. Stop monitoring. 22. Close the properties window for the ArmorBlock MaXum input module.

Leave the connector on input 2 of the ArmorBlock MaXum input module disconnected. 23. Save the network configurati on.

How Did You Do?

Rev. July 2008



11--12


Exercise B

In this exercise, you will practice diagnosing a network using the DeviceNet MD tool.

Context: You want to be able to detect device-s pecific problem s, as well as potential device problems before they begin to impact network operation. Your company has purchased a DeviceNet MD activation to help you do just that. Since you are already online to the network with RSNetWorx for DeviceNet software, you decide to diagnose the network using the DeviceNet MD tool as a preventative maintenance measure. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 500/5000softw are, consult the Start Pages or the online Help.

Directions: 1. If you have not already done so, Go online to the network. 2. Edit device parameter 24 (Trip Enable) of the E3 overload relay, enabling Comm Idle as shown in the following graphic:

3. Download the device configura tion to the E3 overload relay. 4. Cycle the controller’s operatin g mode (This will cause the

DeviceNet mode to be Idle momentarily.) 5. Diagnose the network using the DeviceNet MD tool.




11-- 13

6. Write the names of the device for which problems have been diagnosed and the diagnosis for each device in the space below:

7. Perform the necessary corrective action to restore the network to proper operation. 8. Diagnose using the DeviceNet tool again to verify thatthe anynetwork warnings or errors have beenMD cleared. 9. Edit device parameter 24 (Trip Enable) of the E3 overload relay and disable Comm Idle. 10. Download the device configurat ion to the E3 overload relay. 11. Save the network configurati on. 12. Close RSNetWorx for DeviceNet software.

How Did You Do?

Rev. July 2008



11--14


Answers

Exercise A 4. If you interpreted the error icons correctly , the table you completed should resemble the following: Device

ErrorIcon

Bulletin 160 drive

Missing device

RightSight glass fiber optic sensor

Device mismatch

Reason

There is no Bulletin 160 drive on the physical network. The RightSight Glass Fiber Optic in the software configuration is not the device that actual exists at node 40, the PanelView Plus terminal.

5. To clear the error icons successfully, you should have performed the following actions: A. Deleted the icon for the Bulletin 160 drive, since it is not actually present on the physical network . B. Resolved the device mismatch for the PanelView Plus operator interface (the software network representation for this device was a RightSight glass fiber optic sensor which did not exist on the physical network). 6. Depending upon the workstation you are using, there may or may not be messages displayed in the message view. 20. Input 2 (Connector C) is Offwire. Based on this indication, it can be concluded that the connection for input 2 on the ArmorBlock MaXum input module is bad. Possible causes for

this condition include a broken or loose connection or an open circuit.

Exercise B 6. The devices for which problems have been diagnosed are the ArmorBlock MaXum input module and the E3 overload relay. The diagnoses are as follows: A. The ArmorBlock MaXum input module has a recoverable fault (due to a loose input connection). B. To reset the fault on the E3, simply press the blue Trip Reset button on the front of the E3. It was faulted because the Comm Idle was set as a trip condition in Parameter 24, and the Master was in idle mode when you put the controller in Program mode. Be sure to reset this parameter so that the Comm Idle is NOT a trip condition and download to the E3.



Lesson If you are using SLC 500 hardware, use the alternative lesson, Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators.

What You Will Learn

12

Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators After completing this lesson, you should be able to troubleshoot a DeviceNet network using hardware indicators by performing the following tasks: •

Interpret scanner module status indicators

•

Interpret device network status indicators

•

Interpret scanner module numeric or alphanumeric codes

•

Clear scanner module numeric or alphanumeric codes

Why These Skills Are Important The ability to troubleshoot a network using hardware status indicators is important for the following reason s: •

Hardware status indicators are the most commonly used resources to determine the exact nature of a network fault, so being able to interpret them is essential to restoring a malfunctioning network to proper working order.

•

Since they are on the plant floor, hardware indicators are among the most accessible troubleshooting resources for maintenance technicians.

•

Before You Begin

Hardware indicators can often provide more specific information about the status of a network and the nature of network faults than software tools.

Status Indicators (LEDs)

Review the role of a scanner module as the interface between a processor or controller and devices on a DeviceNet network.

Tip "

Status indicator s are light displays on scanner modules and devices that provide information about the status of the scanner module or device. Status indicator s are most often used in combination with scanner module numeric and alphanumeric codes to determine the exact nature of a fault or condition. Status indicator s are typically bi-color (red or green) and either solid or flashing. Different combinations of these variables provide specific information about scanner module or device status.

Tip "

Rev. July 2008

Tables with interpretations of scanner module and slave device status indicators are provided in the Troubleshoo ting Guide.

E 2008 Rockwell Automation, Inc. All rights reserved. HRDib100

12 -- 2


1756-DNB Scanner Module Status Indicators Hold up the troubleshooting guide and show students where interpretations of a 1756-DNB scanner module’s status indicators can be found.

A 1756-DNB scanner module, used with ControlLogix controllers, has the following status indicators: •

Combined Module/Network Status Indicator: Provides information on the status of both the scanner module itself and the entire network that it is a part of. Specifically, this status indicator can provide the following types of information:

-- Power supply status -- Scanlist status -- Recoverable/unrecoverable fault status •

Note that information about the status indicators found on other scanner modules, such as the 1771-SDN scanner module, the 1784-PCIDS scanner card, and the 1788-CN2DN linking device, can be found in the Troubleshooting Guide.

I/O Status Indicator: Provides information regarding the state of inputs and outputs on the network. Specific ally, this indicator can provide information on whether or not network inputs and outputs are active or faulted and whether or not they are under program control.

An I/O status indicator reflects the state of inputs and outputs, not necessarily the on/off status of the input or output points themselves. •

Health (OK) Status Indicator: Indicates whether the scanner module has power and is operating properly .

The following graphic shows the status indicator s on a 1756-DNB scanner module:

Combined Module/Network Status Indicator

Health (OK) Status Indicator

I/O Status Indicator

1756-DNB Scanner Module


Rev. July 2008 HRDib100


12 -- 3

Device Network Status Indicators Explain that devices can also have other types of status indicators and point out the status indicators for each individual input point on the ArmorBlock MaXum input module in the following graphic. Also note the “Logic Status” indicator and briefly explain its advanced troubleshooting purpose in conjunction with DeviceLogix functionality.

Most DeviceNet- compatible devices have a network status indicator that provides information about that device’s status on the network. A device’s network status indicator can provide the following information about the device:

Briefly explain the Faulted Address Recovery feature of RSNetWorx for DeviceNet software and note that a device’s network status indicator can be used to identify a device that has a duplicate node address (the network status indicator will flash red and green alternately).

•

Power supply status

•

Connection status (i.e., whether or not it is either in the scanlist of a master scanner module or has a peer-to-peer connection with another device)

•

Communication status (i.e., whether or not it is able to communicate on the network)

The following graphic shows the various status indicators , including the network status indicator, available for an ArmorBlock MaXum input module:

Individual Input Point Status Indicators

Individual Input Point Status Indicators Network Status Indicator

Logic Status Indicator (For Modules that Support DeviceLogix Functionality) ArmorBlock MaXum Input Module

Tip "

Devices may have other status indicators not necessarily related to the DeviceNet networ k that can also be used for troubleshooting purposes.

Tip "

The location and physical appearance of a device’s network status indicator varies with each device. Consult a device’s user documentation for details.

Status Indicator Interpretation Explanations of the various states that scanner module and device status indicators may take can be found in the following places: •

The Troubleshooting Guide

•

A device’s user documentation For theindicator most accurate picture of network status, in status s should be read and interpreted conjunction with scanner module numeric and alphanumeric codes.

Rev. July 2008


12 -- 4


Scanner Module Numeric and Alphanumeric Codes Numeric and alphanumeric codes are typically used in conjunction with scanner module and device status indicators and provide more specific information about the status of a network. Depending upon the scanner module, these codes are displayed in a different location and manner. Tell students that detailed information on how to access codes for scanner modules that do notcan display theminonthe the front of the module be found troubleshooting guide.

The following table summarizes the location and type of numeric or alphanumeric codes available for five of the main scanner modules manufactured by Rockwell Automation: For this scanner module . . .

This type of code is available . . .

And is located . . .

1771-SDN

Numeric only

On the front of the scanner module

1747-SDN

Numeric only


1756-DNB

Numeric and alphanumeric

1784-PCIDS

Numeric only

• On the front of

the scanner module StatusDisplay status structure element of RSLogix 5000 software

• In the

In I/O Linx for DeviceNet software • In the

1788-CN2DN

If you are teaching this lesson as part of a standard school, do not go into detail now about how RSLogix 5000 software can be used to access numeric codes for the 1756-DNB scanner module. This information will be covered in a later lesson.

Numeric only

ScannerStatus and ScrollingDevice status structure elements of RSLogix 5000 software (for the Logix5000 family of controllers) • In the first word of the input data table in RSLogix 5 software (for PLC-5 processors)

The following graphic shows where numeric and/or alphanumeric codes are displayed on the 1756-DNB scanner modules: DeviceNet

Numeric or Alphanumeric Display MOD/NET I/O OK

Top Part of a 1756-DNB Scanner Module

Tip "


Explanations of the numeric and alphanumeric codes that can be displayed on Rockwell Automation DeviceNet scanner modules and the recommended course of action to clear them can be found in the Troubleshooting Guide. Rev. July 2008 HRDib100


Here’s How Create a fault on your workstation using the 1756-DNB scanner module as the network master, then clear it using information from the hardware status indicators, device network status indicators, and scanner module numeric and alphanumeric codes. Before clearing the error, be sure to point out the status of all of the following indicators: 1. Scanner module status indicators

12 -- 5

To troubleshoot a DeviceNet network using hardware indicators by performing the following tasks: •


•

Interpret device network status indicators

•

Interpret scanner module numeric or alphanumeric codes

•



2. Scanner module numeric or alphanumeric codes 3. Device network status indicator

Rev. July 2008


12 -- 6



Rev. July 2008 HRDib100

Exercise: Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators

12 -- 7

Exercise: Troubleshooting Using DeviceNet and ControlLogix Hardware Indicators Exercise A

In this exercise, you will practice troublesho oting a DeviceNet network using hardware indicators.

Context: You are performing routine maintenance by checking device connections when you notice that the network status indicators on a few devices are not solid green and that several numeric/alphanumeric codes are flashing on the front of the scanner module that is acting as the master on the network. Recognizing these as indications of problems on the network, you begin troubleshooting by interpreting the various status indicators and numeric/alphanumeric codes being displayed. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: 1. Open the HRD_N100_A1.dnt network configuration file. 2. Go online to the network using either the 1770-KFD or the Ethernet driver. Do not upload the network configurati on.

3. If the controller is not currently in Program mode, change the controller’s operating mode to Program. 4. Download the network configuration. 5. Disconnect the 871TM proximity sensor from the network.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. HRDe100

12 -- 8


6. Interpret the status indicators on the scanner module that is acting as the master scanner module on your network and complete the following table: Scanner Module

Status Indicator

State

Meaning

MOD/NET

1756-DNB scanner module

IO

OK

Do not attempt to perform any corrective action to change the state of any status indicators at this time. 7. Interpret the network status indicator s on the workstation devices listed below and complete the following table: Network Status Indicator

State

Meaning

871TM photoelectric sensor ArmorBlock I/O module

Tip "

Look at the network status indicator of the ArmorBlock MaXum Input module for at least ten seconds before determining its state. 8. Interpret the numeric or alphanumeric codes displayed on the front of the scanner module acting as the master scanner module on your workstation.

Tip "


Tables with interpretations of scanner module numeric and alphanumeric codes are provided in the Troubleshootin g Guide.

Rev. July 2008 HRDe100


12 -- 9

9. List the numeric or alphanumeric codes that are displayed on the front of the scanner module and the probable cause of each:

10. Perform the necessary corrective actions module numeric or alphanumeric codes. to clear the scanner

Tip "

The Scanner Module Master Data Maps appendix, which contains information about the I/O sizes that the workstation devices should be configured to send and receive, may help you clear one of the error codes. 11. Save the network configurati on. 12. Close RSNetWorx for DeviceNet software.

How Did You Do?

Rev. July 2008



12 -- 10


Answers

Exercise A 6. If you have correctly interpreted the status indicators on the scanner module that is acting as the master scanner module on your workstation, the table you completed should resemble the following table: Scanner Module

Status Indicator

MOD/NET 1756-DNB scanner module

State

Flashing red

Meaning

The scanner module has a minor recoverable fault or a connection

IO

Flashing green

timeout. The scanner module is in Idle mode, outputs are not under control, and inputs are being consumed.

OK

Solid green

The scanner module is operating normally.

7. If you have correctly interpreted the status indicators on the workstation devices, the table you completed should resemble the following table: Network Status Indicator

State

Meaning

871TM photoelectric sensor

Off

There is no power being applied to the device.

ArmorBlock I/O module

Flashing green or flashing red

The device needs commissioning. Read the scanner module numeric or alphanumeric code.

9. The following numeric and alphanumeric codes should be displayed on the front of the scanner module: A. A# 00 and IDLE (the cause is that the controller is in Program mode) B. N# 02 and E# 78 alternately (probable cause is that the connection betwee n the 871TM inductive proximity sensor and the network is loose) C. N#30 and E# 77 alternately (probable cause is that the I/O sizes configured for the ArmorBlock I/O module in the scanner do not match those that were srcinally configured for the device). This error can be cleared by editing the input size of the ArmorBlock I/O module in the scanlist of the

1756-DNB scanner module to send 2 input bytes instead of 1.




12--11

Troubleshooting Tips If you are unable to successfully clear scanner module numeric or alphanumeric codes, verify that you have completed the following actions:

-

Securely reconnected the 871TM inductive proximity sensor to the network Changed the input size configured for the ArmorBlock I/O module in the master scanner module’ s scanlist to send 2 input bytes instead of 1.

-

Rev. July 2008

Downloaded corrective changes made in the scanner module configuration to the scanner module If problems persist, cycle power to the workstation after performing the corrective action


12 -- 12




Lesson If you are using SLC 500 hardware, use the alternative lesson, Troubleshooting a DeviceNet Network Using RSLogix 500 Software.

What You Will Learn

13

Troubleshooting a DeviceNet Network Using RSLogix 5000 Software After completing this lesson, you should be able to troubleshoot a DeviceNet network using RSLogix 5000 software by performing the following tasks: •

Trace I/O points through a 1756-DNB scanner module

•

Monitor data in a 1756-DNB scanner module’s status register

•

Monitor a 1756-DNB scanner module’s module-defined status tag values

Why These Skills Are Important Being able to troubleshoot a DeviceNet network using RSLogix 5000 software is important for the following reasons:

Before You Begin Stress the importance of making sure that RSNetWorx for DeviceNet input and output mapping is aligned with device addresses in the ladder logic program.

•

Recognizing the relationship between an RSNetWorx for DeviceNet software data map and RSLogix 5000 I/O addresses can help identify communica tions problems stemming from address misalignment.

•

A significant amount of data regarding the status of a scanner module and a network in general can be obtained through RSLogix 5000 software.

Relationship Between an RSNetWorx for DeviceNet Software Data Map and I/O Points in RSLogix 5000 Software For communicatio ns between a controller and devices to occur, input and output data mapped for devices in the scanlist of a scanner module must correlate directly with the input and output addresses for these devices in the corresponding ladder logic program. Since misalignme nt of this data can cause communica tions problems, the ability to trace I/O points is essential to maintaining and troubleshooting a DeviceNet network.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. RSLib100

13 -- 2


To trace I/O points through a 1756-DNB scanne r module, the following informatio n is used: •

The RSNetWorx for DeviceNet software data map

•

The data structure of the device for which I/O points are to be traced

•

RSLogix 5000 software tags database (1756-DNB scanner modules only)

RSNetWorx for DeviceNet Software Data Map

The location where a device’s data is mapped in a 1756-DNB scanner module can also be determined by accessing the input and output data maps in the Scanner Module window of RSNetWorx for DeviceNet software. The following graphic shows the RSNetWorx for DeviceNet window where the location of input data for an ArmorBlock MaXum input module in the scanlist of a 1756-DNB scanner module can be determined:

The ArmorBlock MaXum module’s input data is mapped to the first half of the second double-word (DINT).

A total of 16 bits have been mapped.


Rev. July 2008 RSLib100


13 -- 3

Device Data Structure

Knowledge of a device’s data structure is needed to trace I/O points because the data map in RSNetWorx for DeviceNet software alone does not provide a user with information about the specific function of each individual bit that has been mapped for a device (e.g., it does not provide information as to which bit in an operator interface represents the start button). Advise students that data structure information for devices that have large amounts of I/O data or different I/O assemblies to choose from is not usually located in RSNetWorx for DeviceNet software and must be accessed using device documentation (e.g., information about the data structure of a Bulletin 160 drive or E3 solid-state overload relay).

Tip " Stress that a device’s data structure can vary based on the kind of messaging the device has been configured for. Make sure students know they must look up a device’s data structure based on the device’s message type.

Rev. July 2008

The following resources provide informati on about the data structure of a device, including the function of individual bits in the device: • •

The I/O Data property page for the device The EDS (electronic data sheet) file for the device

•

The online Help system in RSNetWorx for DeviceNet software (Allen-Bradley devices only)

•

The device’s user manual

•

Data sheets that ship with the device

The location of data structure informat ion varies with each device. Device data structure can vary depending upon the type of messaging the device has been configured for (e.g., polled, strobed, change-of-sta te, etc.)


13 -- 4


The following graphic shows the I/O Data property page for the RightSight polarized retroref lective sensor and the data structure information that can be accessed from the I/O Data property page:

I/O Data Property Page

Help for the Selected Parameter Button Used to Access a Device’s Data Structure Information from the I/O Data Property Page

Device Data Structure Information (Drawn from Device’s EDS File) Function of Bit 0 in Byte 1 of the RightSight Polarized Retroreflective Sensor



13 -- 5


The following graphic shows the I/O Data property page for the ArmorBlock MaXum input module and the data structure information that can be accessed from the I/O Data property page:


Device Data Structure Information (Drawn from Device’s EDS File)

Function of Bits 0 to 3 in Byte 1 of the Input Data from the Module

RSLogix 5000 Software Tags Database

Once the location where device data is mapped and a device’s data structure are known, device I/O points can be traced using tags in the RSLogix 5000 software tags database. I/O points can be traced using the following types of tags: Review the structure of ControlLogix addresses. Make sure that students understand how DeviceNet tag addresses are constructed in the RSLogix 5000 tag database. Stress that since all DeviceNet data passes through the scanner module, the addresses in the tags’ database are really the addresses assigned in RSNetWorx for DeviceNet software.

•

Module-Defined Tags: Tags are generated automatically when a 1756-DNB scanner module is added to an RSLogix 5000 I/O configuration. Module-define d tags are named after the input or output data location they represent:

Local:1:I.Data[1].0 Local Chassis

Slot Number of Input 1756-DNB Scanner

Word 1

Bit 0

Module

Rev. July 2008


13 -- 6


•

Note that module-defined and alias tags are housed in the same place, so two tags that reference the same I/O point may be available in the same database.

Alias Tags: User-created tags that rename module-defined tags so that their function in the ladder logic program can be more easily identified. For example, an alias tag for “Local:1:I.Data[1].0” might be “Motor_Start.”

The following graphic shows a portion of the tags database in RSLogix 5000 software to which I/O points mapped in a 1756-DNB scanner module can be traced:

Alias Tag

Module Defined Tag




In the graphic below, note that alias tags could also be created to reference the module-defined tags used by the ArmorBlock MaXum input module. For example, an alias tag called Armor_Short_0 could be created to reference the bit that represents the module-generated tag Local:1:I.Data[2].3 (a short on input 0).

To trace I/O points, the input or output data map in RSNetWorx for DeviceNet software must be compared with input or output tags in the tags database of RSLogix 5000 software. The following graphic shows the relationship between the input data map in a 1756-DNB scanner module where an ArmorBlock MaXum input module is mapped and the tags database in RSLogix 5000 software:

1756-DNB Scanner Module Input Data Map

The ArmorBlock input module is mapped to the first half of input word 2 in the 1756-DNB scanner module.

Rev. July 2008

13 -- 7

RSLogix 5000 Software Tags Database

Bits 4 to 7 represent short circuits The first 16 bits in on the ArmorBlock MaXum input Local:1:I.Data[2] represent bits in the module’s connectors. ArmorBlock input module.


13 -- 8


Scanner Module Status Register Direct students to the pages in the Documentation Reference Guide where status register information for a 1756-DNB scanner module is located.

Tip "

Note information bit function in thethat status register ofabout a 1771-SDN scanner module can also be found in the Documentation Reference Guide.

The status of a scanner module can be monitored by viewing the scanner module’s status register. Status register for a 1756-DNB scanner module is a unique input word (I.StatusRegister) of the corresponding ControlLogix controller. The tags associated with a 1756-DNB scanner module’s status register are automatically created when the module is added to the RSLogix 5000 I/O configuration. The following the information about acan scanner modulethrough and, the status consequently, entire network, be obtained register: •

The operational mode of the scanner module (Run, Idle, Disabled, etc.)

•

If there are faulted devices on the network

•

If there are duplicate node addresses on the network

•

If there is an explicit message response availab le from a device

The following graphic shows the portion of the tag database in RSLogix 5000 software where information from the status register of a 1756-DNB scanner module is located:

Status Register Data for a 1756-DNB Scanner Module




13 -- 9

1756-DNB Scanner Module Module-Defined Status Tags Direct students to the page in the Documentation Reference Guide where the 1756-DNB scanner module’s status structure elements are described and discuss the purpose and usage of each.

Additional status information for a 1756-DNB scanner module and the devices in its scanlist can be obtained by monitoring certain tags that are automatically created when a 1756-DNB scanner module is added to the I/O configuration in RSLogix 5000 software. These tags are housed in the status structure elements shown in the following graphic:

Module-Defined Input Tags Module-Defined Output Tags

Module-Defined Status Structure Elements

Alias Tags

Review the terms “status structure” and “array”.

With the exception of the S.ScanCounter and S.StatusDisplay status structures, each 1756-DNB module-defined status structure is an array of 8 bytes that make up a 64 bit table. There is one bit for every one of the 64 possible node addresses on the network. Each bit that is turned on (equals 1) provides some type of status information for the node address it represents.

Tip "

Rev. July 2008

Details about the specific information provided by each of the 1756-DNB module-defined status structu res can be found in the Documentation Reference Guide.


13 -- 10


Here’s How

To trace I/O points through a 1756-DNB scanner module.

Demonstrate how to trace the Start bit for the PowerFlex 40 drive in the scanlist of the 1756-DNB scanner module using your workstation and the example below.

Example

As your instructor demonstrates this procedure, refer to the following example:

Tracing I/O Points through a 1756-DNB Scanner Module In this example, the Start bit of a PowerFlex 40 drive will be traced through a 1756-DNB scanner module. The drive has the following characteristics:

Tip "

•

It is configured for polled messaging .

•

It sends and receives 4 bytes of data.

The data structure of the input and output assemblies used by the drive is located in the drive’s user manual. Step 1: Determine Output Mapping

The output mapping information is accessed using the RSNetWorx for DeviceNet software output data map. It is determined that the PowerFlex 40 drive is mapped to the first half of double-words 6 and 7 in the 1756-DNB scanner module:

Output data is mapped to words 6 and 7.



13--11


Step 2: Determine Data Structure

The data structure of the PowerFlex 40 drive’s output assembly is determined by accessing the drive’s user manual (see also Appendix C). Based on the output assembly data structure excerpted from the user manual and shown in the following graphic, it is determined that bit 1 enables the drive to start: RunFwd (Run Forward) Bit Instance 21 Data Format (Reversing Speed Control Output Assembly) Byte

Bit7

Bit6

0 1

Bit5

Bit4

Bit3

Bit2

Bit 0

Bit1

Clear Fault

Jog

2


3


Start

Stop

Step 3: Determine I/O Point Location in RSLogix 5000 Software Tags Database

Using the information now known about the output data map and output assembly data structure for the PowerFlex 40 drive, the exact location of the Start bit is located in the RSLogix 5000 software tags database:

Start Bit Alias Tag

Rev. July 2008


13 -- 12


Step 4: Verify the Addressing of the Ladder Logic Instruction Controlling the I/O Point

Once it is known that output point Local:2:O.Data[6].1 represents the Start bit in the PowerFlex 40 drive, the ladder logic instruction that actually turns this bit on must be checked against this address to make sure that it is referencing the correct point. The following graphic shows the rung of ladder logic that controls the PowerFlex 40 drive:

Output Instruction to Turn PowerFlex 40 Drive RunFwd (Run Forward) Bit On

Per the output instruction in the example graphic, the Start bit is at output address Local:2:O.D ata[6].1. Since this is the address where the Start bit for the drive is mapped in the scanner module, it can be determined that the PowerFlex 40 drive’s output map in RSNetWorx for DeviceNet softwa re is aligned with the RSLogix 5000 addressing.

Here’s How

Perform the following demonstration: 1. Toggle the ControlLogix controller at your workstation between Idle and Run modes and monitor the changes in the 1756-DNB scanner module’s status r egister.

To troubleshoot a DeviceNet network using RSLogix 5000 software by performing the following tasks: •


•

Monitor a 1756-DNB module’s module-defined status tag values


2. Still using the 1756-DNB scanner module, create an error on the network that will show up in the 1756-DNB scanner module’s status structure tags, then monitor these tags.



Exercise: Troubleshooting a DeviceNet Network Using RSLogix 5000 Software

13 -- 13

Exercise: Troubleshooting a DeviceNet Network Using RSLogix 5000 Software Exercise A

In this exercise, you will practice troublesho oting a DeviceNet network by performing the following tasks: •

Trace I/O points through a 1756-DNB scanner module

•


•

Monitor a 1756-DNB module’s module-defined status tag values

Context: An ArmorBlock MaXum input module has recently been replaced on the DeviceNet networ k. The module has already been configured and mapped in RSNetWorx for DeviceNet software. The module’s network status indicato r is solid green and there are no alphanumeric codes displayed for it on the 1756-DNB scanner module, but it is still not communicating on the network. You begin to suspect that the module’s mapping in RSNetWorx for DeviceNet software and the addresses it references in the RSLogix 5000 software program that runs the conveyor line may be mismatched. You decide to troubleshoot the problem by tracing I/O points for the ArmorBlock MaXum input module. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "


Directions: 1. Open network configuration file RSL_N100_A1.dnt. 2. Go online to the network. 3. Change the controller’s operat ing mode to Program. 4. Download the device configurat ion to the 1756-DNB scanner module. 5. Change the controller’s operati ng mode to Run.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. RSLe100

13 -- 14


6. Attempt to start the motor in the workstation by pressing the IN2 pushbutton.

Tip "

This pushbutton is wired to the third input of the ArmorBlock MaXum Input module and should command the PowerFlex 40 drive to start the motor. 7. Does the motor start?

8. Open project file RSL_N100_A2.acd. 9. Download the project to your controller. 10. If you have not already done so, change the controller’s operating mode to Run. 11. Using the RSNetWorx for DeviceNet input data map, the I/O Defaults property page for the ArmorBlock input module, and the RSLogix 5000 controller tags database, trace the third ArmorBlock MaXum input point and complete the following information:

RSNetWorx for DeviceNet Software Input Data Map Address:

Location of Input 2 On Bit Within Device Data Structure:

12. To which RSLogix 5000 module-defined tag will data from input 2 in the ArmorBlock MaXum input module go?

13. Access rung 0 in the Cooling_Rack subroutine. 14. Does the input instruction for input 2 in the ArmorBlock MaXum input module match the module-defined tag where the ArmorBlock MaXum input module’s inputs will be found based on the RSNetWorx for DeviceNet software input data map? Why or why not?

15. Go online to the ControlLogix controller. E 2008 Rockwell Automation, Inc. All rights reserved.

Rev. July 2008 RSLe100


13 -- 15

16. Access the controller tags database. 17. Expand the database until the module-defined tag where the ArmorBlock MaXum module’s inputs should be found is in view. 18. While monitoring this tag, attempt to start the motor in the workstation by pressing the IN2 pushbutton. This pushbutton is wired to the third input of the ArmorBlock input module and should energize the PowerFlex 40 to start the motor. 19. Which input bit goes on as a result of this action? Is this the bit that is referenced in rung 0 of the ladder logic?

20. What actions can be taken to fix this situation?

21. Change the controller’s operat ing mode to Program. 22. Choose one of the following options to align the ArmorBlock MaXum input module’s addressing: • •

Open network configuration file RSL_N100_A3.dnt and download the network configuration . Using the currently open RSNetWorx for DeviceNet file RSL_N100_A1.dnt, manually map device input data for the ArmorBlock input module so that it is aligned with the address referenced in the input instruction in rung 0.

23. Change the controller’s operati ng mode to Run. 24. Attempt to start the motor in the workstation by pressing the IN2 pushbutton. This pushbutton is wired to the third input of the ArmorBlock input module and should command the PowerFlex 40 drive to start the motor. If the motor starts, you have successfully fixed input address alignment. 25. Press the red button on the PowerFlex 40 drive to stop the motor.

Rev. July 2008


13 -- 16


26. Trace the input point that reflects the status of the offwire diagnostic parameter for input 2 in the ArmorBlock MaXum input module. 27. Which bit in the RSLogix 5000 controller tags database will go on if an offwire condition is detected on input 2 of the ArmorBlock MaXum input module?

28. Test your conclusion by disconnecting the cable for input 2 on the

ArmorBlock MaXum input module, activating the Connector Fault Status parameter for input 2 of the module in RSNetWorx for DeviceNet software, and monitoring the bit that should be affected in the RSLogix 5000 input data file. 29. Reconnect the cable for input 2 of the ArmorBlock MaXum input module and deactivate the Connector Fault Status parameter for input 2 of the module. 30. Monitor data in the 1756-DNB scanner module’s status register. 31. Which bit is on in the status register and what does it signify?

32. Disconnect the 871TM inductive proximity sensor from the network. 33. values. Monitor the 1756-DNB module’s module-defined status tag 34. Which module-defi ned status tag indicates that a fault exists for the 871TM inductive proximity sensor?

35. Which module-defi ned status tag reflects the numeric code created in the scanner module by disconnecting the 871TM inductive proximity sensor from the network?

36. Change the controller’s operati ng mode to Program. 37. Close RSLogix 5000 software. 38. Close RSNetWorx for DeviceNet software.

How Did You Do?





Rev. July 2008

13 -- 17


13 -- 18


Answers

Exercise A 7. No, the motor should not start. 11. The RSNetWorx for DeviceNet Software Input Data Map Address for the ArmorBlock MaXum input module is 2:I.Data[8]. The third input corresponds to the 2:I.Data[8]. 2 address. 12. Data from input 2 in the ArmorBlock MaXum input module will go to module-defined tag Local:2:I.Data[8].2. 14. No, the input instruction for input 2 in the ArmorBlock MaXum input module does not match the module-defined tag where the ArmorBlock MaXum input module’s inputs will be found based on the RSNetWorx for DeviceNet software input data map.

The ArmorBlock MaXum inputs are mapped to the first half of double-word 8, beginning at bit 0. Since the third bit (bit 16) of the first byte of input data from the ArmorBlock MaXum input module controls input 2, the input instruction in RSLogix 5000 software should reference Local:1:I.Data[8].2. Since it references Local:1:I.Data[2].18, the addressing does not match. 19. Input bit Local:1:I.Data[8].2 goes on as a result of pressing the IN2 pushbutton. However , this is not the bit that is referenced in rung 0 of the ladder logic. 20. Either one of the following actions can be taken to align the input addressing for the ArmorBlock MaXum input module:

-- The input data map in RSNetWorx for DeviceNet software can be changed to match the ladder logic.

-- The ladder logic can be re-written to reference the address where the input module is actually mapped. 27. Bit 26 of input word 8 in the RSLogix 5000 Controller Tags database will go on if an offwire condition is detected on input 2 of the ArmorBlock MaXum input module. 31. Bit 0 is on in the status register, signifying that the scanner module is in Run mode. 34. The DeviceFailur eRegister tag indicates that a fault exists for the 871TM inductive proximity sensor . 35. The DeviceStatu s tag reflects the numeric code created in the scanner module by disconnecting the 871TM inductive proximity sensor from the network.



Lesson

14

Troubleshooting Duplicate Node Addresses on a DeviceNet Network What You Will Learn

After completing this lesson, you should be able to troubleshoot duplicate node addresse s on a DeviceNet network by performing the following tasks: •

Recognize conditions that indicate a duplicate node address

•

Recover a duplicate node address using the Faulted Address Recovery (FAR) wizard

Why These Skills Are Important These skills are important because devices with duplicate node addresses will not function properly on a network and can cause the entire network to malfunction.

Before You Begin

Duplicate Node Addresses A common problem on DeviceNet networks is the accidental assignment of the same node address to two different devices . Since each device on a network must have a unique node address, significant network errors can occur if two devices are assigned the same one.

? How do you think adding and commissioning devices one at a time helps to avoid duplicate node addresses? Answer: Since new devices come factory-commissioned to node address 63, adding multiple new devices at once means adding devices with duplicate node addresses. If only one device is added at a time and immediately commissioned to another node address, this problem will not occur.

Rev. July 2008

Duplicate node address assignment can be avoided by adhering to the following guidelines: •

Adding devices to a network and commissioning them one at a time

•

Never using node address 63 as a permanent address for any device In a situation where the same node address is assigned to two devices, it is possible for either of the two devices to lose the ability to communicate.

E 2008 Rockwell Automation, Inc. All rights reserved. FARib100

14 -- 2


Duplicate Node Address Recognition Although no single numeric or alphanumeric code on a scanner module indicates the presence of duplicate node addresses on a network, several indicators can be used in combination to determine if duplicate node addresses exist. Point out that if a duplicate node address exists for a scanner module itself, a numeric code of 70 (or alphanumeric code “Duplicate Node” for 1756-DNB scanner modules) will be displayed on the scanner module.

The following symptoms are possible indications that duplicate node addresses may exist on a network: •

Solid red network status indicators on two or more devices

•

Numeric codes of 72 or 78 alternating with device node addresses on the front of the scanner module, indicating that communications with these devices has been lost

•

Missing device icons in RSNetWorxt for DeviceNet software

Faulted Address Recovery Wizard Note that the Faulted Address Recovery wizard can be a handy maintenance tool when more than one device is being added to a network at a time: multiple devices with default node addresses of 63 can be placed on the network at once and commissioned using the Faulted Address Recovery wizard. Provide the following examples of devices that support the Faulted Address Recovery wizard: S All 1734 POINT I/O products

S

All PanelView products

S

Bulletin 100 DNY auxiliary starters

S

Bulletin 160 DN2 adapter modules

S

E3 and E3 Plus solid-state overload relays

S

800E pushbutton stations

S

Ultra 100 digital servo drives

S

1203-GK5, 1203-GM5, 1203-GU6, and 1203-GM6 Scanport adapters


The Faulted Address Recovery wizard is an RSNetWorx for DeviceNet software tool that enables a user to quickly and easily determine which devices on a network have duplicate node addresses. The Faulted Address Recovery wizard can also assign a new node address to any device for which a duplicate address is detected. Not all devices support the Faulted Address Recovery feature. Consult the user documentation to determine whether or not a particular device supports the feature.

The Faulted Address Recovery wizard will not work if an Ethernet driver has been used to go online to a network through the ControlLogix backplane.

Rev. July 2008 FARib100


14 -- 3

The following graphic shows the Faulted Address Recovery Wizard window where duplicate node addresses are detected and re-assigned:

Use this button to identify a faulted device by flashing its network indicator.status Use this button to let the software assign a new node address to a faulted device.

Use this field to assign a faulted device a new node address of your choice.

The following actions can be accomplished using the Faulted Address Recovery wizard: • The serial numbers of devices with duplicate node addresses can be displayed. Note that if a duplicate node address is detected, a user has the choice of letting the Faulted Address Recovery wizard assign the next available node address to a faulted device or of personally selecting a unique address.

Rev. July 2008

•

The network status indicators of devices with duplicate node addresses can be made to blink red and green (“flashed”) to help a user identify the faulted device.

•

New node addresses can be assigned to all devices for which duplicate node addresses have been detected.


14 -- 4


The following graphic illustrates the flashing feature of the Faulted Address Recovery wizard:

Flash LED Command Button Network Status Indicator That Alternately Flashes Red and Green to Indicate a Duplicate Node Address on This Device

Faulted Address Recovery Wizard Window

1203-GK5 Communications Module

Manual Node Address Recovery Stress that an indication by the Faulted Address Recovery wizard that no faulted node addresses were detected does not eliminate the possibility that duplicate

If duplicate node addresses are suspected but not detected by the Faulted Address Recovery wizard because the faulted device(s) do not support the feature, the faulted node addresses must be recovered

node addresses exist: there still be duplicate node addresses onmay devices that do not support the Faulted Address Recovery wizard.

manually. Use either of the following methods to recover duplicate node addresses manually:

Tip "


•

Visually inspect all devices whose node addresses can be set using device hardware for duplicate node address assignments.

•

Turn off network power, then power up each device individually until the device with the duplicate node address is isolated.

•

Remove each device from the network one at a time and verify its node address using a point-to-point connection between the device and a 1770-KFD module with it’s own power supply.

For a 1756-DNB scanner module, the (former) node addresses of the devices with duplicate node addresses will flash alternately in the ScrollingDeviceStatus structure element in RSLogix 5000 software.



Here’s How Create a duplicate node address on your workstation and point out the network conditions that indicate a possible duplicate node address. Then use the Faulted Address Recovery wizard to isolate the faulted node and assign it a unique node address. Note that the Procedures Guide does not include a procedure for recognizing conditions that indicate a duplicate node address.

Rev. July 2008

14 -- 5

To troubleshoot duplicate node addresses on a DeviceNet network using the Faulted Address Recovery wizard by performing the following tasks: •

Recognize conditions that indicate a duplicate node address

•

Recover a duplicate node address using the Faulted Address Recovery (FAR) wizard



14 -- 6




Exercise: Troubleshooting Duplicate Node Addresses on a DeviceNet Network

14 -- 7

Exercise: Troubleshooting Duplicate Node Addresses on a DeviceNet Network Exercise A

In this exercise, you will practice troublesho oting duplicate node addresses on a DeviceNet network.

Context: You have just added two brand new devices to your network at the same time, forgetting that they both came from the factory with node addresses of 63. Consequently, both of the new devices have faulted. You suspect a duplicate node address condition on the network and need to troubleshoot it. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: 1. Go online to the network using the 1770-KFD driver.

For this lab exercise, you must go online using the 1770-KFD driver. 2. Assign a node address using the Node Commission ing tool: assign the 871TM inductive proximity sensor to node address 63. 3. Disconnect the 871TM proximity sensor from the network. 4. Delete the icon in the RSNetWorx for DeviceNet software configuration that represents the 871TM inductive proximity sensor at node 63. 5. Perform a single-pass browse of the network. 6. Configure the node address dials to node 99 on the E3 overload relay. 7. Cycle power to the workstation 8. Assign a node address through the Hardware View: assign the E3 overload relay to node 63. 9. Turn the power off on the workstation. 10. Re-connect the 871TM proximity sensor to the network. 11. Reapply power to the workstation.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. FARe100

14 -- 8


12. Wait for scanner module start-up diagnostics to complete, then perform a single-pass browse. 13. List at least two conditions on the network that indicate duplicate node addresses may be present:

14. Recover node addresses using the Faulted Address Recoveryduplicate (FAR) wizard.

Tip "

Remember to use the flashing feature to identify the device with the duplicate node address. 15. When duplicate node addresses have been recovered, re-assi gn node addresses for the faulted devices to the node address assignments indicated in the Scanner Module Master Data Maps appendix. 16. Save the network configuratio n. 17. Close RSNetWorx for DeviceNet software.

How Did You Do?



Rev. July 2008 FARe100


Rev. July 2008

14 -- 9

E 2008 Rockwell Automation, Inc. All rights reserved. FARe100

14 -- 10


Answers

Exercise A 13. The following conditions are good indications that duplicate node addresses may be present on the network: •

• •

A missing device icon(s) in the RSNetWorx for DeviceNet software network configuration for either the E3 solid-state overload relay or the 871TM proximity sensor A solid red network status indicator on either the E3 solid-state overload relay or the 871TM proximity sensor Numeric code 78 for the E3 solid-state overload relay and/or the 871TM proximity sensor

Exercise Troubleshooting Tips If you are unable to successfully create and clear a duplicate node address conditio n, verify that you have completed the following actions:

-


Connected to the network using the 1770-KFD driver Successfully commission ed the 871TM proximity sensor to node 63 and verified that it appears in RSLinx at node 63 before cycling network power.

Rev. July 2008 FARe100

Lesson

15

Integrated Practice: Restoring a Malfunctioning DeviceNet Network to Normal Operation What You Will Learn

After completing this lesson, you should be able to restore a malfunctioning DeviceNet network to normal operation by performing the following tasks: •

Troubleshoot a network using RSNetWorx for DeviceNet software

•

Troubleshoot a network using hardware indicators

•

Troubleshoot a network using RSLogix 5000 or RSLogix 500 software

•

Troubleshoot duplicate node addresses

Why These Skills Are Important Restoring a DeviceNet network to normal operation using multiple resources is important for the following reasons :

Rev. July 2008

•

Some resources are more convenient to use than others depending upon one’s location relative to the network (i.e., it makes more sense to look at numeric or alphanumeric codes using a scanner module’s status register if you are far away from the scanner module itself, but close to a computer with programming software).

•

Using a combination of troubleshooting resources provides a more complete picture of a network’s status.

•

Each of the various troubleshooting resourc es provides unique information about a network.

E 2008 Rockwell Automation, Inc. All rights reserved. RETib100

15 -- 2

Integrated Practice: Restoring a Malfunctioning DeviceNet Network to Normal Operation


Rev. July 2008 RETib100

Exercise: Integrated Practice -- Restoring a Malfunctioning DeviceNet Network to Normal Operation

15 -- 3

Exercise: Integrated Practice -Restoring a Malfunctioning DeviceNet Network to Normal Operation Exercise A

In this exercise, you will practice restoring a malfunctioning network to normal operation.

Context: The DeviceNet network at your plant is malfunctioning as evidenced by the following indications : •

The oven line conveyor no longer starts when the Start button, IN2, is pressed.

•

The status indicators on the front of the scanner module are not solid green.

•

There are numeric/alphanu meric codes other than the scanner module’s own node address on the front of the scanner module.

•

Some devices are showing up with errors in the RSNetWorx for DeviceNet software network configuration.

•

Not all network devices have solid green network status indicators.

It is your job to clear all of the error indications on the network and restore it to normal operation. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 500/5000 software, consult the Start Pages or the online Help.

Directions: Restore the malfunctioning network to normal operation using the following resources:

Rev. July 2008

•


•

Hardware status indicators

•

RSLogix 500/5000 software

• •

The Troubleshooting Guide The Procedures Guide

•

The Documentation Reference Guide

•

The Scanner Module Master Data Maps in Appendix A E 2008 Rockwell Automation, Inc. All rights reserved. RETe100

15 -- 4


After you have restored the network to normal operation, use the following checklist to verify that the network has been properly restored:

-

The module and network status indicators on the 1747-SDN scanner module or the combined network/ status indicator on the 1756-DNB scanner module are solid green. The only code displayed on the front of the scanner module is the module’s own node address. All of the network devices are displayed without error icons in the RSNetWorx for DeviceNet software online network configuration. The network status indicator on all network devices is solid green. The motor in the workstation starts when the IN2 Start pushbutton is pressed and stops when the red button on the PowerFlex 40 drive is pressed. The motor in the workstation starts when the IN2 pushbutton or the PanelView Plus Start Motor button is pressed and stops when the red pushbutton on the PowerFlex 40 drive or the Stop Motor pushbutton on the PanelView Plus is pressed. If all of the above conditions are not present, there are still problems on the network that must be resolved.

1. Open the RET_N100_A1.dnt network configuration file. 2. Disconnect the right-hand 871TM proximity sensor. 3. Change the controller’s operati ng mode to Program. 4. Go online to the network. 5. Download the network configuration. 6. Troubleshoot and correct the network errors.

How Did You Do?



Rev. July 2008 RETe100


Rev. July 2008

15 -- 5

E 2008 Rockwell Automation, Inc. All rights reserved. RETe100

15 -- 6


Answers

Exercise A If you restored the malfunctioning DeviceNet network to normal operation succes sfully, you will have identified and corrected the following problems: Problem 1: A loose connection between the 871TM proximity sensor and the network. Solution: Secure the connection. Problem 2: Misalignment of the output mapping specified for the PowerFlex 40 drive in RSNetWorx for DeviceNet software and the address in the output instruction to activate the drive in the ladder logic program. Solution: Change the mapping in RSNetWorx for DeviceNet software so it is aligned with the addresses used in the ladder logic, or change the ladder logic so that instructions for the PowerFlex 40 drive reference the output address specifie d for the drive in RSNetWorx for DeviceNet software. Problem 3: Several nodes have an identity mismatch. This includes the PanelView Plus, the absolute multi-tur n encoder, and the E3 overload relay. Solution: Right--click each device and resolve the device mismatch.

Tip "


The PowerFlex 40 drive’s output dataData mapping information found in the Master Scanner Module Maps appendix. can be

Rev. July 2008 RETe100

Optional Lesson

16

Configuring a 1747-SDN DeviceNet Scanner Module What You Will Learn

After completing this lesson, you should be able to configure a 1747-SDN DeviceNet scanner module by performing the following tasks: •

Configure a 1747-SDN scanner module

•

Create a scanlist Configure a scanner module for slave mode

• •

Enter ladder logic instructions to place a 1747-SDN scanner module in Run mode

Why These Skills Are Important Being able to configure a scanner module correctly is important for the following reasons:

Before You Begin Point out to students that DeviceNet networks are compatible with a number of platforms, each of which uses a different scanner module. This lesson covers configuration tasks associated with the scanner modules used with SLC 500 platforms.

Rev. July 2008

•

A scanner module is responsible for the exchange of information between devices and the processor or controller . If it is incorrectly configured, communications will not occur.

•

Correct scanner module configurati on ensures that the scanner module is aware of the status of network devices and can provide valuable informati on for isolating faults.

Scanner Module Communications with Devices A scanner module acts as an interface between devices on a DeviceNet network and a processor or controller. Specifically, a scanner module performs the following actions: •

Reads input data from devices and makes it available to a processor or controller

•

Writes output data from a processor or controller to devices

•

Downloads configuration data from the software to devices

•

Uploads configur ation data from the devices to the software

•

Monitors the operational status of devices

E 2008 Rockwell Automation, Inc. All rights reserved. SCNSib100

16 -- 2

Configuring a 1747-SDN DeviceNet Scanner Module

Scanner Module Communications with a Processor

? Does anyone have experience working with scanner modules? If so, what kind of tasks have you performed using a scanner module?

Scanner module communicatio ns with a processor or controller consists of two general steps: •

Data received from devices (input data) is organized by the scanner module and made available to the processor or controller .

•

Data received from the processor or controller (output data) is organized in the scanner module and sent to devices.

The following graphic shows the flow of data between a processor or controller, a scanner module, and a device on a DeviceNet network: Processor Output to Device

Processor Output to Device

Device Input to Processor

Device Input to Processor


Device

Scanner Module

Scanner Modules

Note that configuration of a 1771-SDN scanner module is not practiced in this course, but that information specific to the configuration of this module can be found in the procedures guide and the documentation reference guide.

Tip "


A different scanner module is used depending upon the type of processor or controller being used with a network. The following table shows four of the Rockwell Automation scanner modules most often used on DeviceNet networks and their correspondin g processor or controller types: Scanner Module


1771-SDN

PLC --5

1747-SDN

SLC500

1756-DNB

ControlLogix

1769-SDN

CompactLogix

An additional scanner module, the 1784-PCIDS scanner card, can be used to connect most applications to a DeviceNet network via a personal computer.

Rev. July 2008 SCNSib100


16 -- 3

1747-SDN Scanner Module A 1747-SDN scanner module has the following characteristics: •

Communicates with up to 62 commissioned nodes

•

Resides in an SLC 500 chassis

•

Provides one channel for DeviceNet communications

•

Requires M file reads and writes in order to transfer more than 32 words of data

1747-SDN Scanner Module Data Transfer Types To configure a 1747-SDN scanner module properly, it is necessary to understand the way in which the module transfers data between devices and a processor. Specifically, a 1747-SDN scanner module communicates with an SLC 500 processor and devices via the following data transfers:

Note that discrete I/O transfer is generally faster than M file transfer.

•

M1 File Reads/M0 File Writes: A method of moving large amounts of data (up to 361 words) between an SLC 500 processor and a 1747-SDN scanne r module.

•

Discrete Input/Output Data Transfers: A method of transferring one to 32 words of data between an SLC 500 processor and a 1747-SDN scanner module.

M1 File Reads/M0 File Writes

M files are areas specific to the 1747-SDN scanner module’s memory. The M1 and M0 files can be defined as follows:

Rev. July 2008

•

M1 File: The area in a 1747-SDN scanner module’s memory where data sent from network devices to a processor (input data) is stored. The M1 file can contain up to 361 words. These words are divided into groups. Each group of words stores a specific type of data.

•

M0 File: The area in a 1747-SDN scanner module’s memory where data sent from a processor to network devices (output data) is stored. The M0 file can conta in up to 361 words. These words are also divided into groups that store specific types of data.


16 -- 4


Data is stored by type in groups of words within the M files of a 1747-SDN scanner module. The following types of data are stored in the scanner module M files: Do not go into detail about explicit messaging. It will be discussed in a later lesson. If students have questions about the other data types that are stored in a 1747-SDN scanner module, describe each data type briefly.

•

Pass through driver data

•

Explicit message program control data

•

Device failure data

•

Scan counter data

Tell students it’s important to be aware of the location of the various data in a scanner module so that ladder logic can be written to access it. For example, a COP instruction to get data from the device failure table (words 216 to 219) can be included in the main routine to get detailed diagnostic information from devices. M1 File

•

Scanner LED data

•

Device input data greater than 32 words in length

•

Device output data greater than 32 words in length

The following graphic shows the division of data within the M files of a 1747-SDN scanner module: M0 File

Pass Through Driver

Words 256-360

Pass Through Driver

Explicit Message Program Control

Words 224-255

Explicit Message Program Control

Auto Verify Failure Table

Words 220-223

Device Failure Table

Words 216-219

Reserved

Words 212-215 Reserved

Scan Counter

Word 211

Scanner LEDs

Word 210

Reserved

Words 150-209

Input Data

Words 0-149

Inform students that detailed information about the 1747-SDN scanner module’s data tables, as well as those of other scanner modules, can be found in the Documentation Reference Guide.


Output Data

Only 1747-SDN scanner modules at firmware revision level 4.015 or higher support 361 word file transfers. Earlier firmware revision levels support file transfer of up to 256 words and therefore do not support a pass through driver .



16 -- 5

M File Transfer

Point out that devices like operator interfaces and drives are often configured for M data transfer in a scanner module because they need to transfer large amounts of data at a time. Remind students that M file data transfer only applies to the 1747-SDN scanner module. You may want to briefly explain that the 1771-SDN scanner module used with PLC 5 processors uses BTW and BTR instructions to transfer large amounts of data. Refer students to the documentation reference guide for information regarding 1771-SDN file transfer.

Since an SLC 500 processor does not contain an image of the scanner module’s M1 and M0 files, M file data must be edited and monitored using instructions in the ladder logic program. The following rules apply to the transfer of M1 and M0 file data (input and output data greater than 32 words in length) to and from an SLC 500 processor: •

M file data must be transferred between a 1747-SDN scanner module and an SLC 500 processor via a COP instruction in the ladder logic.

•

Input data to an SLC 500 processor (M1 file data) must be transferred from the 1747-SDN scanner module to a data file in the SLC 500 processor using two COP instructions of 128 and 22 words, respectively.

The following graphic shows the ladder logic used to copy the maximum of 150 words of data from the M1 file of a 1747-SDN scanner module to a data file in an SLC 500 processor (input data): COP Source #M1:1.0 Dest #N23:0 Length 128

COP Source #M1:1.128 Dest #N23:128 Length 22

Explain that the rung containing instructions for M1 file transfer should be near the beginning of the main routine because the data must be moved into the processor before it can be used in the program.

Tip "

The rung containing instructions to transfer M1 file data from a scanner module to a processor should generally be near the beginning of the main ladder logic routine.

Two separate COP instructions are only needed if there are more than 128 words of data to be transferred from a 1747-SDN scanner module to an SLC 500 processor. If 128 words or less are being transferred, only one COP instruction is required. •

Output data from an SLC 500 processor must be transferred to the M0 file of a 1747-SDN scanner module from a data file in the processor using two COP instructions of 128 and 22 words, respectively.

Rev. July 2008


16 -- 6


The following graphic shows the ladder logic used to copy data from a data file in an SLC 500 processor to the M0 file of a 1747-SDN scanner module (output data): COP Source #N3:0 Dest #M0:1.0 Length 128

COP Source #N3:128 Dest #M0:1.128 Length 22

Access the RSLogix 500 program that runs the DeviceNet workstation and point out the rungs containing M file transfer instructions.

Tip "

The rung containing instructi ons to transfer M0 file data from a processor to a scanner module should generally be near the end of the main ladder logic routine.

Two separate COP instructions are only needed if there are more than 128 words of data to be transferred from an SLC 500 processor to a 1747-SDN scanner module. If 128 words or less are being transferred, only one COP instruction is required. Discrete Input and Output Data Transfers

Point out that devices like a photoelectric sensor or a limit switch are usually configured for discrete data transfer in a scanner module because they rarely transfer more than a word or two of data.

Tip "


Device data that is less than 32 words in length is passed between a device and an SLC 500 processor using discrete data transfers. To correctly configure a scanner module, it is important to understand the way in which discrete data is organized and transferred. Discrete input and output data as it applies to 1747-SDN scanner modules can be described as follows: •

Discrete Input Data: Data up to 32 words in length that is sent from network devices to a processor.

•

Discrete Output Data: Data up to 32 words in length that is sent from a processor to network devices .

No special ladder logic is necessary to transfer discrete input and output data between a scanner module and processor.



16 -- 7

The following graphic shows the process of both discrete and M file data transfer between a 1747-SDN scanner module and an SLC 500 processor: 1747-SDN Scanner Module

SLC 500 Processor Discrete Input Image

Discrete Input Table A1

A1


B M1 File C A2

B M1 Data File C A2

D E

M1 File Transfer (Read)

D E

Discrete Output Image

Discrete Output Table X

X


M0 File Z

M0 Data File Z

Y

Y M0 File Transfer (Write)

Scanner Module Configuration The following general settings must be configured in a DeviceNet scanner module:

Rev. July 2008

•

Node address and data rate

•

Interscan delay time

•

Foreground to background poll ratio


16 -- 8


Node Address and Data Rate

Like other network devices, a scanner module must be assigned a node address and data rate to communicate on the network. Depending upon scanner module type, the node address and data rate can be assigned using RSNetWorx for DeviceNet software or the scanner module itself. The 1747-SDN node address and data rate can be assigned using RSNetWorx for DeviceNet software.

Tip "

The recommended node address for a scanner module is the lowest address available. Interscan Delay

? Why would it not be advisable to set the interscan delay to a very high value? Answer: The data coming from devices may change frequently and the scanner module will not receive this data as often if the value is set high. Therefore, important device information may not be received when needed.

The interscan delay is the time delay between consecutive I/O scans. During this time, the scanner module performs non-time -critical communications on the network (e.g., communications with software). Settings for interscan delay can be described as follows: •

The interscan delay can be set from 2 to 9000 milliseconds (10 is the default.)

•

If set low, the time required for the scanner to respond to RSLinx software and configuration functions is increased.

•

If set high, the data is not scanned as often and a change in data may take longer to be noticed.

Expected Packet Rate

When a scanner opens an I/O connection it sets a gross timeout into the device. If the device does not receive a packet from the scanner in this time period, then the device drops the connection. If the scanner does not receive a packet from the slave in this time period, it will drop the connection and attempt to open a new connection periodically. This timeout value is called the Expected Packet Rate (EPR):


•

The default EPR is 75 times 4 = 300 ms for polled and strobed messaging.

•

The gross network timeout for COS messaging is 4 times the heartbeat rate.

•

Gross network timeout for a CYCLIC device is 4 times the send rate.



16 -- 9

The interscan delay should always be set to a value lower than the expected packet rate to help prevent messaging timeouts. Foreground to Background Poll Ratio Mention that this feature is often used to conserve network bandwidth, since it reduces the amount of traffic on a network at a given time.

The foreground to background poll ratio sets the frequency of I/O messages to a device in relation to the number of I/O scans (e.g., if the ratio is four, the scanner module communic ates with the device every five scans). This feature allows a user to determine whether or not a device will communicate with a scanner during every scan cycle. Interscan delay and foreground to background poll ratio are configured using the following RSNetWorx for DeviceNet software property page:

Interscan Delay Foreground to Background Poll Ratio

Rev. July 2008


16 -- 10


Scanlist Make sure students understand how important it is to create a scanlist. If the scanlist is not configured, the scanner module will not be able to communicate with devices on the network.

A scanlist is a list of devices on a network with which a scanner module will communicate. A scanlist must exist in a scanner module for communicatio ns to occur between devices and a processor. The scanlist provides the scanner module with the following informa tion: •

Which devices to scan

Point out that simply adding a device to a scanlist does not automatically define all of these variables. Additional configuration (such as specification of message type and I/O sizes, level of electronic keying, and mapping, must also be performed.

•

How to scan each device

•

How closely a device in the scanlist must match the physical device on the network

•

How often each device is to be scanned

•

Where data can be found in each device’s memory

If this lesson is being taught as part of a standard school (e.g., not a part of a Tailored Training curriculum, mention that these tasks will be performed in the lesson on mapping.

•

The size of input and output data

•

Where input and output data is to be mapped in the scanner module in order for the processor or controller to read it

•

How the processor or controller should read each device (i.e., M1/M0 file or discrete I/O)


Note that electronic keying is integral to the Automatic Device Recovery (ADR) feature. If this lesson is being taught as part of a standard school (e.g., not part of a Tailored Training curriculum), mention that the topic will be covered in detail in the lesson on Automatic Device recovery.

“Electronic Keying” is a feature that automatically compares the expected module (as shown in the I/O Configuration tree) to the physical module before I/O communications begin. Using electronic keying can help prevent communications to a module that does not match the type and revision expected. For each module in the I/O Configuration tree, the user-selected Keying Option determines if and how an electronic keying check is performed. Typically three keying options are available, though for some specific module types fewer options are available. The three options are: •

Exact Match

•

Compatible Keying

•

Disable Keying

Each option has benefits and implications that the user must carefully consider when selecting between these options.




16--11

For help understanding these options see the Glossary definitions for Electronic Keying, Compatible Module Keying, Disabled Keying, and Exact Match Keying in your Procedures Guide.

Point out the Node Active check box in the graphic below and note that when this check box is deselected for a

The following graphic shows the RSNetWorx for DeviceNet property page where a scanlist is created and electronic keying criteria are specified:

device, the device will scan not beeven included in the scanner module’s though it is in the scanlist. Point out that the electronic keying criteria selected in the following graphic apply to the E3 solid-state overload relay, since this is the device currently selected in the scanlist. If another device were selected, the electronic keying Scanlist criteria for that device would be displayed.


Slave Mode DeviceNet scanner modules also have the capability of acting as “slaves” to another scanner module on the same network. Part of a scanner module’s configuration includes specifying whether or not the module will operate in slave mode. For network operation in slave mode to occur, the following conditions must exist: •

More than one scanner module must exist on the network.

•

One scanner module must operate as the “master.”

•

Scanner modules other than the “master” scanner module must be considered “slaves” on the network and can only exchange information through the “master” scanner module.

Rev. July 2008


16 -- 12


Example: Slave Mode

The following graphic shows an example of the use of slave mode on a DeviceNet network: Node 0 Scanner Module (Master)

Node 1 Scanner Module (Slave to Node 0)

Node 8

In this example, the following conditions exist:

? Why might you put two scanner

•

modules on a network?

•

Possible Answer: To speed up network traffic. • •

? How would you know the size of the inputs and outputs to be transferred by a scanner module in slave mode? Answer inputofand output would be: The the total inputs andsizes outputs being read from network devices by the scanner module in slave mode.


Node 9

There are two scanner modules on the network. The scanner module at node 0 has its own scanlist and is a master to several nodes on the network, including the scanner module at node 1. The scanner module at node 1 has its own scanlist and can be a master to other nodes on the network Data gathered by the scanner module at node 1 is then collected by the scanner module at node 0.

If a scanner module is configured for slave mode, the following additional parameters must be specified: • •

The message type that will be used to communicate with the master scanner module The size of inputs and outputs that will be transferred



16 -- 13

Slave mode is enabled and configured in the following RSNetW orx for DeviceNet software window:

Check Box to Enable Slave Mode

Area Where Message Type and Size Are Specified

Shared Inputs

? In what kind of situation would the shared input option be useful? Possible Answer: When another processor or controller must use data from devices, but does not need to send them data.

Rev. July 2008

When more than one scanner module exists on a network, it is possible to include devices that are already slaves to one scanner module in another scanner module’ s scanlist as “shared inputs.” Only input data from these devices is consumed by the module and stored in its input area. The following conditions must exist for shared inputs to be enabled in a scanner module: •

More than one scanner module must exist on a network.

•

A scanlist with mapped devices must exist in the scanner module acting as the network master.

•

The scanner module that is to share inputs must support the shared inputs option.


16 -- 14


Remind students that even though more than one scanner can receive device inputs, outputs can be controlled by only one processor and scanner module.

The following graphic shows an RSNetWorx for DeviceNet software Scanlist property page where the shared inputs function has been selected:

Once shared inputs have been enabled for a scanner module, the devices whose inputs the module will be sharing with another scanner module are designated with a special icon, as shown in the following graphic:

Icon Designating a Shared Input




16 -- 15

Even with the shared inputs function enabled, a slave device still can only have one master.

If the Automatic Device Recovery feature has been enabled in a scanner module, the shared inputs function cannot be enabled for that scanner module.

Scanner Module Run Mode A scanner module will not communicate with network devices until it is placed in Run mode. This action must be performed using the scanner module’s command register, which is accessed via the programming software being used to control network devices.

Tip "

A scanner module’s operating mode is reflected in the module’s status register, also accessed via the programming software. A scanner module’s command and status registers can be defined in the following way:

Refer the class to the detailed information about scanner module command registers in the Documentation Reference Guide and point out where the command register is located in a 1747-SDN scanner module.

•

Command Register: The area in a scanner module’s memor y where commands specific to the scanner module are entered. Each bit in the command register executes a unique command. The following bits are examples of commands that can be sent to the scanner module:

------

Tip "

Rev. July 2008

Run/idle Fault network Disable network Halt scanner Reboot/reset scanner

Command register location and format for 1771-SDN, 1747-SDN, and 1756-DNB scanner modules can be found in the documentation reference guide.


16 -- 16


Refer the class to the detailed information about scanner module status registers in the documentation reference guide and point out where the status register is located in a 1747-SDN scanner module.

•

Status Register: The area in a scanner module’ s memory where scanner module status is reflected. Each bit in the status register represents a scanner module mode. The following bits are examples of scanner module modes that can be reflected in the status register:

----------

Tip "

Run/idle Network fault Network disable Device failure Autoverify failure Communications failure Duplicate node address failure DeviceNet power failure (1756-DNB scanner module only) Explicit message program control (1747-SDN scanner module only)

Status register location and format for 1771-SDN, 1747-SDN, and 1756-DNB scanner modules can be found in the documentation reference guide. 1747-SDN Scanner Module Run/Idle Bit

The 1747-SDN scanner module’s Run/Idle bit is bit 0 of output word 0. Turning this bit on (1) places the scanner module in Run mode, and turning it off (0) places the scanner module in Idle mode. The following graphic shows a 1747-SDN scanne r module’s status and command registers in RSLogix 500 software: 1747-SDN Status Register

1747-SDN Command Register

Run/Idle Bit

The following graphic shows a sample ladder logic instruction used to turn on the Run bit in a 1747-SDN scanner module:




Here’s How Perform the following demonstration: 1. Configure one of the scanner modules at your workstation by setting an interscan delay value, a foreground to background poll ratio, and creating a scanlist. 2. Configure the other scanner module at your workstation for slave mode. 3. Demonstrate how to place each scanner module in turn in Run

16 -- 17

To configure a DeviceNet scanner module by performing the following tasks: •


•

Create a scanlist

•


•

Enter ladder logic instructions to place a 1747-SDN scanner module in Run mode


mode.

Rev. July 2008


16 -- 18




Exercise: Configuring a 1747-SDN DeviceNet Scanner Module

16 -- 19

Exercise: Configuring a 1747-SDN DeviceNet Scanner Module Exercise A

In this exercise, you will practice configuring a scanner module by performing the following tasks: •


•

Create a scanlist

•


Context: You need to configure the network’s master scanner, the 1747-SDN module, to define which devices it is to communicate with and how. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 500 software, consult online Help.

Directions: Follow the steps below to configure a 1747-SDN scanner module. 1. Open your network configurati on. 2. Go online to the network. 3. Upload the network configurati on. 4. Configure the PanelV iew Plus scanner module for slave mode with the following properties: • • •

Tip "

Cyclic 4 bytes of input 4 bytes of output

If you receive an error that the processor is in Run mode, press the GoTo Config button on the PanelView Plus. 5. Configure the scanner module, the 1747-SDN, as outlined in the following table: Parameter

Setting

InterscanDelay Foreground to Background Poll Ratio

8milliseconds 2

Slot

Slotlocationofscannermodule

6. Download the device configurat ion to the scanner module. Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. SCNSe100

16 -- 20


7. On the Scanlist tab of the 1747-SDN properties dialog box, verify that the Automap on Add check box is not selected. If it is, clear it. 8. Create a scanlist that includes all the devices on the network.

Tip "

Click OK to the Scanner Configuration Applet dialog box warning that the 1734-ADN Point I/O module contains no I/O data.

Tip "

If prompted, click OK to the Scanner Configura tion Applet dialog box warning that the PanelView Plus operator interface contains no I/O data. 9. Download the device configura tion to the scanner module. 10. Save the network configuratio n.

How Did You Do?


Exercise B

In this exercise, you will practice entering ladder logic instructions to place a scanner module in Run mode.

Context: You have configured the scanner module that is to act as the network master for the DeviceNet network. Y ou now need to write the necessary ladder logic to place scannerorincontroller Run modeand so itnetwork can begin communicatin g with thethe processor devices. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 500 software, consult online Help.

Directions: Follow the steps below to place the scanner module in Run mode. 1. Open exercise file SCNS_N100_B1.rss. 2. In the main routine, enter ladder logic instructions to place the scanner in Run mode. 3. Verify the rung. 4. Download the program to the processor. 5. Change the processor’ s operating mode to Run.


Rev. July 2008 SCNSe100


16 -- 21

6. Verify that the scanner module is in Run mode by accessing the Run bit in the scanner module’s status register and verifying that it is on.

Tip "

RUN

will also be displayed on the front of the scanner module.

7. Change the processor’s operating mode to Program.

How Did You Do?

Rev. July 2008



16 -- 22


Answers

Exercise A 4. If you have correctly configured the PanelView Plus DeviceNet scanner module for slave mode, the Slave Mode dialog box for that scanner module should look like the following graphic:

5. If you have correctly configured the 1747-SDN scanner module that is to act as the network master for your workstation, the Module property page will look like the following graphic:




16 -- 23

8. If you have correctly created a scanlist, the Scanlist property page for the scanner module that is to act as the network master for your workstation will look like the following graphic:

Exercise B 2. If you correctly entered ladder logic instructions to place the 1747-SDN scanner module in Run mode, you should have a

rungRSLogix of ladder500 logic near theprogram beginning the main routine in the software thatofresembles the following graphic:

Rev. July 2008


16 -- 24




Optional Lesson

17

Mapping Inputs and Outputs to a 1747-SDN Scanner on a DeviceNet Network What You Will Learn

After completing this lesson, you should be able to map inputs and outputs on a DeviceNet network by performing the following tasks: •


•


•


•

Identify DeviceN et addresses in an SLC 500 processor

Why These Skills Are Important Mapping is important because the location of inputs and outputs in a processor must be correctly specified in a scanner module for communications to occur between the processor and network devices. Well-organized inputs and outputs in a scanner module can also improve the efficiency of network communica tions and facilitate future maintenance and troubleshooting tasks.

Before You Begin

? Does anyone have experience mapping input and output data? If s o, what have you found to be the most challenging aspect of this task? Since this is often a confusing concept for students, emphasize the fact that inputs and outputs on a DeviceNet network are defined from the point of view of the processor.

Inputs and Outputs To correctly map inputs and outputs, it is important to understand the perspective from which inputs and outputs are defined on a DeviceNet network. The following definitions apply to inputs and outputs on a DeviceNet network: •

Input data is data received by a processor from a device via a scanner module (read).

•

Output data is data sent to a device from a processor via a scanner module (write). Input and output data on a DeviceNet network are defined from the point of view of the processor, not the devices with which it communicates.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. MAPSib100

17 -- 2

Mapping Inputs and Outputs to a 1747-SDN Scanner on a DeviceNet Network

Message Type and I/O Sizes

Do not go into detail about each of these message types now. They will be explained in the ensuing pages.

Tip " If this course is being taught in its standard format (i.e., it is not part of a Tailored Training curriculum), do not go into detail about EDS files; they will be covered in a later lesson.

•

Polled

•

Strobed

•

Change-of-state

•

Cyclic

Not all devices support all message types. The message type(s) that are supported by a given device can be determined by accessing the I/O Data property page, the device’s EDS (electronic data sheet) file, or the data sheets that ship with the device. In addition to the types of messages used by the scanner module, the following message size parameters must be set:

Tip "

Mention that if an output bit is Tip ever configured for a strobed device, it usually contains status data.

Device message type and I/O sizes must be edited to determine the manner in which data will be transmitted to and from a scanner module and how much data will be transmitted. One of the following message types must be specified for each device in a scanner module’s scanlist:

"


•

Input Size: The number of bytes of data being sent from a device to a processor via a scanner module in an I/O message.

•

Output Size: The number of bytes of data that a processor will send to a device via the scanner module in an I/O message.

The range of valid values for input and output sizes differs depending upon the type of message being sent (i.e., strobed, polled, change-of-state, or cyclic). Strobed messages do not have an output size parameter because they are not generally capable of receiving data from a processor via the scanner module.

Rev. July 2008 MAPSib100


17 -- 3

The following graphic shows the RSNetWorx for DeviceNet software window where message type and I/O sizes are edited for a device:

Message Type I/O Sizes

Polled Messages

Polled messages operate on a network in the following manner: 1. A poll rate (the rate at which the scanner module to which a

device is assigned will request data from the device) is configured. Unless the foreground to background poll ratio is set for a longer time interval between scans, poll commands are issued during every scan cycle.

Explain that since poll commands are issued during every scan cycle, configuring a device that seldom has new data to report for polled messaging needlessly slows down network performance.

Rev. July 2008

2. A poll command containing output data is sent from a scanner module to each polled device. 3. Upon receipt of the command, the device transmits a response containing input data.


17 -- 4


The following graphic shows a scanner module communica ting with devices via polled messaging:




Device Response

Device 1

Scanner Module

Scanner Module

Scanner Module

Device 2

Device Response

Device Response

Device 3

Device 1

Device 2

Device 3

Device 1

Device 2

Device 3

Strobed Messages

Strobed messages operate on a network in the following manner: Emphasize that even though both poll and strobe commands are issued during every scan cycle, the difference is that polled devices receive input data and send output strobed data, but, with a do fewnot exceptions, devices receive any output data.

1. A strobe command is transmitted by a scanner module to all devices in its scanlist. 2. Only those devices configure d for strobed messaging respond

with their input data. Strobe commands are issued during every scan cycle.

Tip "


Strobed messages are used for devices that have input data to send to a processor, but do not receive output data from the processor.


17 -- 5


The following graphic shows a scanner module communic ating with devices via strobed messaging: Scanner Module

Scanner Module Strobe Command

Scanner Module Strobe Command Device Response

Device 1

Device2

Device3

Device4

Device Response

Device5

Change-of-State Messages

Devices configured for change-of-state messaging only send data to a scanner module when they have new data to report (i.e., the data has changed since the last time it was sent) or at a user-configured “heartbeat” rate. A scanner module does not solicit data from devices configured for change-of-state messaging (i.e., they are not polled during every scan cycle).

Tip "

? Why do you think a heartbeat rate is necessary if a device only sends information on a change-of-state basis?

Tip "

Answer: Because it allows a scanner module to distinguish between a change-of-state device whose data has not changed and a change-of-state device that has become non-operational.

Tip " Suggest that change-of-state and cyclic messaging should be used whenever they are appropriate to a device’s function on a network, since they are the most efficient forms of messaging. Rev. July 2008

Devices configured for change-of-state messaging can be configured to send a scanner module data at a user-configured “heartbeat” rate regardless of whether or not their data has changed since the last change-of-state message was sent. Devices configured for change-of-state messaging can still receive output data from a scanner module. Cyclic Messages

Cyclic messages are similar to change-of-state messages, but they are sent only at a user-configured rate. Therefore, a cyclic message may be sent by a device even if the device’s data has not changed since the last time it was sent. Both change-of-state and cyclic messages greatly reduce network traffic and allow faster scanner module respons e time since they do not require the scanner module to scan every device during a scan. These types of messages work well for devices with data that does not change often.


17 -- 6


Tip " Note that in the following graphic,which illustrates change-of-state and cyclic messaging, devices send data to a scanner module without a request for data from the scanner module.

Devices configured for cyclic messaging can still receive output data from a scanner module. The following graphic shows a scanner module communica ting with devices via change-of-sta te and a device cyclic messaging: Scanner Module

Device’s Change-of-State Message to Scanner Module

Device 1

Device 2

Device’s Cyclic Message to a Scanner Module

Device 3

Device 4

Device 5

The following table provides an overview of the relationship between a scanner module and devices configured for each of the four message types from the point of view of the scanner module: If a device is configured for this message type . . .


Then the scanner module . . .

And . . .

Polled



Strobe

Does not send data to the device, but does receive data from the device


Change-of-state



Cyclic





17 -- 7

Data Map Plan It’s important to give careful considerat ion to where device input and output data is to be mapped in a scanner module so that no devices overlap each other and space is provided for future additions, if necessary. Planning a configuration before mapping data can help ensure that the following needs are met: Make sure everyone understands what is meant by the term “bandwidth.”

•

Memory and bandwidth are used efficiently.

•

Device-specific needs and requirements are acknowledged.

•

Priority is given to critical I/O transfers.

•

Room is left for expansion.

•

Device data does not overlap.

To ensure that the above considerations are addresse d, you should be familiar with the following variables specific to your network and devices:

Note that data structure of devices will be discussed in detail later in this lesson.

•

Communications requirements

•

Size and importance of the inputs and outputs sent and received by each device

•

Data structure of devices

•

Frequency of the message

•

Plans for the addition of devices or changes to the network

Mapping Explain that the input and output data map in a scanner module is comparable to a road map that helps a processor to find the location of device input and output data in a scanner module.

Rev. July 2008

Mapping is the software function by which device input and output data locations are specified in a scanner module. Mapping enables communications between network devices and a processor to occur by determining the following variables : •

Where discrete input data from devices will be located in a processor

•

Where discrete output data from a processor will be located in a scanner module so that it may be sent to network devices

•

For SLC 500 processors, where input data from devices will be located in the M1 memory area of a scanner module so it can be easily accessed by a processor

•

For SLC 500 processors, where output data from a processor will be located in the M0 memory area of a scanner module so that it can be sent to network devices


17 -- 8


Automatic Mapping

? How would you define data optimization? Answer: The use of each bit of data in the scanner module’s data table (i.e., if one device does not use every bit in one word of data, the next device will begin where the one before it left off). This may not necessarily happen if automatic mapping is used.

Data is often mapped using the automatic mapping feature in RSNetWorx for DeviceNet software. The following facts should be taken into consideration when the automatic mapping feature is used: •

Automatic mapping does not allow much control (i.e., data organization cannot be optimized or consolidated).

•

Automatic mapping does not align input and output data with input and output addresse s in a processor.

•

If all devices on a network are mapped simultaneously using the automatic mapping feature, the software will map devices based on their node addresses. The device with the lowest node address will be assigned to the first available word, and so on.

Verify that students have an understanding of byte, bit, and word lengths. If not, spend a few minutes reviewing these terms.

Even though a device’s node address roughly determines where the device will be automapped, the word to which a device is automapped is not a one-to-one match (i.e., a device with a node address of 2 will not necessarily be automapped to word 2). •

If devices are automatically mapped individually as they are added to a network, the software will assign word numbers based on the order in which the devices are mapped (e.g., the first device will be mapped to word 1, etc.).

•

Future changes (e.g., addition of devices, removal of devices) may not be easily addressed.

Automatic Mapping Options

Mapped data can be organized using the following alignment options:

Point out that since the first two devices mapped in the following graphic both contain only one byte of input data, the pack alignment and byte alignment options line up the data in the same way.


•

Pack Align: Allows data to be mapped on a byte, word, or double-word boundary or to be efficiently grouped without alignment (pack).

•

Byte Align: Ensures that data is used as efficiently as possible to the byte level (two devices can share the same word location).

The following graphic illustrates the pack and byte alignment options in a 1747-SDN scanner module:



•

In the graphic that illustrates the word alignment option, point out that input mapping for each device begins at a new word, even through the individual devices do not all send an entire word of input data.

17 -- 9

Word Align: Ensures that each device is mapped to a unique word.

The following graphic illustrates the word alignment option in a 1747-SDN scanner module:

Manual Mapping

? If you know that in the future you will

Data can also be mapped manually (i.e., a user can specify exactly where a processor should look for device data in a scanner module) using RSNetWorx for DeviceNet software. The following considerations should be taken into account when data is mapped manually:

have a device at node 8, how would you map the current device data?

•

Data can be organized and optimized.

•

Room can be left for future expansion.

Answer: So that that scanner module’s map table is empty at word 8 (or that enough room is left for the device data).

•

Manual mapping can be more time-consuming than automatic mapping.

Tip "

To map data manually, it is necessary to deactivate the automatic mapping feature that is set up in the software by default.

Tip "

A combination of manual and automatic mapping can also be used (i.e., inputs and outputs can be automatically mapped and then fine tuned using the manual mapping feature). Take the following facts into consideration when mapping data manually:

? Why might you configure a device to

•

The type of data transmitted (e.g., status, I/O data, and configuration data) varies with each device.

•

All data sent to devices from a processor (output data) is in byte length (i.e., even if a processor or produces two bits of information, an entire byte will be sent to the device).

•

Data sent by devices to a processor (input data) can be less than one byte.

•

Bits can be mapped to separate memory locations (i.e., map segmentation).

send less than one byte of data to a processor? Answer: If all bits in a byte are not being used, data table space can be conserved by sending only those bits that are used.

Note that map segmentation will be discussed in greater detail later in this lesson.

Rev. July 2008


17 -- 10


Remind students that the Input tab in the following graphic represents the area where inputs from devices to a processor are mapped.

The following graphic shows the RSNetWorx for DeviceNet property page where input data (data sent from devices to a processor) is entered for a 1747-SDN scanne r module: The First Processor Input Word to which Devices Will Be Mapped

The Device Being Mapped

The First Word Word Offset The Scanner Memory Area to which the Device Will Be Mapped The Word Offset

Map Segmentation Mention the 871TM inductive proximity sensor as an example of a device for which map segmentation is useful. Since the sensor’s analog signal is the entire second byte of input data sent by the sensor to a processor, it is easier to access the data in a ladder logic program if the byte containing the analog data is mapped to its own word.


The process of mapping data for a single device to different areas of a scanner module’s memory is called map segmentation. Map segmentation is most often used when it is necessary to isolate bits pertaining to specific functions of a device so they can be easily accessed in the ladder logic program.


17--11


Example: PowerFlex 40 Drive Map Segmentation in a 1747-SDN Scanner Module

A PowerFlex 40 is configured to receive four bytes (two words) of output data from a SLC 500 processor via a 1747-SDN scanner module, as shown in the following graphic of the drive’s sele cted output assembly: Logic Command/Status Words First Output Word

Byte

Bit7

Bit6

Bit5

Bit4

Bit 2

Bit3 Clear Faults

Jog

Bit 1

B it 0

S t a rt

St o p


Second Output Word


The drive’s speed reference is two bytes, or one word.

Since the drive’s speed refere nce is the entire second word of output data, the second output word is mapped to its own word in the 1747-SDN scanner module so that it can be easily accessed in the ladder logic that controls the drive, as shown in the following graphic:

The PowerFlex 40 drive’s output data is mapped to two separate word locations. PowerFlex 40 Logic/Status Word PowerFlex 40 Speed Reference Word

Rev. July 2008


17 -- 12


Address Identification Note that the addresses to which inputs and outputs are mapped in a scanner module are arbitrary as long as the ladder logic to control the devices has not yet been written.

Tip "

Explain that since this is not a programming course, the workstation ladder logic is already provided. Point out that knowledge of bit functions within a device is essential when writing ladder logic to correspond to input and output data maps in RSNetWorx for DeviceNet software.

Being able to identify DeviceN et addresses in a processor is important because the ladder logic to control the devices must use the addresses to which the devices have been mapped. It’s a good idea to document where inputs and outputs have been mapped in a scanner module so their locations can be referenced when ladder logic is written. Addresses are identified by comparing the location where a device is mapped in a scanner module to the corresponding area in the processor that is to control the device. All of the following tools are used to identify addresses: •

The logic programming software for the application (e.g., RSLogix 500 software, RSLogix 5000 software, etc.)

•


•

The device’s documentation manuals

1747-SDN Mapping in RSNetWorx for DeviceNet Software and SLC 500 Addresses in RSLogix 500 Software

DeviceNet data is stored in the following SLC 500 processor files that can be monitored in RSLogix 500 software:


•

Input Data File: Location where discrete input data (data less than 32 words in length going from devices to the processor) is stored.

•

Output Data File: Location where discrete output data (data less than 32 words in length coming from the processor to devices) is stored.

•

Integer Files: User-defined files where data longer than 32 words being transferr ed between 1747-SDN scanner module M files is stored.



Note that input mapping for the 871TM inductive proximity sensor shown below is segmented.

The following graphic shows the relationship between the input data table in a 1747-SDN scanner module and the input data file in the corresponding SLC 500 processor:

Scanner Module Input Table

Inputs from a 871TM inductive proximity sensor are mapped to words 1 and 5 in the 1747-SDN scanner module. (There is one word of input data, and each byte is mapped to a different location.)

Rev. July 2008

17 -- 13

Processor Input Data File

The lower bytes of input words 1 and 5 in the SLC 500 processor reflect the status of the sensor’s inputs.


17 -- 14


The following graphic shows the relationship between the output data table in a 1747-SDN scanner module and the output data file in the corresponding SLC 500 processor: Scanner Module Output Table

Outputs from the E3 overload relay are mapped to the lower byte of word 1 in the 1747-SDN scanner module.


Processor Output Data File

The lower byte of output word 1 in the SLC 500 processor reflects the status of the E3 overload relay.



17 -- 15

When discussing the following graphic, The following graphic shows the relationship between M1 file data stress that since PanelView data is mapped in a 1747-SDN scanner module and the integer file in an mapped to an M file in the 1747-SDN SLC 500 processor where the data resides: scanner module, ladder logic must be used to move the data from the M file to an integer file in the SLC 500 processor. Rung to Copy M1 File Data to an SLC 500 Integer File

Scanner Module Output Table

Rev. July 2008

SLC 500 Integer File


17 -- 16


Device Data Structure Explain that, even if it is known that inputs for an operator interface are mapped to input word one in a processor, it is necessary to determine which of those bits represents the “start” button.

Knowledge of a device’s data structure is necessary to properly identify Device Net addresses in a processor or because even if the general address location of a device is known, ladder logic cannot be written to properly control the device without specific information about individual bit function. The data structure of a device can be determined using any one of the following resources:

If this course is being taught in its standard format (i.e., it is not a part of a Tailored Training curriculum), do not explain EDS files in detail; they will be addressed in the Managing EDS Files lesson.

•

The I/O Data property page for the device (called the I/O Defaults property page for some devices)

•

The device’s EDS file (which can be accessed using the EDS File property page)

•

Documentation that ships with the device

•

The RSNetWorx for DeviceNet software Help system

Example: Data Structure of an ArmorBlock MaXum Input Module Point out that the data structure information in the following example was accessed using the I/O Defaults property page in RSNetWorx for DeviceNet software.

The data structure of an ArmorBlock MaXum 4 input module configured for change-of-state messaging is shown in the following graphic: Input Data Byte 1 Bit 7

ArmorBlock 4 Input Module

Bit 0

Circuit Detection for Connectors A-D

Inputs 0- 3


Bit 0

Unused


Offwire Detection for Connectors A-D



? How would the information about the

17 -- 17

When configured for change-of-state messaging, the ArmorBlock MaXum 4 input module sends 2 bytes of input data and does not send any output data. The first byte of input data sent contains the following bits:

data structure of the ArmorBlock MaXum I/O module in this example help when mapping inputs and outputs? Possible Answer: Scanner module space could be conserved by only mapping those bytes that are essential to the module’s operation in a specific application.

• • • • • • • •

Bit 0 is an input bit corresponding to input 0. Bit 1 is an input bit corresponding to input 1. Bit 2 is an input bit corresponding to input 2. Bit 3 is an input bit corresponding to input 3. Bit 4 indicates a input short circuit for connector A. Bit 5 indicates a input short circuit for connector B. Bit 6 indicates an off wire fault for connector C. Bit 7 indicates an off wire fault for connector D.

The second byte of input data contains the following bits: • • • • •

Here’s How Perform the following demonstration:

Bit 0 is an offwire detection bit corresponding to connector A. Bit 1 is an offwire detection bit corresponding to connector B. Bit 2 is an offwire detection bit corresponding to connector C. Bit 3 is an offwire detection bit corresponding to connector D. Bits 4 to 7 are not used.

To map device inputs and outputs on a DeviceNet network by performing the following tasks:

1. Using the 1747-SDN scanner module, edit the message type and I/O sizes for any device on your

•


•


workstation. 2. Map data automatically for the device, then unmap it and map again manually.

•


Rev. July 2008



17 -- 18


Here’s How Perform the following demonstration: 1. Access the I/O data structure for the 871TM sensor in the Online Help system and point out the sensor’s output bit.

To identify DeviceNet addresses in an SLC 500 processor. As your instructor demonstrates this procedure, refer to the following example:

2. Based on the input data table for the sensor in RSNetWorx software, point out the bit in the SLC 500 processor’s input data file that should be affected if an object is placed in front of the photoelectric sensor. 3. Test this conclusion by touching the sensor to a metal object and monitoring the appropriate bit in the RSLogix 500 input data table.

Example

DeviceNet Address Identification Step 1: Identify RSNetWorx for DeviceNet Input Data Map

The following graphic shows RSNetWorx for DeviceNet software input maps for an 871TM inductive proximity sensor in the scanlists of a 1747-SDN scanner module: 1747-SDN Input Data Map

Sensor Inputs (Two Bytes or One Word Mapped to Two Separate Locations)

In the example, the input data table in RSNetWorx for DeviceNet software is used to determine in the 1747-SDN scanner module, a total of one sensor input word is mapped to two separate locations -one byte of data is mapped to the lower byte of word 1, and one byte of data is mapped to the lower byte of word 5.




17 -- 19

Step 2: Identify RSLogix 500 Input Data File or RSLogix 5000 Input Tags Point out that since the two bytes of input data coming from the 871TM inductive proximity sensor were mapped to two separate words in the 1747-SDN scanner module, this input data is showing up in two separate words in the RSLogix 500 input data file.

The following graphic shows the RSLogix 500 software input data file associated with the 1747-SDN scanne r module: RSLogix 500 Input Data File

Sensor Inputs

In the example, input data from the 871TM inductive proximity sensor is traced to the areas in the SLC 500 processor based on input data mapping in RSNetWorx for DeviceNet software. Step 3: Identify Device Data Structure

The following graphic shows the data structure of the 871TM inductive proximity sensor used to determine the function of each input bit mapped for the sensor:

In the example above, the RSNetW orx for DeviceNet online Help system is used to determine the function of individual input bits mapped for the 871TM inductive proximity sensor in RSNetWorx for DeviceNet software.

Tip "

Rev. July 2008

Access the online Help topic list by selecting Contents from the Help menu in the main RSNetWorx for DeviceNet software window.


17 -- 20




Exercise: Mapping Inputs and Outputs to a 1747-SDN on a DeviceNet Network

17 -- 21

Exercise: Mapping Inputs and Outputs to a 1747-SDN on a DeviceNet Network Exercise A

In this exercise, you will practice mapping inputs and outputs on a DeviceNet network by performing the following tasks: •


•


•


Context: You are now ready to map the device input and output data for your DeviceNet network to define how the devices on your network will communicate with the processor or controller. You have received specifications on where the devices should be mapped so that ladder logic to control the production line could be written accordingly. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: Follow the steps below to map device inputs and outputs: 1. Open a new network configuration . 2. Go online to the subnetwork of the 1734-ADN module:

1734-ADN Subnetwork

3. Upload the network configurati on.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. MAPSe100

17 -- 22


4. Access the Scanner Module window for the 1734-ADN Point I/O scanner module. 5. Automatically map device input and output data for all Point I/O nodes on the 1734-ADN scanner’ s (node 00) subnetwork. 6. Save the network configuration as ADN_Subnet.dnt. 7. Close the ADN_Subnet configuration. 8. Open a new network configuration . 9. Go online to the main network. 10. Upload the network configuratio n. 11. Access the properties of the 1734-ADN Point I/O adapter and associate the ADN_Subnet.dnt file you created with the adapter. 12. Access the PanelView Plus properties dialog box. 13. Automatically map device input and output data on the Input and Output tabs of the PanelView Plus properties dialog box. 14. Access the Scanner Module window for the scanner module that is acting as the master for your network, the 1747-SDN module. 15. Edit device message type and I/O sizes as outlined in the following table: Device

Absolute multi--turn

Message Type

Input Size

Strobed

Output Size

4

N/A

Encoder


E3overloadrelay 1734-ADN Point I/O adapter PowerFlex40Drive


Strobed " Be sure to deselect the default message type (change-of-state) Polled

2

8

Change-of-state (250 ms Heartbeat) Polled

N/A

1 8

4

5 4


Change-of-state (250 ms Heartbeat)

2

0

PanelView Plus operator interface

Cyclic Heartbeat rate (Sendrate 1000ms)

4

4

Rev. July 2008 MAPSe100

17 -- 23


PanelView Plus I/O sizes must also be configured at the device itself using RSView Studio software. I/O sizes have already been configured for you at the PanelView Plus terminal.

16. Download the device configurat ion to the scanner module. 17. Manually map device input and output data in the 1747-SDN scanner module as outlined in the following table: Device

Input Data Mapping • Assembly



Output Data Mapping

Data N/A

0



• Bit:

0 • Number of bits: 16 • Assembly

E3 overload relay

1734-ADN Point I/O adapter module

PowerFlex 40 drive

Data

N/A • Assembly

• DWord: 2

• DWord: 2

• Bit:


• Bit:

• Assembly

• Assembly

Data

• DWord: 4

• Bit:

• Bit:

0

Data


• DWord: 4

Data

0





• Assembly


Data

• DWord: 1

Data


N/A

0



Data

• DWord: 9

• Bit:

• Bit:

0


Rev. July 2008

• Assembly

• DWord: 9

Data

0



17 -- 24


18. Download the device configura tion to the scanner module. 19. Save the network configuratio n.

How Did You Do?


Exercise B

In this exercise, you will practice identifying DeviceNet address es in an SLC 500 processor.

Context: You have mapped input and output data in the 1747-SDN scanner module acting as the master on the DeviceNet network. You now need to identify DeviceN et addresses is the corresponding SLC 500 processor so that ladder logic to control these devices can be written accordingly. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "

For help performing steps in RSLogix 500 software, consult the online Help.

Directions: Using RSNetWorx for DeviceNet and RSLogix 500 software, identify DeviceN et addresses in the SLC 500 processor and answer the following questions: 1. Change the processor’ s operating mode to Run. 1. Open your network configuratio n. 2. Go online to the network . 3. Identify the input address(es) where the analog values from the 871TM inductive proximity sensor should show up in the Input data file of the SLC 500 processor:

Tip "


Use either the EDS file for the 871TM inductive proximity sensor or the 1747-SDN properties dialog box to determine the sensor’s data structure:



Tip "

17 -- 25

Remember that the 871TM inductive proximity sensor has been configured for strobed messaging, which is not the default message type supported by the sensor. 4. Test your conclusion by performing the following actions: A. Start RSLogix 500 software. B. Go online to the SLC 500 processor at your workstation. C. Change the processor’ s operating mode to Run. D. Monitor the processor’s Input data file while moving a metal target (such as a key or coin) towards and away from the 871TM inductive proximity sensor . The bits at the addresses you identified in Step 3. should turn on as the target moves towards the sensor.

Tip "

For help going online to the SLC 500 processor, changing the processor’s operating mode, and monitoring the processor’s data files, refer to the Start pages or online Help . 5. Identify the input address where pushbutton DI0 (wired to to input point 0 on the first input sink of the 1734-ADN Point I/O adapter) on the workstation should show up in the Input data file of the SLC 500 processor:

6. Test your conclusion by performing the following actions: A. Press the DI0 pushbutton on workstation to start the motor while monitoring input tag values in the processor’s input data file. The bit that goes on when this button is pressed should be the bit that was identified in Step 5. B. Press the DI1 pushbutton to stop the motor. 7. Identify the address of the third ArmorBlock input bit:

8. Test your conclusion by pressing pushbutton IN2 on the workstation while monitoring input tag values in the processor’s input data file. The bit that goes on when this button is pressed should be the bit that was indentified in Step 7. 9. Close the Input data file. 10. Identify the output address that reflects the status of the PowerFlex 40 drive’s Start bit:

Rev. July 2008


17 -- 26


Tip "

Use the PowerFlex 40 Drive Data Structure appendix to determine the data structure of the PowerFlex 40 drive. Data structure information for the drive is located in the user manual of the drive’s DeviceNet communications module, not the drive’s EDS file. 11. Test your conclusion by performing the following actions: A. Press the DI0 pushbutton on the workstation to start the motor in workstation. B. Monitor output tag values in the Output data file of the processor. The bit identified in Step 10. should be on. C. Press the DI1 pushbutton on the workstation to stop the motor. 12. Close the output data file. 13. Change the SLC 500 processor’s operating mode to Program. 14. Minimize RSLogix 500 software. 15. Close RSNetWorx for DeviceNet software.

How Did You Do?





Rev. July 2008

17 -- 27


17 -- 28


Answers

Exercise A 5. On the Scanlist tab of the 1734-ADN Point I/O scanner module’s scanner window make sure Automap is selected and move all Point I/O nodes to the scanlist:

Add All

Automap

11. You should have accessed the Device Bridging tab of the

1734-ADN Point I/O adapter’s propertie s page and associated the ADN_Subnet.dnt file with module:




17 -- 29

13. The input and output tabs of the PanelView Plus properties window should look similar to the following:

15. If you have correctly edited input and output parameters for the E3 overload relay, the Edit I/O Parameters window for the E3 overload relay will look like the following graphic:

Rev. July 2008


17 -- 30


If you have correctly edited input and output parameters for the Absolute Multi-Turn Encoder, the Edit I/O Parameters window for the RightSight photoelectric sensor will look like the following graphic:

If you have correctly edited input and output parameters for the PowerFlex 40 drive, the Edit I/O Parameters window for the PowerFlex 40 drive will look like the following graphic:




17 -- 31

If you have correctly edited input and output parameters for the 871TM inductive proximity sensor, the Edit I/O Parameters window for the 871TM inductive proximity sensor will look like the following graphic:

If you have correctly edited input and output parameters for the 1734-ADN Point I/O adapter, the Edit I/O Parameters window for the 1734-ADN Point I/O adapter will look like the following graphic:

Rev. July 2008


17 -- 32


If you have correctly edited input and output parameters for the ArmorBlock MaXum input module, the Edit I/O Parameters window for the ArmorBlock MaXum input module will look like the following graphic:

If you have correctly edited input and output parameters for the PanelView Plus operator interface, the Edit I/O Parameters window for the PanelView Plus operator interface will look like the following graphic:




17 -- 33

17. If you have correctly entered input data manually, the input data table for the 1747-SDN scanner module will look like the following graphics:

If you have correctly entered output data manually, the output data table for the 1747-SDN scanner module will look like the following graphics:

Rev. July 2008


17 -- 34


Exercise B 3. The input address(es) where the analog values from the 871TM inductive proximity sensor should show up in the input data file of the SLC 500 processor are bits 8--15 of input word 3 (I:1.3, bits 8 to 15). The second input byte the sensor sends contains its analog value and, in the 1747-SDN scanner module, this byte is mapped to input word 3, bits 8 to 15. 5. The address bit for pushbutton DI0 should show up in the processor’s input file at input word 9, bit 0 (I:1.9. 0). In the

1747-SDN scanner module, the input map for the 1734-ADN Point I/O adapter begins at word 8, bit 0. The first 16 bits are read-only data. Therefore, the the adapter’s first input is located at word 9, bit 0. 7. The address of the third ArmorBlock input bit is input word 14, bit 2 (I:1.14.2). When the ArmorBlock input module is configured for change-of-state messaging, the first input bit in its data structure controls the first ArmorBlock input connection. In the 1747-SDN scanne r module, the module’s input map begins at word 14, bit 0. Therefore, this is the bit that corresponds to the ArmorBlock module’ s third input. 10. The output address that reflects the status of the PowerFlex 40 drive’s Start bit when the drive is output word 12, bit 0 (O:1.12.0). The drive’s Start bit is the second output bit (bit 0) received by the drive from the processor. In the 1747-SDN scanner module, the output map for the PowerFlex 40 drive begins at word 12, bit 0. Therefore, the drive’s Start bit is located at output word 12, bit 0.



Optional Lesson

18

Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform What You Will Learn

After completing this lesson, you should be able to communicate on a DeviceNet network using explicit messaging by performing the following tasks: •

Identify class, instance, attribute, and service codes

•

Format an explicit message using an SLC 500 processor

Why These Skills Are Important

? Are any of you currently using explicit messaging in your plant? If so, what kind of function is it performing? What devices are involved?

Before You Begin If this lesson is being taught as part of a standard school (i.e., it is not part of a Tailored Training curriculum), point out that the action of monitoring device parameters in the lesson on device configuration was actually a form of explicit messaging, because specific data (i.e., the status of an output, operating mode, etc.) was being requested from and returned by the devices.

? If the scanner module LED already displays the numbers of faulted nodes, why would you want to send a faulted device an explicit message requesting fault information?

Explicit messaging is important because it is a means to transfer very specific device data, such parameter values , that is not available via polled, strobed, change-of- state, or cyclic I/O messaging. In some cases, such as when no EDS (electronic data sheet) file is available, explicit messaging is the only way to configure a device.

Explicit Messaging Explicit messagin g is a method of transmitting commands, responses to commands, requests for data, and responses requests on DeviceNet network. Explicit messaging is usedtotodata accomplish thea following tasks: •

Obtain device data when no EDS file exists

•

Make automatic runtime adjustments to device parameter s according to changes detecte d by a processor

•

Send configuration data to a device

•

Retrieve detailed status and diagnostic information from a device

A device communicating using explicit messaging falls into one of the following categories: •

Explicit Client: The device from which an explicit message request srcinates. In an explicit message between a processor and a device, the processor is always the explicit client.

•

Explicit Server: The device from which an explicit response is being requested. In an explicit message between a processor and a

Answer: To find out the exact nature of the fault.

device, the device is always the explicit server . In an explicit message between two devices, either device can be the explicit server.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. EXPSib100

18 -- 2

Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform

Explicit Messaging vs. I/O Messaging An explicit message differs from a standard I/O message sent on a DeviceNet network in the following ways:

? Why do you think that explicit messages have a lower priority than I/O messages on a DeviceNet network? Answer: Because they are meant to transfer non-time critical data.

ExplicitMessage

Contains specific information describing nature of data being requested Requires a response Has a low priority on a DeviceNet network

I/OMessage

Contains limited device data Does not require a response Has a high priority on a DeviceNet network

The DeviceNet Object Model The object model is comprised of various entities that describe specific aspects of a DeviceNet product. Each of these entities addresses increasingly more specific variables of the product and is represented by a numeric or hexadecimal value. These values make up the body of an explicit message. The DeviceNet object model is made up of the following major entities: •

Object

•

Class

T4:10.ACC:

•

Instance

S

•

Attribute

Use the following PLC-based analogy to help students understand the concepts of class, instance, and attribute:

S S

“T4” is class “10” is instance “ACC” is attribute.

Note that an object corresponds roughly to a PLC-5 data table element. The main difference is that an object has a defined behavior as well as a defined data structure.


•

Service

Object

Object is a general term that describes some function of a DeviceNet product. An object is made up of the following entities: •

Attributes: Information about variable portions of an object (i.e., data elements that can be written to or read from).

•

Services: Functions that an object performs upon request (i.e., getting an attribute, setting an attribute, etc.).

•

Behaviors: The manner in which an object responds to events that it recognizes (e.g., receiving service requests, detecting internal faults, etc.).

•

Connections: Application connections supported by the object.

Rev. July 2008 EXPSib100


18 -- 3

The following list includes example s of DeviceNet objects: •

Device/identity object

•

Connection object

•

Message router object

•

Timer events object

•

Wall clock time object

•

Parameter object

Class Note that class corresponds roughly to a file in a PLC or SLC processor. For example, the “counters” class could be said to consist of the C5 file and the behavior of the CTU, CTD, and RES instructions.

Class is the most general category in the DeviceNet object model. A class is a subset of objects that behave in a similar way but contain different data in their respective variables. By this definition, several objects containing common character istics can fall into one class. Each object class has a unique hexadecima l identifier called a class code. The following table lists a few examples of DeviceNet object classe s for a PowerFlex 40 drive: Class

Object

01

Identity

05

Connection

0F

ParameteTr able

Instance Continuing with the counter example, note that instances would be C5:1 and C5:42.

Rev. July 2008

An instance is a specific occurrence of a given object. Since there can be several occurrences of the same object within a model, each instance is designated by a numeric value.


18 -- 4


Attribute

An attribute is one of many possible data elements in a given DeviceNet object or class that can be written to or read from in an explicit message. Each attribute is assigned a unique numeric ID. The following table lists examples of attributes and their respective numeric IDs supported by the class 0F Parameter T able object for a PowerFlex 40 drive: Class 0F Instance Table AttributeID

AttributeName

1

Tip "

OutpuFt requency

2

CommandedFrequency

3

OutpuCt urrent

4

OutpuVt oltage

5

DCBuV s oltage

Note that each of the attributes listed in the table is actually a parameter in the drive. Not all attributes are parameters , but parameters are some of the most common attributes that explicit messaging is used to access.

Note that the actions of getting and setting attributes are commonly used services. Getting an attribute is simply the action of requesting the value of an object variable; setting an attribute is the

Service

action of sending a new value to an object variable.

object. Each service is assigned a hexadecimal code called a service code.

Cite examples of attributes that are commonly sent to (“set”) and retrieved from (“get”) DeviceNet objects:

S

Input and output values

S

Operating mode

S

Angle (limit switches)

S

Speed reference (drives)


A service refers to a function that an object performs as the result of an explicit request. Services that are supported vary from object to

The following table lists a few of the most common services supported by the PowerFlex 40 drive: ServiceName

ServiceCode

Example

Get_Attribute_Single

0E hex

Upload a single parameter value from a device

Set_Attribute_Single

10 hex

Download a single parameter value to a device



Remind students that though the following graphic shows only instance attributes, there are also attributes that apply to all objects in the same class.

18 -- 5

The following graphic shows the basic structure of the DeviceNet object model:

Class

Object A Instance 1

Attribute Attribute

Attribute

Object A Object A Instance 2

Attribute Attribute

Object B Instance 1

Attribute Attribute

Attribute Attribute

Attribute

Object B Object B Instance 2

Rev. July 2008

Attribute Attribute

Attribute Attribute


18 -- 6


Point out that the following graphic only uses PLC-based terms to illustrate the concepts of class, instance, and attribute. The examples given are not true Class classes, instances, or attributes. (Counters)

The following graphic shows the basic structure of the DeviceNet object model using a PLC-based analogy to illustrate key concepts:

Attribute (DN) Instance 1 (C5:0)

Attribute (PRE)

Attribute (ACC)

Object Attribute (DN) Attribute (PRE)

Attribute (ACC)

Instance (C5:1) 2




Point out that the following graphic only shows two of fourteen instance attributes supported by each of the Connection objects in the PowerFlex 40 drive.

18 -- 7

The following graphic shows the basic structure of the DeviceNet object model as applied to the class 0F Parameter Table object of the PowerFlex 40 drive:

Class 0F

Attribute 1 (Output Frequency) Instance 1

Attribute 2 (Commanded Frequency) Attribute 3 (Output Current) Attribute 4 (Output Voltage)

Parameter Table Object

Rev. July 2008

Attribute 5 (Bus Voltage)


18 -- 8


Class, Instance, Attribute, and Service Code Lookup Knowledge of specific class, instance, attribute, and service codes is necessary to format an explicit message. The class, instance, and attribute codes supported by Rockwell Automation devices can generally be found using one or both of the following resources:

Note that in all Rockwell Automation EDS files, the intervening numbers (20, 24, and 30) in the class, instance, and attribute sequence are “spacers” and are not part of the class, instance, and attribute data. Parameter Number

•

A device’s user manual (usually Appendix B)

•

A device’s EDS file

The following graphic shows the portion of the EDS file for the PowerFlex 40 drive that contains class, instance, needed to access parameter 29 (Torque Current):and attribute data Instance Code

Class Code Parameter Name Attribute Code

The service code needed to format an explicit message must be accessed using documentation manuals. Service codes are generally listed in table format in Appendix B of the device’s user manual.

Explicit Messaging Types Explicit messages can take place in one of the following ways: Do not go into detail about peer-to-peer explicit message connections now, as this will be covered later in the lesson.

•

Between a processor, scanner module, and devices

•

Directly between devices (peer-to-peer)

Explicit Messaging Using an SLC 500 Processor and a 1747-SDN Scanner Module

? Ask if anyone remembers at which word the explicit messaging data starts. Answer: Word 224.

Ladder logic is used in an SLC 500 processor to send explicit messages between devices. As with standard I/O messaging, a 1747-SDN scanner module acts as the interface between devices and a processor. Explicit messaging occurs on a DeviceNet network with an SLC 500 processor and 1747-SDN scanner module in the following manner: 1. data An explicit message transaction block is formatted in an SLC 500 file using RSLogix 500 t software.

Review M file function: The M0 file stores data sent from a processor to devices; the M1 file is where data being sent from devices to a processor is stored. E 2008 Rockwell Automation, Inc. All rights reserved.

2. A COP (copy) instruction is written to copy the explicit message transaction block from the processor data file to words 224 to 256 of the M0 file in the scanner module. Rev. July 2008 EXPSib100


Tip "

18 -- 9

The minimum and maximum data sizes for an explicit messag e request are 6 and 32 words, respectively. The following graphic shows an example of a COP instruction in RSLogix 500 software used to copy data from a data file in an SLC 500 processor to the explicit messaging area of the M0 file in a 1747-SDN scanne r module:

Data File M0 File

3. The explicit message request is obtained from words 224 to 256 of the scanner module’s M0 file by the device from which a response is being requested. 4. The device sends its response to the M1 file in the scanner module.

? Why do you think bit 15 in a scanner module’s status register is important? Answer : Since thedirectly scanner cannot send data to module a processor, without this mechanism, the processor would not know that a response has been received from a device.

5. When the scanner module receives the device’s response, bit 15 in its status register turns on, indicating to the processor that a

response has been sent by the device. 6. The device’s response is copied from words 224 to 256 of the scanner module’s M1 file into a data file in the processor via a COP instruction in the ladder logic. The following graphic shows an example of a COP instruction in RSLogix 500 software used to copy data from the explicit messaging area in the M1 file of a 1747-SDN scanner module to a data file in an SLC 500 processor:

M1 File Data File

7. A COP or MOV (move) instruction copies a word from a data file in the processor to word 224 of the M0 file in the scanner with a command to clear out the response buffer in the scanner module. Rev. July 2008


18 -- 10


8. When the command is received by the scanner module, bit 15 of the module’s status register turns off, indicating that the explicit message transaction has been completed.

Explicit Message Transaction Blocks in SLC 500 Data Files Note that, unlike an MSG instruction in RSLogix 5000 software, there is no single instruction in RSLogix 500 software that “automatically” formats an explicit message. Therefore, a few additional steps are required when configuring explicit messages on an SLC 500 platform.

SLC 500 data files must be specifically formatted for explicit messaging using explicit message transa ction blocks. An explicit message transaction block can either be a request for data from a device or the device’s subsequent response. An explicit message transaction block consists of the following elements: •

Transaction header

Compare the transaction header and body components of an explicit message transaction block to an addressed envelope containing a letter sent by mail: the transaction header is the name and address; the transaction body is the content of the envelope.

•

Transaction body

Transaction Header

The transaction header is the part of an explicit message that contains code identifying the nature and sender of the message. The transaction header is made up of three words (words 224, 225, and 226 in the M files of a 1747-SDN scanner module), which are divided into the following byte offsets: •

Tip " Refer students to the page in the documentation reference guide that contains examples of command and status codes.

Transaction ID (TXID): The upper byte of word 224. The scanner module uses the transaction ID to track the transaction to completion and returns the srcinal value of the transaction ID with the response that matches the original request. The transaction ID number is increased with every new explicit message that is sent.

The term “upper byte” refers to bits 8 to 15 of a word. •

Command: The lower byte of word 224 in an explicit message request transaction block. The command code tells the 1747-SDN scanner module what to do with the transaction block being sent (e.g., execute the transaction block, delete the transaction from the response queue, ignore the transaction block, etc.).

Tip "

The command codes supported by DeviceNet scanner modules can be found in the documentation reference guide.

Tip "

The term “lower byte” refers to bits 0 to 7 of a word. •

Status: The lower byte of word 224 in an explicit message response transaction block. The status code provides the

processor with status information about the device and its response (e.g., transaction successful, transaction still in progress, error, etc.).

Tip " E 2008 Rockwell Automation, Inc. All rights reserved.

The status codes supported by DeviceNet scanner modules can be found in the Documentation Referenc e Guide. Rev. July 2008 EXPSib100


•

Tip " Stress that when determining the size of an explicit message transaction body, only the number of bytes in the class, instance, attribute, and data segments is counted.

"

Port: The upper byte of word 225. The port number in the transaction header indicates the channel through which the explicit message is to be routed.

In an SLC 500 processor, only channel 0 is used. •

Size: The lower byte of word 225. The size indicates the length in bytes of the body of the explicit message.

•

Service Code: The upper byte of word 226. The service code indicates the action that is to be performed as a result of the explicit message (typicall y “getting” or “setting” an attribute).

Refer students to the page in the documentation reference where service names andguide codes Tip are listed.

18--11

The service codes supported by DeviceNet scanner modules can be found in the Documentation Referen ce Guide. •

MAC (Media Access Control) ID: The lower byte of word 226. The MAC ID signifies the node address of the device to which the explicit message is being sent.

Transaction Body

The transaction body contains the actual explicit message data. In an explicit request, this includes the DeviceNet class, instance, and attribute information, as well as the data to be sent or retrieved. In an explicit respons e, the transaction body data contains only the response message. Example: Explicit Message Format for an SLC 500 Platform

The following graphic shows an SLC 500 data file in RSLogix 500 software that contains an explicit messag e transaction block:

Transaction ID

Command Size Service

MAC ID Class

Transaction Header

Rev. July 2008

Instance Attribute

Data

Transaction Body


18 -- 12


The following list summarizes all of the information contained in this transaction block:

Direct students to look up the meanings of the command and service codes used in this explicit message in the documentation reference guide.

• • •

Emphasize that size pertains to the number of bytes in the transaction body only, not the entire transaction block. In the example, the size is 6 because there are two bytes apiece for class, and attribute, and a “0” for datainstance, (because a value is being requested, not sent).

Tip "

• • •

The transaction block is an explicit request (service). The value of an acceleration time parameter is being requested (class and attribute). The value of the first occurrence of the acceleration time parameter attribute is being requested (instance). The acceleration time parameter is being requested from the device at node 9 (MAC ID). The explicit request size is 6 bytes (size). The explicit request is being routed through channel 0.

Since the port (channel) through which the message is routed is 0, this value is not displayed. It would normally be visible to the left of the data size value.

Peer-to-Peer Explicit Messaging

? What might be one reason for establishing a peer-to-peer explicit message connection between devices on a DeviceNet network? Possible Answer: To enable faster transfer of time-critical data through the scanner module by decreasing the number of devices with which the scanner module must communicate.

Peer-to-peer explicit messaging is accomplished via a direct connection between two devices without the use of a scanner module as an intermediary. UCMM (Unconnected Message Manager) Capability

To communicate using a peer-to-peer explicit message connection, both devices must be UCMM-capable. UCMM connectivit y is a feature that enables a device to communicate with another UCMM-capable device on a DeviceNet network without the need for a scanner module. The following list includes examples of Allen-Bradley devices that are UCMM-capable:


•

PanelView operator interface

•

Flex I/O

•

POINT I/O

•

MicroLogix adapter

•

Scanport adapter

•

1398 ULTRA 10 servo drive

•

Bulletin 150 SMC AC dialog plus

•

1305 AC drive

•

1336 AC drive

•

1557 Medium Voltage drive

•

Powermonitor II


18 -- 13


Tip "

Not all DeviceNet-compatible devices are UCMM-capable. To find out if a device is UCMM capable, acces s its DeviceNet Statement of Compliance, which is normally located in Appendix B of the device’s user manual. Method of Configuration

The manner in which a device is configured for peer-to-peer explicit messaging differs depending upon the device. However, the following basic steps are generally followed: Ask a student to review theand meanings the terms “explicit server” “explicitof client.”

1. One device is designated the explicit server and the other device is designated the explicit client. 2. Class, instance, and attribute codes are used to specify the data that is to be read or written. 3. The size and location of the data to be read or written is specified. Example: PanelView Peer-to-Peer Explicit Message Configuration

The following graphic shows the PanelBuilder software window where peer-to-peer explicit messaging is configured:

PanelView Operator Interface Function (Explicit Client)

Class, Instance, and Attribute Codes

Explicit Server Node Address Location and Size of Data

Rev. July 2008


18 -- 14


In the example above, the following elements required for the PanelView operator interface to communicate using peer-to-peer explicit messaging are specified: • • • •

The function of the PanelView operator interface (either explicit server or explicit client) The node address of the device with which the PanelView operator interface is to communicate (explicit server) The location and size of the data to be exchanged The class, instance, and attribute codes that specify the data to be exchanged. The configuration shown in the example above applies only to the PanelView operator interface. Though the main elements needed to configure a peer-to-peer explicit message are similar, the method of configuration varies from device to device.

Here’s How Perform the following demonstration: 1. Identify the class, instance, attribute, service, and command codes needed to change the operating mode of the E3 overload relay sensor.

" Use the E3 overload relay’s EDS file to identify the necessary class, instance, and attribute codes, and the documentation reference guide to identify the command and service codes.

To communicate on a DeviceNet network using explicit messaging by performing the following tasks: •

Identify class, instance, and attribute codes

•

Format an explicit message in an SLC 500 processor


2. Format an explicit message in RSLogix 500 software to change the operating mode of the E3 overload relay. 3. Format an explicit message in RSLogix 500 software to change the operating mode of the 871TM inductive proximity sensor.



18 -- 15

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform

Exercise: Communicating on a DeviceNet Network Using Explicit Messaging with the SLC 500 Platform Exercise A

In this exercise, you will practice communic ating on a DeviceNet network using explicit messaging.

Context: You have completed all of the essential configuration tasks for the DeviceNet network and the network is operational. However, you would like to use explicit messaging to enable the count up function of the 871TM inductive proximity sensor using an input from the PanelView Plus operator interface instead of having to reconfigure this parameter in RSNetWorx for DeviceNet software every time the count up function is needed. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "


Directions: Perform the steps below and answer the following questions : 1. Open your network configurati on. 2. Identify the class, instance, and attribute codes needed to write to the 871TM inductive proximity sensor parameter listed in the following table: Device Variable or Parameter

Class Code

Instance Code

Attribute Code


Tip "

Use the 871TM inductive proximity sensor’ s EDS file to determine class, instance, and attribute codes. 3. Identify the service code that is used to set a single attribute:

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. EXPSe100

18 -- 16


4. Identify the command code used to execute an explicit message transaction block:

Tip "

Refer to the Documentation Referenc e Guide for service and command codes. 5. Open exercise file EXPS_N100_A1.rss. 6. Verify that the processor is offline or go offline. 7. Open data file N20. 8. Change the radix to Hex/BCD. 9. Format an explicit message in the SLC processor’s data file N20:10 to enable the Counter parameter (parameter 15) in the 871TM inductive proximity sensor. (First write the necessary values in the table below, then transfer them to N20:10): BlockSegment

Value

Text ID Command Port Size Service MAC ID Object Instance Attribute Data

Tip "

Be sure to enter all data, including the node address of the target device (the 871TM inductive proximity sensor) in hexadecimal format.

Tip "

Use the Decimal to Hexadecimal Conversion Table appendix for help converting the node address of of the target device (the 871TM inductive proximity sensor) to hexadecimal code.

Tip "

Use the Documentation Reference Guide to determine command and service codes. 10. Format an explicit message in the SLC 500 processor’s data file N20:0 to clear the scanner module’s response buffer after a successful explicit message. (First write the necessary values in the table below, then transfer them to N20:0): BlockSegment

Value

Text ID Command E 2008 Rockwell Automation, Inc. All rights reserved.

Rev. July 2008 EXPSe100


18 -- 17

11. Which rung of ladder logic sends the explicit message to enable the 871TM sensor’s Up Counter Enabled parameter from N20:10 to the sensor?

12. An input from which device triggers the message?

13. In rung 006, what condition triggers the transfer of data from the 871TM inductive proximity sensor back to the SLC 500 processor?

14. In rung 006, what condition triggers the clearing of the scanner module’s explicit message response buffer?

15. Download the program to the SLC 500 processor. 16. Change the processor’ s operating mode to Run. 17. Test the explicit message by performing the following actions: A. Select Run Application on the PanelView Plus terminal. B. PanelView Navigate to Plus the 871TM Proximity Sensor screen on the terminal. C. Touch the Enable Counter pushbutton and hold for a moment on the PanelView Plus screen. D. Touch a metal object (such as a a coin or key) to the sensing end of the 871TM inductive proximity sensor. The PanelView Plus counter should increment by one every time a metal object is sensed. 18. Open data file N20. 19. What in this data file indicates that the explicit message was successful?

20. Save the RSLogix 500 program. 21. Close RSLogix 500 software. 22. Close RSNetWorx for DeviceNet software. Rev. July 2008


18 -- 18


How Did You Do?





Rev. July 2008

18 -- 19


18 -- 20


Answers

Exercise A 2. If you correctly identified the class, instance, and attribute codes needed to write to the 871TM inductive proximity sensor parameters, your table will look like the following: Device Variable or Parameter

Up Counter Enabled (parameter 18)

Instance Code

Class Code

ee

01

Attribute Code

01

3. The service code used to set a single attribute is 10. 4. The command code used to execute an explicit message transaction block is 1. 9. If you correctly formatted an explicit message transaction block in data file N20:10 to enable the Up Counter Enabled parameter in the 871TM inductive proximity sensor, the data file will look like the following graphic:

10. If you successfully formatted an explicit message transaction block in N20:0 to clear the scanner module’s response buffer, the data file will look like the following graphic:

11. Rung 005 of the main routine sends an explicit message transaction block to enable the 871TM sensor’s Up Counter Enabled parameter from N20:10 to the sensor. 12. An input from the PanelView operator interface triggers the message. 13. In rung 006, when bit 15 (the Explicit Message Program Control bit) goes on in the scanner module’ s status register , it triggers the transfer of data from the 871TM inductive proximity sensor back to the SLC 500 processor. When bit 15

goes on message in the scanner module’s status , itdevice. means the explicit has been received by register the target




18 -- 21

14. In rung 006, when the data in file N20:50 equals the data in file N20:10 (e.g., the Transaction ID and command sent to the target device equals the Transaction ID and command received from the target device), the scanner module’s explicit message response buffer is cleared. 19. You can tell that the explicit message was received since N20:10 equals N20:50 (101).

Rev. July 2008


18 -- 22




Optional Lesson

19

Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators What You Will Learn

After completing this lesson, you should be able to troubleshoot a DeviceNet network using hardware indicators by performing the following tasks: •


• •

Interpret device network status indicators Interpret scanner module numeric or alphanumeric codes

•


Why These Skills Are Important The ability to troubleshoot a network using hardware status indicators is important for the following reason s:

Before You Begin

Hardware status indicators are the most commonly used resources to determine the exact nature of a network fault, so being able to interpret them is essential to restoring a malfunctioning network to proper working order.

•

Since they are on the plant floor, hardware indicators are among the most accessible troubleshooting resources for maintenance technicians.

•

Hardware indicators can often provide more specific information about the status of a network and the nature of network faults than software tools.

Status Indicators (LEDs)

Review the role of a scanner module as the interface between a processor and devices on a DeviceNet network.

Rev. July 2008

•

Status indicator s are light displays on scanner modules and devices that provide information about the status of the scanner module or device. Status indicator s are most often used in combination with scanner module numeric and alphanumeric codes to determine the exact nature of a fault or condition.

Tip "

Status indicator s are typically bi-color (red or green) and either solid or flashing. Different combinations of these variables provide specific information about scanner module or device status.

Tip "

Tables with interpretations of scanner module and slave device status indicators are provided in the Troubleshoo ting Guide.

E 2008 Rockwell Automation, Inc. All rights reserved. HRDSib100

19 -- 2

Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators

1747-SDN Scanner Module Status Indicators Hold up the troubleshooting guide and show students where interpretations of a 1747-SDN scanner module’s status indicators can be found.

Different types of status indicator s exist on the various scanner modules manufac tured by Rockwell Automation for use on DeviceNet networks. A 1747-SDN scanne r module, used with SLC 500 processors, has the following status indicators : •

Module Status Indicator: Indicates whether the 1747-SDN scanner module has power and is operating properly. Specifically, this status indicator can provide the following types of information:

-- Power supply status -- Scanlist status -- Recoverable/unrecoverable fault status •

Network Status Indicator: Indicates whether or not the DeviceNet communicatio ns channel is active and if there are problems with any of the devices in the scanner module’ s scanlist.

The following graphic shows the status indicators on a 1747-SDN scanner module:

Network Status Indicator

Module Status Indicator

1747-SDN Scanner Module


Rev. July 2008 HRDSib100


19 -- 3

Device Network Status Indicators Explain that devices can also have other types of status indicators and point out the status indicators for each individual input point on the ArmorBlock MaXum input module in the following graphic. Also note the “Logic Status” indicator and briefly explain its advanced troubleshooting purpose in conjunction with DeviceLogix functionality.

Most DeviceNet- compatible devices have a network status indicator that provides information about that device’s status on the network. A device’s network status indicator can provide the following information about the device:

Briefly explain the Faulted Address Recovery feature of RSNetWorx for DeviceNet software and note that a device’s network status indicator can be used to identify a device that has a duplicate node address (the network status indicator will flash red and green alternately).

•

Power supply status

•

Connection status (i.e., whether or not it is either in the scanlist of a master scanner module or has a peer-to-peer connection with another device)

•

Communication status (i.e., whether or not it is able to communicate on the network)

The following graphic shows the various status indicators , including the network status indicator, available for an ArmorBlock MaXum input module:

Individual Input Point Status Indicators

Individual Input Point Status Indicators Network Status Indicator

Logic Status Indicator (For Modules that Support DeviceLogix Functionality) ArmorBlock MaXum Input Module

Tip "

Devices may have other status indicators not necessarily related to the DeviceNet networ k that can also be used for troubleshooting purposes.

Tip "

The location and physical appearance of a device’s network status indicator varies with each device. Consult a device’s user documentation for details.

Status Indicator Interpretation Explanations of the various states that scanner module and device status indicators may take can be found in the following places:

Rev. July 2008

•

The Troubleshooting Guide

•

A device’s user documentation


19 -- 4


For the most accurate picture of network status, status indicator s should be read and interpreted in conjunction with scanner module numeric and alphanumeric codes.

Scanner Module Numeric and Alphanumeric Codes Numeric and alphanumeric codes are typically used in conjunction with scanner module and device status indicators and provide more specific information about the status of a network. Dependi ng upon the scanner module, these codes are displayed in a different location and manner. Tell students that detailed information on how to access codes for scanner modules that do not display them on the front of the module can be found in the troubleshooting guide.

The following table summarizes the location and type of numeric or alphanumeric codes available for five of the main scanner modules manufactured by Rockwell Automation: For this scanner module . . .

This type of code is available . . .

And is located . . .

1771-SDN

Numeric only


1747-SDN

Numeric only


1756-DNB

Numeric and alphanumeric

1784-PCIDS

Numeric only

• On the front of

the scanner module StatusDisplay status structure element of RSLogix 5000 software

• In the

In IOLinx for DeviceNet software • In the

1788-CN2DN

If you are teaching this lesson as part of a standard school, do not go into detail now about how RSLogix 500 software can be used to access numeric codes for the 1747-SDN scanner module. This information will be covered in a later lesson.

Numeric only

ScannerStatus and

ScrollingDevice status structure elements of RSLogix 5000 software (for the Logix5000 family of controllers) • In the first word of the input data table in RSLogix 5 software (for PLC-5 processors)

The following graphic shows where numeric and/or alphanumeric codes are displayed on the 1747-SDN scanner modules: DeviceNet

STATUS MODULE NET Numeric Display ADDRESS/ERROR

Top Part of a 1747-SDN Scanner Module E 2008 Rockwell Automation, Inc. All rights reserved.



Tip "

Here’s How 1. Create a fault on your workstation using the 1747-SDN scanner module as the network master, then clear it using information from the hardware status indicators, device network status indicators, and scanner module numeric and alphanumeric codes. 2. Create the same fault on your workstation using the 1747-SDN scanner module as the network master, then clear it.

19 -- 5

Explanations of all the numeric and alphanumeric codes that can be displayed on Rockwell Automation DeviceNet scanner modules and the recommended course of action to clear them can be found in the Troubleshooting Guide.

To troubleshoot a DeviceNet network using hardware indicators by performing the following tasks: • •


•

Interpret device network status indicators Interpret scanner module numeric or alphanumeric codes

•



Before clearing the error, be sure to point out the status of all of the following indicators: 1. Scanner module status indicators 2. Scanner module numeric or alphanumeric codes 3. Device network status indicator

Rev. July 2008


19 -- 6




Exercise: Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators

19 -- 7

Exercise: Troubleshooting Using DeviceNet and SLC 500 Hardware Indicators Exercise A

In this exercise, you will practice troublesho oting a DeviceNet network using hardware indicators.

Context: You are performing routine maintenance by checking device connections when you notice that the network status indicators on a few devices are not solid green and that several numeric/alphanumeric codes are flashing on the front of the scanner module that is acting as the master on the network. Recognizing these as indications of problems on the network, you begin troubleshooting by interpreting the various status indicators and numeric/alphanumeric codes being displayed. Underlined actions indicate a procedure can be found in the associated job aid.

Directions: 1. Open the HRDS_N100_A1.dnt network configuration file. 2. Go online to the network using the 1770-KFD driver. Do not upload the network configurati on.

3. If it is not already, change the processor’s operating mode to Program. 4. Download the network configuration. 5. Disconnect the 871TM proximity sensor from the network.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. HRDSe100

19 -- 8


6. Interpret the status indicators on the scanner module that is acting as the master scanner module on your network and complete the following table: Scanner Module

Status Indicator

State

Meaning

MODULE 1747-SDN scanner module

NET

Do not attempt to perform any corrective action to change the state of any status indicators at this time. 7. Interpret the network status indicator s on the workstation devices listed below and complete the following table: Network Status Indicator

State

Meaning

871TM photoelectric sensor ArmorBlock I/O module

Tip "

Look at the network status indicator of the ArmorBlock MaXum Input module for at least ten seconds before determining its state. 8. Interpret the numeric or alphanumeric codes displayed on the front of the scanner module acting as the master scanner module on your workstation.

Tip "


Tables with interpretations of scanner module numeric and alphanumeric codes are provided in the Troubleshootin g Guide.

Rev. July 2008 HRDSe100


19 -- 9

9. List the numeric or alphanumeric codes that are displayed on the front of the scanner module and the probable cause of each:

10. Perform thealphanumeric necessary actions to clear the scanner module numeric or codes.

Tip "

The Scanner Module Master Data Maps appendix, which contains information about the I/O sizes that the workstation devices should be configured to send and receive, may help you clear one of the error codes. 11. Save the network configurati on. 12. Close RSNetWorx for DeviceNet software.

How Did You Do?

Rev. July 2008



19 -- 10


Answers

Exercise A 6. If you have correctly interpreted the status indicators on the scanner module that is acting as the master scanner module on your workstation, the table you completed should resemble the following table: Scanner Module 1747-SDN scanner module

Status Indicator

State

MODULE

Flashing red

NET

Solid green

Meaning

The scanner module has a minor recoverable fault or a connection timeout. The scanner module is operating normally.

7. If you have correctly interpreted the status indicators on the workstation devices, the table you completed should resemble the following table: Network Status Indicator

State

Meaning

871TM photoelectric sensor

Off

There is no power being applied to the device.

ArmorBlock I/O module

Flashing green or flashing red

The device needs commissioning. Read the scanner module numeric or alphanumeric code.

9. The following numeric and alphanumeric codes should be

displayed on the front of the scanner module: A. 80 and 01 alternately (the cause is that the processor is in Program mode) B. 78 and 02 alternately (probable cause is that the connection between the 871TM inductive proximity sensor and the network is loose) C. 77 and 30 alternately (probable cause is that the I/O sizes configured for the ArmorBlock I/O module in the scanner do not match those that were srcinally configured for the device). This error can be cleared by editing the input size of the ArmorBlock I/O module in the scanlist of the 1747-SDN scanner module to send 0 inputs instead of 1.




19--11

Troubleshooting Tips If you are unable to successfully clear scanner module numeric or alphanumeric codes, verify that you have completed the following actions:

-

Securely reconnected the 871TM inductive proximity sensor to the network Changed the input size configured for the ArmorBlock I/O module in the master scanner module’ s scanlist to send 0 inputs instead of 1.

-

Rev. July 2008

Downloaded corrective changes made in the scanner module configuration to the scanner module If problems persist, cycle power to the workstation after performing the corrective action


19 -- 12




Optional Lesson

20

Troubleshooting a DeviceNet Network Using RSLogix 500 Software What You Will Learn

After completing this lesson, you should be able to troubleshoot a DeviceNet network using RSLogix 500 software by performing the following tasks: •

Trace I/O points through a 1747-SDN scanner module

•

Monitor data in a 1747-SDN scanner module’s status register

Why These Skills Are Important Being able to troubleshoot a DeviceNet network using RSLogix 500 software is important for the following reasons :

Before You Begin Stress the importance of making sure that RSNetWorx for DeviceNet input and output mapping is aligned with device addresses in the ladder logic program.

•

Recognizing the relationship between an RSNetWorx for DeviceNet software data map and RSLogix 500 I/O addresses can help identify communications problems stemming from address misalignment.

•

A significant amount of data regarding the status of a scanner module and a network in general can be obtained through RSLogix 500 software.

Relationship Between an RSNetWorx for DeviceNet Software Data Map and I/O Points in RSLogix 500 Software For communications between a processor or and devices to occur, input and output data mapped for devices in the scanlist of a scanner module must correlate directly with the input and output addresses for these devices in the corresponding ladder logic program. Since misalignment of this data can cause communications problems , the ability to trace I/O points is essential to maintaining and troubleshooting a DeviceNet network. To trace I/O points through a 1747-S DN scanner module, the following information is used:

Rev. July 2008

•

The RSNetWorx for DeviceNet software data map

•

The data structure of the device for which I/O points are to be

•

traced RSLogix 500 software data files (1747-SDN scanner modules only)

E 2008 Rockwell Automation, Inc. All rights reserved. RSLSib100

20 -- 2


RSNetWorx for DeviceNet Software Data Map

The location where a device’s data is mapped in a 1747-SDN scanner module can be determined by accessing the input and output data maps in the Scanner Module window of RSNetWorx for DeviceNet software. Remind students that, for 1747-SDN scanner modules, devices may also be mapped to M files. In such cases, the M file mapping information should be accessed.

The following graphic shows the RSNetWorx for DeviceNet window where the location of discrete input data for a RightSight photoelectric sensor in the scanlist of a 1747-SDN scanner module can be determined:

The RightSight photoelectric sensor’s input data is mapped to input word 6, bit 0.

A total of 8 bits have been mapped.


Rev. July 2008 RSLSib100


20 -- 3

Device Data Structure

Knowledge of a device’s data structure is needed to trace I/O points because the data map in RSNetWorx for DeviceNet software alone does not provide a user with information about the specific function of each individual bit that has been mapped for a device (e.g., it does not provide information as to which bit in an operator interface represents the start button). Advise students that data structure information for devices that have large amounts of I/O data or different I/O assemblies to choose from is not usually located in RSNetWorx for DeviceNet software and must be accessed using device documentation (e.g., information about the data structure of a Bulletin 160 drive or E3 solid-state overload relay).

Tip " Stress that a device’s data structure can vary based on the kind of messaging the device has been configured for. Make sure students know they must look up a device’s data structure based on the device’s message type.

Rev. July 2008

The following resources provide informati on about the data structure of a device, including the function of individual bits in the device: • •

The I/O Data property page for the device The EDS (electronic data sheet) file for the device

•

The online Help system in RSNetWorx for DeviceNet software (Allen-Bradley devices only)

•

The device’s user manual

•

Data sheets that ship with the device

The location of data structure informat ion varies with each device. Device data structure can vary depending upon the type of messaging the device has been configured for (e.g., polled, strobed, change-of-sta te, etc.)


20 -- 4


The following graphic shows the I/O Data property page for the RightSight polarized retroref lective sensor and the data structure information that can be accessed from the I/O Data property page:


Button Used to Access a Device’s Data Structure Information from the I/O Data Property Page

Device Data Structure Information (Drawn from Device’s EDS File) Function of Bit 0 in Byte 1 of the RightSight Polarized Retroreflective Sensor




20 -- 5

The following graphic shows the I/O Data property page for the ArmorBlock MaXum input module and the data structure information that can be accessed from the I/O Data property page: I/O Data Property Page

Button Used to Access Change-of- State Data Structure Information from the I/O Data Property Page

Device Data Structure Information (Drawn from Device’s EDS File)

Function of Bits 0 to 3 in Byte 1 of the Input Data from the Module

RSLogix 500 Software Data Files Make sure that everyone is familiar with the terms discussed in this section. If not, review them briefly.

Note that M file data is not automatically transferred to an integer file from a 1747-SDN scanner module when it is mapped but must be transferred using a COP instruction in RSLogix 500 software.

Rev. July 2008

Once the location where device data is mapped in a 1747-SDN scanner module and a device’s data structure are known, device I/O points can be traced using RSLogix 500 software data files. The following data files in RSLogix 500 software are used to trace I/O points: •

Input Data File: The location where discrete inputs from network devices are stored in an SLC 500 processor.

•

Output Data File: The location where discrete outputs to network devices are located in an SLC 500 processor.

•

Integer Files: The user-specified location where inputs or outputs that have been mapped to M files in a 1747-SDN scanner module are located.


20 -- 6


? Are inputs mapped in RSNetWorx for DeviceNet software being sent to or from the device? Answer: They are being sent to a processor from a device via a scanner module.

To trace discrete I/O points, the input or output data map in RSNetWorx for DeviceNet software must be compared with the input or output data files in RSLogix 500 software. The following graphic shows the relationship between the input data map in a 1747-SDN scanne r module where the RightSight photoelectr ic sensor is mapped and the input data file in the SLC 500 processor being used on the DeviceNet network:

1747-SDN Scanner Module Input Data Table

Input data from the RightSight photoelectric sensor is mapped to input word 6, bit 0 in the SLC 500 processor.

Each individual bit in the first byte of I:1.6 represents a bit in the RightSight photoelectric sensor.


SLC 500 Processor Input Data File

Bit 1 represents diagnostic data for the RightSight photoelectric sensor. The lower byte of word 6 in the SLC 500 processor reflects the status of the RightSight photoelectric sensor’s inputs.



In the screen capture, stress that a COP instruction is used to copy M file data from a scanner module to an SLC 500 processor.

20 -- 7

The following graphic shows the relationship between the M1 file data map in a 1747-SDN scanner module and the integer file where the M1 file data is stored in an SLC 500 processor: RSLogix 500 Copy Instruction

1747-SDN Scanner Module Input Table

SLC 500 Processor Integer File

All input data from module’s the 1747-SDN scanner M1 file area is copied to integer file N10 in the SLC 500 processor. Input data from the PanelView operator interface is mapped to the 1747-SDN scanner module’s M1 file starting at word 0.

Input data from the PanelView operator interface is located in integer file N10 of the SLC 500 processor.

Scanner Module Status Register Direct students to the pages in the documentation reference guide where status register information for a 1747-SDN scanner module is located.

The status of a scanner module can be monitored by viewing the scanner module’s status register. The status register of a 1747-SDN scanner module is the first discrete input word (word 0) of the corresponding SLC 500 processor.

Note that information about bit function in the status register of a 1771-SDN scanner module can also be found in the documentation reference guide.

The following information about a scanner module and, consequently, the entire network, can be obtained through the status register:

In the graphic, point out that since bit 1 of the status register is turned on, it can be discerned that the scanner module is in Run mode.

•

The operational mode of the scanner module (Run, Idle, Disabled, etc.)

•

If there are faulted devices on the network

•

If there are duplicate node addresse s on the network

•

If there is an explicit message response availabl e from a device

The following graphic shows the portion of the input data file in an SLC 500 processor where information from the status register of a 1747-SDN scanner module is located:

Status Register Data for a 1747-SDN Scanner Module Rev. July 2008


20 -- 8


Here’s How

To trace I/O points through a 1747-SDN scanne r module.

Demonstrate how to trace the RunFwd (Run Forward) bit for the Bulletin 160 drive in the scanlist of the 1747-SDN scanner module using your workstation and the example below.

Example

As your instructor demonstrates this procedure, refer to the following example:

Tracing I/O Points through a 1747-SDN Scanner Module In this example, the Start bit of a PowerFlex 40 drive will be traced through a 1747-SDN scanner module. The drive has the following characteristics:

Tip "

•

It is configured for polled messaging .

•

It sends and receives 4 bytes of data.

The data structure of the input and output assemblies used by the drive is located in the drive’s user manual. Step 1: Determine Output Mapping

The output mapping information is accessed using the RSNetWorx for DeviceNet software output data map. It is determined that the PowerFlex 40 drive is mapped to output words 13 and 14 in the 1747-SDN scanner module:

Output data is mapped to words 13 and 14.



20 -- 9


Step 2: Determine Data Structure

The data structure of the PowerFlex 40 drive’s output assembly is determined by accessing the drive’s user manual. Based on the output assembly data structure shown in the following graphic, it is determined that bit 1 of the first byte of drive output data enables the drive to start: Start Bit Logic Command Byte

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2 Clear Fault

Bit1 J og

Bit0 Start

Stop

Speed Reference RPM (Low Byte) Speed Reference RPM (High Byte)

Step 3: Determine I/O Point Location in RSLogix 500 Software Output Data File

Using the information now known about the output data map and output assembly data structure for the PowerFlex 40 drive, the exact location of the Start bit can be determined in the RSLogix 500 software output data file:

Location of All Output Data from the PowerFlex 40 drive

Rev. July 2008

Start Bit (O:1.13/1 or O:1.209)


20 -- 10


Step 4: Verify the Addressing of the Ladder Logic Instruction Controlling the I/O Point

Once it is known that output point O:1.13/1 (or O:1.209) represents the Start bit in the PowerFlex 40 drive, the ladder logic instruction that actually turns this bit on must be checked against this address to make sure that it is referencing the correct point. The following graphic shows the rung of the RSLogix 500 program that controls the PowerFlex 40 drive:

Output Instruction to Turn PowerFlex 40 Drive Start Bit On

Per the output instruction in the example graphic, the Start bit is at output address O:1/209. Since this is the same as output address O:1.13/1 (or the 209th bit mapped in the scanner module), it can be determined that the PowerFlex 40 drive’s output map in RSNetWorx for DeviceNet softwa re is aligned with the RSLogix 500 addressing.




20--11

Exercise: Troubleshooting a DeviceNet Network Using RSLogix 500 Software Exercise A

In this exercise, you will practice troublesho oting a DeviceNet network by performing the following tasks: •

Trace I/O points through a 1747-SDN scanner module

•

Monitor data in a 1747-SDN scanner module’s status register

Context: An ArmorBlock MaXum input module has recently been replaced on the DeviceNet network that runs the cookie production line at your plant. The module has already been configured and mapped in RSNetWorx for DeviceNet software. The module’s network status indicator is solid green and there are no numeric codes displayed for it on the 1747-SDN scanner module, but it is still not communicating on the network. You suspect that the module’s mapping in RSNetWorx for DeviceNet software and the addresses it references in the RSLogix 500 software program that runs the conveyor line may be mismatched. You decide to troubleshoot the problem by tracing I/O points for the ArmorBlock input module. Underlined actions indicate a procedure can be found in the associated job aid.

Tip "


Directions: 1. In RSNetWorx for DeviceNet software, open network configuration file RSLS_N100_A1.dnt. 2. Go online to the network. 3. Change the processor’s operating mode to Program. 4. Download the device configurat ion to the 1747-SDN scanner module. 5. Change the processor’ s operating mode to Run.

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. RSLSe100

20 -- 12


6. Attempt to start the motor in the workstation by pressing the IN2 pushbutton.

Tip "

This pushbutton is wired to the third input of the ArmorBlock MaXum Input module and should command the PowerFlex 40 drive to start the motor. 7. Does the motor start?

8. Open project file RSLS_N100_A2.rss. 9. Download the project to the SLC 500 processor. 10. If you have not already done so, change the processor’s operating mode to Run. 11. Using the RSNetWorx for DeviceNet software input data map, the I/O Defaults property page for the ArmorBlock input module, and the RSLogix 500 input data file, trace the third ArmorBlock MaXum input point (input 2) and complete the following information:

RSNetWorx for DeviceNet Software Input Data Map Address:

Location of Input 2 On Bit within Device Data Structure:

12. To which RSLogix 500 input data file address will data from input 2 in the ArmorBlock MaXum input module go?

13. Access rung 0 in the LAD 3 -- C OOL subroutine. 14. Does the input instruction for input 2 in the ArmorBlock MaXum input module match the input data file address where the module’s inputs will be found based on the RSNetWorx for DeviceNet software input data map? Why or why not?

15. Go online to the SLC 500 processor. E 2008 Rockwell Automation, Inc. All rights reserved.

Rev. July 2008 RSLSe100


20 -- 13

16. Open the RSLogix 500 input data file. 17. While monitoring data in the the RSLogix 500 input data file, press the IN2 pushbutton in the workstation. 18. Which input bit goes on as a result of this action? Is this the bit that is referenced in rung 0 of the ladder logic?

19. What actions can be taken to align the input addressing?

20. Change the processor’s operating mode to Program. 21. Choose one of the following options to align the ArmorBlock MaXum input module’s addressing: • •

•

Open network configuration file RSLS_N100_A3.dnt and download the network configuration . Using the currently open RSNetWorx for DeviceNet file RSLS_N100_A1.dnt, manually map the device input data for the ArmorBlock input module so that it is aligned with the address referenced in the input instruction in rung 0. Download the changes to the scanner module.

22. Change the processor’ s operating mode to Run. 23. Attempt to start the motor in the workstation by pressing the IN2 pushbutton. This pushbutton is wired to the third input of the ArmorBlock input module and should command the PowerFlex 40 drive to start the motor. If the motor starts, you have successfully fixed input address alignment. 24. Press the red button on the PowerFlex 40 drive to stop the motor. 25. Trace the input point that reflects the status of the offwire diagnostic parameter for input 2 in the ArmorBlock MaXum input module.

Rev. July 2008


20 -- 14


26. Which bit in the RSLogix 500 input data file will go on if an offwire condition is detected on input 2 of the ArmorBlock MaXum input module?

27. Test your conclusion by disconnecting the cable for input 0 on the ArmorBlock MaXum input module, activating the Connector Fault Status parameter for input 2 of the module in RSNetWorx for DeviceNet software, and monitoring the bit that should be

affected in the RSLogix 500 input data file. 28. Reconnect the cable for input 2 of the ArmorBlock MaXum input module and deactivate the Connector Fault Status parameter for input 2 of the module. 29. Monitor data in the 1747-SDN scanner module’s status register. 30. Which bit is on in the status register and what does it signify?

31. Change the processor’s operating mode to Program. 32. Save the RSNetWorx for DeviceNet software network configuration. 33. Close RSLogix 500 software. 34. Close RSNetWorx for DeviceNet software.

How Did You Do?





Rev. July 2008

20 -- 15


20 -- 16


Answers

Exercise A 7. No, the motor should not start. 11. The RSNetWorx for DeviceNet input data map address for the ArmorBlock MaXum input module is I:1.14. 12. Data from input 2 in the ArmorBlock MaXum input module will go to input address I:1.14/2 (or I:1/226) in the RSLogix 500 input data file. 14. No, the input instruction for input 2 in the ArmorBlock MaXum

input module does not match the input data file address where the module’s inputs will be found based on the RSNetWorx for DeviceNet software input data map. The ArmorBlock MaXum inputs are mapped to input word 14 in RSNetWorx for DeviceNet software. Since the third bit (bit 2) of the first byte of input data from the module controls input 2, the input instruction in RSLogix 500 software should reference I:1.14/2 (or I:1/226). Since it references I:1.15 (or I:1/242), the addressing does not match. 18. Input bit I:1.14/2 (or I:1/226) goes on as a result of pressing the IN2 pushbutton. However, this is not the bit that is referenced in the input instruction for the ArmorBlock MaXum input module in rung 0 of the LAD 3 -- COOL subroutine. 19. Either one of the following actions can be taken to align the input addressing for the ArmorBlock MaXum input module:

-- The input data map in RSNetWorx for DeviceNet software can be changed to match the ladder logic.

-- The ladder logic can be re-written to reference the address where the input module is actually mapped. 26. Bit 10 of input word 15 (I:1.1 5/10) in the RSLogix 500 input data file will go on if an offwire condition is detected on input 2 of the ArmorBlock MaXum input module. 30. Bits 0 is on in the status register. Bit 0 signifies that the scanner module is in Run mode.



Appendix

A

Scanner Module Master Data Maps 1756-DNB Scanner Module Master Data Map Node Address

Device

1756-DNBscannermodule

0 0 01


02

E3solid-stateoverload relay

1734-ADN Point I/O adapter

PowerFlex40drive

03

04

20

N/A Strobed

30


40

Polled

N/A

InputMap

N/A N/A

Output Map

N/A DWord: 00 Bit: 0 Bit Length: 32

N/A

2

N/A

DWord: 1 Bit: 0 Bit Length: 16

N/A

8

1





Segment 1: DWord: 6 Bit: 0 Bit Length: 16





N/A



Change-of-State

8

4

5

4

Change-of-State 2

Cyclic

Output Size

4

Strobed

Polled


Input Size

Message Type

N/A

Absolute muti-turn encoder

Rev. July 2008

For a workstation using the 1756-DNB scanner module as the network master to function properly , device mapping should meet the following requirements:

4

N/A

4

E 2008 Rockwell Automation, Inc. All rights reserved. DATa100

A--2

Scanner Module Master Data Maps

1747-SDN Scanner Module Master Data Map Node Address

Device

1747-SDNscannermodule

For a workstation using the 1747-SDN scanner module as the network master to function properly, device mapping should meet the following requirements:

0 0

N/A

Absolute muti-turn encoder

01


02

E3solid-stateoverloadrelay

1734-ADN Point I/O adapter

PowerFlex40drive

03

04

20

N/A Strobed

30


40

Polled

N/A N/A

OutputMap

N/A Word: 1 Bit: 0 Bit Length: 32

N/A

N/A

Word: 3 Bit: 0 Bit Length: 16

N/A

8

1





Word:12 Bit:0 Bit Length: 32



N/A



8

4

5

4

Change-of-State 2


InputMap

N/A

2

Change-of-State

Cyclic

Output Size

4

Strobed

Polled


Input Size

Message Type

4

N/A

4

Rev. July 2008 DATa100

Appendix

B

Decimal to Hexadecimal Conversion Table Use the following table to convert decimal values to hexadecimal values: Decimal

HexadecimalEquivalent

0 1

0 1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

a

11

b

12

c

13

d

14

e

15 16

f 10

17

11

18

12

19

13

20

14

21

15

22

16

23

17

24

18

25

19

26

1a

27

1b

28

1c

29

1d

30

1e

31

1f

32

20

33

21 (Continued)

Rev. July 2008

E 2008 Rockwell Automation, Inc. All rights reserved. HEXa100

B--2

Decimal to Hexadecimal Conversion Table

Decimal


34

22

35

23

36

24

37

25

38

26

39

27

40

28

41

29

42

2a

43 44

2b 2c

45

2d

46

2e

47

2f

48

30

49

31

50

32

51

33

52

34

53

35

54

36

55

37

56

38

57

39

58

3a

59 60

3b 3c

61

3d

62

3e

63

3f

64

40

65

41

66

42

67

43

68

44

69

45

70

46

71

47

72

48

73

49

74

4a (Continued)


Rev. July 2008 HEXa100


Decimal

Rev. July 2008


75

4b

76

4c

77

4d

78

4e

79

4f

80

50

81

51

82

52

83

53

84 85

54 55

86

56

87

57

88

58

89

59

90

5a

91

5b

92

5c

93

5d

94

5e

95

5f

96

60

97

61

98

62

99

63

100

B -- 3

64

E 2008 Rockwell Automation, Inc. All rights reserved. HEXa100

B--4



Rev. July 2008 HEXa100

Appendix

C

PowerFlex 40 Drive Data Structure The following tables outline the data structure of the input and output assemblies used in the PowerFlex 40 drive included in the DeviceNet double-box workstations: Logic Command (Output Byte 0

Bit7

Bit6

Bit5

Bit4

Bit3

Bit 2 Jog

Fault Reset

Bit1 Start

Bit0 Stop

1 2


3


"

Rev. July 2008

The information in this appendix is from the user manual for the DN2 DeviceNet communications module used with PowerFlex 40 drives.

E 2008 Rockwell Automation, Inc. All rights reserved. PFDa100

C--2

PowerFlex 40 Drive Data Structure


Rev. July 2008 PFDa100

The following are trademarks of Rockwell Automation, Inc.: 1336FORCE 1336PLUS ControlBus DataHighwayPlus DriveTools Flex Logix5000 PanelBuilder PLC-5 PowerFlex RSLinx RSView SCANPort SoftLogix

1336IMPACT CompactLogix ControlLogix DH+ FactoryTalk FlexLogix Logix5550 PanelView PHOTOSWITCH RediSTATION RSLogix RSNetWorx SLC Ultra

EtherNet/IP and ControlNet are trademarks of ControlNet International Ltd. DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA). The following are registered trademarks of Microsoft Corporation: MS-DOS Windows

PowerPoint WindowsNT

IBM is a registered trademark of International Business Machines Corporation. Pentium is a registered trademark of Intel Corporation. All other trademarks are the property of their respective holders and are hereby acknowledged.

Catalog Number ABT-CCP164-TIM -- July 2008 Supercedes Catalog Number ABT-CCP164-TIM -- February 2007

E 2008 Rockwell Automation, Inc. All rights reserved. Printed in USA

ABT-CCP164-TIM 2008-07

Recommend Documents