User Manual for altus models including: NX3005 Nexto Serie CPU, NX3005, Nexto Serie CPU, CPU
2023-11-21 — It is essential to read and understand the product documentation, such as manuals and technical characteristics before its installation or use. The examples and ...
File Info : application/pdf, 259 Pages, 11.96MB
DocumentDocumentUser Manual Nexto Serie CPU NX3005 MU214617 Rev. C June 30, 2023 General Supply Conditions No part of this document may be copied or reproduced in any form without the prior written consent of Altus Sistemas de Automação S.A. who reserves the right to carry out alterations without prior advice. According to current legislation in Brazil, the Consumer Defense Code, we are giving the following information to clients who use our products, regarding personal safety and premises. The industrial automation equipment, manufactured by Altus, is strong and reliable due to the stringent quality control it is subjected to. However, any electronic industrial control equipment (programmable controllers, numerical commands, etc.) can damage machines or processes controlled by them when there are defective components and/or when a programming or installation error occurs. This can even put human lives at risk. The user should consider the possible consequences of the defects and should provide additional external installations for safety reasons. This concern is higher when in initial commissioning and testing. The equipment manufactured by Altus does not directly expose the environment to hazards, since they do not issue any kind of pollutant during their use. However, concerning the disposal of equipment, it is important to point out that built-in electronics may contain materials which are harmful to nature when improperly discarded. Therefore, it is recommended that whenever discarding this type of product, it should be forwarded to recycling plants, which guarantee proper waste management. It is essential to read and understand the product documentation, such as manuals and technical characteristics before its installation or use. The examples and figures presented in this document are solely for illustrative purposes. Due to possible upgrades and improvements that the products may present, Altus assumes no responsibility for the use of these examples and figures in real applications. They should only be used to assist user trainings and improve experience with the products and their features. Altus warrants its equipment as described in General Conditions of Supply, attached to the commercial proposals. Altus guarantees that their equipment works in accordance with the clear instructions contained in their manuals and/or technical characteristics, not guaranteeing the success of any particular type of application of the equipment. Altus does not acknowledge any other guarantee, directly or implied, mainly when end customers are dealing with thirdparty suppliers. The requests for additional information about the supply, equipment features and/or any other Altus services must be made in writing form. Altus is not responsible for supplying information about its equipment without formal request. These products can use EtherCAT® technology (www.ethercat.org). COPYRIGHTS Nexto, MasterTool, Grano and WebPLC are the registered trademarks of Altus Sistemas de Automação S.A. Windows, Windows NT and Windows Vista are registered trademarks of Microsoft Corporation. OPEN SOURCE SOFTWARE NOTICE To obtain the source code under GPL, LGPL, MPL and other open source licenses, that is contained in this product, please contact opensource@altus.com.br. In addition to the source code, all referred license terms, warranty disclaimers and copyright notices may be disclosed under request. I CONTENTS Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1. Nexto Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Innovative Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Documents Related to this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Visual inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6. Warning Messages Used in this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Technical description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Panels and Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Common General Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. General features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Standards and Certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Serial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3.1. COM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Ethernet interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.4.1. NET 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5. Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.6. Environmental Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Compatibility with Other Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Application Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2. Time for Instructions Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.3. Initialization Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.4. Interval Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Physical Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7. Purchase Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.1. Integrant Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.2. Product Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8. Related Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Mechanical Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Electrical Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Ethernet Network Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2. Gratuitous ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. Network Cable Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 II CONTENTS 3.4. Serial Network Connection RS-485/422 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.1. RS-485 Communication without termination . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.2. RS-485 Communication with Internal Termination . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.3. RS-485 Communication with External Termination . . . . . . . . . . . . . . . . . . . . . . 23 3.4.4. RS-422 Communication without Termination . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.5. RS-422 Communication with Internal Termination . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.6. RS-422 Communication with External Termination . . . . . . . . . . . . . . . . . . . . . . 25 3.4.7. RS-422 Network Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Architecture Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5.1. Module Installation on the Main Backplane Rack . . . . . . . . . . . . . . . . . . . . . . . 26 3.6. Programmer Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Initial Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1. Memory Organization and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2. Project Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.1. Single . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.2. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3. Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.4. Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.5. Custom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.6. Machine Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.7. General Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.8. Maximum Number of Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. CPU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.5. Inserting a Protocol Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.5.1. MODBUS Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.6. Finding the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.7. Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.8. Run Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.9. Stop Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.10. Writing and Forcing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.11. Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.12. Project Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.13. CPU Operating States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.1. Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.2. Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.3. Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.4. Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.5. Reset Warm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.6. Reset Cold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.7. Reset Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.13.8. Reset Process Command (IEC 60870-5-104) . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.14. Programs (POUs) and Global Variable Lists (GVLs) . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.14.1. MainPrg Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.14.2. StartPrg Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.14.3. UserPrg Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.14.4. GVL System_Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.14.5. GVL Disables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 III CONTENTS 4.14.6. GVL IOQualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.14.7. GVL Module_Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.14.8. GVL Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.14.9. GVL ReqDiagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.14.10. Prepare_Start Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.14.11. Prepare_Stop Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.14.12. Start_Done Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.14.13. Stop_Done Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.1. CPU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.1.1. General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.1.1.1. Hot Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.1.1.1.1. Hot Swap Disabled, for Declared Modules Only . . . . . . . . . . . . . . . 55 5.1.1.1.2. Hot Swap Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.1.1.1.3. Hot Swap Disabled, without Startup Consistency . . . . . . . . . . . . . . 56 5.1.1.1.4. Hot Swap Enabled, with Startup Consistency for Declared Modules Only . 56 5.1.1.1.5. Hot Swap Enabled with Startup Consistency . . . . . . . . . . . . . . . . . 56 5.1.1.1.6. Hot Swap Enabled without Startup Consistency . . . . . . . . . . . . . . . 56 5.1.1.1.7. How to do the Hot Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.1.2. Retain and Persistent Memory Areas . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.1.1.3. Project Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.2. External Event Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1.3. Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1.3.1. IEC 60870-5-104 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.1.3.2. SNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.1.3.3. Daylight Saving Time (DST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.4. Internal Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.4.1. Quality Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.4.1.1. Internal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.1.4.1.2. IEC 60870-5-104 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.4.1.3. MODBUS Internal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1.4.1.4. Local Bus I/O Modules Quality . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.4.1.5. PROFIBUS I/O Modules Quality . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.4.1.6. PROFIBUS Digital Input Quality . . . . . . . . . . . . . . . . . . . . . . . 71 5.1.4.1.7. PROFIBUS Digital Output Quality . . . . . . . . . . . . . . . . . . . . . . 72 5.1.4.1.8. PROFIBUS Analog Input Quality . . . . . . . . . . . . . . . . . . . . . . 73 5.1.4.1.9. PROFIBUS Analog Output Quality . . . . . . . . . . . . . . . . . . . . . . 74 5.2. Serial Interfaces Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.2.1. COM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.2.1.1. Advanced Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.3. Ethernet Interfaces Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3.1. Internal Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3.1.1. NET 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3.2. NX5000 Remote Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3.2.1. NET 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3.3. Reserved TCP/UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4. Protocols Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.4.1. Protocol Behavior x CPU State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 IV CONTENTS 5.4.2. Double Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.4.3. CPU's Events Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.4.3.1. Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.4.3.2. Queue Functioning Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.4.3.2.1. Overflow Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.4.3.3. Producers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.4.4. Interception of Commands Coming from the Control Center . . . . . . . . . . . . . . . . . . 84 5.4.5. MODBUS RTU Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.5.1. MODBUS Master Protocol Configuration by Symbolic Mapping . . . . . . . . . . 89 5.4.5.1.1. MODBUS Master Protocol General Parameters Symbolic Mapping Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.5.1.2. Devices Configuration Symbolic Mapping configuration . . . . . . . . . 92 5.4.5.1.3. Mappings Configuration Symbolic Mapping Settings . . . . . . . . . . . 93 5.4.5.1.4. Requests Configuration Symbolic Mapping Settings . . . . . . . . . . . . 94 5.4.5.2. MODBUS Master Protocol Configuration for Direct Representation(%Q) . . . . . 98 5.4.5.2.1. General Parameters of MODBUS Master Protocol - setting by Direct Representation (%Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4.5.2.2. Devices Configuration Configuration for Direct Representation (%Q) . . . 100 5.4.5.2.3. Mappings Configuration Configuration for Direct Representation (%Q) . . 101 5.4.6. MODBUS RTU Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.6.1. MODBUS Slave Protocol Configuration via Symbolic Mapping . . . . . . . . . . 103 5.4.6.1.1. MODBUS Slave Protocol General Parameters Configuration via Symbolic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.6.1.2. Configuration of the Relations Symbolic Mapping Setting . . . . . . . . . 107 5.4.6.2. MODBUS Slave Protocol Configuration via Direct Representation (%Q) . . . . . . 108 5.4.6.2.1. General Parameters of MODBUS Slave Protocol Configuration via Direct Representation (%Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.4.6.2.2. Mappings Configuration Configuration via Direct Representation (%Q) . 109 5.4.7. MODBUS Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.4.8. MODBUS Ethernet Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.4.8.1. MODBUS Ethernet Client Configuration via Symbolic Mapping . . . . . . . . . . 113 5.4.8.1.1. MODBUS Client Protocol General Parameters Configuration via Symbolic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.4.8.1.2. Device Configuration Configuration via Symbolic Mapping . . . . . . . . 115 5.4.8.1.3. Mappings Configuration Configuration via Symbolic Mapping . . . . . . 117 5.4.8.1.4. Requests Configuration Configuration via Symbolic Mapping . . . . . . . 118 5.4.8.2. MODBUS Ethernet Client configuration via Direct Representation (%Q) . . . . . . 123 5.4.8.2.1. General parameters of MODBUS Protocol Client - configuration for Direct Representation(%Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.4.8.2.2. Device Configuration Configuration via Direct Representation (%Q) . . . 124 5.4.8.2.3. Mapping Configuration Configuration via Direct Representation (%Q) . . 125 5.4.8.3. MODBUS Client Relation Start in Acyclic Form . . . . . . . . . . . . . . . . . . 127 5.4.9. MODBUS Ethernet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4.9.1. MODBUS Server Ethernet Protocol Configuration for Symbolic Mapping . . . . . 127 5.4.9.1.1. MODBUS Server Protocol General Parameters Configuration via Symbolic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4.9.1.2. MODBUS Server Diagnostics Configuration via Symbolic Mapping . . . 129 5.4.9.1.3. Mapping Configuration Configuration via Symbolic Mapping . . . . . . . 131 5.4.9.2. MODBUS Server Ethernet Protocol Configuration via Direct Representation (%Q) 132 V CONTENTS 5.4.9.2.1. General Parameters of MODBUS Server Protocol Configuration via Direct Representation (%Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.4.9.2.2. Mapping Configuration Configuration via Direct Representation (%Q) . . 134 5.4.10. OPC DA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.4.10.1. Creating a Project for OPC DA Communication . . . . . . . . . . . . . . . . . . . 138 5.4.10.2. Configuring a PLC on the OPC DA Server . . . . . . . . . . . . . . . . . . . . . . 141 5.4.10.2.1. Importing a Project Configuration . . . . . . . . . . . . . . . . . . . . . . 143 5.4.10.3. OPC DA Communication Status and Quality Variables . . . . . . . . . . . . . . . 143 5.4.10.4. Limits of Communication with OPC DA Server . . . . . . . . . . . . . . . . . . . 145 5.4.10.5. Accessing Data Through an OPC DA Client . . . . . . . . . . . . . . . . . . . . . 145 5.4.11. OPC UA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 5.4.11.1. Creating a Project for OPC UA Communication . . . . . . . . . . . . . . . . . . . 148 5.4.11.2. Types of Supported Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.4.11.3. Limit Connected Clients on the OPC UA Server . . . . . . . . . . . . . . . . . . . 150 5.4.11.4. Limit of Communication Variables on the OPC UA Server . . . . . . . . . . . . . 150 5.4.11.5. Encryption Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 5.4.11.6. Main Communication Parameters Adjusted in an OPC UA Client . . . . . . . . . . 151 5.4.11.6.1. Endpoint URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 5.4.11.6.2. Publishing Interval (ms) e Sampling Interval (ms) . . . . . . . . . . . . . . 151 5.4.11.6.3. Lifetime Count e Keep-Alive Count . . . . . . . . . . . . . . . . . . . . . 152 5.4.11.6.4. Queue Size e Discard Oldest . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.4.11.6.5. Filter Type e Deadband Type . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.4.11.6.6. PublishingEnabled, MaxNotificationsPerPublish e Priority . . . . . . . . . 152 5.4.11.7. Accessing Data Through an OPC UA Client . . . . . . . . . . . . . . . . . . . . . 153 5.4.12. EtherNet/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 5.4.12.1. EtherNet/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 5.4.12.2. EtherNet/IP Scanner Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.4.12.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.4.12.2.2. Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.4.12.2.3. Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 5.4.12.2.4. EtherNet/IP I/O Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.4.12.3. EtherNet/IP Adapter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.4.12.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.4.12.3.2. EtherNet/IP Adapter: I/O Mapping . . . . . . . . . . . . . . . . . . . . . . 160 5.4.12.4. EtherNet/IP Module Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.4.12.4.1. Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.4.12.4.2. EtherNet/IP Module: I/O Mapping . . . . . . . . . . . . . . . . . . . . . . 161 5.4.13. IEC 60870-5-104 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.4.13.1. Type of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 5.4.13.2. Double Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 5.4.13.2.1. Digital Input Double Points . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.4.13.2.2. Digital Output Double Points . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.4.13.3. General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 5.4.13.4. Data Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 5.4.13.5. Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.4.13.6. Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.4.13.7. Server Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 5.4.13.8. Commands Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 VI CONTENTS 5.5. Communication Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.5.1. MODBUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.5.1.1. CPU's Local Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.5.1.2. Remote Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 5.5.2. OPC UA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 5.5.3. IEC 60870-5-104 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 5.6. System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 5.6.1. I/O Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 5.7. RTC Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 5.7.1. Function Blocks for RTC Reading and Writing . . . . . . . . . . . . . . . . . . . . . . . . . 181 5.7.1.1. Function Blocks for RTC Reading . . . . . . . . . . . . . . . . . . . . . . . . . . 181 5.7.1.1.1. GetDateAndTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 5.7.1.1.2. GetTimeZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 5.7.1.1.3. GetDayOfWeek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 5.7.1.2. Function Blocks and Functions of RTC Writing and Configuration . . . . . . . . . 184 5.7.1.2.1. SetDateAndTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 5.7.1.2.2. SetTimeZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.7.2. RTC Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 5.7.2.1. EXTENDED_DATE_AND_TIME . . . . . . . . . . . . . . . . . . . . . . . . . . 186 5.7.2.2. DAYS_OF_WEEK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.7.2.3. RTC_STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.7.2.4. TIMEZONESETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.8. User Files Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.9. CPU's Informative and Configuration Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 5.10. Function Blocks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.10.1. Special Function Blocks for Serial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.10.1.1. SERIAL_CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 5.10.1.2. SERIAL_GET_CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.10.1.3. SERIAL_GET_CTRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 5.10.1.4. SERIAL_GET_RX_QUEUE_STATUS . . . . . . . . . . . . . . . . . . . . . . . 201 5.10.1.5. SERIAL_PURGE_RX_QUEUE . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 5.10.1.6. SERIAL_RX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.10.1.7. SERIAL_RX_EXTENDED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 5.10.1.8. SERIAL_SET_CTRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 5.10.1.9. SERIAL_TX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 5.10.2. Inputs and Outputs Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 5.10.2.1. REFRESH_INPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 5.10.2.2. REFRESH_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 5.10.3. PID Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.10.4. Timer Retain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.10.4.1. TOF_RET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.10.4.2. TON_RET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 5.10.4.3. TP_RET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 5.10.5. ClearRtuDiagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 5.10.6. ClearEventQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 5.11. User Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 5.12. Management Tab Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 5.12.1. System Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 VII CONTENTS 5.12.2. Network Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 5.12.2.1. Network Section Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 5.12.2.1.1. Defined by Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 5.12.2.1.2. Defined by web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 5.12.2.2. Network Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 5.13. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 5.13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 5.13.2. SNMP nas UCPs Nexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 5.13.3. Private MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 5.13.4. Configuration SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 5.13.5. User and SNMP Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 5.14. Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 5.14.1. User Management and Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 5.14.2. PLC Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 6.1. Module Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 6.1.1. One Touch Diag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 6.1.2. Diagnostics via LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 6.1.2.1. DG (Diagnostic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 6.1.2.2. WD (Watchdog) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 6.1.2.3. RJ45 Connector LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.1.3. Diagnostics via System Web Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.1.4. Diagnostic Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 6.1.5. Diagnostics via Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 6.1.5.1. Summarized Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 6.1.5.2. Detailed Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 6.1.6. Diagnostics via Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 6.1.6.1. GetTaskInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 6.2. Graphic Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 6.3. System Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 6.4. Not Loading the Application at Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 6.5. Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 6.6. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 6.7. Preventive Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 VIII 1. INTRODUCTION 1. Introduction Nexto Series programmable controllers are the ultimate solution for industrial automation and system control. With high embedded technology, the products of the family are able to control, in a distributed and redundant way, complex industrial systems, machines, high performance production lines and the most advanced processes of Industry 4.0. Modern and highspeed, the Nexto series uses cutting-edge technology to provide reliability and connectivity, helping to increase the productivity of different businesses. Compact, robust and with high availability, the series products have excellent processing performance and rack expansion possibilities. Its architecture allows easy integration with supervision, control and field networks, in addition to CPU and power supply redundancy. The family's equipment also offers advanced diagnostics and hot swapping, minimizing or eliminating maintenance downtime and ensuring a continuous production process. Figure 1: NX3005 1.1. Nexto Series Nexto Series is a powerful and complete series of Programmable Controllers (PLC) with exclusive and innovative characteristics. Due to its flexibility, functional design, advanced diagnostic resources and modular architecture, the Nexto PLC can be used to control systems in small, medium and large scale applications. Nexto Series architecture has a great variety of input and output modules. These modules combined with a powerful 32 bits processor and a high speed bus based on Ethernet, fit to several application kinds as high speed control for small machines, complex distributed processes, redundant applications and systems with a great number of I/O as building automation. Furthermore, Nexto Series has modules for motion control, communication modules encompassing the most popular field networks among other features. Nexto Series uses an advanced technology in its bus, which is based on a high speed Ethernet interface, allowing input and output information and data to be shared between several controllers inside the same system. The system can be easily divided and distributed throughout the whole field, allowing the use of bus expansion with the same performance of a local module, turning possible the use of every module in the local frame or in the expansion frames with no restrictions. For interconnection between frames expansions a simple standard Ethernet cable is used. 1 1. INTRODUCTION Figure 2: Nexto Series Overview 1.2. Innovative Features Nexto Series brings to the user many innovations regarding utilization, supervision and system maintenance. These features were developed focusing a new concept in industrial automation. Battery Free Operation: Nexto Series does not require any kind of battery for memory maintenance and real time clock operation. This feature is extremely important because it reduces the system maintenance needs and allows the use in remote locations where maintenance can be difficult to be performed. Besides, this feature is environmentally friendly. Easy Plug System: Nexto Series has an exclusive method to plug and unplug I/O terminal blocks. The terminal blocks can be easily removed with a single movement and with no special tools. In order to plug the terminal block back to the module, the frontal cover assists the installation procedure, fitting the terminal block to the module. Multiple Block Storage: Several kinds of memories are available to the user in Nexto Series CPUs, offering the best option for any user needs. These memories are divided in volatile memories and non-volatile memories. For volatile memories, Nexto Series CPUs offer addressable input (%I), addressable output (%Q), addressable memory (%M), data memory and redundant data memory. For applications that require non-volatile functionality, Nexto Series CPUs bring retain addressable memory (%Q), retain data memory, persistent addressable memory (%Q), persistent data memory, program memory, source code memory, CPU file system (doc, PDF, data) and memory card interface. One Touch Diag: One Touch Diag is an exclusive feature that Nexto Series brings to PLCs. With this new concept, the user can check diagnostic information of any module present in the system directly on CPU's graphic display with one single press in the diagnostic switch of the respective module. OTD is a powerful diagnostic tool that can be used offline (without supervisor or programmer), reducing maintenance and commissioning times. OFD On Board Full Documentation: Nexto Series CPUs are capable of storing the complete project documentation in its own memory. This feature can be very convenient for backup purposes and maintenance, since the complete information is stored in a single and reliable place. ETD Electronic Tag on Display: Another exclusive feature that Nexto Series brings to PLCs is the Electronic Tag on Display. This new functionality brings the process of checking the tag names of any I/O pin or module used in the system directly to the CPU's graphic display. Along with this information, the user can check the description, as well. This feature is extremely useful during maintenance and troubleshooting procedures. 2 1. INTRODUCTION DHW Double Hardware Width: Nexto Series modules were designed to save space in user cabinets or machines. For this reason, Nexto Series delivers two different module widths: Double Width (two backplane rack slots are required) and Single Width (only one backplane rack slot is required). This concept allows the use of compact I/O modules with a high-density of I/O points along with complex modules, like CPUs, fieldbus masters and power supply modules. High-speed CPU: All Nexto Series CPUs were designed to provide an outstanding performance to the user, allowing the coverage of a large range of applications requirements. iF Product Design Award 2012: Nexto Series was the winner of iF Product Design Award 2012 in industry + skilled trades group. This award is recognized internationally as a seal of quality and excellence, considered the Oscars of the design in Europe.. 1.3. Documents Related to this Manual In order to obtain additional information regarding the Nexto Series, other documents (manuals and technical features) besides this one, may be accessed. These documents are available in its last version on the site https://www.altus.com.br/en/. Each product has a document designed by Technical Features (CE), where the product features are described. Furthermore, the product may have Utilization Manuals (the manuals codes are listed in the CE). For instance, the NX2020 module has the information for utilization features and purchasing on its CE. On another hand, the NX5001 has, besides the CE, a User Manual (MU). It is advised the following documents as additional information source: Code CE114000 CT114000 CS114000 CE114104 CT114104 CS114104 CE114700 CT114700 CS114700 CE114810 CT114810 CS114810 CE114902 CT114902 CS114902 CE114903 CT114903 CS114903 CE114908 CT114908 CS114908 MU214600 MU214000 MU214617 MU214105 Description Nexto Series Technical Characteristics Série Nexto Características Técnicas Serie Nexto Características Técnicas NX3005 Technical Characteristics Características Técnicas NX3005 Especificaciones y Configuraciones NX3005 Nexto Series Backplane Racks Technical Characteristic Características Técnicas dos Bastidores da Série Nexto Características Técnicas de los Bastidores de la Serie Nexto Nexto Series Accessories for Backplane Rack Technical Characteristics Características Técnicas Acessórios para Bastidor Série Nexto Características Técnicas del Cierres Laterales para el Bastidor Nexto Series PROFIBUS-DP Master Technical Characteristics Características Técnicas do Mestre PROFIBUS-DP da Série Nexto Características Técnicas del Módulo Profibus-DP Maestro Nexto Series Ethernet Module Technical Characteristics Características Técnicas Módulo Ethernet Série Nexto Características Técnicas del Modulo Ethernet Série Nexto NX5110 and NX5210 PROFIBUS-DP Heads Technical Characteristics Características Técnicas Interfaces Cabeça PROFIBUSDP NX5110 e NX5210 Especificaciones y Configuraciones PROFIBUS-DP Interfaz Cabezas NX5110 y NX5210 Nexto Series User Manual Manual de Utilização Série Nexto NX3005 CPU User Manual Manual de Utilização UCP NX3005 Language English Portuguese Spanish English Portuguese Spanish English Portuguese Spanish English Portuguese Spanish English Portuguese Spanish English Portuguese Spanish English Portuguese Spanish English Portuguese English Portuguese 3 1. INTRODUCTION Code MU299609 MU299048 MP399609 MP399048 MU214601 MU214001 MU214608 MU214108 MU214603 MU214606 MU214610 NAP151 NAP152 NAP165 NAP165_ing Description MasterTool IEC XE User Manual Manual de Utilização MasterTool IEC XE MasterTool IEC XE Programming Manual Manual de Programação MasterTool IEC XE NX5001 PROFIBUS DP Master User Manual Manual de Utilização Mestre PROFIBUS-DP NX5001 Nexto PROFIBUS-DP Head Utilization Manual Manual de Utilização da Cabeça PROFIBUS-DP Nexto Nexto Series HART Manual MQTT User Manual Advanced Control Functions User Manual Utilização do Tunneller OPC Extensão da potência de saída para até 20 W Comunicação OPC UA com Controladores ALTUS OPC UA Communication with ALTUS Controllers Table 1: Related documents Language English Portuguese English Portuguese English Portuguese English Portuguese English English English Portuguese Portuguese Portuguese English 4 1. INTRODUCTION 1.4. Visual inspection Before resuming the installation process, it is advised to carefully visually inspect the equipment, verifying the existence of transport damage. Verify if all parts requested are in perfect shape. In case of damages, inform the transport company or Altus distributor closest to you. CAUTION Before taking the modules off the case, it is important to discharge any possible static energy accumulated in the body. For that, touch (with bare hands) on any metallic grounded surface before handling the modules. Such procedure guaranties that the module static energy limits are not exceeded. It's important to register each received equipment serial number, as well as software revisions, in case they exist. This information is necessary, in case the Altus Technical Support is contacted. 1.5. Technical support For Altus Technical Support contact in São Leopoldo, RS, call +55 51 3589-9500. For further information regarding the Altus Technical Support existent on other places, see https://www.altus.com.br/en/ or send an email to altus@altus.com.br. If the equipment is already installed, you must have the following information at the moment of support requesting: The model from the used equipments and the installed system configuration The product serial number The equipment revision and the executive software version, written on the tag fixed on the product's side CPU operation mode information, acquired through MasterTool IEC XE The application software content, acquired through MasterTool IEC XE Used programmer version 1.6. Warning Messages Used in this Manual In this manual, the warning messages will be presented in the following formats and meanings: DANGER Reports potential hazard that, if not detected, may be harmful to people, materials, environment and production. CAUTION Reports configuration, application or installation details that must be taken into consideration to avoid any instance that may cause system failure and consequent impact. ATTENTION Identifies configuration, application and installation details aimed at achieving maximum operational performance of the system. 5 2. TECHNICAL DESCRIPTION 2. Technical description This chapter presents all technical features from Nexto Series CPU NX3005. 2.1. Panels and Connections The following figure shows the CPU front panel. Figure 3: NX3005 As it can be seen on the figure, on the front panel upper part is placed the graphic display used to show the whole system status and diagnostics, including the specific diagnostics of each module. The graphic display also offers an easy-to-use menu which brings to the user a quick mode for parameters reading or defining, such as: inner temperature (reading only) and local time (reading only). Just below the graphic display, there are 2 LEDs used to indicate alarm diagnostics and watchdog circuit. The table below shows the LEDs description. For further information regarding the LEDs status and meaning, see Diagnostics via LED section. LED DG WD Diagnostics LED Watchdog LED Description Table 2: LEDs Description Nexto Series CPUs has two switches available to the user. The table below shows the description of these switches. For further information regarding the diagnostics switch, see sections One Touch Diag. Keys Diagnostics Switch Description Switch placed on the module upper part. Used for diagnostics visualization on the graphic display or for navigation through the informative menu and CPU configuration. Table 3: Keys Description On the frontal panel the connection interfaces of Nexto Series CPUs are available. The table below presents a brief description of these interfaces. 6 2. TECHNICAL DESCRIPTION Interfaces NET 1 COM 1 Power Supply Description RJ45 communication connector 10/100Base-TX standard. Allows the point to point or network communication. For further utilization information, see Ethernet Interfaces Configuration section. DB9 female connector for RS-232 communication standard. Allows the point to point or network. For further utilization information, see Serial Interfaces Configuration section. Connection by terminal on pin V1 to 24 Vdc and pin N1 to 0 Vdc. It powers the CPU, counters, fast outputs and the rack, providing a power of up to 10 W for the latter. The pins V2 and N2, respectively 24 Vdc and 0 Vdc, powers the normal outputs and inputs. Table 4: Connection Interfaces 2.2. Common General Features 2.2.1. General features Backplane rack occupation Power supply integrated Ethernet TCP/IP local interface Serial Interface CAN Interface USB Port Host Memory Card Interface Real time clock (RTC) Watchdog Status and diagnostic Indication Programming languages Tasks Online changes Maximum number of tasks Maximum number of expansion bus Bus expansion redundancy support NX3005 2 sequential slots Yes 1 1 No No No Yes Resolution of 1 ms and maximum variance of 2 s per day. Yes Graphic display LEDs System Web Page CPU internal memory Structured Text (ST) Ladder Diagram (LD) Sequential Function Chart (SFC) Function Block Diagram (FBD) Continuous Function Chart (CFC) Cyclic (periodic) Event (software interruption) External (hardware interruption) Freewheeling (continuous) Status (software interruption) Yes 16 4 Yes 7 2. TECHNICAL DESCRIPTION Maximum number of I/O modules on the bus 64 Maximum number of additional Ethernet TCP/IP interface modules 1 Ethernet TCP/IP interface redundancy support No Maximum number of PROFIBUS-DP network (using master modules PROFIBUS-DP) 1 PROFIBUS-DP network redundancy support No Redundancy support (half-clusters) No Hot Swap support Yes Event oriented data reporting (SOE) No Protocol - Maximum Event Queue Size - Web pages development (available through the HTTP protocol) Yes One Touch Diag (OTD) Yes Electronic Tag on Display (ETD) Yes Table 5: Common Features NX3005 Notes: Real Time Clock (RTC): The retention time, time that the real time clock will continue to update the date and time after a CPU power down, is 15 days for operation at 25 C. At the maximum product temperature, the retention time is reduced to 10 days. Maximum number of I/O modules on bus: The maximum number of I/O modules refers to the sum of all modules on the local bus and expansions. 8 2. TECHNICAL DESCRIPTION 2.3. Standards and Certifications Standards and Certifications 61131-2: Industrial-process measurement and control - Programmable controllers - Part 2: Equipment requirements IEC and tests 61131-3: Programmable controllers - Part 3: Programming languages DNV Type Approval DNV-CG-0339 (TAA000013D) 2014/30/EU (EMC) 2014/35/EU (LVD) 2011/65/EU and 2015/863/EU (ROHS) S.I. 2016 No. 1091 (EMC) S.I. 2016 No. 1101 (Safety) S.I. 2012 No. 3032 (ROHS) UL/cUL Listed UL 61010-1 UL 61010-2-201 (file E473496) TR 004/2011 (LVD) CU TR 020/2011 (EMC) Table 6: Standards and Certifications 9 2. TECHNICAL DESCRIPTION 2.3.1. Memory Addressable input variables memory (%I) Addressable output variables memory (%Q) Direct representation variable memory (%M) Symbolic variable memory Persistent or Retain symbolic variables memory Full Redundant Data Memory Direct representation input variable memory (%I) Direct representation output variable memory (%Q) Direct representation variable memory (%M) Symbolic variable memory Program memory Source code memory (backup) User files memory Table 7: Memory NX3005 32 Kbytes 32 Kbytes 16 Kbytes 3 Mbytes 7.5 Kbytes 8 Mbytes 40 Mbytes 16 Mbytes Notes: Addressable input variables memory (%I): Area where the addressable input variables are stored. Addressable variables means that the variables can be accessed directly using the desired address. For instance: %IB0, %IW100. Addressable input variables can be used for mapping digital or analog input points. As reference, 8 digital inputs can be represented per byte and one analog input point can be represented per two bytes. Total addressable output variables memory (%Q): Area where the addressable output variables are stored. Addressable variables means that the variables can be accessed directly using the desired address. For instance: %QB0, %QW100. Addressable output variables can be used for mapping digital or analog output points. As reference, 8 digital outputs can be represented per byte and one analog output point can be represented per two bytes. The addressable output variables can be configured as retain, persistent or redundant variables, but the total size is not modified due to configuration. Addressable variables memory (%M): Area where the addressable marker variables are stored. Addressable variables means that the variables can be accessed directly using the desired address. For instance: %MB0, %MW100. Symbolic variables memory: Area where the symbolic variables are allocated. Symbolic variables are IEC variables created in POUs and GVLs during application development, which are not addressed directly in memory. Symbolic variables can be defined as retentive or persistent, in which case the memory areas of retentive symbolic variables or memory of persistent symbolic variables respectively will be used. The PLC system allocates variables in this area, so the space available for the allocation of variables created by the user is lower than that reported in the table. The occupation of the system variables depends on the characteristics of the project (number of modules, drivers, etc...), so it is recommended to observe the space available in the compilation messages of the MasterTool IEC XE tool. Persistent or Retain symbolic variables memory: Area where are allocated the retentive symbolic variables. The retentive data keep its respective values even after a CPU's cycle of power down and power up. The persistent data keep its respective values even after the download of a new application in the CPU. ATTENTION The declaration and use of symbolic persistent variables should be performed exclusively through the Persistent Vars object, which may be included in the project through the tree view in Application -> Add Object -> Persistent Variables. It should not be used to VAR PERSISTENT expression in the declaration of field variables of POUs. The full list of when the symbolic persistent variables keep their values and when the value is lost can be found in the table below. Besides the persistent area size declared in the table above, are reserved these 44 bytes to store information about the persistent variables (not available for use). The table below shows the behavior of retentive and persistent variables for different situations in which "-" means the value is lost and "X" means the value is kept. 10 2. TECHNICAL DESCRIPTION Command/Operation Power cycle Reset warm Reset cold Reset origin Remove CPU with integrated power supply from the rack while powered on Remove the power supply or a CPU without integrated power supply from the rack while powered on Download Online change Clean All Reset Process (IEC 60870-5-104) VAR - - - X - VAR RETAIN X X - X - X X Table 8: Variables Behavior after the Event VAR PERSISTENT X X X - X - X X X X In the case of Clean All command, if the application has been modified so that persistent variables have been removed, inserted into the top of the list or otherwise have had its modified type, the value of these variables is lost (when prompted by the tool MasterTool to download). Thus it is recommended that changes to the persistent variables GVL only include adding new variables on the list. Program memory: Program memory is the maximum size that can be used to store the user application. This area is shared with source code memory, being the total area the sum of "program memory" and "source code memory". From version 3.40 of MasterTool IEC XE on, the memory has been increased from 6 MBytes to 8 MBytes. Source code memory (backup): This memory area is used as project backup. If the user wants to import the project, MasterTool IEC XE will get the information required in this area. Care must be taken to ensure that the project saved as a backup is up to date to avoid the loss of critical information. This area is shared with source code memory, being the total area the sum of "program memory" and "source code memory". User files memory: This memory area offers another way for the user to store files such as doc, pdf, images, and other files. This function allows data recording as in a memory card. For further information check User Files Memory. 2.3.2. Protocols Open Protocol MODBUS RTU Master MODBUS RTU Slave MODBUS TCP Client MODBUS TCP Server MODBUS RTU over TCP Client MODBUS RTU over TCP Server CANopen Master CANopen Slave CAN low level SAE J-1939 OPC DA Server OPC UA Server EtherCAT Master SNMP Agent NX3005 Yes Yes Yes Yes Yes Yes Yes No No No No Yes Yes No Yes Interface COM1 COM1 COM1 NET1 NET1 NET1 NET1 NET1 NET1 NET1 11 2. TECHNICAL DESCRIPTION SOE (Event-oriented data) IEC 60870-5-104 Server EtherNet/IP Scanner EtherNet/IP Adapter MQTT Client SNTP Client (for clock synchronism) PROFINET Controller PROFINET Device NX3005 No Yes Yes Yes Yes Yes Yes No Table 9: Protocols Interface NET1 NET1 NET1 NET1 NET1 NET1 - Note: PROFINET Controller: Enabled for use on a simple (not ring) network with up to 8 devices. For larger applications, consult technical support. 2.3.3. Serial Interfaces 2.3.3.1. COM 1 Connector Physical interface Communication direction RS-422 transceivers RS-485 transceivers Termination maximum maximum Baud rate Isolation Logic to Serial Port Serial Port to protection earth COM 1 Shielded female DB9 RS-422 or RS-485 (depending on the selected cable) RS-422: full duplex RS-485: half duplex 11 (1 transmitter and 10 receivers) 32 Yes (optional via cable selection) 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps 1000 Vac / 1 minute 1000 Vac / 1 minute Table 10: COM 1 Serial Interface Features Notes: Physical Interface: Depending on configuration of the used cable, it is possible to choose the kind of physical interface: RS-422 or RS-485. The list of cables can be found at Related Products section. RS-422 Maximum Transceivers: It is the maximum number of RS-422 transceivers that can be used on a same bus. RS-485 Maximum Transceivers: It is the maximum number of RS-485 transceivers that can be used on a same bus. 12 2. TECHNICAL DESCRIPTION 2.3.4. Ethernet interfaces 2.3.4.1. NET 1 Connector Auto crossover Maximum cable length Cable type Baud rate Physical layer Data link layer Network layer Transport layer Diagnostic Isolation Ethernet interface to Serial Port NET 1 Shielded female RJ45 Yes 100 m UTP or ScTP, category 5 10/100 Mbps 10/100 BASE-TX (Full Duplex) LLC (Logical Link Control) IP (Internet Protocol)) TCP (Transmission Control Protocol) UDP (User Datagram Protocol) LEDs - green (speed), yellow (link/activity) 1500 Vac / 1 minute Table 11: Ethernet NET 1 Interface Features 2.3.5. Power Supply Nominal input voltage Maximum output power Maximum output current Input voltage Maximum input current (inrush) Maximum input current Maximum input voltage interrupt time Isolation Input to logic Input to protective earth Input to functional earth Cross section Polarity inversion protection Internal auto recovery fuse Output short-circuit protection Overcurrent protection Power Supply 24 Vdc 15 W 3A 19.2 to 30 Vdc 30 A 1.4 A 10 ms @ 24 Vdc 1000 Vac / 1 minute 1500 Vac / 1 minute 1000 Vac / 1 minute 0.5 mm2 Yes Yes Yes Yes Table 12: Power Supply Features Note: 13 2. TECHNICAL DESCRIPTION Maximum output power: Using modules I/O NextoJet, you can extend and get to use 20 W of power output. See Application Note NAP152 to meet the restrictions to use this limit. 2.3.6. Environmental Characteristics Current consumption on the power supply rail Dissipation Operating temperature Storage temperature Relative humidity Conformal coating IP Level Module dimensions (W x H x D) Package dimensions (W x H x D) Weight Weight with package NX3005 4W 0 to 60 C -25 to 75 C 5% to 96%, non-condensing Yes IP 20 36,00 x 114,63 x 115,30 mm 44,00 x 122,00 x 147,00 mm 350 g 400 g Table 13: Environmental Characteristics Notes: Conformal coating of electronic circuits: The covering of electronic circuits protects internal parts of the product against moisture, dust and other harsh elements to electronic circuits. 2.4. Compatibility with Other Products To develop an application for Nexto Series CPUs, it is necessary to check the version of MasterTool IEC XE. The following table shows the minimum version required (where the controllers were introduced) and the respective firmware version at that time: Nexto Series CPUs NX3005 NX3005 MasterTool IEC XE 2.07 to 2.09 3.00 or above Firmware version 1.6.0.0 to 1.7.17.0 1.8.11.0 or above Table 14: Compatibility with other products Additionally, along the development roadmap of MasterTool IEC XE some features may be included (like special Function Blocks, etc...), which can introduce a requirement of minimum firmware version. During the download of the application, MasterTool IEC XE checks the firmware version installed on the controller and, if it does not meets the minimum requirement, will show a message requesting to update. The latest firmware version can be downloaded from Altus website, and it is fully compatible with previous applications. 2.5. Performance The Nexto Series CPUs performance relies on: User Application Time Application Interval Operational System Time Module quantity (process data, input/output, among others) 14 2. TECHNICAL DESCRIPTION 2.5.1. Application Times The execution time of Nexto CPUs application depends on the following variables: Input read time (local and remote) Tasks execution time Output write time (local and remote) It is important to stress that the execution time of the "MainTask" will be directly influenced by the "Configuration" system task, a task of high priority, executed periodically by the system. The "Configuration" task may interrupt the "MainTask" and, when using the communication modules, as the Ethernet NX5000 module, for instance, the time addition to the "MainTask" may be up to 25% of the execution average time. 2.5.2. Time for Instructions Execution The table below presents the necessary execution time for different instructions. Instruction 1000 Contacts 1000 Divisions Language LD ST LD ST 1000 Multiplications LD ST 1000 Sums LD 1000 PID ST Variables BOOL INT REAL INT REAL INT REAL INT REAL INT REAL INT REAL REAL Instruction Times (µs) 6 43 81 43 81 15 23 15 23 15 23 15 23 < 5000 Table 15: Instruction Times 2.5.3. Initialization Times Nexto Series CPUs have initialization times of 50 s, and the initial screen with the NEXTO logo (Splash) is presented after 20 s from the power switched on. 2.5.4. Interval Time The interval time of the main task of the CPU can be set from 5 to 750 ms. 15 2. TECHNICAL DESCRIPTION 2.6. Physical Dimensions Dimensions in mm. Figure 4: NX3004 and NX3005 CPU Physical Dimensions 2.7. Purchase Data 2.7.1. Integrant Items The product package contains the following items: NX3005 module 6-terminal connector with fixing Installation guide 16 2. TECHNICAL DESCRIPTION 2.7.2. Product Code The following code should be used to purchase the product: Code NX3005 Description CPU, 1 Ethernet port, 1 serial channel, remote rack expansion support, power supply integrated and user web pages support Table 16: Product Code 2.8. Related Products The following products must be purchased separately when necessary: Code MT8500 AL-2600 AL-2306 AL-1763 NX9202 NX9205 NX9210 NX9404 NX9020 NX9000 NX9001 NX9002 NX9003 NX9010 Description MasterTool IEC XE RS-485 network branch and terminator RS-485 cable for MODBUS or CAN network CMDB9-Terminal Block Cable RJ45-RJ45 2 m Cable RJ45-RJ45 5 m Cable RJ45-RJ45 10 m Cable 6-terminal connector with fixing 2-Slot base for panel assembly 8-Slot Backplane Rack 12-Slot Backplane Rack 16-Slot Backplane Rack 24-Slot Backplane Rack 8-Slot Backplane Rack (No Hot Swap) Table 17: Related Products Notes: MT8500: MasterTool IEC XE is available in four different versions: LITE, BASIC, PROFESSIONAL and ADVANCED. For more details, please check MasterTool IEC XE User Manual - MU299609. AL-2600: This module is used for branch and termination of RS-422/485 networks. For each network node, an AL-2600 is required. The AL-2600 that is at the ends of network must be configured with termination, except when there is a device with active internal termination, the rest must be configured without termination. AL-2306: Two shielded twisted pairs cable without connectors, used for networks based on RS-485 or CAN. AL-1763: Cable with one DB9 male connector and terminal block for communication between CPUs of the Nexto Series and products with RS-485/RS-422 standard terminal block. NX9202/NX9205/NX9210: Cables used for Ethernet communication and to interconnect the bus expansion modules. NX9404: 6 terminal connector. NX9020: 2 slot base for panel assembly. 17 3. INSTALLATION 3. Installation This chapter presents the necessary proceedings for the Nexto Series CPUs physical installation, as well as the care that should be taken with other installation within the panel where the CPU is been installed. CAUTION If the equipment is used in a manner not specified by in this manual, the protection provided by the equipment may be impaired. 3.1. Mechanical Installation This product must be inserted in the backplane rack position 0. It requires two sequential positions, this means that it uses positions 0 and 1 of the rack. The mechanical assembly of this module is described in the Nexto Series User's Manual MU214600. 3.2. Electrical Installation DANGER When executing any installation in an electric panel, certify that the main energy supply is OFF. The figure below shows the CPUs NX3004 and NX3005 electric diagram installed in a Nexto Series backplane rack. The connectors placement depicted are merely illustrative. Figure 5: NX3004 and NX3005 CPU Electric Diagram 18 3. INSTALLATION Diagram Notes: 1. Ethernet interface 10/100Base-TX standard for programming, debugging and MODBUS TCP network connection or other protocols. 2. Serial interface RS-485/RS-422 standard for MODBUS RTU network connection or other protocols. The physical interface choice depends on the cable used. 3. The grounding from the external power source is connected to the terminal . Use 0.5 mm2 cables. 4. The power supply is connected to the terminals 24 V and 0 V. Use 0.5 mm2 cables. 5. The module feeds the other modules of the Nexto Series through rack connection. 6. The module is grounded through Nexto Series backplane rack. 3.3. Ethernet Network Connection The NET 1 isolated communication interface allows the connection with an Ethernet network, however, the NET 1 interface is the most suitable to be used for communication with MasterTool IEC XE. The Ethernet network connection uses twisted pair cables (10/100Base-TX) and the speed detection is automatically made by the Nexto CPU. This cable must have one of its endings connected to the interface that is likely to be used and another one to the HUB, switch, microcomputer or other Ethernet network point. 3.3.1. IP Address The NET 1 Ethernet interface is used for Ethernet communication and for CPU configuration which comes with the following default parameters configuration: IP Address Subnetwork Mask Gateway Address NET 1 192.168.15.1 255.255.255.0 192.168.15.253 Table 18: Default Parameters Configuration for Ethernet NET 1 Interface The IP Address and Subnet Mask parameters can be seen on the CPU graphic display via parameters menu, as described in CPU's Informative and Configuration Menu section. Initially, the NET 1 interface must be connected to a PC network with the same subnet mask to communicate with MasterTool IEC XE, where the network parameters can be modified. For further information regarding configuration and parameters modifications, see Ethernet Interfaces Configuration section. 3.3.2. Gratuitous ARP The NETx Ethernet interface promptly sends ARP packets type in broadcast informing its IP and MAC address for all devices connected to the network. These packets are sent during a new application download by the MasterTool IEC XE software and in the CPU startup when the application goes into Run mode. Five ARP commands are triggered within a 200 ms initial interval, doubling the interval every new triggered command, totalizing 3 s. Example: first trigger occurs at time 0, the second one at 200 ms and the third one at 600 ms and so on until the fifth trigger at time 3 s. 3.3.3. Network Cable Installation Nexto Series CPUs Ethernet ports, identified on the panel by NET, have standard pinout which are the same used in PCs. The connector type, cable type, physical level, among other details regarding the CPU and the Ethernet network device are defined in the Ethernet interfaces. The table below present the RJ-45 Nexto CPU female connector, with the identification and description of the valid pinout for 10BASE-TE and 100BASE-TX physical levels. 19 3. INSTALLATION Figure 6: RJ45 Female Connector Pin Signal Description 1 TXD + Data transmission, positive 2 TXD - Data transmission, negative 3 RXD + Data reception, positive 4 NU Not used 5 NU Not used 6 RXD - Data reception, negative 7 NU Not used 8 NU Not used Table 19: RJ45 Female Connector Pinout - 10BASE-TE and 100BASE-TX The interface can be connected in a communication network through a hub or switch, or straight from the communication equipment. In this last case, due to Nexto CPUs Auto Crossover feature, there is no need for a cross-over network cable, the one used to connect two PCs point to point via Ethernet port. It is important to stress that it is understood by network cable a pair of RJ45 male connectors connected by a UTP or ScTP cable, category 5 whether straight connecting or cross-over. It is used to communicate two devices through the Ethernet port. These cables normally have a connection lock which guarantees a perfect connection between the interface female connector and the cable male connector. At the installation moment, the male connector must be inserted in the module female connector until a click is heard, assuring the lock action. To disconnect the cable from the module, the lock lever must be used to unlock one from the other. 3.4. Serial Network Connection RS-485/422 The COM 1 isolated communication interface allow the connection to a RS-485/422 network. As follows it's presented the DB9 female connector to Nexto CPU, with identification and sign description. 20 3. INSTALLATION Figure 7: DB9 Female Connector Pin Sign Description 1 - Not used 2 Term+ Internal Termination, positive 3 TXD+ Data Transmission, positive 4 RXD+ Data Reception, positive 5 GND Negative Reference for External Termination 6 +5V Positive Reference for External Termination 7 Term- Internal Termination, negative 8 TXD- Data Transmission, negative 9 RXD- Data Reception, negative Table 20: COM 1 and COM 2 DB9 Female Connector Pin Layout 3.4.1. RS-485 Communication without termination In order to connect in a RS-485 network with no termination, the cable AL-1763 identified terminals must be connected in the respective device terminals, as shown on table below. AL-1763 terminals 0 1 2 3 4 5 6 7 8 Device terminal signals Shield Not connected D+ D+ Not connected Not connected Not connected DD- Table 21: RS-485 Connections without Termination The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. 21 3. INSTALLATION Figure 8: RS-485 Connections without Termination Diagram Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 3.4.2. RS-485 Communication with Internal Termination In order to connect in a RS-485 network using the internal termination, the cable AL-1763 identified terminals must be connected in the respective device terminals, as shown on table below. AL-1763 terminals 0 1 2 3 4 5 6 7 8 CPU terminal signals Shield D+ D+ D+ Not connected Not connected DDD- Table 22: RS-485 Connections with Internal Termination PS.: The internal termination available is a safe state type in open mode. The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. Figure 9: RS-485 Connections with Internal Termination Diagram 22 3. INSTALLATION Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 3.4.3. RS-485 Communication with External Termination In order to connect to a RS-485 network wih external termination, the AL-1763 cable identified terminals must be connected in the respective device terminals according to the table below. AL-1763 terminals 0 1 2 3 4 5 6 7 8 CPU terminal signals Shield Not connected D+ D+ 0V +5 V Not connected DD- Table 23: RS-485 Connections with External Termination The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. Figure 10: RS-485 Connections with External Termination Diagram Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 3.4.4. RS-422 Communication without Termination In order to connect in a RS-422 network with no termination, the cable AL-1763 identified terminals must be connected in the respective device terminals, as shown on table below. AL-1763 terminals 0 1 2 CPU terminal signals Shield Not connected TX+ 23 3. INSTALLATION AL-1763 terminals 3 4 5 6 7 8 CPU terminal signals RX+ Not connected Not connected Not connected TXRX- Table 24: RS-422 Connections without Termination The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. Figure 11: Connections without Termination Diagram Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 3.4.5. RS-422 Communication with Internal Termination In order to connect in a RS-422 network using the internal termination, the cable AL-1763 identified terminals must be connected in the respective device terminals, as shown on table below. AL-1763 terminals 0 1 2 3 4 5 6 7 8 CPU terminal signals Shield TERM+ TX+ RX+ Not connected Not connected TERMTXRX- Table 25: RS-422 Connections with Internal Termination PS.: The internal terminations available are secure state in open mode. The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. 24 3. INSTALLATION Figure 12: RS-422 Connections with Termination Diagram Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 3.4.6. RS-422 Communication with External Termination In order to connect in a RS-422 network using interface external termination, the cable AL-1763 identified terminals must be connected in the respective device terminals, as shown on table below. AL-1763 Terminals 0 1 2 3 4 5 6 7 8 CPU terminal signals Shield Not connected TX+ RX+ 0V +5 V Not connected TXRX- Table 26: RS-422 Connections with External Termination The figure diagram below indicates how the AL-1763 connection terminals should be connected in the device terminals. Figure 13: RS-422 Connections with External Termination Diagram Diagram Note: 1. The not connected terminals must be insulated so they do not make contact with each other. 25 3. INSTALLATION 3.4.7. RS-422 Network Example The figure below shows an example of RS-422 network utilization, using the Nexto CPU as master, slave devices with RS-422 Interface, and Altus solutions for terminators and connections. Figure 14: RS-422 Network Example Diagram Note: The AL-2600 modules which are in the network endings perform the terminators function. In this case the AL-2600 keys must be configured in PROFIBUS Termination. 3.5. Architecture Installation 3.5.1. Module Installation on the Main Backplane Rack Nexto Series has an exclusive method for connecting and disconnecting modules on the bus which does not require much effort from the operator and guarantee the connection integrity. For further information regarding Nexto Series products fixation, please see Nexto Series User Manual MU214600. 3.6. Programmer Installation To execute the MasterTool IEC XE development software installation, it is necessary to have the distribution CD-ROM or download the installation file from the site https://www.altus.com.br/en/. For further information about the step by step to installation, consult MasterTool IEC XE User Manual MT8500 MU299609. 26 4. INITIAL PROGRAMMING 4. Initial Programming The main goal of this chapter is to help the programming and configuration of Nexto Series CPUs, allowing the user to take the first steps before starting to program the device. Nexto Series CPU uses the standard IEC 61131-3 for language programming, which are: IL, ST, LD, SFC and FBD, and besides these, an extra language, CFC. These languages can be separated in text and graphic. IL and ST are text languages and are similar to Assembly and C, respectively. LD, SFC, FBD and CFC are graphic languages. LD uses the relay block representation and it is similar to relay diagrams. SFC uses the sequence diagram representation, allowing an easy way to see the event sequence. FBD and CFC use a group of function blocks, allowing a clear vision of the functions executed by each action. The programming is made through the MasterTool IEC XE (IDE) development interface. The MasterTool IEC XE allows the use of the six languages in the same project, so the user can apply the best features offered by each language, resulting in more efficient applications development, for easy documentation and future maintenance. For further information regarding programming, see MasterTool IEC XE User Manual - MU299609, MasterTool IEC XE Programming Manual - MP399609 or IEC 61131-3 standard. 4.1. Memory Organization and Access Nexto Series uses an innovative memory organization and access feature called big-endian, where the most significant byte is stored first and will always be the smallest address (e.g. %QB0 will always be more significant than %QB1, as in table below, where, for CPUNEXTO string, the letter C is byte 0 and the letter O is the byte 7). Besides this, the memory access must be done carefully as the variables with higher number of bits (WORD, DWORD, LONG), use as index the most significant byte, in other words, the %QD4 will always have as most significant byte the %QB4. Therefore it will not be necessary to make calculus to discover which DWORD correspond to defined bytes. The table below, shows little and big endian organization. BYTE WORD DWORD LWORD BYTE WORD DWORD LWORD MSB Little-endian LSB %QB7 %QB6 %QB5 %QB4 %QB3 %QB2 %QB1 %QB0 C P U N E X T O %QW3 %QW2 %QW1 %QW0 CP UN EX TO %QD1 %QD0 CPUN EXTO %QL0 CPUNEXTO MSB Big-endian LSB %QB0 %QB1 %QB2 %QB3 %QB4 %QB5 %QB6 %QB7 C P U N E X T O %QW0 %QW2 %QW4 %QW6 CP UN EX TO %QD0 %QD4 CPUN EXTO %QL0 CPUNEXTO Table 27: Memory Organization and Access Example 27 4. INITIAL PROGRAMMING MSB LSB MSB LSB Bit %QX0.7 %QX0.6 %QX0.5 %QX0.4 %QX0.3 %QX0.2 %QX0.1 %QX0.0 %QX1.7 %QX1.6 %QX1.5 %QX1.4 %QX1.3 %QX1.2 %QX1.1 %QX1.0 %QX2.7 %QX2.6 %QX2.5 %QX2.4 %QX2.3 %QX2.2 %QX2.1 %QX2.0 %QX3.7 %QX3.6 %QX3.5 %QX3.4 %QX3.3 %QX3.2 %QX3.1 %QX3.0 %QX4.7 %QX4.6 %QX4.5 %QX4.4 %QX4.3 %QX4.2 %QX4.1 %QX4.0 %QX5.7 %QX5.6 %QX5.5 %QX5.4 %QX5.3 %QX5.2 %QX5.1 %QX5.0 %QX6.7 %QX6.6 %QX6.5 %QX6.4 %QX6.3 %QX6.2 %QX6.1 %QX6.0 %QX7.7 %QX7.6 %QX7.5 %QX7.4 %QX7.3 %QX7.2 %QX7.1 %QX7.0 SIGNIFICANCE Byte Word DWord %QB 00 %QW 00 %QB 01 %QD 00 %QB 02 %QW 02 %QB 03 %QB 04 %QW 04 %QB 05 %QD 04 %QB 06 %QW 06 %QB 07 LWord %QL 00 OVERLAPPING Byte Word DWord %QB00 %QB01 %QW 00 %QB02 %QW 01 %QD 00 %QB03 %QW 02 %QD 01 %QB04 %QW 03 %QD 02 %QB05 %QW 04 %QD 03 %QB06 %QW 05 %QD 04 %QB07 %QW 06 Table 28: Memory Organization and Access 28 4. INITIAL PROGRAMMING The table above shows the organization and memory access, illustrating the significance of bytes and the disposition of other variable types, including overlapping. 4.2. Project Profiles A project profile in the MasterTool IEC XE consists in an application template together with a group of verification rules which guides the development of the application, reducing the programming complexity. The applications can be created according the following profiles: Single Basic Normal Expert Custom Machine Profile The Project Profile is selected on the project creation wizard. Each project profile defines a template of standard names for the tasks and programs, which are pre-created according to the selected Project Profile. Also, during the project compilation (generate code), MasterTool IEC XE verify all the rules defined by the selected profile. The following sections details the characteristics of each profile, which follow a gradual complexity slope. Based in these definitions, it's recommended that the user always use the simplest profile that meets his application needs, migrating to a more sophisticated profile only when the corresponding rules are being more barriers to development than didactic simplifications. It is important to note that the programming tool allows the profile change from an existent project (see project update section in the MasterTool IEC XE User Manual MU299609), but it's up to the developer to make any necessary adjustments so that the project becomes compatible with the rules of the new selected profile. ATTENTION Through the description of the Project profiles some tasks types are mentioned, which are described in the section `Task Configuration', of the MasterTool IEC XE User Manual MU299609. ATTENTION When more than one task is used, the I/O access can only be done in the context of the MainTask. In case that the option Enable I/O Update per Task can't be used, present as of MasterTool IEC XE version 2.01. 4.2.1. Single In the Single Project Profile, the application has only one user task, MainTask. This task is responsible for the execution of a single Program type programming unit called MainPrg. This single program can call other programming unit, of the Program, Function or Function Block types, but the whole code will be executed exclusively by the MainTask. In this profile, the MainTask will be of the cyclical type (Cyclic) with priority fixed as 13 (thirteen) and runs exclusively the MainPrg program in a continuous loop. The MainTask is already fully defined and the developer needs to create the MainPrg program, using any of the languages of the IEC 61131-3 standard. It is not always possible to convert a program to another language, but it's always possible to create a new program, built in a different language, with the same name and replace it. The MasterTool IEC XE standard option is to use the MasterTool Standard Project associated with the Single profile, which also include the MainPrg created in the language selected during the project creation. This type of application never needs to consider issues as data consistence, resource sharing or mutual exclusion mechanisms. Task POU Priority Type Interval Event MainTask MainPrg 13 Cyclic 20 ms - Table 29: Single Profile Task 29 4. INITIAL PROGRAMMING 4.2.2. Basic In the Basic Project Profile, the application has one user task of the Continuous type called MainTask, which executes the program in a continuous loop (with no definition of cycle time) with priority fixed in 13 (thirteen). This task is responsible for the execution of a single programming unit POU called MainPrg. It's important to notice that the cycle time may vary according to the quantity of communication tasks used, as in this mode, the main task is interrupted by communication tasks. This profile also allows the inclusion of two event tasks with higher priority, that can interrupt (preempt) the MainTask at any given moment: the task named ExternInterruptTask00 is an event task of the External type with priority fixed in 02 (two); the task named TimeInterruptTask00 is an event task of the Cyclic type with priority fixed as 01 (one). The Basic project template model includes three tasks already completely defined as presented in table below. The developer need only to create the associated programs. Tasks MainTask ExternInterruptTask00 TimeInterruptTask00 POU MainPrg ExternInterruptPrg00 TimeInterruptPrg00 Priority 13 02 01 Type Continuous External Cyclic Interval - 20 ms Event - IO_EVT_0 - Table 30: Basic Profile Tasks 4.2.3. Normal In the Normal Project Profile, the application has one user task of the Cyclic type, called MainTask. This task is responsible for the execution of a single programming unit POU called MainPrg. This program and this task are similar to the only task and only program of the Single profile, but here the application can integrate additional user tasks. These other tasks, named CyclicTask00 and CyclicTask01, each one responsible for the exclusive execution of its respective CyclicPrg<nn> program. The CyclicTask<nn> tasks are always of the cyclic type and with priority fixed in 13 (thirteen), same priority as MainTask. These two types form a group called basic tasks, which associated programs can call other POUs of the Program, Function and Function Block types. Furthermore, this profile can include event tasks with higher priority than the basic tasks, which can interrupt (preempt) these tasks execution at any time. The task called ExternInterruptTask00 is an event task of the External type which execution is triggered by some external event, such as the variation of a control signal on a serial port or the variation of a digital input on the NEXTO bus. This task priority is fixed in 02 (two), being responsible exclusively for the execution of the ExternInterruptPrg00 program. The task called TimeInterruptTask00 is an event task of the Cyclic type with a priority fixed as 01 (one), being responsible for the execution exclusively of TimeInterruptPrg00 program. In the Normal project model, there are five tasks, and its POUs, already fully defines as shown in table below. The developer needs only to implement the programs content, opting, on the wizard, for any of the languages in IEC 61131-3 standard. The tasks interval and trigger events can be configured by the developer and the unnecessary tasks can be eliminated. Tasks MainTask CyclicTask00 CyclicTask01 ExternInterruptTask00 TimeInterruptTask00 POU MainPrg CyclicPrg00 CyclicPrg01 ExternInterruptPrg00 TimeInterruptPrg00 Priority 13 13 13 02 01 Type Cyclic Cyclic Cyclic External Cyclic Interval 20 ms 200 ms 500 ms 20 ms Event - IO_EVT_0 - Table 31: Normal Profile Tasks 4.2.4. Expert The Expert Project Profile includes the same basic tasks, CyclicTask<nn>, ExternInterruptTask00 and TimeInterruptTask00 with the same priorities (13, 02 and 01 respectively), but it's an expansion from the previous ones, due to accept multiple events tasks. That is, the application can include various ExternInterruptTask<nn> or TimeInterruptTask<nn> tasks that execute the ExternInterruptPrg<nn> and TimeInterruptPrg<nn> programs. The additional event tasks priorities can be freely selected from 08 to 12. In this profile, besides the standard programs, each task can execute additional programs. 30 4. INITIAL PROGRAMMING In this project profile, the application may also include the user task FreeTask of the Freewheeling type with priority 31, responsible for the FreePrg program execution. As this task is low priority it can be interrupted by all others so it can execute codes that might be blocked. There are eight tasks already fully defined, as shown in table below, as well as their associated programs in the chosen language. Intervals and trigger events of any task, as well as the priorities of the event tasks can be configured by the user. When developing the application using Expert project's profile, a special care is needed with the event tasks scaling. If there is information and resource sharing between these tasks or between them and the basic tasks, it is strongly recommended to adopt strategies to ensure data consistency. Tasks MainTask CyclicTask00 CyclicTask01 ExternInterruptTask00 TimeInterruptTask00 ExternInterruptTask01 TimeInterruptTask01 FreeTask POU MainPrg CyclicPrg00 CyclicPrg01 ExternInterruptPrg00 TimeInterruptPrg00 ExternInterruptPrg01 TimeInterruptPrg01 FreePrg Priority 13 13 13 02 01 11 09 31 Type Cyclic Cyclic Cyclic External Cyclic External Cyclic Continuous Interval 20 ms 200 ms 500 ms 20 ms 30 ms - Event - IO_EVT_0 - IO_EVT_1 - Table 32: Expert Profile Tasks 4.2.5. Custom The Custom project profile allows the developer to explore all the potential of the Runtime System implemented in the Nexto Series central processing units. No functionality is disabled; no priority, task and programs association or nomenclatures are imposed. The only exception is for MainTask, which must always exist with this name in this Profile. Beyond the real time tasks, with priority between 00 and 15, which are scheduled by priority, in this profile it is also possible to define tasks with lower priorities in the range 16 to 31. In this range, it's used the Completely Fair Scheduler (time sharing), which is necessary to run codes that can be locked (for example, use of sockets). The developer is free to partially follow or not the organization defined in other project profiles, according to the characteristics of the application. On the other hand, the Custom model associated with this profile needs no pre-defining elements such as task, program or parameter, leaving the developer to create all the elements that make up the application. However, the user can generate the same elements available for the Expert profile. Tasks MainTask CyclicTask00 CyclicTask01 ExternInterruptTask00 TimeInterruptTask00 ExternInterruptTask01 TimeInterruptTask01 FreeTask POU MainPrg CyclicPrg00 CyclicPrg01 ExternInterruptPrg00 TimeInterruptPrg00 ExternInterruptPrg01 TimeInterruptPrg01 FreePrg Priority 13 13 13 02 01 11 09 31 Type Cyclic Cyclic Cyclic External Cyclic External Cyclic Continuous Interval 20 ms 200 ms 500 ms 20 ms 30 ms - Event - IO_EVT_0 - IO_EVT_1 - Table 33: Custom Profile Tasks 4.2.6. Machine Profile In the Machine Profile, by default, the application has a user task of the Cyclic type called MainTask. This task is responsible for implementing a single Program type POU called MainPrg. This program can call other programming units of the Program, Function or Function Block types, but any user code will run exclusively by MainTask. This profile is characterized by allowing shorter intervals in the MainTask, allowing faster execution of user code. This optimization is possible because MainTask also performs the processing of the bus. This way, different from other profiles, the machine profile requires no context switch for the bus treatment, which reduces the overall processing time. 31 4. INITIAL PROGRAMMING This profile may further include an interruption task, called TimeInterruptTask00, with a higher priority than the MainTask, and hence, can interrupt its execution at any time. Tasks MainTask TimeInterruptTask00 POU MainPrg TimeInterruptPrg00 Priority 13 01 Type Cyclic Cyclic Interval 20 ms 4 ms Event - Table 34: Machine Profile Tasks Also, this profile supports the inclusion of additional tasks associated to the external interruptions. 4.2.7. General Table Total tasks Tasks per program Type Main Task Priority Quantity Time Type Interrupt Priority Task Quantity Extern Type Interrupt Priority Task Quantity Type Ciclic Task Priority Quantity Type Free Task Priority Quantity Type Event Task Priority Quantity Single 01 01 Cyclic 13 01 Machine 04 Cyclic 13 01 Cyclic 01 [00..01] External 02 [00..01] Project Profiles Basic Normal Expert [01..03] [01..32] [01..32] 01 01 <n> Continuous Cyclic Cyclic 13 13 13 01 01 01 Cyclic Cyclic Cyclic 01 01 01 or [08..12] [00..01] [00..01] [00..31] External External External 02 02 02 or [08..12] [00..01] [00..01] [00..31] Cyclic Cyclic 13 13 [00..31] [00..31] Continuous 31 [00..01] Custom [01..32] <n> Cyclic 13 01 Cyclic 01 or [08..12] [00..31] External 02 or [08..12] [00..31] Cyclic 13 [00..31] Continuous 31 [00..01] Event <n> [00..31] Table 35: General Profile x Tasks Table ATTENTION The suggested POU names associated with the tasks are not consisted. They can be changed, as long as they are also changed in the tasks configurations. 4.2.8. Maximum Number of Tasks The maximum number of tasks that the user can create is only defined for the Custom profile, the only one which has this permission. The others already have their tasks created and configured. However, the tasks that will be created must use the following prefixes, according to the type of each of the tasks: CyclicTaskxx, TimeInterruptTaskxx, ExternInterruptTaskxx, where xx represents the number of the task that being created. The table below describes the maximum IEC task quantity per CPU and project profile, where the protocol instances are also considered communication tasks by the CPU. 32 4. INITIAL PROGRAMMING Configuration Task (Task WHSB) User Tasks NETs Client or Server Instances COM (n) Master or Slave Instances TOTAL Task Type Cyclic Cyclic Triggered by Event Triggered by External Event Freewheeling Triggered by State Cyclic Cyclic NX3003 / NX3004 / NX3005 SB N E P M 11 1 1 1 0 1 1 15 15 15 4 0 0 0 0 15 0 0 1 1 14 15 2 0 1 0 1 15 0 0 0 0 0 15 0 4 1 16 Table 36: Tasks Maximum Number IEC Notes: Profiles Legend: The letters S, B, N, E, P and M correspond respectively to Simple, Basic, Normal, Experienced, Custom and Machine Profiles. Values: The numbers defined for each task type represent the (Maximum values allowed). WHSB Task: A WHSB task that is a system task should be considered so that it is not exceeded or full value. NETs - Client or Server Instances: The defined maximum value considers all Ethernet interfaces of the system, that is, it includes the expansion modules, when they are applicable. Examples for this type of task are how to engineer the MODBUS protocol. COM (n) - Master or Slave instances: The "n" represents the serial interface number, that is, even with expansion modules, the table value will be the maximum per interface. Examples for this type of task are how to engineer the MODBUS protocol. Total: The total value does not represent the sum of all tasks per profile, but the maximum value allowed per CPU. Then, the user will be able to create several types of tasks, as long as the number established for each one and the total value are not exceeded. 4.3. CPU Configuration The Nexto CPU configuration is located in the device tree, as shown on figure below, and can be accessed by a double-click on the corresponding object. In this tab it's possible to configure the diagnostics area, the retentive and persistent memory area and hot swap mode, among other parameters, as described in the CPU Configuration. Figure 15: CPU Configuration 33 4. INITIAL PROGRAMMING Besides that, by double-clicking on CPU's NET 1 icon, it's possible to configure the Ethernet interface that will be used for communication between the controller and the software MasterTool IEC XE. Figure 16: Configuring the CPU Communication Port The configuration defined on this tab will be applied to the device only when sending the application to the device (download), which is described further on sections Finding the Device and Login. 4.4. Libraries There are several programming tool resources which are available through libraries. Therefore, these libraries must be inserted in the project so its utilization becomes possible. The insertion procedure and more information about available libraries must be found in the MasterTool Programming Manual MP399609. 4.5. Inserting a Protocol Instance The Nexto Series CPUs, as described in the Protocols section, offers several communication protocols. Except for the OPC DA and OPC UA communication, which have a different configuration procedure, the insertion of a protocol can be done by simply right-clicking on the desired communication interface, selecting to add the device and finally performing the configuration as shown in the Protocols Configuration section. Below is presented an examples. 4.5.1. MODBUS Ethernet The first step to configure the MODBUS Ethernet (Client in this example), is to include the instance in the desired NET (in this case, NET 1, as the CPU NX3010 has only one Ethernet interface). Click on the NET with the mouse right button and select Add Device..., as shown on figure below. 34 4. INITIAL PROGRAMMING Figure 17: Adding the Instance After that, the available protocols for the user will appear on the screen. In this menu is defined the configuration mode of the protocol. Selecting the option MODBUS Symbol Client, for Symbolic Mapping setting or MODBUS Client, for Direct Addressing (%Q). Then, click Add Device, as shown in the figure below. 35 4. INITIAL PROGRAMMING Figure 18: Selecting the Protocol 4.6. Finding the Device To establish the communication between the CPU and MasterTool IEC XE, first it's necessary to find and select the desired device. The configuration of this communication is located on the object Device on device tree, on Communication Settings tab. On this tab, after selecting the Gateway and clicking on button Scan network, the software MasterTool IEC XE performs a search for devices and shows the CPUs found on the network of the Ethernet interface of the station where the tool is running. Figure 19: Finding the CPU If there is no gateway previously configured, it can be included by the button Add gateway, using the default IP address localhost to use the gateway resident on the station or changing the IP address to use the device internal gateway. Next, the desired controller must be selected by clicking on Set active path. This action selects the controller and informs the configuration software which controller shall be used to communicate and send the project. 36 4. INITIAL PROGRAMMING Figure 20: Selecting the CPU Additionally, the user can change the default name of the device that is displayed. For that, you must click the right mouse button on the desired device and select Change Device Name. After a name change, the device will not return to the default name under any circumstances. In case the Ethernet configuration of the CPU to be connected is in a different network from the Ethernet interface of the station, the software MasterTool IEC XE will not be able to find the device. In this case, it's recommended to use the command Easy Connection located on Online menu. Figure 21: Easy Connection This command performs a MAC level communication with the NET 1 interface of the device, allowing to permanently change the configuration of the CPU's Ethernet interface, independently of the IP configuration of the station and from the one previously configured on the device. So, with this command, it's possible to change the device configuration to put it on the same network of the Ethernet interface of the station where MasterTool IEC XE is running, allowing to find and select the device for the communication. The complete description of Easy Connection command can be found on User Manual of MasterTool IEC XE code MU299609. 37 4. INITIAL PROGRAMMING 4.7. Login After compiling the application and fixing errors that might be found, it's time to send the project to the CPU. To do this, simply click on Login command located on Online menu of MasterTool IEC XE as shown on the following figure. This operation may take a few seconds, depending on the size of the generated file. Figure 22: Sending the Project to the CPU After the command execution, some user interface messages may appear, which are presented due to differences between an old project and the new project been sent, or simply because there was a variation in some variable. If the Ethernet configuration of the project is different from the device, the communication may be interrupted at the end of download process when the new configuration is applied on the device. So, the following warning message will be presented, asking the user to proceed or not with this operation. Figure 23: IP Configuration Warning If there is no application on the CPU, the following message will be presented. 38 4. INITIAL PROGRAMMING Figure 24: No application on the device If there is already an application on the CPU, depending on the differences between the projects, the following options will be presented: Login with online change: execute the login and send the new project without stopping the current CPU application (see Run Mode item), updating the changes when a new cycle is executed. Login with download: execute the login and send the new project with the CPU stopped (see Stop Mode). When the application is initiated, the update will have been done already. Login without any change: executes the login without sending the new project. Figure 25: Project Update at the CPU ATTENTION In the online changes is not permitted to associate symbolic variables mapping from a global variable list (GVL) and use these variables in another global variable list (GVL). If the new application contains changes on the configuration, the online change will not be possible. In this case, the MasterTool IEC XE requests whether the login must be executed as download (stopping the application) or if the operation must be cancelled. PS.: The button Details... shows the changes made in the application. Figure 26: Configuration Changes Finally, at the end of this process the MasterTool IEC XE offers the option to transfer (download) the source code to the internal memory of the device, as shown on the following figure: 39 4. INITIAL PROGRAMMING Figure 27: Source code download Transferring the source code is fundamental to ensure the future restoration of the project and to perform modifications on the application that is loaded into the device. 4.8. Run Mode Right after the project has been sent to the CPU, the application will not be immediately executed (except for the case of an online change). For that to happen, the command Start must be executed. This way, the user can control the execution of the application sent to the CPU, allowing pre-configuring initial values which will be used by the CPU on the first execution cycle. To execute this command, simply go to the Debug menu and select the option Start, as shown on figure below. Figure 28: Starting the Application The figure below shows the application in execution. In case the POU tab is selected, the created variables are listed on a monitoring window, in which the values can be visualized and forced by the user. 40 4. INITIAL PROGRAMMING Figure 29: Program running If the CPU already have a boot application internally stored, it goes automatically to Run Mode when the device is powered on, with no need for an online command through MasterTool IEC XE. 4.9. Stop Mode To stop the execution of the application, the user must execute the Stop command, available at the menu Debug, as shown on figure below. Figure 30: Stopping the Application In case the CPU is initialized without the stored application, it automatically goes to Stop Mode, as it happens when a software exception occurs. 4.10. Writing and Forcing Variables After Logging into a PLC, the user can write or force values to a variable of the project. The writing command (CTRL + F7) writes a value into a variable and this value could be overwritten by instructions executed in the application. 41 4. INITIAL PROGRAMMING Moreover, the forced writing command (F7) writes a value into a variable without allowing this value to be changed until the forced variables are released. It is important to highlight that, when used the MODBUS RTU Slave and the MODBUS Ethernet Server, and the Read-only option from the configured relations is not selected, the forced writing command (F7) must be done over the available variables in the monitoring window as the writing command (CTRL + F7) leaves the variables to be overwritten when new readings are done. ATTENTION The variables forcing can be done in Online mode. Diagnostic variables cannot be forced, only written, because diagnostics are provided by the CPU and will be overwritten by it. ATTENTION When a CPU is with forced variables and it is de-energized, the variables will lose the forcing in the next initialization. The limit of forcing for the Nexto CPUs is 128 variables, regardless of model or configuration of CPU used. 4.11. Logout To finalize the online communication with the CPU, the command Logout must be executed, located in the Online menu, as shown on figure below. Figure 31: Finalizing the online communication with the CPU 4.12. Project Upload Nexto Series CPUs are capable to store the source code of the application on the internal memory of the device, allowing future retrieval (upload) of the complete project and to modify the application. To recover a project previously stored on the internal memory of the CPU, the command located on File menu must be executed as shown on the following figure. 42 4. INITIAL PROGRAMMING Figure 32: Project Upload Option Next, just select the desired CPU and click OK, as shown on figure below. Figure 33: Selecting the CPU To ensure that the project loaded in the CPU is identical and can be accessed in other workstations, consult the chapter Projects Download/Login Method without Project Differences at the MasterTool IEC XE User Manual MT8500 - MU299609. ATTENTION The memory size area to store a project in the Nexto CPUs is defined on section Memory. 43 4. INITIAL PROGRAMMING ATTENTION The upload recovers the last project stored in the controller as described in the previous paragraphs. In case only the application was downloaded, without transferring its source code, it will not be possible to be recovered by the Upload procedure. 4.13. CPU Operating States 4.13.1. Run When a CPU is in Run mode, all application tasks are executed. 4.13.2. Stop When a CPU is in Stop mode, all application tasks are stopped. The variable values in the tasks are kept with the current value and output points go to the safe state. When a CPU goes to the Stop mode due to the download of an application, the variables in the application tasks will be lost except the persistent variables type. 4.13.3. Breakpoint When a debugging mark is reached in a task, it is interrupted. All the active tasks in the application will not be interrupted, continuing their execution. With this feature, it's possible to go through and investigate the program flow step by step in Online mode according to the positions of the interruptions included through the editor. For further information about the use of breakpoints, please consult the MasterTool IEC XE Utilization Manual - MU299609. 4.13.4. Exception When a CPU is in Exception it indicates that some improper operation occurred in one of the application active tasks. The task which caused the Exception will be suspended and the other tasks will pass for the Stop mode. It is only possible to take off the tasks from this state and set them in execution again after a new CPU start condition. Therefore, only with a Reset Warm, Reset Cold, Reset Origin or a CPU restart puts the application again in Run mode. 4.13.5. Reset Warm This command puts the CPU in Stop mode and initializes all the application tasks variables, except the persistent and retentive type variables. The variables initialized with a specific value will assume exactly this value, the other variables will assume the standard initialization value (zero). 4.13.6. Reset Cold This command puts the CPU in Stop mode and initializes all the application tasks variables, except the persistent type variables. The variables initialized with a specific value will assume exactly this value, the other variables will assume the standard initialization value (zero). 4.13.7. Reset Origin This command removes all application task variables, including persistent type variables, deletes the application CPU and puts the CPU in Stop mode. Notes: Reset: When a Reset is executed, the breakpoints defined in the application are disabled. Command: To execute the commands Reset Warm, Cold or Origin, it's necessary to have MasterTool IEC XE in Online mode with the CPU. 44 4. INITIAL PROGRAMMING 4.13.8. Reset Process Command (IEC 60870-5-104) This process reset command can be solicited by IEC 60870-5-104 clients. After answer the client, the CPU start a rebooting process, as if being done an energizing cycle. In case of redundant PLCs, the process reset command is synchronized with the non-active PLC, resulting the reboot of both PLCs. The standard IEC 60870-5-104 foresee a qualification value pass (0..255) with the process reset command, but this "parameter" is not considered by the CPU. 4.14. Programs (POUs) and Global Variable Lists (GVLs) The project created by MasterTool IEC XE contains a set of program modules (POUs) and global variables lists that aims to facilitate the programming and utilization of the controller. The following sections describe the main elements that are part of this standard project structure. 4.14.1. MainPrg Program The MainTask is associated to one unique POU of program type, named MainPrg. The MainPrg program is created automatically and cannot be edited by user. The MainPrg program code is the following, in ST language: (*Main POU associated with MainTask that calls StartPrg, UserPrg/ActivePrg and NonSkippedPrg. This POU is blocked to edit.*) PROGRAM MainPrg VAR isFirstCycle : BOOL := TRUE; END_VAR SpecialVariablesPrg(); IF isFirstCycle THEN StartPrg(); isFirstCycle := FALSE; ELSE UserPrg(); END_IF; MainPrg call other two POUs of program type, named StartPrg and UserPrg. While the UserPrg is always called, the StartPrg is only called once in the PLC application start. To the opposite of MainPrg program, that must not be modified, the user can change the StartPrg and UserPrg programs. Initially, when the project is created from the wizard, these two programs are created empty, but the user might insert code in them. 4.14.2. StartPrg Program In this POU the user might create logics, loops, start variables, etc. that will be executed only one time in the first PLC's cycle, before execute UserPrg POU by the first time. And not being called again during the project execution. In case the user load a new application, or if the PLC gets powered off, as well as in Reset Origin, Reset Cold and Reset Warm conditions, this POU is going to be executed again. 4.14.3. UserPrg Program In this POU the user must create the main application, responsible by its own process control. This POU is called by the main POU (MainPrg). 45 4. INITIAL PROGRAMMING The user can also create additional POUs (programs, functions or function blocks), and called them or instance them inside UserPrg POU, to ends of its program instruction. Also it is possible to call functions and instance function blocks defined in libraries. 4.14.4. GVL System_Diagnostics The System_Diagnostics GVL contains the diagnostic variables of the CPU, of the communication interface (Ethernet and PROFIBUS) and of all communication drivers. This GVL isn't editable and the variables are declared automatically with type specified by the device to which it belongs when it is added to the project. ATTENTION In System_Diagnostics GVL, are also declared the diagnostic variables of the direct representation MODBUS Client/Master Requests. Some devices, like the MODBUS Symbol communication driver, doesn't have its diagnostics allocated at %Q variables with the AT directive. The same occurs with newest communication drivers, as Server IEC 60870-5-104. The following picture shows an example of the presentation of this GVL when in Online mode. Figure 34: System_Diagnostics GVL in Online Mode 46 4. INITIAL PROGRAMMING 4.14.5. GVL Disables The Disables GVL contains the MODBUS Master/Client by symbolic mapping requisition disabling variables. It is not mandatory, but it is recommended to use the automatic generation of these variables, which is done clicking in the button Generate Disabling Variables in device requisition tab. These variables are declared as type BOOL and follow the following structure: Requisition disabling variables declaration: [Device Name]_DISABLE_[Requisition Number] : BOOL; Where: Device name: Name that shows on Tree View to the MODBUS device. Requisition Number: Requisition number that was declared on the MODBUS device requisition table following the sequence from up to down, starting on 0001. Example: Device.Application.Disables VAR_GLOBAL MODBUS_Device_DISABLE_0001 : BOOL; MODBUS_Device_DISABLE_0002 : BOOL; MODBUS_Device_DISABLE_0003 : BOOL; MODBUS_Device_1_DISABLE_0001 : BOOL; MODBUS_Device_1_DISABLE_0002 : BOOL; END_VAR The automatic generation through button Generate Disabling Variables only create variables, and don't remove automatically. This way, in case any relation is removed, its respective disabling variable must be removed manually. The Disables GVL is editable, therefore the requisition disabling variables can be created manually without need of following the model created by the automatic declaration and can be used both ways at same time, but must always be of BOOL type. And it is need to take care to do not delete or change the automatic declared variables, cause them can being used for some MODBUS device. If the variable be deleted or changed then an error is going to be generated while the project is being compiled. To correct the automatically declared variable name, it must be followed the model exemplified above according to the device and the requisition to which they belong. The following picture shows an example of the presentation of this GVL when in Online mode. If the variable values are TRUE it means that the requisition to which the variables belong is disabled and the opposite is valid when the variable value is FALSE. Figure 35: Disable GVL in Online Mode 4.14.6. GVL IOQualities The IOQualities GVL contains the quality variables of I/O modules declared on CPU's bus. This GVL is not editable and the variables are automatically declared as LibDataTypes.QUALITY type arrays, and dimensions according to I/Os quantities of the module to which it belongs when that is added to the project. 47 4. INITIAL PROGRAMMING Example: Device.Application.IOQualities VAR_GLOBAL QUALITY_NX1001: ARRAY[0..15] QUALITY_NX2020: ARRAY[0..15] QUALITY_NX6000: ARRAY[0..7] QUALITY_NX6100: ARRAY[0..3] END_VAR OF LibDataTypes.QUALITY; OF LibDataTypes.QUALITY; OF LibDataTypes.QUALITY; OF LibDataTypes.QUALITY; Once the application is in RUN it is possible to watch the I/O modules quality variables values that were added to the project through IOQualities GVL. 4.14.7. GVL Module_Diagnostics The Module_Diagnostics GVL contains the diagnostics variables of the I/O modules used in the project, except by the CPU and communication drivers. This GVL isn't editable and the variables are automatically declared with type specified by the module, to which it belongs, when that is added to the project. The following picture shows an example of the presentation of this GVL when in Online mode. Figure 36: Module_Diagnostics GVL in Online Mode 48 4. INITIAL PROGRAMMING 4.14.8. GVL Qualities The Qualities GVL contains the quality variable of the internal variables MODBUS Master/Client of symbolic mapping. It is not mandatory but is recommended to use these variables' automatic generation, what is done clicking on button Generate Quality Variables in the device mapping tab. These variables are declared as LibDataTypes.QUALITY type and follow the following structure: Quality mapping variable declaration: [Device Name]_QUALITY_[Mapping Number]: LibDataTypes.QUALITY; Where: Device Name: Name that appear at the Tree View to the device. Mapping Number: Number of the mapping that was declared on the device mapping table, following the up to down sequence, starting with 0001. ATTENTION It is not possible to associate quality variables to the direct representation MODBUS Master/Client drivers' mappings. Therefore it is recommended the use of symbolic mapping MODBUS drivers. Example: Device.Application.Qualities VAR_GLOBAL MODBUS_Device_QUALITY_0001: LibDataTypes.QUALITY; MODBUS_Device_QUALITY_0002: LibDataTypes.QUALITY; MODBUS_Device_QUALITY_0003: LibDataTypes.QUALITY; END_VAR The Qualities GVL is editable, therefore the mapping quality variables can be created manually without need to follow the automatic declaration model, and can be used both ways at same time. But must always be of LibDataTypes.QUALITY type and take care to don't delete or change a variable automatically declared, because they might being used by some device. If the variable be deleted or changed an error is going to be generated while the project is being compiled. To correct the automatically declared variable name, it must be followed the model exemplified above according to the device and the requisition to which they belong. To the MODBUS communication devices the quality variables behave on the way showed at Table 47. The following picture shows an example of the presentation of this GVL when in Online mode. ATTENTION If a symbolic mapping MODBUS Client/Master driver's variable be mapped in IEC 608705-104 Server driver, it is necessary that the MODBUS mapping quality variables had been created to generate valid quality events to such IEC 60870-5-104 Server points. Case opposite, aren't going to be generated "bad" quality events to IEC 60870-5-104 Server clients in the situations that MODBUS Master/Client can't communicate with its slaves/servers, by example. 49 4. INITIAL PROGRAMMING Figure 37: Qualities GVL in Online Mode 4.14.9. GVL ReqDiagnostics The ReqDiagnostics GVL contains the requisition diagnostics variables of symbolic mapping MODBUS Master/Client. It is not mandatory, but recommended the use of these variables' automatic generation, what is done by clicking in the button Generate Diagnostics Variables in device requests tab. These variables declaration follow the following structure: Requisition diagnostic variable declaration: [Device Name]_REQDG_[Requisition Number]: [Variable Type]; Where: Device Name: Name that appear at the Tree View to the device. Mapping Number: Number of the mapping that was declared on the device mapping table, following the up to down sequence, starting with 0001. Variable Type: NXMODBUS_DIAGNOSTIC_STRUCTS.T_DIAG_MODBUS_RTU_MAPPING_1 to MODBUS Master and NXMODBUS_DIAGNOSTIC_STRUCTS.T_DIAG_MODBUS_ETH_MAPPING_1 to MODBUS Client. 50 4. INITIAL PROGRAMMING ATTENTION The requisition diagnostics variables of direct mapping MODBUS Master/Client are declared at System_Diagnostics GVL. Example: Device.Application.ReqDiagnostics VAR_GLOBAL MODBUS_Device_REQDG_0001 : NXMODBUS_DIAGNOSTIC_STRUCTS. T_DIAG_MODBUS_RTU_MAPPING_1; MODBUS_Device_REQDG_0002 : NXMODBUS_DIAGNOSTIC_STRUCTS. T_DIAG_MODBUS_RTU_MAPPING_1; MODBUS_Device_REQDG_0003 : NXMODBUS_DIAGNOSTIC_STRUCTS. T_DIAG_MODBUS_RTU_MAPPING_1; MODBUS_Device_1_REQDG_0001 : NXMODBUS_DIAGNOSTIC_STRUCTS. T_DIAG_MODBUS_ETH_MAPPING_1; MODBUS_Device_1_REQDG_0002 : NXMODBUS_DIAGNOSTIC_STRUCTS. T_DIAG_MODBUS_ETH_MAPPING_1; END_VAR The ReqDiagnostics GVL is editable, therefore the requisitions diagnostic variables can be manually created without need to follow the model created by the automatic declaration. Both ways can be used at same time, but the variables must always be of type referring to the device. And take care to don't delete or change a variable automatically declared, because they might being used by some device. If the variable be deleted or changed an error is going to be generated while the project is being compiled. To correct the automatically declared variable name, it must be followed the model exemplified above according to the device and the requisition to which they belong. The following picture shows an example of the presentation of this GVL when in Online mode. Figure 38: ReqDiagnostics GVL in Online Mode 4.14.10. Prepare_Start Function In this POU, the PrepareStart system event function is defined. It belongs to the communication task and is called before starting the application. When there is active communication with the PLC, it is possible to observe the event status and the call count in the System Events tab in the Task Configuration object. Every time the user starts the application, the count is incremented. 51 4. INITIAL PROGRAMMING 4.14.11. Prepare_Stop Function In this POU, the PrepareStop system event function is defined. It belongs to the communication task and is called before stopping the application. When there is active communication with the PLC, it is possible to observe the event status and the call count in the System Events tab in the Task Configuration object. Every time the user stops the application, the count is incremented. 4.14.12. Start_Done Function In this POU, the StartDone system event function is defined. It belongs to the communication task and is called when the application is successfully started. When there is active communication with the PLC, it is possible to observe the event status and the call count in the System Events tab in the Task Configuration object. Every time the user successfully launches the application, the count is incremented. 4.14.13. Stop_Done Function In this POU, the StopDone system event function is defined. It belongs to the communication task and is called when the application is successfully stopped. When there is active communication with the PLC, it is possible to observe the event status and the call count in the System Events tab in the Task Configuration object. Every time the user successfully stops the application, the count is incremented. 52 5. CONFIGURATION 5. Configuration The Nexto Series CPUs are configured and programmed through the MasterTool IEC XE software. The configuration made defines the behavior and utilization modes for peripherals use and the CPUs special features. The programming represents the Application developed by the user. 5.1. CPU Configuration 5.1.1. General Parameters The parameters related below are part of the CPU configuration included in the application. Each item must be properly verified for the correct project execution. Besides these parameters, it is possible to change the name of each module inserted in the application by clicking the right button on the module. In the Properties item from the Common sheet, change the name, what is limited to 24 characters. Settings %Q Start Address Size %Q Start Address Size %Q Start Address Size Start User Application after Reset by Watchdog Description Standard Options Diagnostics Area (%Q) Starting address of the UCP diagnostics (%Q) Automatically allocated on project creation. 0 a 32210 Size of diagnostics area in bytes 558 It is not possible to change the size of the CPU diagnostics area Retaining Area (%Q) Starting address of the retentive data memory (%Q) 4096 0 a 32767 Retain data memory size in bytes 7680 0 a 7680 Persistent Area (%Q) Persistent data memory start address (%Q) 12288 0 a 32767 Persistent data memory size in bytes 7680 0 a 7680 CPU Parameters When enabled, starts the user application after resetting the hardware watchdog or restarting Runtime, but maintaining the diagnostic indication via WD LED and via variables. Disabled Enabled Disabled 53 5. CONFIGURATION Settings Hot Swap Mode Enable I/O update per task Enable retain and persistent variables in Function Blocks Description Standard Options Module hot swap mode Enabled, no match consistency. (may vary according to CPU model) - Denabled, only for declared modules - Disabled (with match consistency) - Disabled, no match consistency - Enabled, with match consistency only for declared modules - Enabled, with match consistency - Enabled, no match consistency Project Parameters Setting to update inputs and outputs in the tasks in which they are used. unmarked - Checked: Inputs and outputs are updated by the tasks in which they are used. - Unchecked: Inputs and outputs are only updated by MainTask Setting that allows the use of retentive and persistent variables in Function Blocks unmarked - Marked: allows the use of retentive and persistent variables in Function Blocks. - Unchecked: Exception error may occur at startup. Table 37: CPU settings ATTENTION When the initial address or the retentive or persistent data memory size are changed in the user application, the memory is totally reallocated, what makes the retentive and persistent variable area be clean. So the user has to be careful so as not to lose the saved data in the memory. ATTENTION In situations where the symbolic persistent memory area is modified, a message will be displayed by MasterTool IEC XE programmer, to choose the behavior for this area after charging the modified program. The choice of this behavior does not affect the persistent area of direct representation, which is always clean. ATTENTION The option Enable I/O update per task is not supported for fieldbus masters such as NX5001 module. This feature is applicable only for input and output modules present on the controller local bus (main rack and expansion racks). ATTENTION Even when an I/O point is used in other tasks, with the Enable I/O update per task marked, it will continue to be updated in the MainTask as well; except when all the points of the module are used in some other task, in this case they will not be updated on MainTask anymore. 54 5. CONFIGURATION 5.1.1.1. Hot Swap Nexto Series CPUs have the possibility of I/O modules change in the bus with no need for system turn off and without information loss. This feature is known as hot swap. CAUTION Nexto Series CPUs do not guarantee the persistent and retentive variables retentivity in case the power supply or even the CPU is removed from the energized backplane rack. On the hot swap, the related system behavior modifies itself following the configuration table defined by the user which represents the options below: Disable, for declared modules only Disabled (with startup consistency) Disabled, without startup consistency Enabled, with startup consistency for declared modules only Enabled, with startup consistency Enabled, without startup consistency Therefore, the user can choose the behavior that the system must assume in abnormal bus situations and when the CPU is in Run Mode. The table below presents the possible abnormal bus situations. Situation Incompatible configuration Absent module Possible causes - Some module connected to the bus is different from the model that is declared in configuration. - The module was removed from the bus. - Some malfunctioning module is not responding to CPU - Some bus position is malfunctioning. Table 38: Bus Abnormal Situations For further information regarding the diagnostics correspondent to the above described situations, see Diagnostics via Variables. If a module is present in a specific position in which should not exist according to the configuration modules, this module is considered as non-declared. The options of hot swap Disabled, for Declared Modules Only and Enabled, with Startup Consistency for Declared Modules Only do not take into consideration the modules that are in this condition. 5.1.1.1.1. Hot Swap Disabled, for Declared Modules Only In this configuration, the CPU is immediately in Stop Mode when an abnormal bus situation (as described on Table 38) happens. The LED DG starts to blink 4x (according to Table 39). In this case, in order to make the CPU to return to the normal state Run, in addition to undo what caused the abnormal situation, it is necessary to execute a Reset Warm or a Reset Cold. If a Reset Origin is carried out, it will be necessary to perform the download so that the CPU can return to the normal state (Run). The Reset Warm, Reset Cold and Reset Origin commands can be done by MasterTool IEC XE in the Online menu. The CPU will remain in normal Run even if find a module not declared on the bus. 5.1.1.1.2. Hot Swap Disabled This setting does not allow any abnormal situation in the bus (as shown in Table 38) modules including undeclared and present on the bus. The CPU enters in Stop mode, and the DG LED begins to blink 4x (as in Table 39). For these cases, to turn the CPU back to normal Run, in addition to undo what caused the abnormal situation it is necessary to perform a Reset Warm or Reset Cold. If a Reset Origin is done, you need to download the project so that the CPU can return to normal Run. The Reset Warm, Reset Cold and Reset Origin commands can be done by MasterTool IEC XE in the Online menu. 55 5. CONFIGURATION 5.1.1.1.3. Hot Swap Disabled, without Startup Consistency Allows the system to start up even when some module is in an abnormal bus situation (as shown in Table 38). Abnormal situations are reported via diagnosis. Any modification to the bus will cause the CPU to enter Stop Mode, and the DG LED will start blinking 4x (as in Table 39). In order for the CPU to return to the normal Run state in these cases, it is necessary to perform a Reset Warm or Reset Cold. If a Reset Origin is performed, it will be necessary to download the CPU so that the CPU can return to the normal Run state. The Reset Warm, Reset Cold and Reset Origin commands can be done by MasterTool IEC XE in the Online menu. 5.1.1.1.4. Hot Swap Enabled, with Startup Consistency for Declared Modules Only "Startup" is the interval between the CPU energization (or reset command or application download) until the first time the CPU gets in Run Mode after been switched on. This configuration verifies if any abnormal bus situation has occurred (as described on Table 38) during the start. In affirmative case, the CPU gets in Stop Mode and the LED DG starts to blink 4x (according to Table 39). Afterwards, in order to set the CPU in Run mode, further to fix what caused the abnormal situation, it is necessary to execute a Reset Warm or Reset Cold command, which can be done by the MasterTool IEC XE (Online menu). If a Reset Origin is carried out, it will be necessary to perform the download so that the CPU can return to the normal state (Run). After the start, if any module present any situation described in the previous table, the system will continue to work normally and will signalize the problem via diagnostics. If there is no other abnormality for the declared modules, the CPU will go to the normal state (Run) even if a non-declared module is present on the bus. ATTENTION In this configuration when a power fault occurs (even temporally), Reset Warm Command,Reset Cold Command or a new application Download has been executed, and if any module is in an abnormal bus situation, the CPU will get into Stop Mode and the LED DG will start to blink 4x (according to Table 39). This is considered a startup situation. This is the most advised option because guarantee the system integrity on its initialization and allows the modules change with a working system. 5.1.1.1.5. Hot Swap Enabled with Startup Consistency This setting checks whether there has been any abnormal situation in the bus (as shown in Table 38) during the startup, even if there is no declared modules and present on the bus; if so, the CPU goes into Stop mode and the LED DG starts to blink 4x (as shown in Table 39). For these cases, to turn the CPU back to normal Run, in addition to undo what caused the abnormal situation it is necessary to perform a Reset Warm or Reset Cold. If a Reset Origin is done, you need to download the project so that the CPU can return to normal Run. The Reset Warm, Reset Cold and Reset Origin commands can be done by MasterTool IEC XE in the Online menu. 5.1.1.1.6. Hot Swap Enabled without Startup Consistency Allows the system to start working even if a module is in an abnormal bus situation (as described on Table 38). The abnormal situations are reported via diagnostics during and after the startup. ATTENTION This option is advised for the system implementation phase as it allows the loading of new applications and the power off without the presence of all configured modules. 5.1.1.1.7. How to do the Hot Swap CAUTION Before performing the Hot Swap it is important to discharge any possible static energy accumulated in the body. To do that, touch (with bare hands) on any metallic grounded surface before handling the modules. Such procedure guaranties that the module static energy limits are not exceeded. 56 5. CONFIGURATION ATTENTION It is recommended the hot swapping diagnostics monitoring in the application control developed by the user in order to guarantee the value returned by the module is validated before being used. The hot swap proceeding is described below: Unlock the module from the backplane rack, using the safety lock. Take off the module, pulling firmly. Insert the new module in the backplane rack. Certify the safety lock is completely connected. If necessary, push the module harder towards to the backplane rack. In case of output modules is convenient the points to be disconnected when in the changing process, in order to reduce the generation of arcs in module connector. This must be done by switching off the power supply or by forcing the output points using the software tools. If the load is small, there is no need for disconnecting. It is important to note that in the cases the CPU gets in Stop Mode and the DG LED starts to blink 4x (according to Table 39, due to any abnormal bus situation (as described on Table 38, the output modules have its points operation according to the module configuration when CPU toggles from Run Mode to Stop Mode. In case of application startup, when the CPU enters Stop Mode without having passed to the Run Mode, the output modules put their points in failure secure mode, in other words, turn it off (0 Vdc). Regarding the input modules, if one module is removed from energized backplane rack, the logic point's state will remain in the last value. In the case a connector is removed, the logic point's state will be put in a safe state, it means zero or high impedance. ATTENTION Always proceed to the substitution of one module at a time for the CPU to update the modules state. Below, Table 39 presents the bus conditions and the Nexto CPU DG LED operation state. For further information regarding the diagnostics LEDs states, see Diagnostics via LED section. 57 5. CONFIGURATION Condition Non declared module Non declared module (startup condition) Absent module Absent module (startup condition) Incompatible configuration Incompatible configuration(startup condition) Duplicated slot address Nonoperational module Enabled, with Startup Consistency Enabled, with Startup Consistency for Declared Modules Only Enabled, without Startup Consistency Disabled Disabled, for declared modules only Disabled, without Startup Consistency LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run LED DG: Blinks 2x Application: Run or LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 2x Application: Run LED DG: Blinks 4x Application: Stop LED DG: Blinks 4x Application: Stop Table 39: Hot Swap and Conditions Relations Note: Enabled, without startup consistency: When this hot-swap mode is configured, in normal situations when there's an incompatible module on the system's startup, the application will go from Stop to Run. However, if that module is configured as a NX5000 or a NX5001 and there's a different module in that position, the application will stay in Stop. 58 5. CONFIGURATION 5.1.1.2. Retain and Persistent Memory Areas The Nexto CPU allows the use of symbolic variables and output variables of direct representation as retentive or persistent variables. The output variables of direct representation which will be retentive or persistent must be declared in the CPU General Parameters, as described at CPU Configuration. Symbolic names also can be attributed to these output variables of direct representation using the AT directive, plus using the key word RETAIN or PERSISTENT on its declaration. For example, being %QB4096 and %QB20480 within the retentive and persistent memory, respectively: PROGRAM UserPrg VAR RETAIN byRetentiveVariable_01 AT %QB4096 : BYTE; END_VAR VAR PERSISTENT byPersistentVariable_01 AT %QB20480 : BYTE; END_VAR In case the symbolic variables declared with the AT directive are not inside the respective retentive and/or persistent memory, errors during the code generation in MasterTool can be presented, informing that there are non-retentive or nonpersistent variables defined in the retentive or persistent memory spaces. Regarding the symbolic variables which will be retentive or persistent, only the retentive variables may be local or global, as the persistent symbolic variables shall always be global. For the declaration of retentive symbolic variables, it must be used the key word RETAIN. For example, for local variables: PROGRAM UserPrg VAR RETAIN wLocalSymbolicRetentiveVariable_01 : WORD; END_VAR Or, for global variables, declared within a list of global variables: VAR_GLOBAL RETAIN wGlobalSymbolicRetentiveVariable_01 : WORD; END_VAR On the other hand, the persistent symbolic variables shall be declared in a Persistent Variables object, being added to the application. These variables will be global and will be declared in the following way within the object: VAR_GLOBAL PERSISTENT RETAIN wGlobalSymbolicPersistentVariable_01 : WORD; END_VAR 59 5. CONFIGURATION VAR_GLOBAL PERSISTENT RETAIN wGlobalSymbolicPersistentVariable_01 : WORD; END_VAR VAR_GLOBAL RETAIN wGlobalSymbolicRetentiveVariable_01 : WORD; END_VAR ATTENTION To use the retentive and persistent memory flexibly, it's necessary to use MasterTool IEC XE 2.03 or higher. 5.1.1.3. Project Parameters The CPU project parameters are related to the configuration for input/output refreshing at the task that they are used of the project tasks. Configuration Enable I/O update per task Enable retain and persistent variables in Function Blocks Description Updates the input and output in the tasks where they are used Setting to allow the use of retentive and persistent variables in function blocks Default Unmarked Unmarked Options - Marked - Unmarked - Marked - Unmarked Table 40: CPU Project Parameters 5.1.2. External Event Configuration The external event is a feature available in the CPU which enables a digital input, configured by the user, when activated, triggers the execution of a specific task with user-defined code. Thus, it is possible that through this input, when triggered, interrupt the execution of the main application and run the set application in the task ExternInterruptTask00, which has higher priority than other application tasks. Because the inputs and outputs are updated in the context of the MainTask task, the External Event task does not have the input and output data updated at the time of its call. If necessary, use the I/O update functions. It is also important to note that, to avoid the generation of several events in a very short space of time, that was limited the treatment of this type of event in every 10 ms, i.e., if two or more events occurs during 10 ms after the first event, the second and subsequent events are discarded. This limitation is imposed to prevent an external event that is generated in an uncontrolled way, do not block the CPU, since the task has a higher priority over the others. To configure an external event is necessary to insert a digital input module and perform the configurations described below, in the CPU, through the MT8500 programming tool software. 60 5. CONFIGURATION Figure 39: Configuration Screen for External Event in CPU In the configuration external event tab, within the CPU settings, it is necessary to select which module will be the interruption source, in the field Module Address: Name. Then it must be selected which input of this module will be responsible for the event generation (IO_EVT_0). In this selection the options described in the figure below can be chosen. Figure 40: NX1001 Module External Event Source Options In addition to configuring the CPU it is required to configure the task responsible for executing user-defined actions. In this case the user must use a project profile that supports external events. For further information see the section Project Profiles. In the configuration screen of the ExternInterruptTask00 (figure below), it is necessary to select the event source in the corresponding field. In this case, IO_EVT_0 should be selected since the other origin sources (IO_EVT_1 to IO_EVT_7) are not available. In the sequence, the field POU should be checked if the right POU is selected, because it will be used by the user to define the actions to be performed when an external event occurs. 61 5. CONFIGURATION Figure 41: ExternInterruptTask00 Configuration Screen 5.1.3. Time Synchronization For the time synchronization, Nexto Series CPUs use the SNTP (Simple Network Time Protocol) or the synchronism through IEC 60870-5-104. To use the time sync protocols, the user must set the following parameters at Synchronism tab, accessed through the CPU, in the device tree: Figure 42: SNTP Configuration 62 5. CONFIGURATION Configuration Time Zone (hh:mm) SNTP Service Period for SNTP Synchronization (x1 s) Minimum Error Before Clock Update (x1 ms) IP Address of First SNTP Server IP Address of Second Second SNTP Server Description Time zone of the user location. Hours and minutes can be inserted. Enables the SNTP service. Time interval of the synchronization requests (seconds). Offset value acceptable between the server and client (milliseconds). IP Address of the primary SNTP server. IP Address of the secondary SNTP server. Default -3:00 Disabled 60 100 192.168.15.10 192.168.15.11 Options 12:59 to +13:59 Disabled Enabled 1 to 255 1 to 65519 1.0.0.1 to 223.255.255.254 1.0.0.1 to 223.255.255.254 Table 41: SNTP Configurations Notes: SNTP Server: It is possible to define a preferential address and another secondary one in order to access a SNTP server and, therefore, to obtain a synchronism of time. If both fields are empty, the SNTP service will remain disabled. Time zone: The time zone configuration is used to convert the local time into UTC and vice versa. While some sync sources use the local time (IEC 60870-5-104 protocol, SetDateAndTime Function), others use the UTC time (SNTP). The UTC time is usually used to stamp events (DNP3, IEC 60870-5-104 and MasterTool Device Log), while the local time is used by an others CPU's features (GetDateAndTime function, OTD date and time info). It is allowed to enable more than one sync source on the project, however the device doesn't supports the synchronism from more than one sync source during operation. Therefore there are implicitly defined a priority mechanism. The synchronism through SNTP is more prioritary than through IEC 60870-5-104 protocol. So, when both sources are enabled and SNTP server is present, it is going to be responsible for the CPU's clock sync, and any sync command from IEC 60870-5-104 is going to be denied. 5.1.3.1. IEC 60870-5-104 In case the synchronism is through IEC 60870-5-104 protocol, the user must enable the time sync at the protocol configuration screen to receive the clock synchronization. To set this option on the device, check the parameter Enable Time Synchronization available at the Application Layer section. ATTENTION If the PLC receives a time sync command from the control center, and this option is disabled, an error answer will be returned to that command. But if this option is enabled then a success message will be returned to the control center, even that the sync command be discarded for there is another synchronism method active with higher priority. This synchronism method should be used only as an auxiliary synchronism method, once the precision of the clock sync process depends a lot on delays and traffic on the network, as well as the processor load on the CPU, as this mechanism is treated by a low priority task. 5.1.3.2. SNTP When enabled, the CPU will behave as a SNTP client, which is, it will send requests of time synchronization to a SNTP/NTP server which can be in the local net or in the internet. SNTP client works with a resolution of 1 ms, but with an accuracy of 100 ms. The precision of the time sync through SNTP depends on the protocol configurations (minimum error to clock update) and the features of the Ethernet network where it is, if both client and server are in the same network (local) or in different networks (remote). Typically the precision is in tens of milliseconds order. The CPU sends the cyclic synchronization requests according to the time set in the Period for SNTP Synchronization field. In the first synchronization attempt, just after the service start up, the request is for the first server set in the first server IP 63 5. CONFIGURATION address. In case it does not respond, the requests are directed to the second server set in the second server IP address providing a redundancy of SNTP servers. In case the second server does not respond either, the same process of synchronization attempt is performed again but only after the Period of Synchronization having been passed. In other words, at every synchronization period the CPU tries to connect once in each server, it tries the second server in case the first one does not respond. The waiting time for a response from the SNTP server is defined by default in 5 s and it cannot be modified. If, after a synchronization, the difference between the current time of the CPU and the one received by the server is higher than the value set in the Minimum Error Before Clock Update parameter, the CPU time is updated. SNTP uses the time in the UTC (Universal Time Coordinated) format, so the Time Zone parameter needs to be set correctly so the time read by the SNTP will be properly converted to a local time. The execution process of the SNTP client can be exemplified with the following steps: 1. Attempt of synchronization through the first server. In case the synchronization occurs successfully, the CPU waits the time for a new synchronization (Period for SNTP Synchronization) and will synchronize again with this server, using it as a primary server. In case of failure (the server does not respond in less than 5 s) step 2 is performed. 2. Attempt of synchronization through the second server. In case the synchronization occurs successfully, the CPU waits the time for a new synchronization (Period for SNTP Synchronization) and will try to synchronize with this server using the primary server. In case of failure (the server does not respond in less than 5 s) the time relative to the Synchronization Period is waited and step 1 is performed again. As the waiting time for the response of the SNTP server is 5 s, the user must pay attention to lower than 10 s values for the Synchronization Period. In case the primary server does not respond, the time for the synchronization will be the minimum of 5 s (waiting for the primary server response and the synchronization attempt with secondary server). In case neither the primary server nor the secondary one responds, the synchronization time will be 10 s minimum (waiting for the two servers response and the new connection with first server attempt). Depending on the SNTP server's subnet, the client will use the Ethernet interface that is in the corresponding subnet to make the synchronization requests. If there is no interface configured on the same subnet as the server, the request can be made by any interface that can find a route to the server. ATTENTION The SNTP Service depends on the user application only for its configuration. Therefore, this service will be executed even when the CPU is in STOP or BREAKPOINT modes, as long as there is an application in the CPU with the SNTP client enabled and correctly configured. 5.1.3.3. Daylight Saving Time (DST) The DST configuration must be done indirectly through the function SetTimeZone, which changes the time zone applied to the RTC. In the beginning of the DST, it has to be used a function to increase the time zone in one hour. At the end of the DST, it is used to decrease it in one hour. For further information, see the section RTC Clock. 5.1.4. Internal Points A communication point is storage on the CPU memory under form of two distinct variables. One represents the point's value (type BOOL, BYTE, WORD, etc. . . ), while another, represents its quality (type QUALITY). Internal Points are those which the value and the quality are calculated internally by the user application, that is, they don't have an external origin like occur with points linked to IEDs (Communication drivers of type Master/Client) or to local I/O modules. ATTENTION Different from what happen with I/O modules declared on local bus, which have its own quality variables created by MasterTool (IOQualities GVL) and auto updated by the CPU, I/O modules declared on PROFIBUS remotes don't have. It is user responsibility to declare PROFIBUS point's quality variables, the association of these quality variables with the value variables at Internal Points tab, as well as generation and update of the quality variables value, from the existents PROFIBUS diagnostics: PROFIBUS I/O modules, PROFIBUS head and PROFIBUS Master. This Internal Points configuration tab's function is to relate the variable which represents a point's value with the one which represents its quality. It must be used to relate value and quality variables internally created on the PLC program (as in a GVL), which ones typically will be posteriorly mapped to a communication driver, of type Server, for communication with the control center. 64 5. CONFIGURATION ATTENTION If a value variable doesn't own a related quality variable, it will be reported as default a constant good quality (no significant indication) when the value variable is reported to a client or control center. In this way, this tab purpose isn't to create or declare internal points. To do that, just declare value and/or quality variables in a GVL and map it on the communication driver. The internal points configuration, viewed on the figure below, follow the parameters described on table below. It's possible to configure up to 5120 entries on Internal Points table. Figure 43: Internal Points Configuration Screen Configuration Variable Name Quality Description Default Symbol variable which storage the internal point value - Symbol variable which storage the internal point quality - Options Accept variables of type BOOL, WORD, DWORD, LWORD, INT, DINT, LINT, UINT, UDINT, ULINT, REAL, LREAL or DBP. The variable can be simple, array or array's element and can be part of a struct. QUALITY type variables (LibRtuStandard), which can be simple, array or array's element and can be part of a struct. Table 42: Internal Points Configuration The figure below show an example of two internal points configuration: 65 5. CONFIGURATION Figure 44: Internal Points Configuration Example 5.1.4.1. Quality Conversions The internal point's quality is a trust level information about the value stored on that point. The quality may inform, for example, that the value stored is out of range, or yet that it is valid, but low trusted. The Standards IEC 61850, DNP3 and IEC104 have their own formats to representation of point's quality information. The Nexto Series, by its turn, have its own quality format (but quite similar to IEC 61850) called Internal Quality. This format is defined by type QUALITY (library LibRtuStandard) and it is used internally to quality storage, allowing to be done conversion between protocols without information loss. When it is done a mapping of a same communication point between two drivers, the quality conversion is automatically realized in two steps. For example: in case a communication point is mapped from a DNP3 Client driver to a IEC104 Server driver, first the quality will be converted from DNP3 format to internal format (and stored internally in the CPU), after that it will be converted from the internal format to IEC104 format. The following tables define the protocols own formats conversion to internal format. Case it is necessary to consult the conversion between protocols, it is needed to analyze in two steps, looking each of the tables to internal format and after correlating them. ATTENTION In case of internal points mapped to communication drivers, it is not recommended to modify the value of quality flags that dont have a correspondent on the given protocol (i.e, flags that are not described on the following tables). This will result on generation of events equal to the previous one (but with a more recent timestamp) and, this way, depending on the configuration selected for the transmission mode of analog inputs events, it could overwrite the previous event if this one was not delivered to the control center yet. 66 5. CONFIGURATION 5.1.4.1.1. Internal Quality This is the QUALITY structure. The table shows detailed each of its components. Bit Name 0 FLAG_RESTART Type BOOL 1 FLAG_COMM_FAIL BOOL 2 FLAG_REMOTE_SUBSTITUTED BOOL 3 FLAG_LOCAL_SUBSTITUTED BOOL 4 FLAG_FILTER BOOL 5 FLAG_OVERFLOW BOOL 6 FLAG_REFERENCE_ERROR 7 FLAG_INCONSISTENT BOOL BOOL 8 FLAG_OUT_OF_RANGE BOOL 9 FLAG_INACCURATE BOOL 10 FLAG_OLD_DATA BOOL 11 FLAG_FAILURE BOOL 12 FLAG_OPERATOR_BLOCKED BOOL 13 FLAG_TEST BOOL 14-15 RESERVED - Description The RESTART flag indicates that the data haven't been updated by the field since the device's reset. Indicates there is a communication failure on the way between the data origin device and the reports device. If TRUE the data values are overwritten in the remote communication devices. If TRUE the data value is overwritten by the device which generated this flag. This behavior might occur due to a working in diagnostic or temporary due to human intervention. Flag used to signalize and prevent the event communication channel overload, as oscillations (rapid changes) on the digital inputs. This flag should indicates a quality problem, that the value, of the attribute to which the quality has been associated, is beyond representation. This flag should identify that the value cannot be correct due to out of calibration reference. This flag should identify that an evaluation function has found an inconsistency. This flag should indicates a quality problem that the attribute to which the quality has been associated is beyond the predefined values capacity. This flag should indicates that the value doesn't attend the declared precision of the source. A value seems to be outdated. In case an update doesn't occur during a specific time period. This flag should indicates that a watch function detected an internal or external failure. Update blocked by operator. This must be an additional identifier which can be used to classify a value being that a test value which won't be used to operational ends. Reserved 67 5. CONFIGURATION Bit Name 16-17 VALIDITY Type QUALITY_VALIDITY Description 0 Good (Trustfull value, means that there is no abnormal conditions) 1 Invalid (Value doesn't match the IED's value) 2 Reserved (Reserved) 3 Questionable (Present value might be not the same from the IED) Table 43: QUALITY Structure 5.1.4.1.2. IEC 60870-5-104 Conversion The tables below presents respectively the digital, analog and counters internal point's conversion to IEC 60870-5-104 of Nexto Series available to MT8500. Internal-> IEC 60870-5-104 Digital Internal Quality Flags VALIDITY IEC 60870-5-104 Quality FLAG_RESTART ANY NOT TOPICAL FLAG_COMM_FAIL ANY NOT TOPICAL FLAG_REMOTE_SUBSTITUTED ANY SUBSTITUTED FLAG_LOCAL_SUBSTITUTED ANY SUBSTITUTED FLAG_FILTER ANY - FLAG_OVERFLOW ANY - FLAG_REFERENCE_ERROR ANY - FLAG_INCONSISTENT ANY - FLAG_OUT_OF_RANGE ANY - FLAG_INACCURATE ANY - FLAG_OLD_DATA ANY NOT TOPICAL FLAG_FAILURE ANY INVALID FLAG_OPERATOR_BLOCKED ANY BLOCKED FLAG_TEST ANY - ANY VALIDITY_INVALID INVALID Table 44: Digital Points Conversion Internal to IEC 60870-5-104 Internal -> IEC 60870-5-104 Analog Internal Quality Flags VALIDITY IEC 60870-5-104 Quality FLAG_RESTART ANY NOT TOPICAL FLAG_COMM_FAIL ANY NOT TOPICAL FLAG_REMOTE_SUBSTITUTED ANY SUBSTITUTED FLAG_LOCAL_SUBSTITUTED ANY SUBSTITUTED FLAG_FILTER ANY - FLAG_OVERFLOW ANY OVERFLOW FLAG_REFERENCE_ERROR ANY INVALID FLAG_INCONSISTENT ANY INVALID 68 5. CONFIGURATION Internal -> IEC 60870-5-104 Analog Internal Quality Flags VALIDITY IEC 60870-5-104 Quality FLAG_OUT_OF_RANGE ANY OVERFLOW FLAG_INACCURATE ANY INVALID FLAG_OLD_DATA ANY NOT TOPICAL FLAG_FAILURE ANY INVALID FLAG_OPERATOR_BLOCKED ANY BLOCKED FLAG_TEST ANY - ANY VALIDITY_INVALID INVALID Table 45: Analog Points Conversion Internal to IEC 60870-5-104 Internal -> IEC 60870-5-104 Counters Internal Quality Flags VALIDITY IEC 60870-5-104 Quality FLAG_RESTART ANY - FLAG_COMM_FAIL ANY - FLAG_REMOTE_SUBSTITUTED ANY - FLAG_LOCAL_SUBSTITUTED ANY - FLAG_FILTER ANY - FLAG_OVERFLOW ANY OVERFLOW FLAG_REFERENCE_ERROR ANY - FLAG_INCONSISTENT ANY - FLAG_OUT_OF_RANGE ANY - FLAG_INACCURATE ANY - FLAG_OLD_DATA ANY - FLAG_FAILURE ANY INVALID FLAG_OPERATOR_BLOCKED ANY - FLAG_TEST ANY - ANY VALIDITY_INVALID INVALID Table 46: Counters Conversion Internal to IEC 60870-5-104 5.1.4.1.3. MODBUS Internal Quality As the MODBUS standard don't specify quality types to each point, but for help on use of each point's communication diagnostic, MasterTool allows the quality variables mapping, through an internal own structure, to each MODBUS point. The table below describes the quality types that each MODBUS point can assume. Resulting Quality FLAG_RESTART FLAG_COMM_FAIL AND FLAG_RESTART Resulting VALIDITY VALIDITY_INVALID VALIDITY_GOOD VALIDITY_INVALID Description Initial value. The point was never updated. Communication OK. The point is updated. Communication error. The point never was updated. 69 5. CONFIGURATION Resulting Quality FLAG_COMM_FAIL AND FLAG_OLD_DATA FLAG_FAILURE AND FLAG_RESTART FLAG_FAILURE AND FLAG_OLD_DATA FLAG_RESTART AND FLAG_OLD_DATA Resulting VALIDITY VALIDITY_QUESTIONABLE VALIDITY_INVALID VALIDITY_QUESTIONABLE VALIDITY_QUESTIONABLE Description An error has occurred but the point was updated and now has an old value. It has received an exception response and the point kept its initial value. It has received an exception response, but the point has a valid old value. Device stopped. The point has an old value. Table 47: MODBUS Quality 5.1.4.1.4. Local Bus I/O Modules Quality To help in the use of each I/O point's diagnostic, MasterTool automatically creates a quality structure to each local bus module used on the PLC project, through an own internal structure accessible by structure QUALITY, available in GVL IOQualities. The table below describes the quality types to each input and output point. For further information look at GVL IOQualities. Diagnostics Don't care None None bOverRange OR bUnderRange bInputNotEnable OR bOutputNotEnable bOpenLoop bFatalError bNoExternalSupply bShortCircuit OR bOutputShortCircuit bCalibrationError bColdJunctionSensorError Resulting Quality FLAG_RESTART - FLAG_OLD_DATA FLAG_FAILURE AND FLAG_OUT_OF_RANGE FLAG_OPERATOR_BLOCKED FLAG_FAILURE FLAG_FAILURE FLAG_FAILURE FLAG_FAILURE FLAG_INACCURATE FLAG_INACCURATE Resulting VALIDITY VALIDITY_INVALID VALIDITY_GOOD VALIDITY_QUESTIONABLE VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID VALIDITY_INVALID Description The quality has this value before have been read or written for the first time. Communication OK. The point is updated. Non-operational module. However, the data have been read or written at least once. The value is above or below the module's input allowed range. Input/Output not enable. Open loop in input module. Hardware fatal failure. External power supply is under operational minimum limit. Output short-circuit. Calibration error. Cold junction sensor error. Table 48: I/O Modules Quality 5.1.4.1.5. PROFIBUS I/O Modules Quality Different from local bus, MasterTool doesn't automatically create the PROFIBUS modules quality structures, and neither the PLC update such structures. Therefore the creation and cyclic update of PROFIBUS modules quality is user responsibility. To help on the development of such applications, there are following practical examples, in ST language, for the main PROFIBUS modules (DI, DO, AI, AO), based on Nexto Serie's PROFIBUS slaves (NX5110). The user should feel encouraged to make any needed adaptation and change to fit to its application. 70 5. CONFIGURATION ATTENTION For the routines, presented in sequence, correct functioning it is necessary to enable Status in Diagnose in the PROFIBUS slaves. The development of PROFIBUS I/O modules quality points update routine must began from quality variables declaration and initialization, from a GVL: VAR_GLOBAL QUALITY_PB_NX1005_I: LibDataTypes.QUALITY:= (VALIDITY:= VALIDITY_INVALID, FLAGS:= (FLAG_RESTART:= TRUE)); QUALITY_PB_NX1005_O: LibDataTypes.QUALITY:= (VALIDITY:= VALIDITY_INVALID, FLAGS:= (FLAG_RESTART:= TRUE)); QUALITY_PB_NX6000: LibDataTypes.QUALITY:= (VALIDITY:= VALIDITY_INVALID, FLAGS:= (FLAG_RESTART:= TRUE)); QUALITY_PB_NX6100: LibDataTypes.QUALITY:= (VALIDITY:= VALIDITY_INVALID, FLAGS:= (FLAG_RESTART:= TRUE)); END_VAR 5.1.4.1.6. PROFIBUS Digital Input Quality // PROFIBUS digital input quality update, module NX1005 // In communication success case with PROFIBUS slave (address = 99) ... IF DG_NX5001.tMstStatus.abySlv_State.bSlave_99 = TRUE THEN // Waits the PROFIBUS slave become apt to exchange data and diagnostics // (It is necessary to wait, avoiding invalid quality generation) IF DG_NX5110.tPbusHeadA.tStatus1.bStation_Non_Existent = FALSE AND DG_NX5110.tPbusHeadA.tStatus1.bStation_Not_Ready = FALSE AND DG_NX5110.tPbusHeadA.wIdentNumber > 0 THEN QUALITY_PB_NX1005_I.FLAGS.FLAG_COMM_FAIL:= FALSE; // If there is a module present on the bus (slot = 2) and // if there is no modules config problem (general) and // if there is no config problem in that module (specific) and // if there is no fatal error identification by the module ... IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 2)) = 0 AND DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tGeneral.bConfigMismatch = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tGeneral.bFatalError = FALSE THEN QUALITY_PB_NX1005_I.VALIDITY:= VALIDITY_GOOD; QUALITY_PB_NX1005_I.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX1005_I.FLAGS.FLAG_FAILURE:= FALSE; QUALITY_PB_NX1005_I.FLAGS.FLAG_OLD_DATA:= FALSE; ELSE QUALITY_PB_NX1005_I.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX1005_I.FLAGS.FLAG_FAILURE:= TRUE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX1005_I.FLAGS.FLAG_RESTART THEN QUALITY_PB_NX1005_I.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF END_IF // In PROFIBUS communication failure with the PROFIBUS slave ... ELSE 71 5. CONFIGURATION QUALITY_PB_NX1005_I.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX1005_I.FLAGS.FLAG_COMM_FAIL:= TRUE; QUALITY_PB_NX1005_I.FLAGS.FLAG_FAILURE:= FALSE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX1005_I.FLAGS.FLAG_RESTART THEN QUALITY_PB_NX1005_I.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF 5.1.4.1.7. PROFIBUS Digital Output Quality // PROFIBUS digital output quality update, module NX1005 // In communication success case with PROFIBUS slave (address = 99) ... IF DG_NX5001.tMstStatus.abySlv_State.bSlave_99 = TRUE THEN // Waits the PROFIBUS slave become apt to exchange data and diagnostics // (It is necessary to wait, avoiding invalid quality generation) IF DG_NX5110.tPbusHeadA.tStatus1.bStation_Non_Existent = FALSE AND DG_NX5110.tPbusHeadA.tStatus1.bStation_Not_Ready = FALSE AND DG_NX5110.tPbusHeadA.wIdentNumber > 0 THEN QUALITY_PB_NX1005_O.FLAGS.FLAG_COMM_FAIL:= FALSE; // If there is a module present on the bus (slot = 2) and // if there is no modules config problem (general) and // if there is no config problem in that module (specific) and // if there is no fatal error identification by the module and // if there is no outputs short circuit indication and // if there is no external power supply missing indication ... IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 2)) = 0 AND DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tGeneral.bConfigMismatch = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tGeneral.bFatalError = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tDetailed.bOutputShortCircuit = FALSE AND DG_NX1005_24_Vdc_8_DO_Trans_8_DI.tDetailed.bNoExternalSupply = FALSE THEN QUALITY_PB_NX1005_O.VALIDITY:= VALIDITY_GOOD; QUALITY_PB_NX1005_O.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX1005_O.FLAGS.FLAG_FAILURE:= FALSE; QUALITY_PB_NX1005_O.FLAGS.FLAG_OLD_DATA:= FALSE; ELSE QUALITY_PB_NX1005_O.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX1005_O.FLAGS.FLAG_FAILURE:= TRUE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX1005_O.FLAGS.FLAG_RESTART THEN QUALITY_PB_NX1005_O.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF END_IF // In PROFIBUS communication failure with the PROFIBUS slave ... ELSE QUALITY_PB_NX1005_O.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX1005_O.FLAGS.FLAG_COMM_FAIL:= TRUE; QUALITY_PB_NX1005_O.FLAGS.FLAG_FAILURE:= FALSE; // If the point have ever been updated once ... 72 5. CONFIGURATION IF NOT QUALITY_PB_NX1005_O.FLAGS.FLAG_RESTART THEN QUALITY_PB_NX1005_O.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF 5.1.4.1.8. PROFIBUS Analog Input Quality // PROFIBUS analog input quality update, module NX6000 // In communication success case with PROFIBUS slave (address = 99) ... IF DG_NX5001.tMstStatus.abySlv_State.bSlave_99 = TRUE THEN // Waits the PROFIBUS slave become apt to exchange data and diagnostics // (It is necessary to wait, avoiding invalid quality generation) IF DG_NX5110.tPbusHeadA.tStatus1.bStation_Non_Existent = FALSE AND DG_NX5110.tPbusHeadA.tStatus1.bStation_Not_Ready = FALSE AND DG_NX5110.tPbusHeadA.wIdentNumber > 0 THEN QUALITY_PB_NX6000.FLAGS.FLAG_COMM_FAIL:= FALSE; // If there is a module present on the bus (slot = 3) and // if there is no modules config problem (general) and // if there is no config problem in that module (specific) and // if there is no fatal error identification by the module and // if there is no calibration error indication and // if there is no over/under range error indication and // if there is no error indication of input in open loop ... IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 3)) = 0 AND DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = FALSE AND DG_NX6000_8_AI_Voltage_Current.tGeneral.bConfigMismatch = FALSE AND DG_NX6000_8_AI_Voltage_Current.tGeneral.bFatalError = FALSE AND DG_NX6000_8_AI_Voltage_Current.tGeneral.bCalibrationError = FALSE AND DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOverRange = FALSE AND DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bUnderRange = FALSE AND DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOpenLoop = FALSE THEN QUALITY_PB_NX6000.VALIDITY:= VALIDITY_GOOD; QUALITY_PB_NX6000.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_FAILURE:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_OLD_DATA:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_INACCURATE:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_OUT_OF_RANGE:= FALSE; ELSE // Condition to turns on imprecision indication // (check first, because invalid validity must prevail) IF DG_NX6000_8_AI_Voltage_Current.tGeneral.bCalibrationError = TRUE THEN QUALITY_PB_NX6000.VALIDITY:= VALIDITY_QUESTIONABLE; QUALITY_PB_NX6000.FLAGS.FLAG_INACCURATE:= TRUE; ELSE QUALITY_PB_NX6000.FLAGS.FLAG_INACCURATE:= FALSE; END_IF // Condition to turns on out of range indication // (check first, because invalid validity must prevail) 73 5. CONFIGURATION IF DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOverRange = TRUE OR DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bUnderRange = TRUE THEN QUALITY_PB_NX6000.VALIDITY:= VALIDITY_QUESTIONABLE; QUALITY_PB_NX6000.FLAGS.FLAG_OUT_OF_RANGE:= TRUE; ELSE QUALITY_PB_NX6000.FLAGS.FLAG_OUT_OF_RANGE:= FALSE; END_IF // Condition to turns on general failure indication (priority) IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 3)) > 0 OR DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = TRUE OR DG_NX6000_8_AI_Voltage_Current.tGeneral.bConfigMismatch = TRUE OR DG_NX6000_8_AI_Voltage_Current.tGeneral.bFatalError = TRUE OR DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOpenLoop = TRUE THEN QUALITY_PB_NX6000.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX6000.FLAGS.FLAG_FAILURE:= TRUE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX6000.FLAGS.FLAG_RESTART AND NOT DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOpenLoop THEN QUALITY_PB_NX6000.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF ELSE QUALITY_PB_NX6000.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_FAILURE:= FALSE; QUALITY_PB_NX6000.FLAGS.FLAG_OLD_DATA:= FALSE; END_IF END_IF END_IF // In PROFIBUS communication failure with the PROFIBUS slave ... ELSE QUALITY_PB_NX6000.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX6000.FLAGS.FLAG_COMM_FAIL:= TRUE; QUALITY_PB_NX6000.FLAGS.FLAG_FAILURE:= FALSE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX6000.FLAGS.FLAG_RESTART AND NOT DG_NX6000_8_AI_Voltage_Current.tDetailed.tAnalogInput_00.bOpenLoop THEN QUALITY_PB_NX6000.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF 5.1.4.1.9. PROFIBUS Analog Output Quality // PROFIBUS analog output quality update, module NX6100 // In communication success case with PROFIBUS slave (address = 99) ... IF DG_NX5001.tMstStatus.abySlv_State.bSlave_99 = TRUE THEN // Waits the PROFIBUS slave become apt to exchange data and diagnostics // (It is necessary to wait, avoiding invalid quality generation) IF DG_NX5110.tPbusHeadA.tStatus1.bStation_Non_Existent = FALSE AND 74 5. CONFIGURATION DG_NX5110.tPbusHeadA.tStatus1.bStation_Not_Ready = FALSE AND DG_NX5110.tPbusHeadA.wIdentNumber > 0 THEN QUALITY_PB_NX6100.FLAGS.FLAG_COMM_FAIL:= FALSE; // If there is a module present on the bus (slot = 4) and // if there is no modules config problem (general) and // if there is no config problem in that module (specific) and // if there is no fatal error identification by the module and // if there is no calibration error indication and // if there is no external power supply missing indication and // if there is no error indication of output in open loop and // if there is no outputs short circuit indication ... IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 4)) = 0 AND DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = FALSE AND DG_NX6100_4_AO_Voltage_Current.tGeneral.bConfigMismatch = FALSE AND DG_NX6100_4_AO_Voltage_Current.tGeneral.bFatalError = FALSE AND DG_NX6100_4_AO_Voltage_Current.tGeneral.bCalibrationError = FALSE AND DG_NX6100_4_AO_Voltage_Current.tGeneral.bNoExternalSupply = FALSE AND DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bOpenLoop = FALSE AND DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bShortCircuit = FALSE THEN QUALITY_PB_NX6100.VALIDITY:= VALIDITY_GOOD; QUALITY_PB_NX6100.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX6100.FLAGS.FLAG_FAILURE:= FALSE; QUALITY_PB_NX6100.FLAGS.FLAG_INACCURATE:= FALSE; QUALITY_PB_NX6100.FLAGS.FLAG_OLD_DATA:= FALSE; ELSE // Condition to turns on imprecision indication // (check first, because invalid validity must prevail) IF DG_NX6100_4_AO_Voltage_Current.tGeneral.bCalibrationError = TRUE THEN QUALITY_PB_NX6100.VALIDITY:= VALIDITY_QUESTIONABLE; QUALITY_PB_NX6100.FLAGS.FLAG_INACCURATE:= TRUE; ELSE QUALITY_PB_NX6100.FLAGS.FLAG_INACCURATE:= FALSE; END_IF // Condition to turns on general failure indication (priority) IF (DG_NX5110.tPbusHeadA.dwModuleNotPresent AND SHL(1, 4)) > 0 OR DG_NX5110.tPbusHeadA.tSummarized.bConfigMismatch = TRUE OR DG_NX6100_4_AO_Voltage_Current.tGeneral.bConfigMismatch = TRUE OR DG_NX6100_4_AO_Voltage_Current.tGeneral.bFatalError = TRUE OR DG_NX6100_4_AO_Voltage_Current.tGeneral.bNoExternalSupply = TRUE OR DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bOpenLoop = TRUE OR DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bShortCircuit = TRUE THEN QUALITY_PB_NX6100.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX6100.FLAGS.FLAG_FAILURE:= TRUE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX6100.FLAGS.FLAG_RESTART AND NOT DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bOpenLoop THEN QUALITY_PB_NX6100.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF ELSE QUALITY_PB_NX6100.FLAGS.FLAG_RESTART:= FALSE; QUALITY_PB_NX6100.FLAGS.FLAG_FAILURE:= FALSE; 75 5. CONFIGURATION QUALITY_PB_NX6100.FLAGS.FLAG_OLD_DATA:= FALSE; END_IF END_IF END_IF // In PROFIBUS communication failure with the PROFIBUS slave ... ELSE QUALITY_PB_NX6100.VALIDITY:= VALIDITY_INVALID; QUALITY_PB_NX6100.FLAGS.FLAG_COMM_FAIL:= TRUE; QUALITY_PB_NX6100.FLAGS.FLAG_FAILURE:= FALSE; // If the point have ever been updated once ... IF NOT QUALITY_PB_NX6100.FLAGS.FLAG_RESTART AND NOT DG_NX6100_4_AO_Voltage_Current.tDetailed.tAnalogOutput_00.bOpenLoop THEN QUALITY_PB_NX6100.FLAGS.FLAG_OLD_DATA:= TRUE; END_IF END_IF 5.2. Serial Interfaces Configuration 5.2.1. COM 1 The COM 1 communication interface is composed by a DB9 female connector for the RS-422 and RS-485 standards. It allows the point to point or network communication in the open protocols MODBUS RTU slave or MODBUS RTU master. When using the MODBUS master/slave protocol, some of these parameters (such as Serial Mode, Data Bits, UART RX Threshold and Serial Events) are automatically adjusted by MasterTool for the correct operation of this protocol. The parameters which must be configured for the proper functioning of the application are described below. Configuration Serial Type Baud Rate Parity Data Bits Stop Bits Serial Mode Description Serial channel configuration. Serial communication port speed configuration. Default RS-485 115200 Serial port parity configuration. None Sets the data bits quantity in each serial communica- 8 tion character. Sets the serial port stop bits. 1 Sets the serial port operation mode. Normal Mode Options RS-422 and RS-485 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps Odd Even Mark Space None 5, 6, 7 and 8 1, 1.5 and 2 - Extended Mode: Extended operation mode which delivers information regarding the received data frame (see note on COM 1 section). - Normal Mode: Serial communication normal operation mode Table 49: RS-485/RS-422 Standard Serial Configurations 76 5. CONFIGURATION Notes: Extended Mode: This serial communication operation mode provides information regarding the data frame received. The information available is the following: One byte for the received data (RX_CHAR : BYTE): Store the five, six, seven or eight bits from the data received, depending on the serial communication configuration. One byte for the signal errors (RX_ERROR : BYTE): It has the format described below: · Bit 0: 0 - the character in bits 0 to 7 is valid. 1 - the character in bits 0 to 7 is not valid (or it cannot be valid), due to problems indicated in bits 10 to 15. · Bit 1: Not used. · Bit 2: Not used. · Bit 3: UART interruption error. The serial input remained in logic 0 (space) for a time greater than a character (start bit + data bits + parity bit + stop bits). · Bit 4: UART frame error. The logic 0 (space) was read when the first stop bit was expected and it should be logic 1 (mark). · Bit 5: UART parity error. The parity bit read is not correct according to the calculated one. · Bit 6: UART overrun error. Data was lost during the FIFO UART reading. New characters were received before the later ones were removed. This error will only be indicated in the first character read after the overrun error indication. This means some old data were lost. · Bit 7: RX line overrun error. This character was written when the RX line was completed, overwriting the unread characters. Two bytes for the timestamp signal (RX_TIMESTAMP : WORD): Indicates the silence time, within the 0 to 65535 interval, using 10 us as base. It saturates in 655.35 ms if the silence time is higher than 65535 units. The RX_TIMESTAMP of a character measures the time from a reference which can be any of the three options below: · On most of the cases, the end of the later character. · Serial port configuration. · The end of serial communication using the SERIAL_TX FB, in other words, when the last character is sent on line. Besides measuring the silence between characters, the RX_TIMESTAMP is also important as it measures the silence time of the last character on the RX line. The silence measuring is important for the correct protocol implementation, as MODBUS RTU, for example. This protocol specifies an inter-frame greater than 3.5 characters and an inter-byte less than 1.5 characters. Data Bits: The serial interfaces Data Bits configuration limits the Stop Bits and Communication Parity fields. Therefore, the stop bits number and the parity method will vary according to the data bits number. Data Bits 5 6 7 8 Stop Bits 1, 1.5 1, 2 1, 2 1, 2 Parity NO PARITY, ODD, EVEN, PARITY ALWAYS ONE, PARITY ALWAYS ZERO NO PARITY, ODD, EVEN, PARITY ALWAYS ONE, PARITY ALWAYS ZERO NO PARITY, ODD, EVEN, PARITY ALWAYS ONE, PARITY ALWAYS ZERO NO PARITY, ODD, EVEN, PARITY ALWAYS ONE, PARITY ALWAYS ZERO Table 50: Specific Configurations 5.2.1.1. Advanced Configurations The advanced configurations are related to the serial communication control, in other words, when it is necessary the utilization of a more accurate data transmission and reception control. 77 5. CONFIGURATION Configuration UART RX Threshold Description Bytes quantity which must be received for a new UART interruption to be generated. Low values make the TIMESTAMP more precise when the EXTENDED MODE is used and minimizes the overrun errors. However, values too low may cause several interruptions delaying the CPU. Default 8 Options 1, 4, 8 and 14 Table 51: RS-485/RS-422 Standard Serial Advanced Configurations 5.3. Ethernet Interfaces Configuration Nexto CPUs can provide more local Ethernet interfaces. The NX3005 CPU has only the NET 1 interface. In addition to the local Ethernet interfaces, the Nexto Series also provides remote Ethernet interfaces by including the NX5000 module. The NX5000 modules have only the NET 1 interface. 5.3.1. Internal Ethernet Interface The interface is composed by a RJ45 communication connector 10/100Base-TX standard. It allows the point to point or network communication in the following open protocols: MODBUS TCP Client, MODBUS RTU via TCP Client, MODBUS TCP Server and MODBUS RTU via TCP Server. The parameters which must be configured for the proper functioning of the application are described below. 5.3.1.1. NET 1 Configuration Obtain an IP address automatically IP Address Subnetwork Mask Gateway Address Description Enables the DHCP Client functionality on the device for automatic IP assignment IP address of the controller in the Ethernet bus Subnet mask of the controller in the Ethernet bus Controller Gateway address in the Ethernet bus Default Unmarked 192.168.15.1 255.255.255.0 192.168.15.253 Table 52: NET 1 Configuration Options Marked or Unmarked 1.0.0.1 to 223.255.255.254 128.0.0.0 to 255.255.255.252 0.0.0.0 to 223.255.255.254 5.3.2. NX5000 Remote Ethernet Interface 5.3.2.1. NET 1 The interface is composed by a RJ45 communication connector 10/100Base-TX standard. It allows the point to point or network communication in the following open protocols: MODBUS TCP Client, MODBUS RTU via TCP Client, MODBUS TCP Server and MODBUS RTU via TCP Server. The parameters which must be configured for the proper functioning of the application are described below. 78 5. CONFIGURATION Configuration IP Address Subnetwork Mask Gateway Address Description IP address of the controller in the Ethernet bus Subnet mask of the controller in the Ethernet bus Gateway address of the controller in the Ethernet bus Default 192.168.xx.68 255.255.255.0 192.168.xx.253 Table 53: NX5000 Remote NET 1 Configuration Options 1.0.0.1 to 223.255.255.254 128.0.0.0 to 255.255.255.252 0.0.0.0 to 223.255.255.254 5.3.3. Reserved TCP/UDP Ports The following TCP/UDP ports of the Ethernet interfaces, both local and remote, are used by CPU services (depending on availability according to table Protocols) and, therefore, are reserved and must not be used by the user. Service System Web Page SNTP SNMP MODBUS TCP MasterTool MT8500 SQL Server MQTT EtherNet/IP IEC 60870-5-104 OPC UA WEBVISU CODESYS ARTI PROFINET TCP 80 - 502* 1217* 1433 1883* / 8883* 44818 2404* 4840 8080 11740 - UDP - 123 161 1740:1743 2222 34964 Table 54: Reserved TCP/UDP ports * Default port, but user changeable. 5.4. Protocols Configuration Independently of the protocols used in each application, the Nexto Series CPUs has some maximum limits for each CPU model. There are basically two different types of communication protocols: symbolic and direct representation mappings. The maximum limit of mappings as well as the maximum protocol quantity (instances) is defined on table below: Mapped Points Mappings (Per Instance / Total) Requests NETs Client or Server Instances (Per NET / Total) COM (n) Master or Slave Instances Control Centers NX3005 20480 5120 / 20480 512 4/4 1 3 Table 55: Protocols Limits per CPU 79 5. CONFIGURATION Notes: Mapped Points: It refers to the maximum number of mapped points supported by the CPU. Each mapping supports one or more mapped points, depending on the size of the data when used with variables of type ARRAY. Mappings: A "mapping" is the relationship between an internal application variable and an object of the application protocol. This field informs the maximum number of mappings supported by the CPU. It corresponds to the sum of all mappings made within the instances of communication protocols and their respective devices. Requests: The sum of the requests of the communications protocols, declared on devices, may not exceed the maximum number of requests supported by the CPU. NETs Clients or Servers Instances: This field defines the maximum number of protocol instances per Ethernet interface, and also the total maximum distributed along all the Ethernet interfaces of the system. COM (n) Master or Slave Instances: Due to its characteristics, each serial interface supports only one communication protocol instance. Examples of instances compatible with serial interfaces: MODBUS RTU Master and MODBUS RTU Slave. Control Centers: "Control Center" is all client device connected to the CPU through protocol IEC 60870-5-104. This field informs the maximum of client devices of control center type supported by the CPU. Correspond to the sum of all client devices of communication protocol IEC 60870-5-104 Server (does not include master or clients from MODBUS RTU Slave, MODBUS Server and DNP3 Server protocols). The limitations of the MODBUS protocol for Direct Representation and symbolic mapping for the CPUs can be seen in Tables 56 and 57, respectively. Limitations Mappings per instance Devices per instance Mappings per device Simultaneous requests per instance Simultaneous requests per device MODBUS RTU Master 128 64 32 - - MODBUS RTU Slave 32 1(1) 32 - - MODBUS Ethernet Client 128 64 32 128 8 MODBUS Ethernet Server 32 64(2) 32 64 64 Table 56: MODBUS Protocol Limitations for Direct Representation Notes: Devices per instance: Master or Client Protocols: number of slaves or server devices supported by each Master or Slave protocol instance. MODBUS RTU Slave Protocol: the limit (1) informed relates to serial interfaces that do not allow a Slave to establish communication through the same serial interface, simultaneously, with more than one Master device. It's not necessary, nor is it possible to declare or configure the Master device in the instance of the MODBUS RTU slave protocol. The master device will have access to all the mappings made directly on the instance of MODBUS RTU slave protocol. MODBUS RTU Server Protocol: the limit (2) informed relates to the Ethernet interfaces, which limit the number of connections that can be established with other devices through a single Ethernet interface. It is not necessary, nor is it possible to declare or configure Clients devices in the instance of the MODBUS Server protocol. All Clients devices will have access to all the mappings made directly in the instance of the MODBUS Server protocol. Mappings per device: The maximum number of mappings per device, despite being listed above, is also limited by the protocol maximum number of mappings. Also to be considered the maximum CPU mappings as in Table 55. Simultaneous Requests per Instance: Number of requests that can be simultaneously transmitted by each Client protocol instance or that can be received simultaneously by each Server protocol instance. MODBUS RTU protocol instances, Master or Slave, do not support simultaneous requests. Simultaneous Requests per Device: Number of requests that can be simultaneously transmitted to each MODBUS Server device, or may be received simultaneously by each MODBUS client device. MODBUS RTU devices, Master or Slave, do not support simultaneous requests. Limitations Devices per instance Requests per device MODBUS RTU Master 64 32 MODBUS RTU Slave 1(1) - MODBUS Ethernet Client 64 32 MODBUS Ethernet Server 64(2) - 80 5. CONFIGURATION Limitations Simultaneous requests per instance Simultaneous requests per device MODBUS RTU Master - - MODBUS RTU Slave - - MODBUS Ethernet Client 128 8 MODBUS Ethernet Server 64 64 Table 57: MODBUS Protocol Limitations for Symbolic Mappings Notes: Devices per instance: Master or Client Protocol: Number of slave or server devices supported by each Master or Client protocol instance. MODBUS RTU Slave Protocol: the limit (1) informed relates to serial interfaces that do not allow a Slave to establish communication through the same serial interface, simultaneously, with more than one Master device. It's not necessary, nor is it possible to declare or configure the Master device in the instance of the MODBUS RTU slave protocol. The master device will have access to all the mappings made directly on the instance of MODBUS RTU slave protocol. MODBUS RTU Server Protocol: the limit (2) informed relates to the Ethernet interfaces, which limit the amount of connections that can be established with other devices through a single Ethernet interface. It is not necessary, nor is it possible to declare or configure Clients devices in the instance of the MODBUS Server protocol. All Clients devices will have access to all the mappings made directly in the instance of the MODBUS Server protocol. Requests by device: Number of requests, such as reading or writing holding registers, which can be configured for each of the devices (slaves or servers) from Master or Client protocols instances. This parameter does not apply to instances of Slave or Server protocols. Simultaneous Requests per Instance: Number of requests that can be simultaneously transmitted by each client protocol instance or that can be received simultaneously by each server protocol instance. MODBUS RTU protocol instances, Master or Slave, do not support simultaneous requests. Simultaneous Requests per Device: Number of requests that can be simultaneously transmitted for each MODBUS server device, or may be received simultaneously from each MODBUS client device. MODBUS RTU devices, Master or Slave do not support simultaneous requests. ATTENTION Simultaneous requests to a variable associated to communication points, those which support the SBO operation mode (Select Before Operate), even being received from different devices are not supported. Once started the selection/operation of a point by a specific device, that must be finished before this point become able to be commanded by another device. The protocol IEC 60870-5-104 Server limitations can be watched on table below. Limitations Devices per instance Simultaneous requests per instance Simultaneous requests per device IEC 60870-5-104 Server 3 3 1 Table 58: Protocol IEC 60870-5-104 Server Limits Notes: Devices per instance: Quantity of client devices, of type control center, supported for each IEC 60870-5-104 Server protocol instance. The limit informed might be smaller because of the CPU total limits (check Table 55). Simultaneous requests per instance: Quantity of requests that can be received simultaneously by each instance of Server protocol. Simultaneous requests per device: Quantity of requests that can be received simultaneously of each IEC 60870-5-104 Client device. 81 5. CONFIGURATION 5.4.1. Protocol Behavior x CPU State The table below shows in detail the behavior of each configurable protocol in Nexto Series CPUs in every state of operation. Protocol MODBUS Symbol MODBUS SOE (DNP3) IEC 60870-5-104 EtherCAT OPC DA OPC UA SNTP HTTP SNMP EtherNet/IP Type Slave/Server Master/Client Slave/Server Master/Client Outstation Server Master Server Server Client Server Agent Scanner Adapter After download, before application starts STOP CPU operational state RUN After the application goes to STOP (PAUSE) After an exception Non redundant or Active Redundant in Standby After a breakpoint in MainPrg NA NA NA Table 59: Protocol Behavior x CPU State Notes: Symbol : Protocol remains active and operating normally. Symbol : Protocol is disabled. EtherCAT: The tests were performed using the default value defined in PLC Settings (see table PLC Settings), with option Update I/O during stop checked and option Configure all outputs to default. MODBUS Symbol Slave/Server: To keep the protocol communicating when the CPU isn't in RUN or after a breakpoint, it's need to check the option "Keep the communication running on CPU stop". 5.4.2. Double Points The input and output double digital points representation is done through a special data type called DBP (defined in the LibDataTypes library). This type consist basically in a structure of two BOOL type elements, called OFF and ON (equivalent to TRIP and CLOSE respectively). In Nexto, variables of this type cannot be associated to digital input and output modules, being necessary the single digital points mapping, BOOL type, and the treatment by application to conversion in double points. To further information about the double points mapping in the input and output digital modules check the IEC 60870-5-104 Server section. 5.4.3. CPU's Events Queue The CPU owns an events queue of type FIFO (First In, First Out) used to store temporarily the events related to communication points until they are moved to their final destiny. 82 5. CONFIGURATION All communication points events generated in the CPU are directed and stored in CPU's queue. This queue has the following features: Size: 1000 events Retentivity : it is not retentive Overflow policy: keep the newests ATTENTION In the Nexto PLC, the events queue is stored in a non-retentive memory area (volatile). This way, the events present in CPU's queue, which haven't been transmitted yet to the control center, are going to be lost in a CPU's eventual power off. The CPU's event queue is redundant, that means it is synchronized each cycle between both CPUs, when is used CPU's redundancy. Further information can be found on the section about CPU redundancy. The in and out of events in this queue follows the concept of producer/consumer. Producers are those system elements capable of generate events, adding events in the CPU's queue, while the consumers are those system elements which receive and use this events, taking them of the CPU's queue. The figure below describes this working, including the example of some events consumers and producers. Figure 45: CPU's Event Queue 5.4.3.1. Consumers The consumers are typically communication drivers that will communicate with SCADA or HMI. After been stored in CPU's queue, the consumers receive the events related to communication points mapped in its configuration. These events are then stored in a consumer's own events queue, which the size and working are described on the communication driver specific section. 83 5. CONFIGURATION 5.4.3.2. Queue Functioning Principles Once stored in CPU's queue, each event is transmitted to the consumer that has this communication point in its data base. On the figure above, the Event 0 is referred to a communication point mapped to two control centers IEC 60870-5-104 (Client 1 and 2). Thus the Event 1 is referred to a communication point mapped only to one control center IEC 60870-5-104 (Client 2). By its time, the Event 2 is referred to a communication point mapped to another control center IEC 60870-5-104 (Client 3). The events remain stored in the CPU's queue until all its consumers acknowledge its receiving. The criteria used to confirm the receive is specific of each consumer. In case of the IEC 60870-5-104 Server, the acknowledge occurs when the event is transmitted to the IEC 60870-5-104 client. In Nexto Series case, there are no diagnostics available to watch the CPU's events queue occupation, not even information about the queue overflow. However the consumers have a diagnostics group referred to its events queue. Further information can be found at the specific driver communication section. 5.4.3.2.1. Overflow Signaling The overflow sign to the consumers' events queue occurs in two situations: When the consumer events queue is out of space to store new events If the CPU aborted the event generation (because occurred to more events in a single execution cycle than the events queue total size) 5.4.3.3. Producers The producers are typically communication drivers or PLC internal elements that are capable to generate events. The previous figure show some examples. Internal Points: This is a PLC's firmware internal element, which detects events each execution cycle (MainTask) to those communication points that don't have a defined origin and then inserts the events in the CPU's queue. The maximum number of events that can be detected in each MainTask cycle is equal to the CPU's events queue size. In case the number of generated events is bigger than this, in a single cycle, the exceeding are going to be lost. MODBUS Driver (Client/Server/Master/Slave): The variables value change caused by MODBUS read/write are detected at each MainTask cycle and then the events are inserted in CPU's queue. In Client/Master cases, are also generated quality events when there is a communication failure with the slave device. 5.4.4. Interception of Commands Coming from the Control Center The Nexto PLC has a function block that allows selection commands and operation to the output points received by server drivers (IEC 60870-5-104 Server) been treated by the user logic. This resource allows the interlocking implementation, as well as the handling of the received command data in the user logic, or yet the command redirecting to different IEDs. The commands interception is implemented by the CommandReceiver function block, defined in the LibRtuStandard. The input and output parameters are described on the following tables: Parameter bExec bDone dwVariableAddr Type BOOL BOOL DWORD Description When TRUE, executes the command interception Indicates that the command output data have been already processed, releasing the function block to receive another command Variable address, mapped in the server driver, which will receive the client command 84 5. CONFIGURATION Parameter Type eCommandResult ENUM dwTimeout DWORD Description Input action defined by user from the following list: SUCCESS(0) NOT_SUPPORTED(1) BLOCKED_BY_SWITCHING_HIERARCHY(2) SELECT_FAILED(3) INVALID_POSITION(4) POSITION_REACHED(5) PARAMETER_CHANGE_IN_EXECUTION(6) STEP_LIMIT(7) BLOCKED_BY_MODE(8) BLOCKED_BY_PROCESS(9) BLOCKED_BY_INTERLOCKING(10) BLOCKED_BY_SYNNCHROCHECK(11) COMMAND_ALREADY_IN_EXECUTION(12) BLOCKED_BY_HEALTH (13) ONE_OF_N_CONTROL(14) ABORTION_BY_CANCEL(15) TIME_LIMIT_OVER(16) ABORTION_BY_TRIP(17) OBJECT_NOT_SELECTED(18) OBJECT_ALREADY_SELECTED(19) NO_ACCESS_AUTHORITY(20) ENDED_WITH_OVERSHOOT(21) ABORTION_DUE_TO_DEVIATION(22) ABORTION_BY_COMMUNICATION_LOSS(23) BLOCKED_BY_COMAND(24) NONE(25) INCONSISTENT_PARAMETERS(26) LOCKED_BY_OTHER_CLIENT(27) HARDWARE_ERROR(28) UNKNOWN(29) Time-out [ms] to the treatment by user logic Table 60: CommandReceiver Function Block Input Parameters Notes: bExec: When FALSE, the command just stop being intercepted for the user application, but it keeps being treated normally by the server. bDone: After the command interception, the user is going to be responsible for treat it. At the end of the treatment, this input must be enabled for a new command can be received. Case this input is not enabled, the block is going to wait the time defined in dwTimeout, to then become capable of intercept new commands. eCommandResult: Treatment results of command intercepted by user. The result returned to the client that sent the command, which must be attributed together with the input bDone, is converted to the protocol's format from which was received the command. In Nexto Series it is only supported the interception of commands coming from protocol IEC 608705-104. In protocol interception, any return different from SUCCESS results in a negative Acknowledge. ATTENTION It is not recommended the simultaneous commands interception to one same variable by two or more CommandReceiver function blocks. Just one of the function blocks will intercept correctly the command, being able to suffer undesirable interference from the others function blocks if addressed to the same variable. 85 5. CONFIGURATION Parameter bCommandAvailable sCommand eStatus Type BOOL STRUCT ENUM (TYPE_RESULT) Description Indicates that a command was intercepted and the data are available to be processed This structure stores received command data, which is composed by the following fields: eCommand sSelectParameters sOperateParameters The description of each field is in this section. Out of function action from obtained result, according to list: OK_SUCCESS(0) ERROR_FAILED(1) Table 61: CommandReceiver Function Block Output Parameters Note: eStatus: Return of a register process of a communication point command interception. When the interception is registered with success OK_SUCCESS is returned, else ERROR_FAILED is. In case interceptor register failure, commands to the determined point are not intercepted by this function block. TYPE_RESULT is defined in LibDataTypes library. Supported commands are described on table below: Parameter eCommand Type ENUM Description NO_COMMAND(0) SELECT(1) OPERATE(2) Table 62: CommandReceiver Function Block Supported Commands The parameters that build the sSelectParameters, sOperateParameters and sCancelParameters structures are described on the following table: Parameter sSelectConfig sValue Type STRUCT STRUCT Description Received selection command configuration. This structure parameters are described on Table 64 Received value in a select, when is received a selection command with value. This structure parameters are described on Table 67 Table 63: Parameters sSelectParameters Parameter bSelectWithValue Type BOOL Description When true indicates a selection command reception with value. Table 64: Parameters sSelectConfig 86 5. CONFIGURATION Parameter sOperateConfig sValue Type STRUCT STRUCT Description Received selection command configuration. This structure parameters are described on Table 66 Field of received operation command referred value. This structure parameters are described on Table 67 Table 65: Parameters sOperateParameters Parameter bDirectOperate bNoAcknowledgement bTimedOperate liOperateTime bTest Type BOOL BOOL BOOL LINT BOOL Description When true indicates that an operation command without select was received. When true indicates that a command, which doesn't require the receiving acknowledge, was received. When true indicates that an operation command activated by time was received. Programming of the instant in which it must be runned the command. This field is valid only when bTimedOperate is true. When true indicates that the received command was sent only for test, as so the command must not be runned. Table 66: Parameters sOperateConfig Parameter eParamType sSinglePoint sDoublePoint sIntegerStatus sEnumeratedStatus sAnalogueValue Type ENUM STRUCT STRUCT STRUCT STRUCT STRUCT Description Informs the type of the received command: NO_COMMAND(0) SINGLE_POINT_COMMAND(1) DOUBLE_POINT_COMMAND(2) INTEGER_STATUS_COMMAND(3) ENUMERATED_STATUS_COMMAND(4) ANALOGUE_VALUE_COMMAND(5) When a command is received, in received command type function, defined by eParamType, the corresponding data structure is filled. This structures parameters are described on Tables 68 to 72 Table 67: Parameters sValue Parameter bValue sPulseConfig Type BOOL STRUCT Description Point operation value. The pulsed command configuration parameters are stored in this structure. This structure parameters are described on Table 73. Table 68: Parameters sSinglePoint 87 5. CONFIGURATION Parameter bValue sPulseConfig Type BOOL STRUCT Description Point operation value. The pulsed command configuration parameters are stored in this structure. This structure parameters are described on Table 73. Table 69: Parameters sDoublePoint Parameter diValue Type DINT Description Point operation value. Table 70: Parameters sIntegerStatus Parameter dwValue Type DWORD Description Point operation value. Table 71: Parameters sEnumeratedStatus Parameter eType diValue fValue Type ENUM DINT REAL Description Informs the data type of the received analog value. INTEGER (0) FLOAT (1) Point operation value, integer format. Point operation value, float format. Table 72: Parameters sAnalogueValue Parameter bPulseCommand dwOnDuration dwOffDuration dwPulseCount Type BOOL DWORD DWORD DWORD Description When true indicates that received command is pulsed. This is time, in milliseconds, that the output must remain on. This is time, in milliseconds, that the output must remain off. Number of times the command must be executed. Table 73: Parameters sPulseConfig To intercept commands to a specific point, first it is need to load in the dwVariableAddr parameter the variable address correspondent to the point wanted to intercept the commands and then execute a pulse in the bExec parameter. Once the command was intercepted, the function block informs that a command was intercepted through bCommandAvailable parameter. The intercepted command information are then filled in the sCommand and eStatus output parameters, according to the received command type. This operation depends only of the received command type, don't matter the variable's data type to which is being intercepted the command. The interception is finished and then the function block can be released to intercept a new command when bDone parameter is true. Yet must be pointed the command processing result in eCommandResult. 88 5. CONFIGURATION 5.4.5. MODBUS RTU Master This protocol is available for the Nexto Series CPUs in its serial channels. By selecting this option at MasterTool IEC XE, the CPU becomes MODBUS communication master, allowing the access to other devices with the same protocol, when it is in the execution mode (Run Mode). There are two configuration modes for this protocol. One makes use of Direct Representation (%Q), in which the variables are defined by its address. The other, called Symbolic Mapping has the variables defined by its name. Regardless of the configuration mode, the steps to insert a protocol instance and configure the serial interface are the same. The procedure to insert a protocol instance is found in detail in the MasterTool IEC XE User Manual - MU299609 or in the section Inserting a Protocol Instance. The remaining configuration steps are described below for each mode. Add the MODBUS RTU Master Protocol instance to the serial channel COM 1 or COM 2 (or both, in case of two communication networks). To execute this procedure, see Inserting a Protocol Instance section. Configure the serial interface, choosing the transmission speed, the RTS/CTS signals behavior, the parity, the channel stop bits, among others configurations by a double click on the COM 1 or COM 2 serial channel. See Serial Interfaces Configuration section. 5.4.5.1. MODBUS Master Protocol Configuration by Symbolic Mapping To configure this protocol using symbolic mapping, you must perform the following steps: Configure the general parameters of the MODBUS Master protocol, like: transmission delay times and minimum interframe as in Figure 46. Add and configure devices via the General Parameters tab, defining the slave address, communication time-out and number of communication retries as can be seen in Figure 47. Add and configure the MODBUS mappings on Mappings tab as Figure 48, specifying the variable name, data type, and the data initial address, the data size and range are filled automatically. Add and configure the MODBUS requests as presented in Figure 49, specifying the function, the scan time of the request, the starting address (read/write), the data size (read/write) and generate diagnostic variables and disabling the request via the buttons at the bottom of the window. 5.4.5.1.1. MODBUS Master Protocol General Parameters Symbolic Mapping Configuration The general parameters, found on the MODBUS protocol initial screen (figure below), are defined as: Figure 46: MODBUS RTU Master Configuration Screen Configuration Send Delay (ms) Minimum (chars) Interframe Description Delay for the answer transmission. Minimum silence time between different frames. Default 0 3.5 Options 0 to 65535 3.5 to 100.0 Table 74: MODBUS RTU Master General Configurations Notes: Send Delay: The answer to a MODBUS protocol may cause problems in certain moments, as in the RS-485 interface or other half-duplex. Sometimes there is a delay between the slave answer time and the physical line silence (slave delay to put 89 5. CONFIGURATION RTS in zero and put the RS-485 in high impedance state). To solve this problem, the master can wait the determined time in this field before sending the new request. Otherwise, the first bytes transmitted by the master could be lost. Minimum Interframe: The MODBUS standard defines this time as 3.5 characters, but this parameter is configurable in order to attend the devices which do not follow the standard. The MODBUS protocol diagnostics and commands configured, either by symbolic mapping or direct representation, are stored in T_DIAG_MODBUS_RTU_MASTER_1 variables. For the direct representation mapping, they are also in 4 bytes and 8 words which are described in table below (where "n" is the configured value in the %Q Start Address of Diagnostics Area field): Direct Representation Variable %QX(n).0 %QX(n).1 %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 Diagnostic Variable T_DIAG_MODBUS _RTU_MASTER_1.* tDiag. bRunning tDiag. bNotRunning Size Diagnostics Bits: BIT BIT tDiag. bInterruptedByCommand tDiag. bConfigFailure tDiag. bRXFailure tDiag. bTXFailure tDiag. bModuleFailure tDiag. bDiag_7_reserved BIT BIT BIT BIT BIT BIT Error Codes: %QB(n+1) eErrorCode SERIAL_STATUS (BYTE) Description The master is running. The master is not running (see bit: bInterruptedByCommand). The bit bNotRunning was enabled as the master was interrupted by the user through command bits. Discontinued diagnosis. Discontinued diagnosis. Discontinued diagnosis. Indicates if there is failure in the module or the module is not present. Reserved 0: there are no errors 1: invalid serial port 2: invalid serial port mode 3: invalid baud rate 4: invalid data bits 5: invalid parity 6: invalid stop bits 7: invalid modem signal parameter 8: invalid UART RX Threshold parameter 9: invalid time-out parameter 10: busy serial port 11: UART hardware error 12: remote hardware error 20: invalid transmission buffer size 21: invalid signal modem method 22: CTS time-out = true 23: CTS time-out = false 24: transmission time-out error 30: invalid reception buffer size 90 5. CONFIGURATION Direct Representation Variable %QX(n+2).0 %QX(n+2).1 %QX(n+2).2 %QX(n+2).3 %QX(n+2).4 %QX(n+2).5 %QX(n+2).6 %QX(n+2).7 %QB(n+3) %QW(n+4) %QW(n+6) %QW(n+8) %QW(n+10) %QW(n+12) %QW(n+14) Diagnostic Variable T_DIAG_MODBUS Size _RTU_MASTER_1.* Description 31: reception time-out error 32: flow control configured differently from manual 33: invalid flow control for the configured serial port 34: data reception not allowed in normal mode 35: data reception not allowed in extended mode 36: DCD interruption not allowed 37: CTS interruption not allowed 38: DSR interruption not allowed 39: serial port not configured 50: internal error in the serial port Command bits, automatically initialized: tCommand. BIT bStop Stop master. tCommand. BIT bRestart Restart master. tCommand. BIT bResetCounter Restart diagnostics statistics (counters). tCommand. BIT bDiag_19_reserved Reserved tCommand. BIT bDiag_20_reserved Reserved tCommand. BIT bDiag_21_reserved Reserved tCommand. BIT bDiag_22_reserved Reserved tCommand. BIT bDiag_23_reserved Reserved byDiag_3_reserved BYTE Reserved Communication Statistics: tStat. wTXRequests WORD Counter of request transmitted by the master (0 to 65535). tStat. wRXNormalResponses WORD Counter of normal responses received by the master (0 to 65535). tStat. WORD wRXExceptionResponses Counter of responses with exception codes received by the master (0 to 65535). tStat. wRXIllegalResponses WORD Counter of illegal responses received by master invalid syntax, not enough received bytes, invalid CRC (0 to 65535). tStat. wRXOverrunErrors WORD Counter of overrun errors during reception - UART FIFO or RX line (0 to 65535). tStat. wRXIncompleteFrames WORD Counter of answers with construction errors, parity or failure during reception (0 to 65535). 91 5. CONFIGURATION Direct Representation Variable %QW(n+16) %QW(n+18) Diagnostic Variable T_DIAG_MODBUS _RTU_MASTER_1.* tStat. wCTSTimeOutErrors tStat. wDiag_18_Reserved Size WORD WORD Description Counter of CTS time-out error, using RTS/CTS handshake, during transmission (0 to 65535). Reserved Table 75: MODBUS RTU Master Diagnostics Note: Counters: All MODBUS RTU Master diagnostics counters return to zero when the limit value 65535 is exceeded. 5.4.5.1.2. Devices Configuration Symbolic Mapping configuration The devices configuration, shown on figure below, follows the following parameters: Figure 47: Device General Parameters Settings Configuration Slave Address Communication Time-out (ms) Maximum Number of Retries Description MODBUS slave address Defines the application level time-out Defines the numbers of retries before reporting a communication error Default 1 3000 2 Table 76: Device Configurations Options 0 to 255 10 to 65535 0 to 9 Notes: Slave Address: According to the MODBUS standard, the valid slave addresses are from 0 to 247, where the addresses from 248 to 255 are reserved. When the master sends a writing command with the address configured as zero, it is making broadcast requests in the network. Communication Time-out: The communication time-out is the time that the master waits for a response from the slave to the request. For a MODBUS RTU master device it must be taken into account at least the following system variables: the time it takes the slave to transmit the frame (according to the baud rate), the time the slave takes to process the request and the response sending delay if configured in the slave. It is recommended that the time-out is equal to or greater than the time to transmit the frame plus the delay of sending the response and twice the processing time of the request. For more information, see Communication Performance section. Maximum number of retries: Sets the number of retries before reporting a communication error. For example, if the slave does not respond to a request and the master is set to send three retries, the error counter number is incremented by one unit when the execution of these three retries. After the increase of the communication error trying to process restarts and if the number of retries is reached again, new error will increment the counter. 92 5. CONFIGURATION 5.4.5.1.3. Mappings Configuration Symbolic Mapping Settings The MODBUS relations configuration, showed on figure below, follows the parameters described on table below: Figure 48: MODBUS Data Mappings Screen Configuration Value Variable Data Type Data Start Address Data Size Data Range Description Symbolic variable name Default - MODBUS data type - Initial address of the MODBUS data - Size of the MODBUS data - The address range of configured data - Options Name of a variable declared in a program or GVL Coil - Write (1 bit) Coil - Read (1 bit) Holding Register - Write (16 bits) Holding Register - Read (16 bits) Holding Register Mask AND (16 bits) Holding Register Mask OR (16 bits) Input Register (16 bits) Input Status (1 bit) 1 to 65536 1 to 65536 - Table 77: MODBUS Mappings Settings 93 5. CONFIGURATION Notes: Value Variable: this field is used to specify a symbolic variable in MODBUS relation. Data type: this field is used to specify the data type used in the MODBUS relation. Data Type Coil - Write Coil - Read Holding Register - Write Holding Register - Read Holding Register - Mask AND Holding Register - Mask OR Input Register Input Status Size [bits] 1 1 16 16 16 16 16 1 Description Writing digital output. Reading digital output. Writing analog output. Reading analog output. Analog output which can be read or written with AND mask. Analog output which can be read or written with OR mask. Analog input which can be only read. Digital input which can be only read. Table 78: Data Types Supported in MODBUS Data Start Address: Data initial address of a MODBUS mapping. Data Size: The size value specifies the maximum amount of data that a MODBUS interface can access, from the initial address. Thus, to read a continuous address range, it is necessary that all addresses are declared in a single interface. This field varies with the MODBUS data type configured. Data Range: This field shows to the user the memory address range used by the MODBUS interface. 5.4.5.1.4. Requests Configuration Symbolic Mapping Settings The configuration of the MODBUS requests, viewed in figure below, follow the parameters described in table below: Figure 49: Data Requests Screen MODBUS Master 94 5. CONFIGURATION Configuration Function Code Polling (ms) Read Data Start Address Read Data Size Read Data Range Write Data Start Address Write Data Size Write Data Range Diagnostic Variable Disabling Variable Description MODBUS function type Communication period (ms) Initial address of the MODBUS read data Size of MODBUS Read data MODBUS Read data address range Initial address of the MODBUS write data Size of MODBUS Write data MODBUS Write data address range Diagnostic variable name Variable used to disable MODBUS relation Default Value - 100 - - Options 01 Read Coils 02 Read Input Status 03 Read Holding Registers 04 Read Input Registers 05 Write Single Coil 06 Write Single Register 15 Write Multiple Coils 16 Write Multiple Registers 22 Mask Write Register 23 Read/Write Multiple Registers 0 to 3600000 1 to 65536 Depends on the function used 0 to 2147483646 1 to 65536 Depends on the function used 0 to 2147483647 Name of a variable declared in a program or GVL Field for symbolic variable used to disable, individually, MODBUS requests configured. This variable must be of type BOOL. The variable can be simple or array element and can be in structures. Table 79: MODBUS Relations Configuration Notes: Setting: the number of factory default settings and the values for the column Options may vary according to the data type and MODBUS function (FC). Function Code: MODBUS (FC) functions available are the following: Code DEC HEX 1 0x01 2 0x02 3 0x03 4 0x04 Description Read Coils (FC 01) Read Input Status (FC 02) Read Holding Registers (FC 03) Read Input Registers (FC 04) 95 5. CONFIGURATION Code DEC HEX 5 0x05 6 0x06 15 0x0F 16 0x10 22 0x16 23 0x17 Description Write Single Coil (FC 05) Write Single Holding Register (FC 06) Write Multiple Coils (FC 15) Write Multiple Holding Registers (FC 16) Mask Write Holding Register (FC 22) Read/Write Multiple Holding Registers (FC 23) Table 80: MODBUS Functions Supported by Nexto CPUs Polling: this parameter indicates how often the communication set for this request must be performed. By the end of a communication will be awaited a time equal to the value configured in the field polling and after that, a new communication will be executed. Read Data Start Address: field for the initial address of the MODBUS read data. Read Data Size: the minimum value for the read data size is 1 and the maximum value depends on the MODBUS function (FC) used as below: Read Coils (FC 01): 2000 Read Input Status (FC 02): 2000 Read Holding Registers (FC 03): 125 Read Input Registers (FC 04): 125 Read/Write Multiple Registers (FC 23): 121 Read Data Range: this field shows the MODBUS read data range configured for each request. The initial address, along with the read data size will result in the range of read data for each request. Write Data Start Address: field for the initial address of the MODBUS write data. Write Data Size: the minimum value for the write data size is 1 and the maximum value depends on the MODBUS function (FC) used as below: Write Single Coil (FC 05): 1 Write Single Register (FC 06): 1 Write Multiple Coils (FC 15): 1968 Write Multiple Registers (FC 16): 123 Mask Write Register (FC 22): 1 Read/Write Multiple Registers (FC 23): 121 Write Data Range: this field shows the MODBUS write data range configured for each request. The initial address, along with the read data size will result in the range of write data for each request. Diagnostic Variable: The MODBUS request diagnostics configured by symbolic mapping or by direct representation, are stored in variables of type T_DIAG_MODBUS_RTU_MAPPING_1 for Master devices and T_DIAG_MODBUS_ETH_CLIENT_1 for Client devices and the mapping by direct representation are in 4-byte and 2-word, which are described in Table 81 ("n" is the value configured in the %Q Start Address of Diagnostics Area field). Direct Representation Variable %QX(n).0 %QX(n).1 Diagnostic variable of type T_DIAG_MODBUS Size Description _RTU_MAPPING_1.* Communication status bits: byStatus. BIT bCommIdle Communication idle (waiting to be executed). byStatus. BIT bCommExecuting Active communication. 96 5. CONFIGURATION Direct Representation Variable %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) %QB(n+2) %QB(n+3) %QW(n+4) %QW(n+6) Diagnostic variable of type T_DIAG_MODBUS Size _RTU_MAPPING_1.* Description byStatus. BIT bCommPostponed Communication delayed, because the maximum number of concurrent requests was reached. Deferred communications will be carried out in the same sequence in which they were ordered to avoid indeterminacy. The time spent in this State is not counted for the purposes of time-out. The bCommIdle and bCommExecuting bits are false when the bCommPostponed bit is true. byStatus. BIT bCommDisabled Communication disabled. The bCommIdle bit is restarted in this condition. byStatus. BIT bCommOk Communication terminated previously was held successfully. byStatus. BIT bCommError Communication terminated previously had an error. Check error code. byStatus. BIT bCommAborted Not used in MODBUS RTU Master. byStatus. BIT bDiag_7_reserved Reserved Last error code (enabled when bCommError = true): eLastErrorCode MASTER_ERROR _CODE (BYTE) Informs the possible cause of the last error in the MODBUS mapping. Consult Table 104 for further details. Last exception code received by master: NO_EXCEPTION (0) eLastExceptionCode MODBUS _EXCEP- FUNCTION_NOT_SUPPORTED (1) TION (BYTE) MAPPING_NOT_FOUND (2) ILLEGAL_VALUE (3) ACCESS_DENIED (128)* MAPPING_DISABLED (129)* IGNORE_FRAME (255)* Communication statistics: byDiag_3_reserved BYTE Reserved. wCommCounter WORD Finished communications counter (with or without errors). The user can test when communication has finished testing the variation of this counter. When the value 65535 is reached, the counter returns to zero. wCommErrorCounter WORD Finished communications counter (with errors). When the value 65535 is reached, the counter returns to zero. Table 81: MODBUS Relations Diagnostics Notes: Exception Codes: The exception codes presented in this field are values returned by the slave. The definitions of the exception codes 128, 129 and 255 presented in the table are valid only when using Altus slaves. Slaves from other manufacturers might use other definitions for each code. 97 5. CONFIGURATION Disabling Variable: variable of Boolean type used to disable, individually, MODBUS requests configured on request tab via button at the bottom of the window. The request is disabled when the variable, corresponding to the request, is equal to 1, otherwise the request is enabled. Last Error Code: The codes for the possible situations that cause an error in the MODBUS communication can be consulted below: Code 1 2 3 4 5 7 8 9 20 21 22 40 41 42 43 44 128 Enumerable ERR_EXCEPTION ERR_CRC ERR_ADDRESS ERR_FUNCTION ERR_FRAME_DATA_COUNT ERR_NOT_ECHO ERR_REFERENCE_NUMBER ERR_INVALID_FRAME_SIZE ERR_CONNECTION ERR_SEND ERR_RECEIVE ERR_CONNECTION_TIMEOUT ERR_SEND_TIMEOUT ERR_RECEIVE_TIMEOUT ERR_CTS_OFF_TIMEOUT ERR_CTS_ON_TIMEOUT NO_ERROR Description Reply is in an exception code (see eLastExceptionCode = Exception Code). Reply with invalid CRC. MODBUS address not found. The address that replied the request was different than expected. Invalid function code. The reply's function code was different than expected. The amount of data in the reply was different than expected. The reply is not an echo of the request (FC 05 and 06). Invalid reference number (FC 15 and 16). Reply shorter than expected. Error while establishing connection. Error during transmission stage. Error during reception stage. Application level time-out during connection. Application level time-out during transmission. Application level time-out while waiting for reply. Time-out while waiting CTS = false in transmission. Time-out while waiting CTS = true in transmission. No error since startup. Table 82: MODBUS Relations Error Codes ATTENTION Differently from other application tasks, when a depuration mark in the MainTask is reached, the task of a Master MODBUS RTU instance and any other MODBUS task will stop running at the moment that it tries to perform a writing in a memory area. It occurs in order to keep the consistency of the memory areas data while a MainTask is not running. 5.4.5.2. MODBUS Master Protocol Configuration for Direct Representation(%Q) To configure this protocol using direct representation (%Q), the following steps must be performed: Configure the general parameters of the MODBUS protocol, such as: communication times and direct representation variables (%Q) to receive diagnostics. Add and configure devices by setting address, direct representation variables (%Q) to disable the relations, communication time-outs, etc. Add and configure MODBUS relations, specifying the data type and MODBUS function, time-outs, direct representation variables (%Q) to receive diagnostics of the relation and other to receive/write the data, amount of data to be transmitted and relation polling. The descriptions of each configuration are listed below in this section. 98 5. CONFIGURATION 5.4.5.2.1. General Parameters of MODBUS Master Protocol - setting by Direct Representation (%Q) The General parameters, found on the home screen of MODBUS protocol configuration (figure below), are defined as: Figure 50: MODBUS RTU Master Setup Screen Direct representation variables (%Q) for the protocol diagnostic: Configuration %Q Start Address of Diagnostics Area Size Description Initial address of the diagnostic variables Size of diagnostics area Default Value - 20 Options 0 to 2147483628 Disabled for editing Table 83: MODBUS RTU Master Configuration Notes: Initial Address of Diagnostics in %Q: this field is limited by the size of outputs variables (%Q) addressable memory of each CPU, which can be found in section Memory. Default Value: the factory default value cannot be set to the %Q Start Address of Diagnostics Area field, because the creation of a Protocol instance may be held at any time on application development. The MasterTool IEC XE software itself allocate a value, from the range of output variables of direct representation (%Q), not used yet. The diagnostics and MODBUS protocol commands are described in Table 75. 99 5. CONFIGURATION The communication times of the MODBUS Master protocol, found on the button Advanced... in the configuration screen are divided into Send Delay and Minimum Interframe, further details are described in section MODBUS Master Protocol General Parameters Symbolic Mapping Configuration. 5.4.5.2.2. Devices Configuration Configuration for Direct Representation (%Q) The configuration of the devices, viewed in figure below, comprises the following parameters: Figure 51: Device Configuration Configuration Name Slave Address Communication Time-out (ms) Maximum Number of Retries Mapping Disabling Description Name of the instance The MODBUS slave address Sets the time-out of the application level Sets the number of retries before reporting a communication error Initial address used to disable MODBUS relations Default Value MODBUS_Device 1 1000 2 - Options Identifier, according to IEC 61131-3 0 to 255 10 to 65535 0 to 9 0 to 2147483644 Table 84: Device Configuration - MODBUS Master Notes: Instance Name: this field is the identifier of the device, which is checked according to IEC 61131-3, i.e. does not allow spaces, special characters and start with numeral character. It's limited in 24 characters. Mapping Disabling: composed of 32 bits, used to disable, individually, the 32 MODBUS relations configured in Device Mappings space. The relation is disabled when the bit, corresponding to relation, is equal to 1, otherwise, the mapping is enabled. This field is limited by the size of outputs variables (%Q) addressable memory of each CPU, which can be found in section Memory. Default Value: the factory default value cannot be set to the Mapping Disabling field, because the creation of a Protocol instance may be held at any time on application development. The MasterTool IEC XE software itself allocate a value, from the range of output variables of direct representation (%Q), not used yet. For further details on the Slave Address, Communication Time-out and Maximum Number of Retries parameters see notes in section Devices Configuration Symbolic Mapping configuration. 100 5. CONFIGURATION 5.4.5.2.3. Mappings Configuration Configuration for Direct Representation (%Q) The MODBUS relations settings, viewed in the figures below, follow the parameters described in table below: Figure 52: MODBUS Data Type Figure 53: MODBUS Function In table below, the number of factory default settings and the values for the column Options, may vary according to the data type and MODBUS function (FC). Configuration Function Polling (ms) Mapping Diagnostics Area Read Data Start Address Read Data Size Description MODBUS function type Communication period (ms) Initial address of the MODBUS relation diagnostics (%Q) Initial address of the MODBUS read data Number of MODBUS read data Default Value Read 100 1 - Options Read Write Read/Write Mask Write 0 to 3600000 0 to 2147483640 1 to 65536 Depends on the function used 101 5. CONFIGURATION Configuration Read IEC Variable Write Data Start Address Write Data Size Write IEC Variable Mask Write IEC Variables Description Initial address of the read variables (%I) Initial address of the MODBUS write data Number of MODBUS write data Initial address of the write variables (%Q) Initial address of the variables for the write mask (%Q) Default Value 1 - - Options 0 to 2147483646 1 to 65536 Depends on the function used 0 to 2147483647 0 to 2147483644 Table 85: Device Mapping Notes: Function: the available data types are detailed in the Table 104 and MODBUS functions (FC) are available in the Table 102. Polling: this parameter indicates how often the communication set for this relation must be executed. At the end of communication will be awaited a time equal to the configured polling and after, will be performed a new communication as soon as possible. Mapping Diagnostics Area: this field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in the section Memory. The configured MODBUS relations diagnostics are described in Table 81. Read/Write Data Size: details of the data size supported by each function are described in the notes of the section Requests Configuration Symbolic Mapping Settings. ATTENTION When accessing the communication data memory is between devices with different endianism (Little-Endian and Big-Endian), inversion of the read/write data may occur. In this case, the user must adjust the data in the application. Read IEC Variable: if the MODBUS data type is Coil or Input Status (bit), the initial address of the IEC reading variables will have the format %IX10.1, for example. However, if the MODBUS data type is Holding Register or Input Register (16 bits), the initial address of the IEC reading variables will be %IW. This field is limited by the size of input variables addressable memory (%I) at CPU, which can be found in the section Memory. Write IEC Variable: if the MODBUS data type is Coil, the initial address of the IEC writing variables will have the format %QX10.1, for example. However, if the MODBUS data type is Holding Register (16 bits), the initial address of the IEC writing variables will be %QW. This field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in the section Memory. Write Mask: the function Mask Write (FC 22), employs a logic between the value already written and the two words that are configured in this field using %QW(0) for the AND mask and %QW(2) for the OR mask; allowing the user to handle the word. This field is limited by the size of output variables addressable memory (%Q) of each CPU, which can be found in the section Memory. Default Value: the factory default value cannot be set for the Mapping Diagnostics Area, Read IEC Variable, Write IEC Variable and Mask Write IEC Variables fields, since the creation of a relation can be performed at any time on application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. Factory default cannot be set to the Read/Write Data Size fields, as they will vary according to the MODBUS data type selected. ATTENTION Unlike other tasks of an application, when a mark is reached at MainTask debugging, the MODBUS RTU Master instance task or any other MODBUS task will stop being executed at the moment it tries to write in the memory area. This occurs in order to maintain data consistency of memory areas while MainTask is not running. 102 5. CONFIGURATION 5.4.6. MODBUS RTU Slave This protocol is available for the Nexto Series on its serial channels. At selecting this option in MasterTool IEC XE, the CPU becomes a MODBUS communication slave, allowing the connection with MODBUS RTU master devices. There are two ways to configure this protocol. The first one makes use of direct representation (%Q), in which the variables are defined by your address. The second one, through symbolic mapping, where the variables are defined by your name. Independent of the configuration mode, the steps to insert an instance of the protocol and configure the serial interface are equal. The procedure to insert an instance of the protocol is found in detail in the MasterTool IEC XE User Manual MU299609. The remaining configuration steps are described below for each mode: Add the MODBUS RTU Slave Protocol instance to the serial channel COM 1 or COM 2 (or both, in cases of two communication networks). To execute this procedure see Inserting a Protocol Instance section. Configure the serial interface, choosing the communication speed, the RTS/CTS signals behavior, the parity, the stop bits channel, among others. See Serial Interfaces Configuration section. 5.4.6.1. MODBUS Slave Protocol Configuration via Symbolic Mapping To configure this protocol using symbolic mapping, you must perform the following steps: Configure the MODBUS slave protocol general parameters, as: slave address and communication times (available at the Slave advanced configurations button). Add and configure MODBUS relations, specifying the variable name, MODBUS data type and data initial address. Automatically, the data size and range will be filled, in accordance to the variable type declared. 5.4.6.1.1. MODBUS Slave Protocol General Parameters Configuration via Symbolic Mapping The general parameters, found on the MODBUS protocol initial screen (figure below), are defined as. Figure 54: MODBUS RTU Slave Configuration Screen Configuration Slave Address Description MODBUS slave address Default Options 1 1 to 255 Table 86: Slave Configurations The MODBUS slave protocol communication times, found in the Advanced... button on the configuration screen, are divided in: Task Cycle, Send Delay and Minimum Interframe as shown in figure below and in table below. 103 5. CONFIGURATION Figure 55: Modbus Slave Advanced Configurations Configuration Task Cycle (ms) Send Delay (ms) Minimum (chars) Interframe Keep the communication running on CPU stop Description Time for the instance execution within the cycle, without considering its own execution time Delay for the transmission response Minimum silence time between different frames Enable the MODBUS Symbol Slave to run while the CPU is in STOP or standing in a breakpoint Default 50 0 3.5 Unchecked Options 20 to 100 0 to 65535 3.5 to 100.0 Checked or unchecked Table 87: Modbus Slave Advanced Configurations Notes: Task Cycle: the user will have to be careful when changing this parameter as it interferes directly in the answer time, data volume for scan and mainly in the CPU resources balance between communications and other tasks. Send Delay: the answer to a MODBUS protocol may cause problems in certain moments, as in the RS-485 interface or other half-duplex. Sometimes there is a delay between the time of the request from the master and the silence on the physical line (slave delay to put RTS in zero and put the RS-485 in high impedance state). To solve this problem, the master can wait the determined time in this field before sending the new request. On the opposite case, the first bytes transmitted by the master could be lost. Minimum Interframe: the MODBUS standard defines this time as 3.5 characters, but this parameter is configurable in order to attend the devices which don't follow the standard. The MODBUS Slave protocol diagnostics and commands configured, either by symbolic mapping or direct representation, are stored in T_DIAG_MODBUS_RTU_SLAVE_1 variables. For the direct representation mapping, they are also in 4 bytes and 8 words which are described in table below (where "n" is the configured value in the %Q Start Address of Diagnostics Area): 104 5. CONFIGURATION Direct Representation Variable %QX(n).0 %QX(n).1 %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 Diagnostic Variable T_DIAG_MODBUS _RTU_SLAVE_1.* tDiag. bRunning tDiag. bNotRunning tDiag. bInterruptedByCommand tDiag. bConfigFailure tDiag. bRXFailure tDiag. bTXFailure tDiag. bModuleFailure tDiag. bDiag_7_reserved Size Diagnostic Bits: BIT BIT BIT BIT BIT BIT BIT BIT Error codes: %QB(n+1) eErrorCode SERIAL_STATUS (BYTE) Description The slave is in execution mode. The slave is not in execution (see bit: bInterruptedByCommand). The bit bNotRunning was enabled as the slave was interrupted by the user through command bits. Discontinued diagnosis. Discontinued diagnosis. Discontinued diagnosis. Discontinued diagnosis. Reserved. 0: there are no errors 1: invalid serial port 2: invalid serial port mode 3: invalid baud rate 4: invalid data bits 5: invalid parity 6: invalid stop bits 7: invalid modem signal parameter 8: invalid UART RX Threshold parameter 9: invalid time-out parameter 10: busy serial port 11: UART hardware error 12: remote hardware error 20: invalid transmission buffer size 21: invalid signal modem method 22: CTS time-out = true 23: CTS time-out = false 24: transmission time-out error 30: invalid reception buffer size 31: reception time-out error 32: flow control configured differently from manual 33: invalid flow control for the configured serial port 34: data reception not allowed in normal mode 35: data reception not allowed in extended mode 36: DCD interruption not allowed 105 5. CONFIGURATION Direct Representation Variable %QX(n+2).0 %QX(n+2).1 %QX(n+2).2 %QX(n+2).3 %QX(n+2).4 %QX(n+2).5 %QX(n+2).6 %QX(n+2).7 %QB(n+3) %QW(n+4) %QW(n+6) %QW(n+8) Diagnostic Variable T_DIAG_MODBUS Size _RTU_SLAVE_1.* Description 37: CTS interruption not allowed 38: DSR interruption not allowed 39: serial port not configured 50: internal error in the serial port Command bits, automatically initialized: tCommand. BIT bStop Stop slave. tCommand. BIT bRestart Restart slave. tCommand. BIT bResetCounter Restart diagnostics statistics (counters). tCommand. BIT bDiag_19_reserved Reserved. tCommand. BIT bDiag_20_reserved Reserved. tCommand. BIT bDiag_21_reserved Reserved. tCommand. BIT bDiag_22_reserved Reserved. tCommand. BIT bDiag_23_reserved Reserved. byDiag_3_reserved BYTE Reserved. Communication Statistics: tStat. wRXRequests WORD Counter of normal requests received by the slave and answered normally. In case of a broadcast command, this counter is incremented, but it is not transmitted (0 to 65535). tStat. WORD wTXExceptionResponses Counter of normal requests received by the slave and answered with exception code. In case of a broadcast command, this counter is incremented, but it isn't transmitted (0 to 65535). Exception codes: 1: the function code (FC) is legal, but not supported. 2: relation not found in these MODBUS data. 3: illegal value for this field. 128: the master/client hasn't right for writing or reading. 129: the MODBUS relation is disabled. tStat. wRXFrames WORD Counter of frames received by the slave. It's considered a frame something which is processed and it is followed by a Minimum Interframe Silence, in other words, an illegal message is also computed (0 to 65535). 106 5. CONFIGURATION Direct Representation Variable %QW(n+10) %QW(n+12) %QW(n+14) %QW(n+16) %QW(n+18) Diagnostic Variable T_DIAG_MODBUS Size _RTU_SLAVE_1.* tStat. wRXIllegalRequests WORD tStat. wRXOverrunErrors tStat. wRXIncompleteFrames tStat. wCTSTimeOutErrors tStat. wDiag_18_Reserved WORD WORD WORD WORD Description Illegal request counter. These are frames which start with address 0 (broadcast) or with the MODBUS slave address, but aren't legal requests invalid syntax, smaller frames, invalid CRC (0 to 65535). Counter of frames with overrun errors during reception UART FIFO or RX line (0 to 65535). Counter of frames with construction errors, parity or failure during reception (0 to 65535). Counter of CTS time-out error, using the RTS/CTS handshake, during the transmission (0 to 65535). Reserved. Table 88: MODBUS RTU Slave Diagnostic Note: Counters: all MODBUS RTU Slave diagnostics counters return to zero when the limit value 65535 is exceeded. 5.4.6.1.2. Configuration of the Relations Symbolic Mapping Setting The MODBUS relations configuration, showed on figure below, follows the parameters described on table below: Figure 56: MODBUS Data Mappings Screen Configuration Value Variable Data Type Description Symbolic variable name MODBUS data type Default - - Data Start Address MODBUS data initial address - Absolute Data Start Address Absolute initial address of MODBUS data according to its type - Data Size MODBUS data size - 107 Options Name of a variable declared in a program or GVL Coil Input Status Holding Register Input Register 1 to 65536 - 1 to 65536 5. CONFIGURATION Configuration Data Range Description Data address range configured Default - Options - Table 89: MODBUS Mappings Configurations Notes: Value Variable: this field is used to specify a symbolic variable in MODBUS relation. Data Type: this field is used to specify the data type used in the MODBUS relation. Data Type Coil Input Status Holding Register Input Register Size [bits] 1 1 16 16 Description Digital output that can be read or written. Digital input (read only). Analog output that can be read or written. Analog input (read only). Table 90: MODBUS data types supported by Nexto CPUs Data Start Address: data initial address of the MODBUS relation. Data Size: the Data Size value sets the maximum amount of data that a MODBUS relation can access from the initial address. Thus, in order to read a continuous range of addresses, it is necessary that all addresses are declared in a single relation. This field varies according to the configured type of MODBUS data. Data Range: this field shows the user the memory address range used by the MODBUS relation. ATTENTION Differently from other application tasks, when a depuration mark in the MainTask is reached, the task of a MODBUS RTU Slave instance and any other MODBUS task will stop running at the moment that it tries to perform a writing in a memory area. It occurs in order to keep the consistency of the memory areas data while a MainTask is not running. 5.4.6.2. MODBUS Slave Protocol Configuration via Direct Representation (%Q) To configure this protocol using Direct Representation (%Q), you must perform the following steps: Configure the general parameters of MODBUS slave protocol, such as: communication times, address and direct representation variables (%Q) to receive diagnostics and control relations. Add and configure MODBUS relations, specifying the MODBUS data type, direct representation variables (%Q) to receive/write the data and amount of data to communicate. The descriptions of each setting are listed below, in this section. 5.4.6.2.1. General Parameters of MODBUS Slave Protocol Configuration via Direct Representation (%Q) The general parameters, found on the home screen of MODBUS protocol configuration (figure below), are defined as: 108 5. CONFIGURATION Figure 57: MODBUS RTU Slave Configuration Screen by Direct Representation Address and direct representation variables (%Q) to control relations and diagnostics: Configuration %Q Start Address of Diagnostics Area Size Slave Address Mapping Disabling Description Initial address of the diagnostic variables Size of diagnostics area MODBUS slave address Initial address used to disable MODBUS relations Default Value 1 - Options 0 to 2147483628 Disabled for editing 1 to 255 0 to 2147483644 Table 91: Address and Direct Representation Variables Settings Notes: %Q Start Address of Diagnostics Area: this field is limited by the size of output variables addressable memory (%Q) of each CPU, which can be found in section Memory. Slave Address: it is important to note that the Slave accepts requests broadcast, when the master sends a command with the address set to zero. Moreover, in accordance with standard MODBUS, the valid address range for slaves is 1 to 247. The addresses 248 to 255 are reserved. Mapping Disabling: composed of 32 bits, used to disable, individually, the 32 MODBUS relations configured in Slave Mappings space. The relation is disabled when the corresponding bit is equal to 1, otherwise, the mapping is enabled. This field is limited by the size of output variables addressable memory (%Q) of each CPU, which can be found on Memory section. Default Value: the factory default value cannot be set for the %Q Start Address of Diagnostics Area and Mapping Disabling fields, since the creation of a relation can be performed at any time on application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. The MODBUS Slave by Direct Representation protocol stops communicating while the CPU is in STOP or stopped at a breakpoint. The MODBUS protocol diagnostics and commands are described in the Table 88. The communication times of the MODBUS Slave protocol, found on the button Advanced... of the configuration screen, are described in Table 87. 5.4.6.2.2. Mappings Configuration Configuration via Direct Representation (%Q) The MODBUS relations settings, viewed in the figures below, follow the parameters described in table below: 109 5. CONFIGURATION Figure 58: Adding MODBUS Relations Figure 59: Configuring the MODBUS Relation Configuration Data Type Data Start Address Data Size IEC Variable Read-only Description MODBUS data type Default Value Coil Initial address of the MODBUS data Number of MODBUS data Initial address of variables (%Q) Only allows reading 1 Disabled Table 92: Slave Mappings Options Coil (1 bit) Holding Register (16 bits) Input Register (16 bits) Input Status (1 bit) 1 to 65536 1 to 65536 0 to 2147483647 Enabled or disabled Notes: Options: the values written in the column Options may vary according with the configured MODBUS data. Data Size: the value of Data Size defines the maximum amount of data that a MODBUS relation can access, from the initial address. Thus, to read a continuous address range, it is necessary that all addresses are declared in a single interface. 110 5. CONFIGURATION This field varies with the MODBUS data type configured, i.e. when selected Coil or Input Status, the Data Size field must be a multiple of eight. Also, the maximum amount must not exceed the size of output addressable memory and not assign the same values used in the application. ATTENTION When accessing the communication data memory is between devices with different endianism (Little-Endian and Big-Endian), inversion of the read/write data may occur. In this case, the user must adjust the data in the application. IEC Variable: in case the MODBUS data type is Coil or Input Status (bit), the IEC variables initial address will be in the format %QX10.1. However, if the MODBUS data type is Holding Register or Input Register (16 bits), the IEC variables initial address will be in the format %QW. This field is limited by the memory size of the addressable output variables (%Q) from each CPU, which can be seen on Memory section. Read-only: when enabled, it only allows the communication master to read the variable data. It does not allow the writing. This option is valid for the writing functions only. Default Value: the default value cannot be defined for the IEC Variable field since the creation of a relation can be performed at any time on application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. The default cannot be defined for the Data Size field as it will vary according to selected MODBUS data type. In the previously defined relations, the maximum MODBUS data size can be 65535 (maximum value configured in the Data Size field). However, the request which arrives in the MODBUS RTU Slave must address a subgroup of this mapping and this group must have, at most, the data size depending on the function code which is defined below: Read Coils (FC 1): 2000 Read Input Status (FC 2): 2000 Read Holding Registers (FC 3): 125 Read Input Registers (FC 4): 125 Write Single Coil (FC 5): 1 Write Single Holding register (FC 6): 1 Force Multiple Coils (FC 15): 1968 Write Holding Registers (FC 16): 123 Mask Write Register (FC 22): 1 Read/Write Holding Registers (FC 23): · Read: 121 · Write: 121 ATTENTION Differently from other application tasks, when a depuration mark in the MainTask is reached, the task of a Slave MODBUS RTU instance and any other MODBUS task will stop running at the moment that it tries to perform a writing in a memory area. It occurs in order to keep the consistency of the memory areas data while a MainTask is not running. 5.4.7. MODBUS Ethernet The multi-master communication allows the Nexto CPUs to read or write MODBUS variables in other controllers or HMIs compatible with the MODBUS TCP protocol or MODBUS RTU via TCP. The Nexto CPU can, at the same time, be client and server in the same communication network, or even have more instances associated to the Ethernet interface. It does not matter if they are MODBUS TCP or MODBUS RTU via TCP, as described on Table 55. The figure below represents some of the communication possibilities using the MODBUS TCP protocol simultaneously with the MODBUS RTU via TCP protocol. 111 5. CONFIGURATION Figure 60: MODBUS TCP Communication Network The association of MODBUS variables with CPU symbolic variables is made by the user through relations definition via MasterTool IEC XE configuration tool. It's possible to configure up to 32 relations for the server mode and up to 128 relations for the client mode. The relations in client mode, on the other hand, must respect the data maximum size of a MODBUS function: 125 registers (input registers or holding registers) or 2000 bits (coils or input status). This information is detailed in the description of each protocol. All relations, in client mode or server mode, can be disabled through direct representation variables (%Q) identified as Disabling Variables by MasterTool IEC XE. The disabling may occur through general bits which affect all relations of an operation mode, or through specific bits, affecting specific relations. For the server mode relations, IP addresses clusters can be defined with writing and reading allowance, called filters. This is made through the definition of an IP network address and of a subnet mask, resulting in a group of client IPs which can read and write in the relation variables. Reading/writing functions are filtered, in other words, they cannot be requested by any client, independent from the IP address. This information is detailed in the MODBUS Ethernet Server protocol. When the MODBUS TCP protocol is used in the client mode, it's possible to use the multiple requests feature, with the same TCP connection to accelerate the communication with the servers. When this feature isn't desired or isn't supported by the server, it can be disabled (relation level action). It is important to emphasize that the maximum number of TCP connections between the client and server is 63. If some parameters are changed, inactive communications can be closed, which allows the opening of new connections. The tables below bring, respectively, the complete list of data and MODBUS functions supported by the Nexto CPUs. 112 5. CONFIGURATION Data Type Coil Input Status Holding Register Input Register Size [bits] 1 1 16 16 Description Digital output that can be read or written. Digital input (read only). Analog output that can be read or written. Analog input (read only). Table 93: MODBUS data types supported by Nexto CPUs Code DEC HEX 1 0x01 2 0x02 3 0x03 4 0x04 5 0x05 6 0x06 15 0x0F 16 0x10 22 0x16 23 0x17 Description Read Coils (FC 01) Read Input Status (FC 02) Read Holding Registers (FC 03) Read Input Registers (FC 04) Write Single Coil (FC 05) Write Single Holding Register (FC 06) Write Multiple Coils (FC 15) Write Multiple Holding Registers (FC 16) Mask Write Holding Register (FC 22) Read/Write Multiple Holding Registers (FC 23) Table 94: MODBUS Functions Supported by Nexto CPUs Independent of the configuration mode, the steps to insert an instance of the protocol and configure the Ethernet interface are equal. The remaining configuration steps are described below for each modality. Add one or more instances of the MODBUS Ethernet client or server protocol to Ethernet channel. To perform this procedure, refer to the section Inserting a Protocol Instance. Configure the Ethernet interface. To perform this procedure, see section Ethernet Interfaces Configuration. 5.4.8. MODBUS Ethernet Client This protocol is available for all Nexto Series CPUs on its Ethernet channels. When selecting this option at MasterTool IEC XE, the CPU becomes a MODBUS communication client, allowing the access to other devices with the same protocol, when it's in execution mode (Run Mode). There are two ways to configure this protocol. The first one makes use of direct representation (%Q), in which the variables are defined by your address. The second one, through symbolic mapping, where the variables are defined by your name. The procedure to insert an instance of the protocol is found in detail in the MasterTool IEC XE User Manual MU299609 or on Inserting a Protocol Instance section. 5.4.8.1. MODBUS Ethernet Client Configuration via Symbolic Mapping To configure this protocol using Symbolic Mapping, it's necessary to execute the following steps: Configure the general parameters of MODBUS protocol client, with the Transmission Control Protocol (TCP) or RTU via TCP. Add and configure devices by setting IP address, port, address of the slave and time-out of communication (available on the Advanced Settings button of the device). Add and configure the MODBUS mappings, specifying the variable name, data type, data initial address, data size and variable that will receive the quality data. Add and configure the MODBUS request, specifying the desired function, the scan time of the request, the initial address (read/write), the size of the data (read/write), the variable that will receive the data quality and the variable responsible for disabling the request. 113 5. CONFIGURATION 5.4.8.1.1. MODBUS Client Protocol General Parameters Configuration via Symbolic Mapping The general parameters, found on the MODBUS protocol configuration initial screen (figure below), are defined as: Figure 61: MODBUS Client General Parameters Configuration Screen Configuration Connection Mode Description Protocol selection Default TCP Options RTU via TCP TCP Table 95: MODBUS Client General Configurations The MODBUS Client protocol diagnostics and commands configured, either by symbolic mapping or direct representation, are stored in T_DIAG_MODBUS_ETH_CLIENT_1 variables. For the direct representation mapping, they are also in 4 bytes and 8 words which are described in table below (where "n" is the configured value in the %Q Start Address of Diagnostics Area): Direct Representation Variable %QX(n).0 %QX(n).1 %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) %QX(n+2).0 Diagnostic Variable T_DIAG_MODBUS Size _ETH_CLIENT_1.* Description Diagnostic Bits: tDiag. BIT The client is in execution mode. bRunning tDiag. BIT bNotRunning The client is not in execution mode (see bit bInterruptedByCommand). tDiag. BIT bInterruptedByCommand The bit bNotRunning was enabled, as the client was interrupted by the user through command bits. tDiag. BIT bConfigFailure Discontinued diagnostics. tDiag. BIT bRXFailure Discontinued diagnostics. tDiag. BIT bTXFailure Discontinued diagnostics. tDiag. BIT bModuleFailure Indicates if there is failure in the module or the module is not present. tDiag. BIT bAllDevicesCommFailure Indicates that all devices configured in the Client are in failure. byDiag_1_reserved BYTE Reserved. Command bits, automatically initialized: tCommand. BIT bStop Stop client. 114 5. CONFIGURATION Direct Representation Variable %QX(n+2).1 %QX(n+2).2 %QX(n+2).3 %QX(n+2).4 %QX(n+2).5 %QX(n+2).6 %QX(n+2).7 %QB(n+3) %QW(n+4) %QW(n+6) %QW(n+8) %QW(n+10) %QW(n+12) %QW(n+14) %QW(n+16) %QW(n+18) Diagnostic Variable T_DIAG_MODBUS Size _ETH_CLIENT_1.* Description tCommand. BIT bRestart Restart client. tCommand. BIT bResetCounter Restart the diagnostic statistics (counters). tCommand. BIT bDiag_19_reserved Reserved. tCommand. BIT bDiag_20_reserved Reserved. tCommand. BIT bDiag_21_reserved Reserved. tCommand. BIT bDiag_22_reserved Reserved. tCommand. BIT bDiag_23_reserved Reserved. byDiag_3_reserved BYTE Reserved. Communication Statistics: tStat. wTXRequests WORD Counter of number of requests transmitted by the client (0 to 65535). tStat. wRXNormalResponses WORD Counter of normal answers received by the client (0 to 65535). tStat. WORD wRXExceptionResponses Counter of answers with exception code (0 to 65535). tStat. wRXIllegalResponses WORD Counter of illegal answers received by the client invalid syntax, invalid CRC or not enough bytes received (0 to 65535). tStat. wDiag_12_reserved WORD Reserved. tStat. wDiag_14_reserved WORD Reserved. tStat. wDiag_16_reserved WORD Reserved. tStat. wDiag_18_Reserved WORD Reserved. Table 96: MODBUS Client Protocol Diagnostics Note: Counters: all MODBUS TCP Client diagnostics counters return to zero when the limit value 65535 is exceeded. 5.4.8.1.2. Device Configuration Configuration via Symbolic Mapping The devices configuration, shown on figure below, follows the following parameters: 115 5. CONFIGURATION Figure 62: Device General Parameters Settings Configuration IP Address TCP Port Slave Address Description Server IP address TCP port MODBUS Slave address Default 0.0.0.0 502 1 Options 1.0.0.1 to 223.255.255.255 2 to 65534 0 to 255 Table 97: MODBUS Client General Configurations Notes: IP Address: IP address of Modbus Server Device. TCP Port: if there are multiple instances of the protocol added in a single Ethernet interface, different TCP ports must be selected for each instance. Some TCP ports, among the possibilities mentioned above, are reserved and therefore cannot be used. See table Reserved TCP/UDP ports. Slave address: according to the MODBUS standard, the valid address range for slaves is 0 to 247, where addresses 248 to 255 are reserved. When the master sends a command of writing with the address set to zero, it is performing broadcast requests on the network. The parameters in the advanced settings of the MODBUS Client device, found on the button Advanced... in the General Parameters tab are divided into: Maximum Simultaneous Requests, Communication Time-out, Mode of Connection Time-out and Inactive Time. Configuration Maximum Simultaneous Request Communication Time-out (ms) Mode Inactive Time (s) Description Number of simultaneous request the client can ask from the server Application level time-out in ms Defines when the connection with the server finished by the client Inactivity time Default 1 3000 Connection is closed after an inactive time of (s): 10 to 3600. 10 Options 1 to 8 10 to 65535 Connection is closed after a time-out. Connection is closed at the end of each communication. Connection is closed after an inactive time of (s): 10 to 3600. 3600 Table 98: MODBUS Client Advanced Configurations Notes: 116 5. CONFIGURATION Maximum Simultaneous Requests: it is used with a high scan cycle. This parameter is fixed in 1 (not editable) when the configured protocol is MODBUS RTU over TCP. Communication Time-out: the Communication time-out is the time that the client will wait for a server response to the request. For a MODBUS Client device, two variables of the system must be considered: the time the server takes to process a request and the response sending delay in case it is set in the server. It is recommended that the time-out is equal or higher than twice the sum of these parameters. For further information, check Communication Performance section. Mode: defines when the connection with the server is finished by the client. Below follows the available options: Connection is closed after a time-out or Connection is never closed in normal situations: Those options presents the same behavior of Client, close the connection due non response of a request by the Server before reaching the Communication Time-out. Connection is closed at the end of each communication: The connection is closed by the Client after finish each request. Connection is closed after an Inactive Time: The connection will be closed by the Client if it reach the Inactive Time without performing a request to the Server. Inactive Time: inactivity connection time. 5.4.8.1.3. Mappings Configuration Configuration via Symbolic Mapping The MODBUS relations configuration, showed on figure below, follows the parameters described on table below: Figure 63: MODBUS Data Type 117 5. CONFIGURATION Configuration Value Variable Data Type Data Start Address Data Size Data Range Description Symbolic variable name Default - MODBUS data type - Initial address of the MODBUS data - Size of the MODBUS data - The address range of configured data - Options Name of a variable declared in a program or GVL Coil - Write (1 bit) Coil - Read (1 bit) Holding Register - Write (16 bits) Holding Register - Read (16 bits) Holding Register Mask AND (16 bits) Holding Register Mask OR (16 bits) Input Register (16 bits) Input Status (1 bit) 1 to 65536 1 to 65536 - Table 99: MODBUS Mappings Settings Notes: Value Variable: this field is used to specify a symbolic variable in MODBUS relation. Data type: this field is used to specify the data type used in the MODBUS relation. Data Type Coil - Write Coil - Read Holding Register - Write Holding Register - Read Holding Register - Mask AND Holding Register - Mask OR Input Register Input Status Size [bits] 1 1 16 16 16 16 16 1 Description Writing digital output. Reading digital output. Writing analog output. Reading analog output. Analog output which can be read or written with AND mask. Analog output which can be read or written with OR mask. Analog input which can be only read. Digital input which can be only read. Table 100: Data Types Supported in MODBUS Data Start Address: Data initial address of a MODBUS mapping. Data Size: The size value specifies the maximum amount of data that a MODBUS interface can access, from the initial address. Thus, to read a continuous address range, it is necessary that all addresses are declared in a single interface. This field varies with the MODBUS data type configured. Data Range: This field shows to the user the memory address range used by the MODBUS interface. 5.4.8.1.4. Requests Configuration Configuration via Symbolic Mapping The configuration of the MODBUS requests, viewed in figure below, follow the parameters described in table below: 118 5. CONFIGURATION Figure 64: MODBUS Data Request Screen Configuration Function Code Polling (ms) Read Data Start Address Read Data Size Read Data Range Write Data Start Address Write Data Size Write Data Range Diagnostic Variable Description MODBUS function type Communication period (ms) Initial address of the MODBUS read data Size of MODBUS Read data MODBUS Read data address range Initial address of the MODBUS write data Size of MODBUS Write data MODBUS Write data address range Diagnostic variable name Default Value - 100 - Options 01 Read Coils 02 Read Input Status 03 Read Holding Registers 04 Read Input Registers 05 Write Single Coil 06 Write Single Register 15 Write Multiple Coils 16 Write Multiple Registers 22 Mask Write Register 23 Read/Write Multiple Registers 0 to 3600000 1 to 65536 Depends on the function used 0 to 2147483646 1 to 65536 Depends on the function used 0 to 2147483647 Name of a variable declared in a program or GVL 119 5. CONFIGURATION Configuration Disabling Variable Description Variable used to disable MODBUS relation Default Value - Options Field for symbolic variable used to disable, individually, MODBUS requests configured. This variable must be of type BOOL. The variable can be simple or array element and can be in structures. Table 101: MODBUS Relations Configuration Notes: Setting: the number of factory default settings and the values for the column Options may vary according to the data type and MODBUS function (FC). Function Code: MODBUS (FC) functions available are the following: Code DEC HEX 1 0x01 2 0x02 3 0x03 4 0x04 5 0x05 6 0x06 15 0x0F 16 0x10 22 0x16 23 0x17 Description Read Coils (FC 01) Read Input Status (FC 02) Read Holding Registers (FC 03) Read Input Registers (FC 04) Write Single Coil (FC 05) Write Single Holding Register (FC 06) Write Multiple Coils (FC 15) Write Multiple Holding Registers (FC 16) Mask Write Holding Register (FC 22) Read/Write Multiple Holding Registers (FC 23) Table 102: MODBUS Functions Supported by Nexto CPUs Polling: this parameter indicates how often the communication set for this request must be performed. By the end of a communication will be awaited a time equal to the value configured in the field polling and after that, a new communication will be executed. Read Data Start Address: field for the initial address of the MODBUS read data. Read Data Size: the minimum value for the read data size is 1 and the maximum value depends on the MODBUS function (FC) used as below: Read Coils (FC 01): 2000 Read Input Status (FC 02): 2000 Read Holding Registers (FC 03): 125 Read Input Registers (FC 04): 125 Read/Write Multiple Registers (FC 23): 121 Read Data Range: this field shows the MODBUS read data range configured for each request. The initial address, along with the read data size will result in the range of read data for each request. Write Data Start Address: field for the initial address of the MODBUS write data. Write Data Size: the minimum value for the write data size is 1 and the maximum value depends on the MODBUS function (FC) used as below: Write Single Coil (FC 05): 1 Write Single Register (FC 06): 1 Write Multiple Coils (FC 15): 1968 120 5. CONFIGURATION Write Multiple Registers (FC 16): 123 Mask Write Register (FC 22): 1 Read/Write Multiple Registers (FC 23): 121 Write Data Range: this field shows the MODBUS write data range configured for each request. The initial address, along with the read data size will result in the range of write data for each request. Diagnostic Variable: The MODBUS request diagnostics configured by symbolic mapping or by direct representation, are stored in variables of type T_DIAG_MODBUS_RTU_MAPPING_1 for Master devices and T_DIAG_MODBUS_ETH_CLIENT_1 for Client devices and the mapping by direct representation are in 4-byte and 2-word, which are described in Table 81 ("n" is the value configured in the %Q Start Address of Diagnostics Area field). Direct Representation Variable %QX(n).0 %QX(n).1 %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) %QB(n+2) Diagnostic Variable T_DIAG_MODBUS Size _ETH_MAPPING_1.* Description Communication Status Bits: byStatus. BIT bCommIdle Communication idle (waiting to be executed). byStatus. BIT bCommExecuting Active communication. byStatus. BIT bCommPostponed Communication deferred, because the maximum number of concurrent requests was reached. Deferred communications will be carried out in the same sequence in which they were ordered to avoid indeterminacy. The time spent in this State is not counted for the purposes of timeout. The bCommIdle and bCommExecuting bits are false when the bCommPostponed bit is true. byStatus. BIT bCommDisabled Communication disabled. The bCommIdle bit is restarted in this condition. byStatus. BIT bCommOk Communication terminated previously was held successfully. byStatus. BIT bCommError Communication terminated previously had an error. Check error code. byStatus. BIT bCommAborted Previously terminated communication was interrupted due to connection failure. byStatus. BIT bDiag_7_reserved Reserved. Last error code (enabled when bCommError = true): eLastErrorCode MASTER_ERROR _CODE (BYTE) Informs the possible cause of the last error in the MODBUS mapping. Consult Table 104 for further details. Last exception code received by master: NO_EXCEPTION (0) eLastExceptionCode MODBUS _EXCEP- FUNCTION_NOT_SUPPORTED (1) TION (BYTE) MAPPING_NOT_FOUND (2) ILLEGAL_VALUE (3) ACCESS_DENIED (128)* MAPPING_DISABLED (129)* IGNORE_FRAME (255)* 121 5. CONFIGURATION Direct Representation Variable %QB(n+3) %QW(n+4) %QW(n+6) Diagnostic Variable T_DIAG_MODBUS Size _ETH_MAPPING_1.* Communication statistics: byDiag_3_reserved BYTE wCommCounter WORD wCommErrorCounter WORD Description Reserved. Communications counter terminated, with or without errors. The user can test when communication has finished testing the variation of this counter. When the value 65535 is reached, the counter returns to zero. Communications counter terminated with errors. When the value 65535 is reached, the counter returns to zero. Table 103: MODBUS Client Relations Diagnostics Notes: Exception Codes: the exception codes show in this filed is the server returned values. The definitions of the exception codes 128, 129 and 255 are valid only with Altus slaves. For slaves from other manufacturers these exception codes can have different meanings. Disabling Variable: field for the variable used to disable MODBUS requests individually configured within requests. The request is disabled when the variable, corresponding to the request, is equal to 1, otherwise the request is enabled. Last Error Code: The codes for the possible situations that cause an error in the MODBUS communication can be consulted below: Code 1 2 3 4 5 7 8 9 20 21 22 40 41 42 43 44 128 Enumerable ERR_EXCEPTION ERR_CRC ERR_ADDRESS ERR_FUNCTION ERR_FRAME_DATA_COUNT ERR_NOT_ECHO ERR_REFERENCE_NUMBER ERR_INVALID_FRAME_SIZE ERR_CONNECTION ERR_SEND ERR_RECEIVE ERR_CONNECTION_TIMEOUT ERR_SEND_TIMEOUT ERR_RECEIVE_TIMEOUT ERR_CTS_OFF_TIMEOUT ERR_CTS_ON_TIMEOUT NO_ERROR Description Reply is in an exception code (see eLastExceptionCode = Exception Code). Reply with invalid CRC. MODBUS address not found. The address that replied the request was different than expected. Invalid function code. The reply's function code was different than expected. The amount of data in the reply was different than expected. The reply is not an echo of the request (FC 05 and 06). Invalid reference number (FC 15 and 16). Reply shorter than expected. Error while establishing connection. Error during transmission stage. Error during reception stage. Application level time-out during connection. Application level time-out during transmission. Application level time-out while waiting for reply. Time-out while waiting CTS = false in transmission. Time-out while waiting CTS = true in transmission. No error since startup. Table 104: MODBUS Relations Error Codes 122 5. CONFIGURATION ATTENTION Unlike other tasks of an application, when a mark is reached at MainTask debugging, the MODBUS Ethernet Client instance task or any other MODBUS task will stop being executed at the moment it tries to write in the memory area. This occurs in order to maintain data consistency of memory areas while MainTask is not running. 5.4.8.2. MODBUS Ethernet Client configuration via Direct Representation (%Q) To configure this protocol using direct representation (%Q), the following steps must be performed: Configure the general parameters of the MODBUS protocol, such as: communication times and direct representation variables (%Q) to receive diagnostics. Add and configure devices by setting address, direct representation variables (%Q) to disable the relations, communication time-outs, etc. Add and configure MODBUS relations, specifying the data type and MODBUS function, time-outs, direct representation variables (%Q) to receive diagnostics of the relation and other to receive/write the data, amount of data to be transmitted and relation polling. The descriptions of each configuration are listed below in this section. 5.4.8.2.1. General parameters of MODBUS Protocol Client - configuration for Direct Representation(%Q) The General parameters, found on the home screen of MODBUS protocol configuration (figure below), are defined as: Figure 65: MODBUS Client Setup Screen Protocol selection and direct representation variables (%Q) for diagnostics: Setting %Q Start Address of Diagnostics Area Size Description Initial address of the diagnostic variables Size of diagnostics Default Value - 20 Options 0 to 2147483628 Disabled for editing 123 5. CONFIGURATION Setting Protocol Description Protocol selection Default Value TCP Table 105: MODBUS Client settings Options RTU via TCP TCP Notes: %Q Start Address of Diagnostics Area: this field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in section Memory. Default Value: the default value cannot be defined for the %Q Start Address of Diagnostics Area field since the creation of a protocol instance can be made at any moment within the application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. The diagnostics and MODBUS commands are described in Table 96. 5.4.8.2.2. Device Configuration Configuration via Direct Representation (%Q) The configuration of the devices, viewed in figure below, comprises the following parameters: Figure 66: Configuring MODBUS Client Configuration Name Destination IP TCP Port Mapping Disabling Description Name of the instance IP address of the server TCP Port Initial address used to disable MODBUS relations Factory default MODBUS_Device 0. 0. 0.1 502 - Options Identifier, according to IEC 61131-3 1.0.0.1 to 223.255.255.255 2 to 65534 Any address of the %Q area, limited by the CPU model Table 106: Configuration of Client Devices Notes: Instance Name: this field is the identifier of the device, which is checked according to IEC 61131-3, i.e. it does not allow spaces, special characters and starting with numeral character. It is limited to 24 characters. 124 5. CONFIGURATION TCP Port: if there are multiple instances of the protocol added in a single Ethernet interface, different TCP ports must be selected for each instance. Some TCP ports, among the possibilities mentioned above, are reserved and therefore cannot be used. See table Reserved TCP/UDP ports. Mapping Disabling: composed of 32 bits, it is used to disable, individually, the 32 MODBUS relations configured in Device Mappings space. The relation is disabled when the corresponding bit is equal to 1, otherwise, the mapping is enabled. This field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in section Memory. Default Value: factory default cannot be set for the Mapping Disabling field, since the creation of a protocol instance can be made at any moment within the application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. Communication Time-out: the settings present on the button Advanced... on the TCP connection, are described in the notes of the section Device Configuration Configuration via Symbolic Mapping. 5.4.8.2.3. Mapping Configuration Configuration via Direct Representation (%Q) The MODBUS relations settings, viewed in the figures below, follow the parameters described in table below: Figure 67: MODBUS Data Type Figure 68: MODBUS Function In table below, the number of factory default settings and the values for the column Options, may vary according to the data type and MODBUS function (FC). 125 5. CONFIGURATION Configuration Function Slave Address Polling (ms) Mapping Diagnostics Area Read Data Start Address Read Data Size Read IEC Variable Write Data Start Address Write Data Size Write IEC Variable Mask Write IEC Variables Description MODBUS function type MODBUS slave address Period of communication (ms) Starting address of MODBUS interface diagnostics Starting address of the read MODBUS data Number of read MODBUS data Starting address of the read variables (%I) Starting address of MODBUS writing data Number of MODBUS writing data Starting address of the write variables (%Q) Starting address of variables for write mask (%Q) Default Value Read 1 100 1 1 - Options Read Write Read/Write Mask Write 0 to 255 0 to 3600000 0 to 2147483640 1 to 65536 Depends on the function used 0 to 2147483647 1 to 65536 Depends on the function used 0 to 2147483647 0 to 2147483644 Table 107: Device Mapping Notes: Device Mappings Table: the number of settings and values described in the column Options may vary according to the data type and MODBUS function. Slave Address: typically, the address 0 is used when the server is a MODBUS RTU or MODBUS RTU via TCP Gateway, and the same broadcasts the request to all network devices. When the address 0 is used, the client doesn't waits for a response and its use serves only to written commands. Moreover, in accordance with MODBUS standard, the valid address range for slaves is 0 to 247, and addresses 248 to 255 are reserved. Polling: this parameter indicates how often the communication set for this relation must be executed. At the end of communication will be awaited a time equal to the configured polling and after, will be performed a new communication as soon as possible. Mapping Diagnostic Area: this field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in the section Memory . The configured MODBUS relations diagnostics are described in Table 81. Size of the Read and Write Data: details of the size of the data supported by each function are described in the notes of Requests Configuration Symbolic Mapping Settings section. ATTENTION When accessing the communication data memory is between devices with different endianism (Little-Endian and Big-Endian), inversion of the read/write data may occur. In this case, the user must adjust the data in the application. Read IEC Variable: in case the MODBUS data type is Coil or Input Status (bit), the IEC variables initial address will be in the format %IX10.1. However, if the MODBUS data type is Holding Register or Input Register (16 bits), the IEC variables initial address will be in the format %IW. This field is limited by the memory size of the addressable input variables (%I) from each CPU, which can be seen on Memory section. Write IEC Variable: in case the MODBUS data type is Coil (bit), the IEC variables initial address will be in the format %QX10.1. However, if the MODBUS data type is Holding Register (16 bits), the IEC variables initial address will be in the format %QW. This field is limited by the memory size of the addressable output variables (%Q) from each CPU, which can be seen on Memory section. 126 5. CONFIGURATION Write Mask of IEC Variables: the Mask Write Register function (FC 22) employs a logic between the value already written and the two words that are configured in this field using %QW(0) for the AND mask and %QW(2) for the OR mask; allowing the user to handle the word. This field is limited by the size of output variables addressable memory (%Q) of each CPU, which can be found in the section Memory. Default Value: the factory default value cannot be set for the Mapping Diagnostics Area, Read IEC Variable, Write IEC Variable and Mask Write IEC Variables fields, since the creation of a relation can be performed at any time on application development. The MasterTool IEC XE software itself allocate a value from the range of direct representation output variables (%Q), still unused. Factory default cannot be set to the Read/Write Data Size fields, as they will vary according to the MODBUS data type selected. ATTENTION Unlike other tasks of an application, when a mark is reached at MainTask debugging, the MODBUS Ethernet Client instance task or any other MODBUS task will stop being executed at the moment it tries to write in the memory area. This occurs in order to maintain data consistency of memory areas while MainTask is not running. 5.4.8.3. MODBUS Client Relation Start in Acyclic Form To start a MODBUS Client relation in acyclic form, it is suggested the following method which can be implemented in a simple way in the user application program: Define the maximum polling time for the relations; Keep the relation normally disabled; Enable the relation at the moment the execution is desired; Wait for the confirmation of the relation execution finishing and, at this moment, disable it again. 5.4.9. MODBUS Ethernet Server This protocol is available for all Nexto Series CPUs on its Ethernet channels. When selecting this option at MasterTool IEC XE, the CPU becomes a MODBUS communication server, allowing the connection with MODBUS client devices. This protocol is only available when the CPU is in execution mode (Run Mode). There are two ways to configure this protocol. The first one makes use of direct representation (%Q), in which the variables are defined by your address. The second one, through symbolic mapping, where the variables are defined by your name. The procedure to insert an instance of the protocol is found in detail in the MasterTool IEC XE User Manual MU299609. 5.4.9.1. MODBUS Server Ethernet Protocol Configuration for Symbolic Mapping To configure this protocol using Symbolic Mappings, it is necessary to execute the following steps: Configure the MODBUS server protocol general parameters, as: TCP port, protocol selection, IP filters for Reading and Writing (available at the Filters Configuration button) and communication times (available at the Server Advanced Configurations button). Add and configure MODBUS mappings, specifying the variable name, data type, data initial address and data size. The description of each configuration is related ahead in this section. 5.4.9.1.1. MODBUS Server Protocol General Parameters Configuration via Symbolic Mapping The general parameters, found on the MODBUS protocol initial screen (figure below), are defined as. Figure 69: MODBUS Server General Parameters Configuration Screen 127 5. CONFIGURATION Configuration TCP Port Connection Mode Description TCP port Protocol selection Default 502 TCP Options 2 to 65534 RTU via TCP TCP Table 108: MODBUS Server General Configurations Notes: TCP Port: if there are multiple instances of the protocol added in a single Ethernet interface, different TCP ports must be selected for each instance. Some TCP ports, among the possibilities mentioned above, are reserved and therefore cannot be used. See table Reserved TCP/UDP ports. The settings present on the Filters... button, described in table below, are relative to the TCP communication filters: Configuration Write Filter IP Address Write Filter Mask Read Filter IP Address Read Filter Mask Description Specifies a range of IPs with write access in the variables declared in the MODBUS interface. Specifies the subnet mask in conjunction with the IP filter parameter for writing. Specifies a range of IPs with read access in the variables declared in the MODBUS interface. Specifies the subnet mask in conjunction with the IP filter parameter for reading. Default Value 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Options 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 Table 109: IP Filters Note: Filters: filters are used to establish a range of IP addresses that have write or read access to MODBUS relations, being individually configured. The permission criteria is accomplished through a logical AND operation between the Write Filter Mask and the IP address of the client. If the result is the same as the Write Filter IP Address, the client is entitled to write. For example, if the Write Filter IP Address = 192.168.15.0 and the Write Filter Mask = 255.255.255.0, then only customers with IP address = 192.168.15.x shall be entitled. The same procedure is applied in the Read Filter parameters to define the read rights. The communication times of the MODBUS server protocol, found on the Advanced... button of the configuration screen, are divided into: Task Cycle and Connection Inactivity Time-out. 128 5. CONFIGURATION Figure 70: MODBUS Server Advanced Settings Configuration Screen Configuration Task Cycle (ms) Connection Time-out (s) Inactivity Keep the communication running on CPU stop. Description Time for the instance execution within the cycle, without considering its own execution time Maximum idle time between client and server before the connection is closed by the server Enable the MODBUS Symbol Slave to run while the CPU is in STOP or after a breakpoint Default Value 50 10 Unmarked Options 5 to 100 1 to 3600 Marked or Unmarked Table 110: MODBUS Server Advanced Configurations Notes: Task Cycle: the user has to be careful when changing this parameter as it interferes directly in the answer time, data volume for scanning and mainly in the CPU resources balance between communications and other tasks. Connection Inactivity Time-out: this parameter was created in order to avoid that the maximum quantity of TCP connections is reached, imagining that inactive connections remain open on account of the most different problems. It indicates how long a connection (client or server) can remain open without being used (without exchanging communication messages). If the specified time is not reached, the connection is closed releasing an input in the connection table. 5.4.9.1.2. MODBUS Server Diagnostics Configuration via Symbolic Mapping The diagnostics and commands of the MODBUS server protocol configured, either by symbolic mapping or by direct representation, are stored in variables of type T_DIAG_MODBUS_ETH_SERVER_1 and the mapping by direct representation are in 4-byte and 8-word, which are described in table below (n is the value configured in the %Q Start Address of Diagnostics Area field): Direct Representation Variable %QX(n).0 Diagnostic Variable T_DIAG_MODBUS _ETH_SERVER_1 .* tDiag. bRunning Size Diagnostic bits: BIT Description The server is running. 129 5. CONFIGURATION Direct Representation Variable %QX(n).1 %QX(n).2 %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) %QX(n+2).0 %QX(n+2).1 %QX(n+2).2 %QX(n+2).3 %QX(n+2).4 %QX(n+2).5 %QX(n+2).6 %QX(n+2).7 %QB(n+3) %QW(n+4) %QW(n+6) %QW(n+8) %QW(n+10) %QW(n+12) Diagnostic Variable T_DIAG_MODBUS Size _ETH_SERVER_1 .* Description tDiag. BIT bNotRunning The server is not running (see bit bInterruptedByCommand). tDiag. BIT bInterruptedByCommand The bit bNotRunning was enabled, because the server was interrupted by the user through the command bit. tDiag. BIT bConfigFailure Discontinued diagnostic. tDiag. BIT bRXFailure Discontinued diagnostic. tDiag. BIT bTXFailure Discontinued diagnostic. tDiag. BIT bModuleFailure Discontinued diagnostic. tDiag. BIT bDiag_7_reserved Reserved. byDiag_1_reserved BYTE Reserved. Command bits, restarted automatically: tCommand. BIT bStop Stop the server. tCommand. BIT bRestart Restart the server. tCommand. BIT bResetCounter Reset diagnostics statistics (counters). tCommand. BIT bDiag_19_reserved Reserved. tCommand. BIT bDiag_20_reserved Reserved. tCommand. BIT bDiag_21_reserved Reserved. tCommand. BIT bDiag_22_reserved Reserved. tCommand. BIT bDiag_23_reserved Reserved. byDiag_3_reserved BYTE Reserved. Communication statistics: tStat. wActiveConnections WORD Number of established connections between client and server (0 to 64). tStat. WORD wTimeoutClosedConnections Connections counter, between the client and server, interrupted after a period of inactivity - time-out (0 to 65535). tStat. WORD wClientClosedConnections Connections counter interrupted due to customer request (0 to 65535). tStat. wRXFrames WORD Ethernet frames counter received by the server. An Ethernet frame can contain more than one request (0 to 65535). tStat. wRXRequests WORD Requests received by the server counter and answered normally (0 to 65535). 130 5. CONFIGURATION Direct Rep- Diagnostic Variable resentation T_DIAG_MODBUS Size Variable _ETH_SERVER_1 .* %QW(n+14) tStat. wTXExceptionResponses WORD %QW(n+16) %QW(n+18) tStat. wRXIllegalRequests tStat. wDiag_18_Reserved WORD WORD Description Requests received by the server counter and answered with exception codes (0 to 65535). The exception codes are listed below: 1: the function code (FC) is legal, but not supported. 2: relation not found in these data MODBUS. 3: illegal value for the address. 128: the master/client has no right to read or write. 129: MODBUS relation is disabled. Illegal requests counter (0 to 65535). Reserved. Table 111: MODBUS Server Diagnostics Note: Counters: all counters of the MODBUS Ethernet Server Diagnostics return to zero when the limit value 65535 is exceeded. 5.4.9.1.3. Mapping Configuration Configuration via Symbolic Mapping The MODBUS relations configuration, showed on figure below, follows the parameters described on table below: Figure 71: MODBUS Server Data Mappings Screen Configuration Value Variable Data Type Description Symbolic variable name MODBUS data type Default Value - - Data Start Address Starting address of the MODBUS data - Absolute Data Start Ad- Start address of absolute dress data of Modbus as its type - Data Size Size of the MODBUS data - Options Name of a variable declared in a program or GVL Coil Input Status Holding Register Input Register 1 to 65536 - 1 to 65536 131 5. CONFIGURATION Configuration Data Range Description Data range address configured Default Value - Options - Table 112: MODBUS Ethernet Mappings Configuration Notes: Value Variable: this field is used to specify a symbolic variable in MODBUS relation. Data Type: this field is used to specify the data type used in the MODBUS relation. Data Start Address: data initial address of the MODBUS relation. Absolute Data Start Address: absolute start address of the MODBUS data according to their type. For example, the Holding Register with address 5 has absolute address 400005. This field is read only and is available to assist in Client/Master MODBUS configuration that will communicate with this device. The values depend on the base address (offset) of each data type and allowed MODBUS address for each data type. Data Size: the Data Size value sets the maximum amount of data that a MODBUS relation can access from the initial address. Thus, in order to read a continuous range of addresses, it is necessary that all addresses are declared in a single relation. This field varies according to the configured type of MODBUS data. Data Range: is a read-only field and reports on the range of addresses that is being used by this mapping. It is formed by the sum of the fields Data Start Address and Data Size. There can be no range overlays with others mappings of the same Data Type. ATTENTION Unlike other tasks of an application, when a mark is reached at MainTask debugging, the MODBUS Ethernet Server instance task or any other MODBUS task will stop being executed at the moment it tries to write in the memory area. This occurs in order to maintain data consistency of memory areas while MainTask is not running. 5.4.9.2. MODBUS Server Ethernet Protocol Configuration via Direct Representation (%Q) To configure this protocol using Direct Representation (%Q), the user must perform the following steps: Configure the general parameters of MODBUS Server Protocol, such as: communication times, address and direct representation variables (%Q) to receive the diagnostics and control relation. Add and configure MODBUS relations, specifying the MODBUS data type, direct representation variables (%Q) to receive/write the data and amount of data to be reported. The descriptions of each configuration are listed below in this section. 5.4.9.2.1. General Parameters of MODBUS Server Protocol Configuration via Direct Representation (%Q) The general parameters, found on the home screen of MODBUS protocol configuration (figure below), are defined as: 132 5. CONFIGURATION Figure 72: MODBUS Server Setup Screen TCP port, protocol and direct representation variables (%Q) to control relations and diagnostics: Configuration %Q Start Address of Diagnostics Area Size TCP Port Mapping Disabling Protocol Description Starting address of the diagnostic variables Size of diagnostics TCP Port Starting address used to disable MODBUS relations Protocol selection Default Value 20 502 - TCP Options 0 to 2147483628 Disabled for editing 2 to 65534 0 to 2147483644 RTU via TCP TCP Table 113: Settings to control relations and diagnostics Notes: %Q Start Address of Diagnostics Area: this field is limited by the size of output variables addressable memory (%Q) at CPU, which can be found in section Memory. TCP Port: if there are multiple instances of the protocol added in a single Ethernet interface, different TCP ports must be selected for each instance. Some TCP ports, among the possibilities mentioned above, are reserved and therefore cannot be used. See table Reserved TCP/UDP ports. Mapping Disabling: composed of 32 bits, used to disable, individually, the 32 MODBUS relations configured in Server Mappings space. The relation is disabled when the corresponding bit is equal to 1, otherwise, the mapping is enabled. This field is limited by the size of output variables addressable memory (%Q) of each CPU, which can be found on Memory section. Default Value: the factory default value cannot be set to the %Q Start Address of Diagnostics Area and Mapping Disabling fields, because the creation of a Protocol instance may be held at any time on application development. The MasterTool IEC XE software itself allocate a value, from the range of output variables of direct representation (%Q), not used yet. The communication times of the MODBUS Server protocol, found on the Advanced... button of the configuration screen, are divided into: Task Cycle (ms) and Connection Inactivity Time-out (s). Further details are described in MODBUS Server Protocol General Parameters Configuration via Symbolic Mapping section. The diagnostics and MODBUS commands are described in Table 111. 133 5. CONFIGURATION 5.4.9.2.2. Mapping Configuration Configuration via Direct Representation (%Q) The MODBUS relations settings, viewed in the figures below, follow the parameters described in table below: Figure 73: MODBUS Data Type Figure 74: MODBUS Server Function 134 5. CONFIGURATION Configuration Data Type Data Start Address Data Size IEC Variable Read-only Description MODBUS data type Default Coil MODBUS data initial address 1 MODBUS data quantity 8 Variables initial address (%Q) Allow reading only Disabled Table 114: Server Mappings Options Coil (1 bit) Holding Register (16 bits) Input Status (1 bit) Input Register (16 bits) 1 to 65536 1 to 65536 (Holding Register and Input Register) 8 to 65536 (Coil and Input Status) 0 to 2147483647 Enabled or Disabled Notes: Options: the values written in the column Options may vary according with the configured MODBUS data. Data Size: the Data Size value sets the maximum amount of data that a MODBUS relation can access from the initial address. Thus, to read a continuous range of addresses, it is necessary that all addresses are declared in a single relation. This field varies according to the set MODBUS data type, that is, when selected Coil or Input Status, the field Data Size must be a number multiple of 8. It is also important to take care so the maximum value is not greater than the addressable output memory size and the attributed values aren't the same already used during the application. ATTENTION When accessing the communication data memory is between devices with different endianism (Little-Endian and Big-Endian), inversion of the read/write data may occur. In this case, the user must adjust the data in the application. IEC Variable: in case the MODBUS data type is Coil or Input Status (bit), the IEC variables initial address will be in the format for example %QX10.1. However, if the MODBUS data type is Holding Register or Input Register (16 bits), the IEC variables initial address will be in the format %QW. This field is limited by the memory size of the addressable output variables (%Q) from each CPU, which can be seen on the Memory section. Read-only: when enabled, it only allows the communication master to read the variable data. It does not allow the writing. This option is valid for the writing functions only. Default: the default cannot be defined for the IEC Variable field as the creation of a protocol instance can be made at any moment within the application development, making the MasterTool IEC XE software allocate a value itself from the direct representation output variables range (%Q) still not used. The default cannot be defined for the Data Size field as it will vary according to selected MODBUS data type. The settings present on the Filters... button, described in table below, are relative to the TCP communication filters: Configuration Write Filter IP Address Write Filter Mask Read Filter IP Address Description Specifies a range of IPs with write access in the variables declared in the MODBUS interface. Specifies the subnet mask in conjunction with the IP filter parameter for writing. Specifies a range of IPs with read access in the variables declared in the MODBUS interface. Default Value 0.0.0.0 0.0.0.0 0.0.0.0 Options 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 135 5. CONFIGURATION Configuration Read Filter Mask Description Specifies the subnet mask in conjunction with the IP filter parameter for reading. Default Value 0.0.0.0 Options 0.0.0.0 to 255.255.255.255 Table 115: IP Filters Note: Filters: filters are used to establish a range of IP addresses that have write or read access to MODBUS relations, being individually configured. The permission criteria is accomplished through a logical AND operation between the Write Filter Mask and the IP address of the client. If the result is the same as the Write Filter IP Address, the client is entitled to write. For example, if the Write Filter IP Address = 192.168.15.0 and the Write Filter Mask = 255.255.255.0, then only customers with IP address = 192.168.15.x shall be entitled. The same procedure is applied in the Read Filter parameters to define the read rights. In the previously defined relations, the maximum MODBUS data size can be 65536 (maximum value configured in the Data Size field). However, the request which arrives in the MODBUS Ethernet Server must address a subgroup of this mapping and this group must have, at most, the data size depending on the function code which is defined below: Read Coils (FC 1): 2000 Read Input Status (FC 2): 2000 Read Holding Registers (FC 3): 125 Read Input Registers (FC 4): 125 Write Single Coil (FC 5): 1 Write Single Holding register (FC 6): 1 Force Multiple Coils (FC 15): 1968 Write Holding Registers (FC 16): 123 Mask Write Register (FC 22): 1 Read/Write Holding Registers (FC 23): · Read: 121 · Write: 121 ATTENTION Differently from other application tasks, when a depuration mark in the MainTask is reached, the task of an Ethernet MODBUS Server instance and any other MODBUS task will stop running at the moment that it tries to perform a writing in a memory area. It occurs in order to keep the consistency of the memory areas data while a MainTask is not running. 5.4.10. OPC DA Server It's possible to communicate with the Nexto Series CPUs using the OPC DA (Open Platform Communications Data Access) technology. This open communication platform was developed to be the standard in industrial communications. Based on client/server architecture, it offers several advantages in project development and communication with automation systems. A very common analogy to describe the OPC DA technology is of a printer. When correctly connected, the computer needs a driver to interface with the equipment. Similarly, the OPC helps with the interface between the supervision system and the field data on the PLC. When it comes to project development, to configure the communication and exchange information between the systems is extremely simple using OPC DA technology. Using other drivers, based on addresses, it's necessary to create tables to relate tags from the supervision system with variables from the programmable controller. When the data areas are changed during the project, it's necessary to remap the variables and create new tables with the relations between the information on the PLC with the Supervisory Control And Data Acquisition system (SCADA). 136 5. CONFIGURATION Figure 75: OPC DA Architecture The figure above shows an architecture to communicate a SCADA system and PLCs in automation projects. All the roles present on a communication are explicit on this figure regardless of the equipment in which it's executed, since they can be done in the same equipment or in various ones. Each of the roles of this architecture are described on table below. Role Programmable Controllers and Field Devices Level Acquisition Network Gateway for PLC Communication OPC Server Module Description The field devices and the PLCs are where the operation state and plant control information are stored. The SCADA system access the information on these devices and store on the SCADA server, so that the SCADA clients can consult it during the plant operation. The acquisition network is where the requests for data collected by field devices travel, to request the data collected from the field devices. A gateway enables the communication between the OPC DA Server and Nexto Series PLCs. A gateway in the same subnet of the PLC is always necessary, as described in chapter Communication Settings of MasterTool IEC XE User Manual MU299609. The OPC DA Server is a Module responsible of receiving the OPC DA requests and translate them to the communication with the field devices. 137 5. CONFIGURATION Role Device Module OPC Client SCADA Server Level Supervision Network SCADA Client Level Description The OPC Client Device module is responsible for the requests to the OPC DA Server using the OPC DA protocol. The collected data is stored on the SCADA Server database. The SCADA Server is responsible for connecting to the various communication devices and store the data collected by them on a database, so that it can be consulted by the SCADA Clients. The supervision network is the network through which the SCADA Clients are connected to the SCADA Servers. In a topology in which there aren't multiple Client or where the Server and the Client are installed on the same equipment, this kind of network doesn't exist. The SCADA Clients are responsible for requesting to the SCADA Servers the necessary data to be shown in a screen where the operation of a plant is being executed. Through then it is possible to execute readings and writings on data stored on the SCADA Server database. Table 116: Roles Description on an OPC DA Server Architecture The relation between the tags on the supervision system and the process data on the controller variables is totally transparent. This means that, if there's an alteration on the data areas through the development of the project, it isn't necessary to rework the relations between the information on the PLC and the SCADA, just use the new variable provided by the PLC on the systems that request this data. The use of OPC offers more productivity and connectivity with SCADA systems. It contributes with the reduction of applications development time and with the maintenance costs. It even makes possible the insertion of new data on the communication in a simplified form and with greater flexibility and interoperability between the automation system, due to the fact that it's an open standard. The installation of the OPC DA Server is done altogether with MasterTool IEC XE installation, and its settings are done inside the tool. It's worth notice that the OPC is available only with the local Ethernet interface of the Nexto CPUs. The Ethernet expansion modules do not support this functionality. 5.4.10.1. Creating a Project for OPC DA Communication Unlike the communication with drivers such as MODBUS and PROFIBUS DP, to set an OPC DA communication it's only necessary to correctly set the node and indicate which variables will be used in the communication. There are two ways to indicate which variables of the project will be available in the OPC DA Server. In both cases it's necessary to add the object Symbol Configuration to the application, in case it isn't present. To add it, right-click over the object Application and select the option. ATTENTION The variables shown in the objects IoConfig_Globals, IoConfig_Application_Mappings and IoConfig_Global_Mappings are used internally for I/O control and shouldn't be used by the user. ATTENTION In addition to the variables declared at SFC language POUs, some implicitly created variables are also shown. To each step created, a type IecSfc.SFCStepType variable is created, where the step states can be monitored, namely whether it is active or not and the time that it's active as in norm IEC 61131-1. To each transition, a BOOL type variable is created that defines if the transition is true or false. These variables are shown in the object Symbol Configuration that can be provided access to the OPC Client. 138 5. CONFIGURATION Figure 76: Symbol Configuration Object The table below presents the descriptions of the Symbol Configuration object screen fields. Symbols Field Access Rights Maximal Attribute Type Members Comment Description Variable identifier that will be provided to the OPC DA Server. Indicates what the possible access right level are in the declared symbol. When not utilized, this column remains empty, and the access right level is maximum. Otherwise the access right level can be modified by clicking over this field. The possible options are: Read only Write only Read and Write Indicates the maximum access right level that is possible to assign to the variable. The symbols hold the same meanings from the ones in Access Rights. It's not possible to change it and it's indicated by the presence or not of the attribute 'symbol' Indicates if attribute 'symbol' is being used when the variable is declared. When not used, this column remains empty. For the cases in which the attribute is used, the behavior is the following: attribute 'symbol' := 'read' the column shows attribute 'symbol' := 'write' the column shows attribute 'symbol' := 'readwrite' the column shows Data type of the declared variable. When the data type is a Struct, a button is enabled in this column. Clicking on the button will allow the selection of which elements of that struct will be provided to the OPC DA Server. Variable comment, inserted on the POU or GVL where the variable was declared. To show up as a variable comment here, the comment must be entered one line before the variable on the editor, while in text mode, or in the comment column when in tabular mode. Table 117: Symbol Configuration object screen fields description When altering the project settings, such as adding or removing variables, it's necessary to run the command Build, in order to refresh the list of variables. This command must be executed until the message in Figure 76 disappear. After this, all available variables in the project, whether they are declared on POUs, GVLs or diagnostics, will be shown here and can be selected. The selected variables will be available on the OPC DA Server to be accessed by the Clients. 139 5. CONFIGURATION Figure 77: Selecting Variables on the Symbol Configuration After this procedure, the project must be loaded into a PLC so the variables will be available for communication with the OPC DA Server. If the object Symbol Configuration screen is open and any of the variables, POUs or GVLs selected is changed, its name will appear with the red color. The situations in which this may happen is when a variable is deleted or the attribute value is modified. It's also possible to set which variables will be available on the OPC DA Server through an attribute inserted directly on the POUs or GVLs where the variables are declared. When the attribute 'symbol' is present on the variable declaration, and it may be before the definition of the POU or GVL name, or to each variable individually, these variables are sent directly to the object Symbol Configuration, with a symbol in the Attribute column. In this case it's necessary, before loading the project into the CPU, to run the command Build from within the object Symbol Configuration. The valid syntaxes to use the attribute are: attribute 'symbol' := 'none' when the attribute value is 'none', the variables won't be available to the OPC DA Server and won't be shown in the object Symbol Configuration screen. attribute 'symbol' := 'read' - when the attribute value is 'read', the variables will be available to the OPC DA Server with read only access right. attribute 'symbol' := 'write' - when the attribute value is 'write', the variables will be available to the OPC DA Server with write only access right. attribute 'symbol' := 'readwrite' when the attribute value is 'readwrite', the variables will be available to the OPC DA Server with read and write access right. In the following example of variable declaration, the variables A and B settings allow that an OPC DA Server access them with read and write access. However the variable C cannot be accessed, while the variable D can be accessed with read only access rights. {attribute 'symbol' := 'readwrite'} PROGRAM UserPrg VAR A: INT; B: INT; {attribute 'symbol' := 'none'} C: INT; {attribute 'symbol' := 'read'} D :INT; END_VAR When a variable with a type different from the basic types is defined, the use of the attribute must be done inside the declaration of this DUT and not only in the context in which the variable is created. For example, in the case of a DUT instance inside of a POU or a GVL that has an attribute, it will not impact in the behavior of this DUT instance elements. It will be necessary to apply the same access right level on the DUT declaration. 140 5. CONFIGURATION ATTENTION The configurations of the symbols that will be provided to the OPC DA Server are stored inside the PLC project. By modifying these configurations it's necessary to load the application on the PLC so that it's possible to access those variables. ATTENTION When a variable is removed from the project and loaded on the PLC unchecking it from the object Symbol Configuration, the variable can no longer be read with the OPC Client. If the variable is added again to the project, with the same name and same context, and inserted on the object Symbol Configuration, it will be necessary to reboot the OPC Client to refresh the variable address reference, which will be created on a different memory area of the PLC. 5.4.10.2. Configuring a PLC on the OPC DA Server The configuration of the PLC is done inside MasterTool IEC XE through the option available in the Online. It's necessary to run MasterTool IEC XE as administrator. Figure 78: OPC DA Server Settings The Gateway Configuration is the same set in the Gateway used for the communication between the MasterTool IEC XE and the PLC and described in Communication Settings, present in the MasterTool IEC XE User Manual MU299609. If the configuration used is localhost the Gateway Address must be filled with 127.0.0.1. This configuration is necessary because the OPC DA Server uses the same communication gateway and the same protocol used for communication between PLC and MasterTool IEC XE. There's the option Using the Gateway Embedded in PLC that can be selected when it's desired to use the Gateway that is in PLC itself. This option can be used to optimize the communication, since it prevent excess traffic through a particular station, when more than one station with OPC Client is connected to the same PLC. To configure the PLC, there are two possible configuration types, depending on the selection of the checkbox Use TCP/IP Blockdriver. When the option isn't selected, the field Device Name must be filled with the name of the PLC. This is the name displayed by the PLC selected as active in the Communication Settings screen. The other option is to use the IP Address of the Ethernet Interfaces. The same address set on the configuration screens must be put in this field. Furthermore, when this method is used, the port number must be set to 11740. The confirmation will save the OPC DA Server configurations. 141 5. CONFIGURATION Device Configuration Name Gateway Address Gateway Port Device Name IP Address Active IP Address PLC A IP Address PLC B Device Port Description PLC description inside the OPC DA Server configuration file. This field can have any name, but for organizational purposes, it's recommended to use the project name that is loaded in the PLC. IP Address of the computer that the OPC DA Server is installed, for the cases in which all PLCs are in the same subnetwork. If there's some PLC that it's in another subnetwork, it must be specified the Gateway used in that subnetwork. TCP Port for the connection with the Gateway. It's the PLC name displayed in the Communication Settings of the Device tab. The name is the STRING before the hexadecimal value that is between [ ]. Enabled only when the checkbox Use TCP/IP Blockdriver is not selected. IP address of the PLC. Enabled only when the checkbox Use TCP/IP Blockdriver is selected. It is used only when the setting is not redundant. IP address of the PLC A. Enabled only when the configuration is redundant. It is the primary PLC address to which the server will communicate if there is no failure. IP address of the PLC B. Enabled only when the configuration is redundant. It is the secondary PLC address to which the server will communicate if a failure occurs. TCP Port. Enabled only when the checkbox Use TCP/IP Blockdriver is selected. Default Setting `PLC01' 127.0.0.1 1217 `0000' 192.168.15.1 192.168.15.69 192.168.15.70 11740 Options This field is a STRING and it accepts alphanumeric (letters and numbers) characters and the "_" character. It's not allowed to initiate a STRING with numbers or with "_". It allows up to 49 characters. 0.0.0.0 to 255.255.255.255 2 to 65534 This field is a STRING and it accepts any characters, as done in the PLC name configuration in the Device Communication Settings tab. It allows up to 49 characters. 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 0.0.0.0 to 255.255.255.255 11740 or 11739 Table 118: Configuration Parameter of each PLC for the OPC DA Server 142 5. CONFIGURATION When a new PLC needs to be configured on the OPC DA Server, simply press the New Device button and the configuration will be created. When the setup screen is accessed, a list of all PLCs already configured on the OPC DA Server will be displayed. Existing configurations can be edited by selecting the PLC in the Devices list and editing the parameters. The PLCs settings that are no longer in use can be deleted. The maximum number of PLCs configured in an OPC DA Server is 16. If the automation architecture used specifies that the OPC DA Server must be ran on a computer that does not execute communication with the PLC via MasterTool IEC XE, the tool must be installed on this computer to allow OPC DA Server configuration in the same way as done in other situations. ATTENTION To store the OPC DA Server configuration, the MasterTool IEC XE must be run with administrator rights on the Operational System. Depending on the OS version, this privilege must be done in the moment that the program is executed: right-click the MasterTool IEC XE icon and choose Run as Administrator. ATTENTION The settings of a PLC on the OPC DA Server are not stored in the project created in MasterTool IEC XE. For this reason, it can be performed with an open or closed project. The settings are stored in a configuration file where the OPC DA Server is installed. When changing the settings, it is not required to load the application on the PLC, but depending on the OPC Client it may be necessary to reconnect to the server or load the settings for the data to be updated correctly. 5.4.10.2.1. Importing a Project Configuration Using the button Read Project Configuration, as shown in Figure 78, you can assign the configuration of the open project to the PLC configuration that is being edited. For this option to work correctly, there must be an open project and an Active Path should be set as described in Communication Settings, present in the MasterTool IEC XE User Manual MU299609. If any of these conditions is not met an error message will be displayed and no data will be modified. When the above conditions are valid, the PLC settings receive the parameters of the opened project. The IP Address and Gateway Port information are configured as described in Communication Settings according to the Active Path. However, the IP Address settings are read from NET 1 Ethernet interface settings. The port for connection to the PLC is always assigned in this case as 11740. 5.4.10.3. OPC DA Communication Status and Quality Variables For each PLC created in the OPC DA Server, status variables are generated, named _CommState and _CommStateOK. The _CommState variable indicates the communication between the OPC and the PLC state. This state can interpreted by the OPC Clients according to table below. State STATE_TERMINATE STATE_PLC_NOT_CONNECTED STATE_PLC_CONNECTED Value -1 0 1 Description If the communication between the OPC DA Server and the OPC Client is terminated, this value will be returned. When there's more than one OPC Client simultaneously connected, this return will occur on the disconnection of the latter connected one. Besides the fact that this state is in the variable, it's value can't be visualized because it only changes when there's no longer a connection with the client. The PLC configured in the OPC DA Server is not connected. It can happen if the configuration is incorrect (wrong PLC and/or Gateway IP Address) or the PLC is unavailable in that moment. The PLC configured in the OPC DA Server is connected. This is a transitory state during the connection. 143 5. CONFIGURATION State STATE_NO_SYMBOLS STATE_SYMBOLS_LOADED STATE_RUNNING STATE_DISCONNECT STATE_NO_CONFIGURATION Value 2 3 4 5 6 Description There are no symbols (variables) available in the PLC configured in the OPC DA Server. It can happen when there are no symbols or there isn't a project loaded on the PLC. Finished the process of reading the symbols (variables) from the PLC configured in the OPC DA Server. This is a transitory state during the connection. After the reading of the symbols (variables) the OPC DA Server is running the periodic update of the values of the available symbols in each configured PLC. There has been a disconnection with the PLC configured in the OPC DA Server. When the OPC configuration (stored in an OPCServer.ini file) has a wrong syntax, the variable value will be this. Generally, this behavior is not observed for the MasterTool IEC XE maintains this configuration valid. Table 119: Description of the Communication states between OPC DA Server and the PLC The _CommStateOK is a variable of the Bool type that indicates if the communication between the OPC DA Server and the PLC is working. When the value is TRUE, it indicates that the communication is working correctly. If the value is FALSE, for some reason it isn't possible to communicate with the PLC. In addition to monitoring the communication status, the OPC Client can access information on the quality of communication. The quality bits form a byte. They are divided into three groups of bits: Quality, Substatus and Limit. The bits are distributed as follows QQSSSSLL, in which QQ are the Quality bits, SSSS Substatus bits and LL Limit bits. In this case the QQ bits are the most significant in the byte, while the LL bits are the least significant. QQ Bits values Definition Description The value read can't be used be- cause there's some problem with 0 00SSSSLL Bad the connection. It's possible to monitor the value of _CommState and diagnose the problem. The quality can't be defined and 1 01SSSSLL Uncertain may be presented in the Substatus field. 2 10SSSSLL NA This value is reserved and isn't used by the OPC standard. 3 11SSSSLL Good The quality is good and the value read can be used. Table 120: Description of the OPC Quality value Table 120 presents the possible quality values. The OPC DA Server only returns Good and Bad Quality values. A OPC Client can maintain the quality as Uncertain due to failures in which it can't establish a connection to the Server. In case of monitoring of the 8 quality bits directly from the OPC DA Server, the Substatus and Limit fields shall be null and the Good Quality will be presented as the value 192 and the Bad Quality will be value 0. 144 5. CONFIGURATION 5.4.10.4. Limits of Communication with OPC DA Server The table below presents the OPC DA Server configuration limits. Maximum number of variables communicating with a single PLC - Maximum number of PLCs in an OPC DA Server 16 Maximum number of simultaneous connections of an OPC DA Server in a single PLC 8 Table 121: OPC DA Server Communication Limits Note: Maximum number of variables communicating with a single PLC: There is no configuration limit. The maximum possible number of variables depends on the processing capacity of the device. ATTENTION The Maximum number of simultaneous connections of an OPC DA Server in a single PLC is shared with connections made with the MasterTool IEC XE. I.e. the sum of connections of OPC DA Server and MasterTool IEC XE should not exceed the maximum quantity defined in Table 121. The communication between the OPC DA Server and the PLC uses the same protocol used in the MasterTool IEC XE communication with the PLC. This protocol is only available for the Ethernet interfaces of the Nexto Series CPUs, it's not possible to establish this kind of communication with the Ethernet expansion modules. When a communication between the OPC DA Server and the PLC is established, these two elements start a series of transactions aimed at solving the addresses of each declared variables, optimizing the communication in data reading regime. Besides, it's also resolved in this stage the communication groups used by some Clients in order to optimize the communication. This initial process demands some time and depends on the quantity of mapped variables and the processing capacity of the device. 5.4.10.5. Accessing Data Through an OPC DA Client After the configuration of the OPC DA Server, the available data on all PLCs can be accessed via an OPC Client. In the configuration of the OPC Client, the name of the OPC DA Server must be selected. In this case the name is CoDeSys.OPC.DA. The figure below shows the server selection on the client driver of the BluePlant SCADA software. ATTENTION The same way that in MasterTool IEC XE, some tools must be executed with administrator privileges in the Operational System for the correct functioning of the OPC Client. Depending on the OS version, this privilege must be activated in the moment that the program is executed. To do this, right-click MasterTool IEC XE icon and choose Run as Administrator. 145 5. CONFIGURATION Figure 79: Selecting the OPC DA Server in the Client Configuration In cases where the server is remotely located, it may be necessary to add the network path or IP address of the computer in which the server is installed. In these cases, there are two configuration options. The first is to directly configure it, being necessary to enable the COM/DCOM Windows Service. However, a simpler way is to use a tunneller tool that abstracts the COM/DCOM settings, and enable a more secure communication between the Client and the Server. For more information on this type of tool, refer to the NAP151 - Tunneller OPC. Once the Client connects with the Server, it's possible to use the TAGs import commands. These commands consult the information declared in the PLC, returning a list with all the symbols available in it. Figure 80: Symbols list consulted by the OPC Client The list of selected variables will be included in the Client communication list and can be used, for example, in a SCADA system screen. 146 5. CONFIGURATION ATTENTION The simulation mode of MasterTool IEC XE software can be used for OPC communication tests. The information on how to configure it are presented in the Testing an OPC Communication using the Simulator section of the MasterTool IEC XE User Manual MU299609. 5.4.11. OPC UA Server The OPC UA protocol is an evolution of the OPC family. Independent of platform, it is designed to be the new standard used in industrial communications. Based on the client/server architecture, the OPC UA protocol offers numerous advantages in the development of design and facilities in communication with the automation systems. When it comes to project development, configuring communication and exchanging information between systems is ex- tremely simple using OPC UA technology. Using other address-based drivers, it is necessary to create tables to relate the supervision system tags and programmable controller variables. When data areas change during project development, it is necessary to redo the mappings and new tables with the relationships between the PLC information and the SCADA system. Figure 81: OPC UA Architecture The figure above presents a typical architecture for SCADA system communication and PLCs in automation design. All roles present in the communication are explicit in this figure regardless of where they are running, they may be on the same equipment or on different equipment. Each of the roles of this architecture is described in table below. 147 5. CONFIGURATION Role Programmable Controllers and Field Devices Level OPC UA Server Modules Acquisition Network OPC Client Device Module SCADA Server Level Supervision Network SCADA Client Level Description The field devices and the PLCs are where the operation state and plant control information are stored. The SCADA system access the information on these devices and store on the SCADA server, so that the SCADA clients can consult it during the plant operation. The OPC UA Server is an internal module of the PLCs responsible for receiving the OPC UA requests and translating them for communication with the field devices. The acquisition network is the network in which OPC UA messages travel to request the data that is collected from the PLCs and field devices. The OPC UA Client module, which is part of the SCADA Server, is responsible for making requests to the OPC UA Servers using the OPC UA protocol. The data collected by it is stored in the SCADA Server database. The SCADA Server is responsible for connecting to the various communication devices and store the data collected by them on a database, so that it can be consulted by the SCADA Clients. The supervisory network is the network by which SCADA Clients are connected to SCADA Servers, often using a proprietary SCADA system protocol. In a topology in which multiple Clients are not used or the Server and Client are installed in the same equipment, there is no such network, and in this case this equipment must directly use the OPC UA protocol for communication with the PLC. The SCADA Clients are responsible for requesting to the SCADA Servers the necessary data to be shown in a screen where the operation of a plant is being executed. Through then it is possible to execute readings and writings on data stored on the SCADA Server database. Table 122: Roles Description on an OPC UA Server Architecture When using the OPC UA protocol, the relationship between the tags of the supervisory systems and the process data in the controller variables is completely transparent. This means that if data areas change during project development, there is no need to re-establish relationships between PLC information and SCADA. Simply use the new variable provided by the PLC in the systems that request this data. The use of OPC UA offers greater productivity and connectivity with SCADA systems. It contributes to reduced application development time and maintenance costs. It also enables the insertion of new data in the communication in a simplified way with greater flexibility and interoperability among the automation systems as it is an open standard. It is worth noting that the OPC UA is only available on the local Ethernet interfaces of the Nexto CPUs. Ethernet expansion modules do not support this functionality. 5.4.11.1. Creating a Project for OPC UA Communication The steps for creating a project with OPC UA are very similar to the steps described in the section Creating a Project for OPC DA Communication. As with the OPC DA protocol, the configuration of the OPC UA protocol is based on the configuration of the Symbol Configuration. To enable the OPC UA, simply enable the Support OPC UA Features option in the configuration, as shown in figure below. 148 5. CONFIGURATION Figure 82: Symbol Configuration Object ATTENTION When enabling OPC UA protocol support, OPC DA protocol support is still enabled. You can enable OPC UA and OPC DA communications at the same time to report the variables configured on the Symbol Configuration object or via attributes. Another way to access this configuration, once already created a project with the Symbol Configuration object, is given by accessing the Settings menu of the configuration tab of the Symbol Configuration. Simply select the option Support OPC UA features to enable support for the OPC UA protocol, as shown in figure below. Figure 83: Enabling OPC UA in Object Symbol Configuration After this procedure the project can be loaded into a PLC and the selected variables will be available for communication with the OPC UA Server. 149 5. CONFIGURATION 5.4.11.2. Types of Supported Variables This section defines the types of variables that support communication via the OPC UA protocol, when declared within GVLs or POUs and selected in the Symbol Configuration object (see previous section). The following types of simple variables are supported: BOOL SINT USINT / BYTE INT UINT / WORD DINT UDINT / DWORD LINT ULINT / LWORD REAL LREAL STRING TIME LTIME You can also use structured types (STRUCTs or Function Blocks) created from previous simple types. Finally, it is also possible to create arrays of simple types or of structured types. 5.4.11.3. Limit Connected Clients on the OPC UA Server The maximum number of OPC UA clients connected simultaneously in a PLC is 8 (eight). 5.4.11.4. Limit of Communication Variables on the OPC UA Server There is no configuration limit. The maximum possible number of variables depends on the processing capacity of the device. When a communication is established between the OPC UA Server and the PLC, these two elements initiate a series of transactions that aim to solve the address of each declared variable, optimizing the communication in regime of reading of data. In addition, at this stage, the classifications of the communication groups used by some Clients are also resolved in order to optimize communication. This initial process takes some time and depends on the amount of variables mapped and the processing capacity of the device. 5.4.11.5. Encryption Settings If desired, the user can configure encryption for OPC UA communication using the Basic256SHA256 profile, for a secure connection (cyber security). To configure encryption on an OPC UA server, you must create a certificate for it using the following steps in the MasterTool programmer: 1. Define an active path for communication with the controller (no login required); 2. From the View menu, select Security Screen; 3. Click the Devices tab on the left side of this screen; 4. Click the icon to perform a refresh; 5. Click on the Device icon, below which will open several certificates (Own Certificates, Trusted Certificates, Untrusted Certificates, Quarantined Certificates); 6. Click the icon to generate a certificate and select the following parameters: Key length (bit): 3072 Validity period (days): 365 (can be modified if desired) 7. Wait while the certificate is calculated and transferred to the controller (this may take a few minutes); 8. Reboot the controller. 9. On the OPC UA client, perform the necessary procedures to connect to the OPC UA server and generate a certificate with the Basic256Sha256 profile (see specific OPC UA client manual for details); 150 5. CONFIGURATION 10. Back to MasterTool, click on the icon of the Security Screen to perform a refresh; 11. On the Security Screen, select the "Quarantined Certificates" folder under the Device. In the right panel you should observe a certificate requested by the OPC UA client; 12. Drag this certificate to the folder "Trusted Certificates"; 13. Proceed with the settings in the OPC UA client (see specific OPC UA client manual for details). To remove encryption previously configured on a controller, you must do the following: 1. Define an active path for communication with the controller (no login required); 2. From menu View, select Security Screen; 3. Click on the Devices on the left side of this screen; 4. Click the icon to perform a refresh; 5. Click on the Device icon, below which will open several certificates (Own Certificates, Trusted Certificates, Untrusted Certificates, Quarantined Certificates); 6. Click the folder "Own Certificates" and in the right panel select the certificate (OPC UA Server); 7. Click the icon to remove this project and driver certificate; 8. Reset (turn off and on) the controller. 5.4.11.6. Main Communication Parameters Adjusted in an OPC UA Client Some OPC UA communication parameters are configured on the OPC UA client, and negotiated with the OPC UA server at the time the connection between both is established. The following subsections describe the main OPC UA communication parameters, their meaning, and care to select appropriate values for them. In an OPC UA client it is possible to group the variables of a server into different subscriptions. Each subscription is a set of variables that are reported in a single communication packet (PublishResponse) sent from the server to the client. The selection of the variables that will compose each subscription is made in the OPC UA client. ATTENTION Grouping variables into multiple subscriptions is interesting for optimizing the processing capacity and consumption of Ethernet communication bandwidth. Such aspects of optimization are analyzed in greater depth in the application note NAP165, where some rules for the composition of subscriptions are suggested. This application note also discusses in more depth several concepts about the OPC UA protocol. Some of the communication parameters described below must be defined for the server as a whole, others for each subscription, and others for each variable that makes up a subscription. 5.4.11.6.1. Endpoint URL This parameter defines the IP address and TCP port of the server, for example: opc.tcp://192.168.17.2:4840 In this example, the IP address of the controller is 192.168.17.2. The TCP port should always be 4840. 5.4.11.6.2. Publishing Interval (ms) e Sampling Interval (ms) The Publishing Interval parameter (unit: milliseconds) must be set for each subscription. The Sampling Interval parameter must be set for each variable (unit: milliseconds). However, in many OPC UA clients, the Sampling Interval parameter can be defined for a subscription, being the same for all the variables grouped in the subscription. Only the variables of a subscription whose values have been modified are reported to the client through a Publish Response communication packet. The Publishing Interval parameter defines the minimum interval between consecutive Publish Response packets of the same subscription, in order to limit the consumption of processing and Ethernet communication bandwidth. To find out which subscription variables have changed and are to be reported to the client in the next Publish Response packet, the server must perform comparisons, and such (samplings) are performed by the same with the Sampling Interval. It is recommended that the value of Sampling Interval varies between 50% and 100% of the value of the Publishing Interval, because there is a relatively high processing consumption associated with the comparison process executed in each Sampling Interval. It can be said that the sum between Publishing Interval and Sampling Interval is the maximum delay between changing a value on the server and the transmission of the Publish Response packet that reports this change. Half of this sum is the average delay between changing a value on the server and the transmission of the Publish Response packet that reports this change. 151 5. CONFIGURATION 5.4.11.6.3. Lifetime Count e Keep-Alive Count These two parameters must be configured for each subscription. The purpose of these two parameters is to create a mechanism for deactivating a subscription on the initiative of the server, in case it does not receive customer's PublishRequest communication packets for this subscription for a long time. PublishRequest packets must be received by the server so that it can broadcast Publish Response packets containing the subscription variables that have changed their values. If the server does not receive PublishRequest packets for a time greater than Lifetime Count multiplied by Publishing Interval, the server deactivates the subscription, which must be re-created by the client in the future if desired. In situations where the variables of a subscription do not change, it could be a long time without the transmission of PublishResponses and consequently PublishRequests that succeed, causing an undesired deactivation of the subscription. To prevent this from happening, the Keep-Alive Count parameter was created. If there are no subscription data changes for a time equal to Keep-Alive Count multiplied by Publishing Interval, the server will send a small empty Publish Response packet indicating that no variable has changed. This empty Publish Response will authorize the client to immediately send the next PublishRequest. The Keep-Alive Count value must be less than the Lifetime Count value to prevent unwanted deactivation of the subscription. It is suggested that LifeTime Count be at least 3 times larger than Keep-Alive Count. 5.4.11.6.4. Queue Size e Discard Oldest These parameters must be maintained with the following fixed values, which are usually the default values on the clients: Queue Size: 1 Discard Oldest: enable According to the OPC UA standard, it is possible to define these parameters for each variable. However, many clients allow you to define common values for all variables configured in a subscription. Queue Size must be retained with value 1 because there is no event support in this implementation of the OPC UA server, so it is unnecessary to define a queue. Increasing the value of Queue Size may imply increase communication bandwidth and CPU processing, and this should be avoided. Discard Oldest must be maintained with the enable value, so that the Publish Response package always reports the most recent change of value detected for each variable. 5.4.11.6.5. Filter Type e Deadband Type These parameters must be maintained with the following fixed values, which are usually the default values in the clients: Filter Type: DataChangeFilter Deadband Type: none According to the OPC UA standard, it is possible to define these parameters for each variable. However, many clients allow you to define common values for all variables configured in a subscription. The Filter Type parameter must be of DataChangeFilter, indicating that value changes in the variables should cause it to be transmitted in a Publish Response package. Deadband Type should be kept in "none" because there is no implementation of deadbands for analog variables. In this way, any change of the analog variable, however minimal, causes its transmission in a Publish Response package. To reduce processing power and Ethernet communication bandwidth, you can deploy deadbands on your own as follows: Do not include the analog variable in a subscription; Instead, include in a subscription an auxiliary variable linked to the analog variable; Copy the analog variable to the auxiliary variable only when the user-managed deadband is extrapolated. 5.4.11.6.6. PublishingEnabled, MaxNotificationsPerPublish e Priority It is suggested that the following parameters be maintained with the following values, which are usually the default values in the clients: PublishingEnabled: true MaxNotificationsPerPublish: 0 Priority: 0 152 5. CONFIGURATION These parameters must be configured for each subscription. PublishingEnable must be "true" so that the subscription variables are reported in case of change of value. MaxNotificationsPerPublish indicates how many of the variables that have changed value can be included in the same Publish Response package. The special value "0" indicates that there is no limit to this, and it is recommended to use this value so that all changed variables are reported in the same Publish Response package. Priority indicates the relative priority of this subscription over others. If at any given moment the server should send multiple Publish Response packages of different subscriptions, it will prioritize the one with the highest value of priority. If all subscriptions have the same priority, Publish Response packets will be transmitted in a fixed sequence. 5.4.11.7. Accessing Data Through an OPC UA Client After configuration of the OPC UA Server the data available in all PLCs can be accessed via a Client OPC UA. In the configuration of the OPC UA Client, the address of the correct OPC UA Server must be selected. In this case the address opc.tcp://ip-address-of-device:4840. The figure below shows the server selection in the SCADA BluePlant client software driver. ATTENTION Like MasterTool IEC XE, some tools need to be run with administrator rights on the Operating System for the correct operation of the OPC UA Client. Depending on the version of the Operating System this right must be authorized when running the program. For this operation right click on the tool executable and choose the option Run as administrator. Figure 84: Selecting OPC UA Server in Client Configuration Once the Client connects to the Server, TAG import commands can be used. These commands query information declared in the PLC, returning a list with all the symbols made available by the PLC. 153 5. CONFIGURATION Figure 85: List of Symbols Browsed by OPC UA The list of selected variables will be included in the Client's communications list and can be used, for example, in screens of a SCADA system. 5.4.12. EtherNet/IP The EtherNet/IP is a master-slave architecture protocol, consisting of an EtherNet/IP Scanner (master) and one or more EtherNet/IP Adapters (slave). The Ethernet/IP protocol is based on CIP (Common Industrial Protocol), which have two primary purposes: The transport of control-oriented data associated with I/O devices and other system-related information to be controlled, such as configuration parameters and diagnostics. The first one is done through implicit messages, while the second one is done through explicit messages. Their runtime system can act as either Scanner or Adapter. Each CPU's NET interface support only one EtherNet/IP instance and it can't be instanced on an Ethernet expansion module. An EtherNet/IP Adapter instance supports an unlimited number of modules or Input/Output bytes. In these modules, can be added variables of types: BYTE, BOOL, WORD, DWORD, LWORD, USINT, UINT, UDINT, ULINT, SINT, INT, DINT, LINT, REAL and LREAL. ATTENTION EtherNet/IP can't be used together with Ethernet NIC-Teaming nor with Half-Cluster's redundancy. ATTENTION To avoid communication issues, EtherNet/IP Scanner can only have Adapters configured within the same subnetwork. 5.4.12.1. EtherNet/IP To add an EtherNet/IP Scanner or Adapter it's needed to add an EtherNet/IP Interface under the NET interface. This can be done through the command Add Device. Under this EtherNet/IP Interface it's possible to add a Scanner or an Adapter. 154 5. CONFIGURATION Figure 86: Adding an EtherNet/IP Interface Figure 87: Adding an EtherNet/IP Adapter or Scanner 155 5. CONFIGURATION 5.4.12.2. EtherNet/IP Scanner Configuration Figure 88: Adding an EtherNet/IP Adapter Under the Scanner 5.4.12.2.1. General After open the Adapter declared under the Scanner it's possible to configure it as needed. The first Tab is General, on it is possible to configure the IP address and the Electronic Keying parameters. These parameters must be checked or unchecked if the adapter being used is installed on MasterTool. Otherwise, if the adapter used is type Generic, then the fields Vendor ID, Device type, Product code, Major revision and Minor revision must be fulfilled with the correct information and the boxes checked as long as needed. 156 5. CONFIGURATION Figure 89: EtherNet/IP General Tab 5.4.12.2.2. Connections The upper area of the Connections tab displays a list of all configured connections. When there is an Exclusive Owner connection in the EDS file, it is inserted automatically when the Adapter is added. The configuration data for these connections can be changed in the lower part of the view. Figure 90: EtherNet/IP Connection Tab Notes: For two or more EtherNet/IP Scanners to connect to the same Remote Adapter: 1. Only one of the Scanners can establish an Exclusive Owner connection. 2. The same value of RPI(ms) must be configured for the Scanners. The configuration data is defined in the EDS file. The data is transmitted to the remote adapter when the connection is opened. 157 5. CONFIGURATION Configuration RPI (ms) O -> T Size (Bytes) T -> O Size (Bytes) Config #1 Size (Bytes) Config #2 Size (Bytes) Connection Path Description Request Packet Interval: exchange interval of the input and output data. Size of the producer data from the Scanner to the Adapter (O -> T) Size of the consumer data from the Adapter to the Scanner (T -> O) Size of configuration data 1. Size of configuration data 2. Address of the configuration objects - input objects - output objects. Default Value 10 ms Depends on adapter's EDS Depends on adapter's EDS Depends on adapter's EDS Depends on adapter's EDS Depends on adapter's EDS Options Multiple the Interval of the Bus Cycle Task to which it is associated 0 - 65527 0 - 65531 - - Table 123: EtherNet/IP Connection parameters To add new connections there is the button Add Connection... which will open the New connection window. On this window it's possible to configure a new type of connection from the ones predefined on Adapter's EDS or a generic connection from zero. Figure 91: EtherNet/IP New Connection's Window 5.4.12.2.3. Assemblies The upper area of the Assemblies tab displays a list of all configured connections. When a connection is selected, the associated inputs and outputs are displayed in the lower area of the tab. 158 5. CONFIGURATION Figure 92: EtherNet/IP Assemblies Output Assembly and Input Assembly: Configuration Add Delete Move Up Move Down Description Opens the dialog box "Add Input/Output" Deletes all selected Inputs/Outputs. Moves the selected Input/Output within the list. The order in the list determines the order in the I/O mapping. Table 124: EtherNet/IP Assemblies tab Dialog box Add Input/Output: Configuration Name Help String Data type Bit Length Description Name of the input/output to be inserted. Type of the input/output to be inserted. This type also define its Bit Length. This value must not be edited. Table 125: EtherNet/IP "Add Input/Output" window 5.4.12.2.4. EtherNet/IP I/O Mapping I/O Mapping tab shows, in the Variable column, the name of the automatically generated instance of the Adapter under IEC Objects. In this way, the instance can be accessed by the application. Here the project variables are mapped to adapter's inputs and outputs. 5.4.12.3. EtherNet/IP Adapter Configuration The EtherNet/IP Adapter requires Ethernet/IP Modules. The Modules will provide I/O mappings that can be manipulated by user application through %I or %Q addresses according to its configuration. New Adapters can be installed on MasterTool with the EDS Files. The configuration options may differ depending on the device description file of the added Adapter. 159 5. CONFIGURATION 5.4.12.3.1. General The first tab of the EtherNet/IP Adapter is the General tab. Here you can set the parameters of the Electronic Keying used in the scanner to check compatibility. In this tab, you can also install the EDS of the device directly in the MasterTool device repository or export it. Figure 93: EtherNet/IP General Tab 5.4.12.3.2. EtherNet/IP Adapter: I/O Mapping On the EtherNet/IP I/O Mapping tab, you can configure which bus cycle task the Adapter will execute. 160 5. CONFIGURATION 5.4.12.4. EtherNet/IP Module Configuration Figure 94: Adding an EtherNet/IP Module under the Adapter 5.4.12.4.1. Assemblies The parameters of the module's General tab follow the same rules as described in the 124 and 125 tables. Figure 95: EtherNet/IP Module Assemblies tab 5.4.12.4.2. EtherNet/IP Module: I/O Mapping The I/O Mapping tab shows, in the Variable column, the name of the automatically generated Adapter instances. In this way, the instance can be accessed by the user application. 5.4.13. IEC 60870-5-104 Server As select this option at MasterTool, the CPU starts to be an IEC 60870-5-104 communication server, allowing connection with up to three client devices. To each client the driver owns one exclusive event queue with the following features: Size: 1000 events Retentivity: non retentive Overflow policy: keep the newest 161 5. CONFIGURATION To configure this protocol, it is needed to do the following steps: Add a protocol IEC 60870-5-104 Server instance to one of the available Ethernet channel. To realize this procedure consult the section Inserting a Protocol Instance Configure the Ethernet interface. To realize this procedure consult the section Ethernet Interfaces Configuration Configure the general parameters of protocol IEC 60870-5-104 Server with connection mode Port or IP, and the TCP port number when the selected connection mode is IP Add and configure devices, defining the proper parameters Add and configure the IEC 60870-5-104 mappings, specifying the variable name, type of object, object address, size, range, dead band and type of dead band Configure the link layer parameters, specifying the addresses, communication time-outs and communication parameters Configure the application layer parameters, synchronism configuration, commands, as well as transmission mode of Integrated Totals objects The descriptions of each configuration are related below, in this section. 5.4.13.1. Type of data The table below shows the supported variable type by the Nexto Series CPU for each protocol IEC 60870-5-104 data type. Object Type Single Point Information (M_SP_NA) Double Point Information (M_DP_NA) Step Position Information (M_ST_NA) Measured Value, normalized value (M_ME_NA) Measured Value, scaled value (M_ME_NB) Measured Value, short floating point value (M_ME_NC) Integrated Totals (M_IT_NA) Single Command (C_SC_NA) Double Command (C_DC_NA) Regulating Step Command (C_RC_NA) Setting Point Command, normalized Value (C_SE_NA) Setting Point Command, scaled Value (C_SE_NB) Setting Point Command, short floating point Value (C_SE_NC) IEC Variables Type BOOL BIT DBP USINT INT INT INT UINT DINT UDINT REAL INT DINT BOOL BIT DBP DBP INT INT REAL Table 126: Variables Declaration to IEC 60870-5-104 Notes: Regulating Step Command: The Lower and Higher object states of the C_RC_NA are associated respectively to OFF and ON internal DBP type states. Step Position Information: According to item 7.3.1.5 of Standard IEC 60870-5-101, this 8 bit variable is compose by two fields: value (defined by the 7 bits less significant) and transient (defined as the most significant bit, which indicates when the measured device is transitioning). Below, there is a code example for fields manipulation in an USINT type variable. Attention, because this code doesn't consist if the value is inside the range, therefore this consistency remains at user's charge. 162 5. CONFIGURATION PROGRAM UserPrg VAR usiVTI: USINT; // Value with transient state indication, mapped for the Client siValue: SINT; // Value to be converted to VTI. Must be between -64 and +63 bTransient: BOOL; // Transient to be converted to VTI END_VAR usiVTI := SINT_TO_USINT(siValue) AND 16#3F; IF siValue < 0 THEN usiVTI := usiVTI OR 16#40; END_IF IF bTransient THEN usiVTI := usiVTI OR 16#80; END_IF PROFIBUS: Except by the digital objects, the protocol IEC 60870-5-104's analog and counters objects data types are different from PROFIBUS analogs and counters modules data types, not being possible to map such PROFIBUS variable types directly to IEC 60870-5-104 clients. In these cases it is needed to create an intermediary variable, to be mapped in the IEC 60870-5-104 client, and properly convert the types, as can be observed on the example's code below. PROGRAM UserPrg VAR iAnalogIn: INT; iAnalogOut: INT; diCounter: DINT; END_VAR // Analog input conversion from WORD (PROFIBUS) to INT (IEC104) iAnalogIn:= WORD_TO_INT(wNX6000in00); // Analog output conversion from INT(IEC104) to WORD (PROFIBUS) wNX6100out00:= INT_TO_WORD(iAnalogOut); // Counter conversion from WORDs high+low (PROFIBUS) to DINT (IEC104) diCounter:= DWORD_TO_DINT(ROL(WORD_TO_DWORD(wNX1005cnt00H), 16) OR wNX1005cnt00L ); 5.4.13.2. Double Points The double digital points are used to indicate equipment position, such as valves, circuit breakers and secctioners, where the transition between open and close states demand a determined time. Can thus indicate an intermediary transition state between both final states. Double digital points are also used as outputs and, in an analogous way, it is necessary to keep one of the outputs enabled for a certain time to complete the transition. Such actuation is done through pulses, also known by trip/close commands, with determined duration (enough to the switching of the device under control). Consult the Double Points section of Utilization Manual for information about double digital points through DBP data type. Once the Nexto Series digital input and output modules don't support DBP points mapping, some application trickery are needed to make it possible. Remembering that is also not possible to use the PulsedCommand function, defined at the LibRtuStandard library, to operate the Nexto Series digital double points. 163 5. CONFIGURATION 5.4.13.2.1. Digital Input Double Points For the digital input modules it is needed two auxiliary variables' declaration, to be mapped on the digital input module, besides the double point that is wished to map on the server: The double point value variable: type DBP The simple point OFF/TRIP value variable: type BOOL The simple point ON/CLOSE value variable: type BOOL Figure 96: Double Point Variables Declaration Example Done the variables declaration, it is necessary to create a link between the value variables and the digital input module quality, through the CPU's Internal Points tab: Figure 97: Double Point Variables Attribution to Internal Points The double point value variable must be mapped at the server IEC 60870-5-104 driver, and both simple variables at the Nexto Series digital input module (in that example, a NX1001). Typically the OFF (TRIP) state is mapped to the even input and the ON (CLOSE) state to the odd input. Figure 98: Double Point Variables Mapping on the Client IEC 60870-5-104 164 5. CONFIGURATION Figure 99: Variables Mapping at the Module Inputs At last, the user must insert two code lines in its application, to be cyclically executed, to simple variables value attribution to double point: DBP value variable, index ON, receive simple point ON value DBP value variable, index OFF, receive simple point OFF value Figure 100: Variables' Values Attribution to the Double Point 5.4.13.2.2. Digital Output Double Points For the digital output modules it must be used the CommandReceiver function block to intercept double points actuation commands originated from the clients IEC 60870-5-104. Consult the section Interception of Commands Coming from the Control Center for further information. The example code below, POU CmdRcv, treats pulsed commands received from clients for a digital double point, mapped in a NX2020 module. Besides the following ST code it is need to map a DBP point in Nexto's IEC 60870-5-104 server. Figure 101: Mapping of Digital Output Double Point variables on IEC 60870-5-104 Client PROGRAM CmdRcv VAR CmdReceive: CommandReceiver; // Interceptor Instance 165 5. CONFIGURATION fbPulsedCmd: PulsedCommandNexto; // Pulsed Command Instance byResult: BYTE; // Pulsed command result dbpIEC104: DBP; // Variable mapped in the IEC 104 bSetup: BOOL:= TRUE; // Interceptor initial setup END_VAR // Executes the function configuration in the first cycle IF bSetup THEN CmdReceive.dwVariableAddr:= ADR(dbpIEC104); CmdReceive.bExec:= TRUE; CmdReceive.eCommandResult:= COMMAND_RESULT.NONE; CmdReceive.dwTimeout:= 256 * 10; bSetup:= FALSE; END_IF // In case a command is captured: IF CmdReceive.bCommandAvailable THEN // Treats each one of the possible commands CASE CmdReceive.sCommand.eCommand OF COMMAND_TYPE.NO_COMMAND: // Inform that there is an invalid command. // Does nothing and must move on by time-out. COMMAND_TYPE.SELECT: // Treats only commands for double points IF CmdReceive.sCommand.sSelectParameters.sValue.eParamType = DOUBLE_POINT_COMMAND THEN // Returns command finished with success // (controlled by IEC104 protocol) byResult:= 7; ELSE // Returns command not supported byResult:= 1; END_IF COMMAND_TYPE.OPERATE: // Treats only commands for double points IF CmdReceive.sCommand.sOperateParameters.sValue.eParamType = DOUBLE_POINT_COMMAND THEN // Pulse generation in outputs IF CmdReceive.sCommand.sOperateParameters.sValue.sDoublePoint.bValue THEN // Executes TRIP function fbPulsedCmd( byCmdType:= 101, byPulseTime:= DWORD_TO_BYTE(CmdReceive.sCommand.sOperateParameters. sValue.sDoublePoint.sPulseConfig.dwOnDuration/10), ptDbpVarAdr:= ADR(dbpIEC104), stQuality:= IOQualities.QUALITY_NX2020[4], byStatus=> byResult); ELSE // Executes CLOSE function 166 5. CONFIGURATION fbPulsedCmd( byCmdType:= 102, byPulseTime:= DWORD_TO_BYTE(CmdReceive.sCommand.sOperateParameters. sValue.sDoublePoint.sPulseConfig.dwOffDuration/10), ptDbpVarAdr:= ADR(dbpIEC104), stQuality:= IOQualities.QUALITY_NX2020[5], byStatus=> byResult); END_IF ELSE // Returns command not supported byResult:= 1; END_IF COMMAND_TYPE.CANCEL: // Returns command finished with success // (controlled by IEC104 protocol) byResult:= 7; END_CASE // Treats the pulsed command function result // and generates the answer to the intercepted command CASE byResult OF 1: // Invalid type of command CmdReceive.eCommandResult:= COMMAND_RESULT.NOT_SUPPORTED; CmdReceive.bDone:= TRUE; 2: // Invalid input parameters CmdReceive.eCommandResult:= COMMAND_RESULT.INCONSISTENT_PARAMETERS; CmdReceive.bDone:= TRUE; 3: // Parameter change in running CmdReceive.eCommandResult:= COMMAND_RESULT.PARAMETER_CHANGE_IN_EXECUTION; CmdReceive.bDone:= TRUE; 4: // Module did not answered the command(absent) CmdReceive.eCommandResult:= COMMAND_RESULT.HARDWARE_ERROR; CmdReceive.bDone:= TRUE; 5: // Command started and in running (does not returns nothing) 6: // Another command has been sent to this point and it is running CmdReceive.eCommandResult:= COMMAND_RESULT.LOCKED_BY_OTHER_CLIENT; CmdReceive.bDone:= TRUE; 7: // Command finished with success CmdReceive.eCommandResult:= COMMAND_RESULT.SUCCESS; CmdReceive.bDone:= TRUE; END_CASE END_IF CmdReceive(); IF CmdReceive.bDone THEN CmdReceive.bDone:= FALSE; END_IF As can be observed in the previous code, to help in the pulse generation in Nexto's digital double outputs, it was created 167 5. CONFIGURATION and used a function block equivalent to PulsedCommand function of library LibRtuStandard. The PulsedCommandNexto() function block shows up coded in ST language. FUNCTION_BLOCK PulsedCommandNexto VAR_INPUT byCmdType: BYTE; // command type: // 100 = status // 101 = close/on // 102 = trip/off byPulseTime: BYTE; // Pulse duration (in hundredths of second) ptDbpVarAdr: POINTER TO DBP; // DBP variable address (can be mapped) stQuality: QUALITY; // DBP point quality(digital module) END_VAR VAR_OUTPUT bON: BOOL; // Odd output mapped on Nexto DO module bOFF: BOOL; // Even output mapped on Nexto DO module byStatus: BYTE:= 7; // Function return: // 1 = invalid command // 2 = Time out of valid range (2..255) // 3 = command changed in running time // 4 = module did not answer to the command (absent) // 5 = command started or running // 6 = There is already an active command on this point // 7 = pulse command finished with success END_VAR VAR byState: BYTE; // Function block state udiPulseEnd: UDINT; // Pulse end instant END_VAR // PulsedCommandNexto state machine CASE byState OF 0: // Init state, ready to receive commands: CASE byCmdType OF 100:// Just returns the last status 101: // Execute pulse ON: // Valids the pulse duration IF byPulseTime > 1 THEN // Check if there is already an active command on this point IF ptDbpVarAdr^.ON OR ptDbpVarAdr^.OFF THEN // Returns that there is already an active command byStatus:= 6; ELSE // Enables CLOSE output ptDbpVarAdr^.ON:= TRUE; ptDbpVarAdr^.OFF:= FALSE; // Next state: execute pulse ON byState:= byCmdType; // Returns started command byStatus:= 5; END_IF ELSE // Returns the out of range pulse 168 5. CONFIGURATION byStatus:= 2; END_IF 102: // Execute pulse OFF // Valids the pulse duration IF byPulseTime > 1 THEN // Check if there is already an active command on this point IF ptDbpVarAdr^.ON OR ptDbpVarAdr^.OFF THEN // Returns that there is already an active byStatus:= 6; ELSE // Enables TRIP output ptDbpVarAdr^.ON:= FALSE; ptDbpVarAdr^.OFF:= TRUE; // Next step: execute pulse OFF byState:= byCmdType; // Returns started command byStatus:= 5; END_IF ELSE // Returns the out of range pulse byStatus:= 2; END_IF ELSE // Returns invalid command byStatus:= 1; END_CASE // Memorizes the instant of the pulse end udiPulseEnd:= SysTimeGetMs() + BYTE_TO_UDINT(byPulseTime) * 10; 101, 102:// Continues the pulse execution ON/OFF // It returns that the command is running byStatus:= 5; // Checks the running parameter change IF byCmdType <> 100 AND byCmdType <> byState THEN // Returns the running parameter change byStatus:= 3; END_IF // Checks pulse end IF SysTimeGetMs() >= udiPulseEnd THEN // Disable TRIP and CLOSE outputs ptDbpVarAdr^.ON:= FALSE; ptDbpVarAdr^.OFF:= FALSE; // Returns finished command, only if the command has not changed IF byCmdType = 100 OR byCmdType = byState THEN byStatus:= 7; END_IF // Next state: initial byState:= 0; END_IF END_CASE // Checks digital module (DBP point) quality IF stQuality.VALIDITY <> QUALITY_VALIDITY.VALIDITY_GOOD THEN 169 5. CONFIGURATION // Disable TRIP and CLOSE outputs ptDbpVarAdr^.ON:= FALSE; ptDbpVarAdr^.OFF:= FALSE; // Returns absent module byStatus:= 4; // Next state: initial byState:= 0; END_IF // Copy DBP output states to the simple outputs bON:= ptDbpVarAdr^.ON; bOFF:= ptDbpVarAdr^.OFF; 5.4.13.3. General Parameters To the General Parameters configuration of an IEC 60870-5-104 Server according to figure below follow the table below parameters: Figure 102: Server IEC 60870-5-104 General Parameters Screen Parameter Connection Mode TCP Port Description Set the connection mode with the Connected Client modules. Defines which PLC's TCP port number will be used to communicate with the Connected Client modules. In case the "Connection Mode" field is set as "IP". Factory Default Port 2404 Possibilities Port IP 1 to 65535 Table 127: IEC 60870-5-104 Server General Parameters Configuration 5.4.13.4. Data Mapping To configure the IEC 60870-5-104 Server data relation, viewed on figure below follow the parameters described on table below: 170 5. CONFIGURATION Figure 103: IEC 60870-5-104 Server Mappings Screen Parameter Value Variable Object Type Object Address Size Range Counter Variable Dead Band Variable Dead Band Type Select Required Description Symbolic variable name IEC 60870-5-104 object type configuration IEC 60870-5-104 mapping first point's index Specifies the maximum data quantity that an IEC 608705-104 mapping will can access Configured data address range Name of the symbolic variable which will hold the counter variable's value Name of the symbolic variable which will hold the dead band's value Defines the dead band type to be used in the mapping Defines if it is required a previous select to run a command Factory Default - - Disabled False Possibilities Name of a variable declared in a POU or GVL Single Point Information Double Point Information Step Position Information Measured Value (Normalized) Measured Value (Scaled) Measured Value (Short Floating Point) Integrated Totals Single Command Double Command Regulating Step Command Setting Point Command (Normalized) Setting Point Command (Scaled) Setting Point Command (Short Floating Point) 1 to 65535 1 to 86400000 - Name of a variable declared in a POU, GVL or counter module Name of a variable declared in a POU or GVL Absolute Disabled Integrated True False 171 5. CONFIGURATION Parameter Short Pulse (ms) Long Pulse (ms) Description Defines the short pulse time to an IEC 60870-5-104 digital command Defines the long pulse time to an IEC 60870-5-104 digital command Factory Default 1000 2000 Possibilities 1 to 86400000 1 to 86400000 Table 128: IEC 60870-5-104 Server Mappings Configuration Notes: Value Variable: When a read command is sent, the return received in the answer is stored in this variable. When it is a write command, the written value is going to be stored in that variable. The variable can be simple, array, array element or can be at structures. Counter Variable: This field applies only on mapping of Integrated Totals type objects, being this the controller variable to be managed on process. It must has same type and size of the variable declared on Value Variable column, which value is going to be read, or reported to, the client in case of events. ATTENTION When the Counter Variable has a quality variable associated, to the quality to be transferred to the frozen variable at freeze command, it must be associated a quality variable to the frozen one. This procedure must be done through Internal Points tab. Dead Band Variable: This field applies only to input analog variables (Measured Value type objects) mappings. It must has same type and size of the variable declared on Value Variable column. New dead band variable values are going to be considered only when the input analog variable change its value. Dead Band Type: The configuration types available to dead band are: Function type Dead Band Type Configuration Disabled Absolute Integrated Description In this option, any value change in a group's point, as smaller it is, generates an event to this point. In this option, if the group's point value absolute change is bigger than the value in "Dead Band" field, an event is going to be generated to this point. In this option, if the absolute of the integration of the group's point value change is bigger than the value in "Dead Band" field, an event is going to be generated to this point. The integration interval is one second. Table 129: IEC 60870-5-104 Server Mappings Dead Band Types Short Pulse and Long Pulse: At the define of short and long pulses duration time it must be considered the limits supported by the device which will treat the command. For example, case the destiny is an output card, which is not supported in native by Nexto Series. It must be checked at the module's Datasheet what the minimum and maximum times, as well as the resolution, to running the pulsed commands. 5.4.13.5. Link Layer To the IEC 60870-5-104 Server link layer parameters configuration, shown on figure below, follow the described parameters on table below: 172 5. CONFIGURATION Figure 104: Server IEC 60870-5-104 Link Layer Configuration Screen Parameter Port Number IP Address Common Address of ASDU Time-out t1 (s) Time-out t2 (s) Time-out t3 (s) Parameter k (APDUs) Description Listened port address to client connection. Used when the client connection isn't through IP Connected client IP, used when the client connection is through IP IEC 60870-5-104 address, if the connected client is through IP Time period (in seconds) that the device waits the receiving of an acknowledge message after sent an APDU message type I or U (data), before close the connection Time period (in seconds) that the device waits to send a watch message (SFrame) acknowledging the data frame receiving Time period (in seconds) in what is going to be sent a message to link test in case there is no transmission by both sides Maximum number of data messages (I-Frame) transmitted and not acknowledged Factory Default 2404 0.0.0.0 1 15 10 20 12 Possibilities 1 to 65535 1.0.0.1 to 223.255.255.254 1 to 65534 1 to 180 1 to 180 1 to 180 1 to 12 173 5. CONFIGURATION Parameter Parameter w (APDUs) Description Maximum number of data messages (I-Frame) received and not acknowledged Factory Default 8 Possibilities 1 to 8 Table 130: IEC 60870-5-104 Server Link Layer Configuration Note: The fields Time-out t1 (s), Time-out t2 (s) and Time-out t3 (s) are dependents between themselves and must be configured in a way that Time-out t1 (s) be bigger than Time-out t2 (s) and Time-out t3 (s) be bigger than Time-out t1 (s). If any of these rules be not respected, error messages are going to be generated during the project compilation. ATTENTION For slow communication links (example: satellite communication), the parameters Time-out t1 (s), Time-out t2 (s) and Time-out t3 (s) must be properly adjusted, such as doubling the default values of these fields. 5.4.13.6. Application Layer To configure the IEC 60870-5-104 Server application layer, shown on figure below, follow the parameters described on table below: Figure 105: Server IEC 60870-5-104 Application Layer Configuration Screen Parameter Enable Time Synchronization Time Synchronization Command Received in Local Time Description Option to Enable/Disable time sync request Option to Enable/Disable the treatment of the synchronization command in local time Factory Default Disabled Enabled Possibilities Disabled Enabled Disabled Enabled 174 5. CONFIGURATION Parameter Use Local Time instead of UTC Time Maximum Time Between Select and Operate (s) Transmission Mode of Analog Input Events Transmission Mode Description Option to Enable/Disable the time stamp in local time for events Time period in which the selection command will remain active (the count starts from the received selection command acknowledge) waiting the Operate command Analog input events transmission mode Frozen counters transmission mode (Integrated Totals) Factory Default Disabled 5 All Events (SOE) Freeze by counterinterrogation command, transmit spontaneously Possibilities Disabled Enabled 1 to 180 All Events (SOE) Most Recent Event Freeze by counterinterrogation command, transmit spontaneously Freeze and transmit by counter-interrogation command Table 131: IEC 60870-5-104 Server Application Layer Configuration Notes: Enable Time Synchronization: Once enabled, allow the IEC 60870-5-104 Server adjust the CPU's clock when a sync command is received. Time Synchronization Command Received in Local Time: When enabled, the IEC 60870-5-104 Server adjusts the CPU clock by treating the time received in the synchronization command as local time. Otherwise, this time is considered UTC. Use Local Time instead of UTC Time: Once enabled, the time stamp of the events generated by IEC 60870-5-104 Server will be sent according to the CPU's local time. ATTENTION When the time sync option is checked in more than one server, the received times from different servers will be overwritten in the system clock in a short time period, being able to cause undesirable behaviors due to delays on messages propagation time and system load. Transmission Mode of Analog Inputs Events: The Analog Inputs Events transmission modes available are the following: Function Type Transmission Mode of Analog Input Events Configuration All Events (SOE) Most Recent Event Description All analog events generated are going to be sent. It is sent only the most recent analog event. Table 132: IEC 60870-5-104 Server Transmission Modes of Analog Inputs Events Transmission Mode: The available transmission modes of the frozen counters (Integrated Totals) are the following: 175 5. CONFIGURATION Function Type Transmission Mode Configuration Freeze by counter- interrogation com- mand, transmit spontaneously Freeze and transmit by counterinterrogation command Description Equivalent to the counters acquisition D Mode (Integrated Totals) defined by Standard IEC 60870-5-101. In this mode, the control station's counters interrogation commands, freeze the counters. Case the frozen values have been modified, they are reported through events. Equivalent to the counters acquisition C Mode (Integrated Totals) defined by Standard IEC 60870-5-101. In this mode, the control station's counters interrogation commands, freeze the counters. The subsequent counters interrogation commands (read) are sent by the control station to receive the frozen values. Table 133: IEC 60870-5-104 Server Transmission Modes of the Frozen Counters ATTENTION The Standard IEC 60870-5-104, section Transmission control using Start/Stop, foresee the commands STARTDT and STOPDT utilization to data traffic control between client and server, using simple or multiple connections. Despite Nexto supports such commands, its utilization isn't recommended to control data transmission, mainly with redundant CPUs, because such commands aren't synchronized between both CPUs. Instead of using multiple connections between client and Nexto server, it's suggested the use of NIC Teaming resources to supply (physically) redundant Ethernet channels and preserve the CPU resources (CPU control centers). 5.4.13.7. Server Diagnostic The IEC 60870-5-104 Server protocol diagnostics are stored in T_DIAG_IEC104_SERVER_1 type variables, which are described in table below: Diagnostic variable of type T_DIAG_IEC104_SERVER_1.* Size Description Command bits, automatically reset: tCommand.bStop BOOL Disable Driver tCommand.bStart BOOL Enable Driver tCommand.bDiag_01_Reserved BOOL Reserved tCommand.bDiag_02_Reserved BOOL Reserved tCommand.bDiag_03_Reserved BOOL Reserved tCommand.bDiag_04_Reserved BOOL Reserved tCommand.bDiag_05_Reserved BOOL Reserved tCommand.bDiag_06_Reserved BOOL Reserved Diagnostics: tClient_X.bRunning BOOL IEC 60870-5-104 Server is running tClient_X.eConnectionStatus. CLOSED Communication channel closed. Server won't accept connection request. ENUM value (0) tClient_X.eConnectionStatus. LISTENING Server is listening to the configured port ENUM(BYTE) and there is no connected clients. ENUM value (1) 176 5. CONFIGURATION Diagnostic variable of type T_DIAG_IEC104_SERVER_1.* tClient_X.eConnectionStatus. CONNECTED tClient_X.tQueueDiags. bOverflow tClient_X.tQueueDiags. wSize tClient_X.tQueueDiags. wUsage tClient_X.tQueueDiags. dwReserved_0 tClient_X.tQueueDiags. dwReserved_1 tClient_X.tStats.wRXFrames tClient_X.tStats.wTXFrames Size BOOL WORD WORD DWORD DWORD WORD WORD tClient_X.tStats.wCommErrors WORD tClient_X.tStats.dwReserved_0 tClient_X.tStats.dwReserved_1 DWORD DWORD Description Connected client. ENUM value (2) Client queue is overflowed Configured queue size Events number in the queue Reserved Reserved Number of received frames Number of sent frames Communication errors counter, including physical layer, link layer and transport layer errors. Reserved Reserved Table 134: IEC 60870-5-104 Server Diagnostics 5.4.13.8. Commands Qualifier The standard IEC 60870-5-104 foresee four different command qualifiers for the objects Single Command, Double Command and Regulating Step Command, all supported by the Nexto Server. Each object type has a specific behavior to each command qualifier, as can be seen on the table below. Qualifier No additional definition (default) Short pulse duration Long pulse duration Persistent output Protocol IEC 60870-5-104 object type Single Command Double Command Regulating Step Command Same behavior of persis- Same behavior of short Same behavior of short pulse tent qualifier. pulse qualifier. qualifier. Requires command interception to application treatment. Other way it will return a negative acknowledge message (fail). Requires command interception to application treatment. Other way it will return a negative acknowledge message (fail). Requires command interception to application treatment. Other way it will return a negative acknowledge message (fail). The output is going to be on or off and that will remain until new command, according to value (ON or OFF) commanded by the client. Table 135: IEC 60870-5-104 Server Commands Qualifier Note: Command Interception: For further information about commands interception of IEC 608705-104 clients, consult section Interception of Commands Coming from the Control Center, implemented through CommandReceiver function block. 177 5. CONFIGURATION 5.5. Communication Performance 5.5.1. MODBUS Server The MODBUS devices configurable in the Nexto CPU run in the background, with a priority below the user application and cyclically. Thus, their performance varies depending on the remaining time, taking into account the difference between the interval and time that the application takes to run. For example, a MODBUS device in an application that runs every 100 ms, with a running time of 50 ms, will have a lower performance than an application running every 50 ms to 200 ms of interval. It happens because in the latter case, the CPU will have a longer time between each MainTask cycle to perform the tasks with lower priority. It also has to be taken into account the number of cycles that the device, slave or server takes to respond to a request. To process and transmit a response, a MODBUS RTU Slave will takes two cycles (cycle time of the MODBUS task), where as a MODBUS Ethernet Server task takes only one cycle. But this is the minimum time between receipt of a request and the reply. If the request is sent immediately after the execution of a task MODBUS cycle time may be equal to 2 or 3 times the cycle time for the MODBUS slave and from 1 to 2 times the cycle time for the MODBUS server. In this case: Maximum Response Time = 3 * (cycle time) + (time of execution of the tasks) + (time interframe chars) + (send delay). For example, for a MODBUS Ethernet Server task with a cycle of 50 ms, an application that runs for 60 ms every 100 ms, the server is able to run only one cycle between each cycle of the application. On the other hand, using the same application, running for 60 ms, but with an interval of 500 ms, the MODBUS performs better, because while the application is not running, it will be running every 50 ms and only each cycle of MainTask it will take longer to run. For these cases, the worst performance will be the sum of the Execution Time of the user application with the cycle time of the MODBUS task. For the master and client devices the operating principle is exactly the same, but taking into account the polling time of the MODBUS relation and not the cycle time of the MODBUS task. For these cases, the worst performance of a relationship will be performed after the polling time, along with the user application Execution Time. It is important to stress that the running MODBUS devices number also changes its performance. In an user application with Execution Time of 60 ms and interval of 100 ms, there are 40 ms left for the CPU to perform all tasks of lower priority. Therefore, a CPU with only one MODBUS Ethernet Server will have a higher performance than a CPU that uses four of these devices. 5.5.1.1. CPU's Local Interfaces For a device MODBUS Ethernet Server, we can assert that the device is capable to answer a x number of requisitions per second. Or, in other words, the Server is able to transfer n bytes per second, depending on the size of each requisition. As smaller is the cycle time of the MODBUS Server task, higher is the impact of the number of connections in his answer rate. However, for cycle times smaller than 20 ms this impact is not linear and the table below must be viewed for information. The table below exemplifies the number of requisitions that a MODBUS Server inserted in a local Ethernet interface is capable to answer, according to the cycle time configured for the MODBUS task and the number of active connections: Number of Active Connections 1 Connection 2 Connections 4 Connections 7 Connections 10 Connections Answered requisitions per second with the MODBUS task cycle at 5 ms 185 367 760 1354 1933 Answered requisitions per second with the MODBUS task cycle at 10 ms 99 197 395 695 976 Answered requisitions per second with the MODBUS task cycle at 20 ms 50 100 200 350 500 Table 136: Communication Rate of a MODBUS Server at Local Interface ATTENTION The communication performances mentioned in this section are just examples, using a CPU with only one device MODBUS TCP Server, with no logic to be executed inside the application that could delay the communication. Therefore, these performances must be taken as the maximum rates. 178 5. CONFIGURATION For cycle times equal or greater than 20 ms, the increase of the answer rate is linear, and may be calculated using an equation: N = C x (1 / T ) Where: N is the medium number of answers per second; C is the number of active connections; T is the MODBUS task interval in seconds. As an example a MODBUS Server, with only one active connection and a cycle time of 50 ms we get: C = 1; T = 0,05 s; N = 1 x (1 / (0,05)) N = 20 That is, in this configuration the MODBUS Server answers, on average, 20 requisitions per second. In case the obtained value is multiplied by the number of bytes in each requisition, we will obtain a transfer rate of n bytes per second. 5.5.1.2. Remote Interfaces The performance of a device MODBUS Server in one remote Ethernet interface is similar to the performance in the CPU's local interfaces. However, due to time of the communication between the CPU and the modules, the maximum performance is limited. For only one active connection, the number of answers is limited in the maximum of 18 answers per second. With more active connections, the number of answers will increase linearly, exactly like the local interfaces, however being limited at the maximum of 90 answers per second. So, for a remote Ethernet interface, we will have the following forms to calculate his performance: For T 55 ms is used: N = C x (18.18 (18.18 / (0.055 x 1000))) And for T 55 ms is used: N = C x (Z (Z / (T x 1000))) Where N is the medium number of answers per second, C is the number of active connections and T is equal to the cycle time of the MODBUS task (in seconds). The user must pay attention to the fact that the maximum performance of a device MODBUS Server in one remote Ethernet interface is 90 answers of requisitions per second. 5.5.2. OPC UA Server The NAP165 application note analyzes the performance of OPC UA communication in greater detail, including addressing the consumption of Ethernet communication bandwidth. This application note also discusses concepts about the operation of the OPC UA protocol. 5.5.3. IEC 60870-5-104 Server The IEC 60870-5-104 Server driver is executed by the CPU in the same way as the other communication drivers Servers, that is, in the background, with a priority below the user application and cyclically. The task of this The driver specifically executes every 50 ms, and 1 driver execution cycle is enough to process and respond to requests. However, as it is a low priority task, it is not guaranteed to be able to run at this frequency because depends on the percentage of free CPU (difference between the MainTask interval and the time that the user application takes to be executed) and also concurrency with tasks from other protocols configured in the CPU. To help in the comprehension of the driver IEC 60870-5-104 Server performance are presented the result of some test done with an IEC 60870-5-104 Client simulator, connected to a NX3030 running an IEC 60870-5-104 Server. The configured data base was compose of 900 digital points and 100 analog points (all with quality and time stamp), and the MainTask was using 70 ms (of the 100 ms interval). Time to complete a general interrogation command: less than one second Time to transfer 900 digital events + 100 analog events: 6 seconds 179 5. CONFIGURATION 5.6. System Performance In cases where the application has only one MainTask user task responsible for the execution of a single Program type programming unit called MainPrg (as in Single Profile), the PLC consumes a certain amount of time for the task to be processed. At that time we call it as Execution Time. In an application the average application Execution Time can be known using the MasterTool IEC XE in the Device item of its Devices Tree as follows: PLC Logic-> Application-> Task Configuration in the Monitor tab, Average Cycle Time column. The user must pay attention to the Cycle Time so that it does not exceed 80% of the interval set in the MainTask user task. For example, in an application where the interval is 100 ms, an appropriate Cycle Time is up to 80 ms. This is due to the fact that the CPU needs time to perform other tasks such as communication processing, processing of the display and memory card, and these tasks take place within the range (the remaining 20% of Cycle Time). ATTENTION For very high cycle times (typically higher than 300 ms), even that the value of 80% is respected, it may occur a reduction in the display response time and of the diagnostics key. In case the 80 percentage is not respected and the running time of the user task is closer or exceeds the interval set for the MainTask, the screen and the diagnosis button cannot respond once its priority in the system running is lower than the user tasks. In case an application with errors is loaded in the CPU, it may be necessary to restart it without loading this application as shown in the System Log section. ATTENTION The CPU's system logs of the Nexto Series, starting from firmware version 1.4.0.33 now reloaded in case of a CPU reset or a reboot of the Runtime System, that is, you can view the older logs when one of these conditions occurs. 5.6.1. I/O Scan Time For a project that uses digital I/O modules, being them inserted into the bus and declared in the project, the MainTask time will increase according to the number of modules. The table below illustrates the average time that is added to the MainTask: Declared Modules in the Bus 5 10 20 Added Time in the MainTask Cycle Time (µs) 300 700 1000 Table 137: I/O Scanning Time In projects that use remote I/Os, for example, using the NX5001 PROFIBUS-DP Master module, the manual of the respective module has to be consulted for information about performance and influences of the module in the execution of user tasks. 5.7. RTC Clock Nexto Series CPUs have an internal clock that can be used through the NextoStandard.lib library. This library is automatically loaded during the creation of a new project (to perform the library insertion procedure, see Libraries section). The figure below shows how to include the blocks in the project: 180 5. CONFIGURATION Figure 106: Clock Reading and Writing Blocks ATTENTION Function blocks of RTC Reading and Writing, previously available in 2.00 MasterTool IEC XE or older become obsolete from 2.00 or newer, the following blocks are no longer used: NextoGetDateAndTime, NextoGetDateAndTimeMs, NextoGetTimeZone, NextoSetDateAndTime, NextoSetDateAndTimeMs and NextoSetTimeZone. 5.7.1. Function Blocks for RTC Reading and Writing Among other function blocks, there are some very important used for clock reading (GetDateAndTime, GetDayOfWeek and GetTimeZone) and for date and time new data configuring (SetDateAndTime and SetTimeZone). These functions always use the local time, that is, take into account the value defined by the Time Zone. The proceedings to configure these two blocks are described below. 5.7.1.1. Function Blocks for RTC Reading The clock reading can be made through the following functions: 5.7.1.1.1. GetDateAndTime Figure 107: Date and Hour Reading 181 5. CONFIGURATION Input Parameters DATEANDTIME Type EXTENDED_DATE _AND_TIME Description This variable returns the value of date and hour of RTC in the format shown at Table 147. Table 138: Input Parameters of GetDateAndTime Output Parameters GETDATEANDTIME Type RTC_STATUS Description Returns the function error state, see Table 149. Table 139: Output Parameters of GetDateAndTime Utilization example in ST language: PROGRAM UserPrg VAR Result : RTC_STATUS; DATEANDTIME : EXTENDED_DATE_AND_TIME; xEnable : BOOL; END_VAR -------------------------------------------------------------------------IF xEnable = TRUE THEN Result := GetDateAndTime(DATEANDTIME); xEnable := FALSE; END_IF 5.7.1.1.2. GetTimeZone The following function reads the Time Zone configuration, this function is directly related with time in Time Zone at SNTP synchronism service: Figure 108: Configuration Reading of Time Zone Input Parameters TIMEZONE Type TIMEZONESETTINGS Description This variable presents the reading of Time Zone configuration. Table 140: Input Parameters of GetTimeZone 182 5. CONFIGURATION Output Parameters GetTimeZone Type RTC_STATUS Description Returns the function error state, see Table 149. Table 141: Output Parameters of GetTimeZone Utilization example in ST language: PROGRAM UserPrg VAR GetTimeZone_Status : RTC_STATUS; TimeZone : TIMEZONESETTINGS; xEnable : BOOL; END_VAR -------------------------------------------------------------------------- IF xEnable = TRUE THEN GetTimeZone_Status := GetTimeZone(TimeZone); xEnable := FALSE; END_IF 5.7.1.1.3. GetDayOfWeek GetDayOfWeek function is used to read the day of the week. Figure 109: Day of Week Reading Output Parameters GetDayOfWeek Type DAYS_OF_WEEK Description Returns the day of the week. See Section 148. Table 142: Output Parameters of GetDayOfWeek When called, the function will read the day of the week and fill the structure DAYS_OF_WEEK. Utilization example in ST language: PROGRAM UserPrg VAR DayOfWeek : DAYS_OF_WEEK; END_VAR -------------------------------------------------------------------------DayOfWeek := GetDayOfWeek(); 183 5. CONFIGURATION 5.7.1.2. Function Blocks and Functions of RTC Writing and Configuration The clock settings are made through function and function blocks as follows: 5.7.1.2.1. SetDateAndTime SetDateAndTime function is used to write the settings on the clock. Typically the precision is on the order of hundreds of milliseconds. Figure 110: Set Date And Time Input parameters REQUEST DATEANDTIME Type BOOL EXTENDED_DATE _AND_TIME Description This variable, when receives a rising edge, enables the clock writing. Receives the values of date and hour with milliseconds. See section 147. Table 143: Input Parameters of SetDateAndTime Output parameters DONE EXEC ERROR STATUS Type BOOL BOOL BOOL RTC_CMD_STATUS Description This variable, when true, indicates that the action was successfully completed. This variable, when true, indicates that the function is processing the values. This variable, when true, indicates an error during the Writing. Returns the error occurred during the configuration. See Table 149. Table 144: Output Parameters of SetDateAndTime When a rising edge occurs at the REQUEST input, the function block will write the new DATEANDTIME values on the clock. If the writing is successfully done, the DONE output will be equal to TRUE. Otherwise, the ERROR output will be equal to TRUE and the error will appear in the STATUS variable. Utilization example in ST language: PROGRAM UserPrg VAR SetDateAndTime : SetDateAndTime; xRequest : BOOL; DateAndTime : EXTENDED_DATE_AND_TIME; xDone : BOOL; 184 5. CONFIGURATION xExec : BOOL; xError : BOOL; xStatus : RTC_STATUS; END_VAR -------------------------------------------------------------------------IF xRequest THEN SetDateAndTime.REQUEST:=TRUE; SetDateAndTime.DATEANDTIME:=DateAndTime; xRequest:= FALSE; END_IF SetDateAndTime(); SetDateAndTime.REQUEST:=FALSE; IF SetDateAndTime.DONE THEN xExec:=SetDateAndTime.EXEC; xError:=SetDateAndTime.ERROR; xStatus:=SetDateAndTime.STATUS; END_IF ATTENTION If you try to write time values outside the range of the RTC, the values are converted to valid values, provided they do not exceed the valid range of 01/01/2000 to 12/31/2035. For example, if the user attempts to write the value 2000 ms, it will be converted to 2 seconds, write the value 100 seconds, it will be converted to 1 min and 40 seconds. If the type value of 30 hours, it is converted to 1 day and 6 hours, and so on. 5.7.1.2.2. SetTimeZone The following function block makes the writing of the time zone settings: Figure 111: Writing of the Time zone Settings Input parameters TIMEZONE Type TIMEZONESETTINGS Description Structure with time zone to be configured. See Table 150. Table 145: SetTimeZone Input Parameters Output parameters SetTimeZone Type RTC_STATUS Description Returns the error occurred during the reading/setting. See Table 149. Table 146: SetTimeZone Output Parameters When called, the function will configure the TIMEZONE with the new system time zone configuration. The configuration results is returned by the function. 185 5. CONFIGURATION Utilization example in ST language: PROGRAM UserPrg VAR Status : RTC_STATUS; TimeZone : TIMEZONESETTINGS; xWrite : BOOL; END_VAR -------------------------------------------------------------------------//FB SetTimeZone IF (xWrite = TRUE) THEN Status := SetTimeZone(TimeZone); IF Status = RTC_STATUS.NO_ERROR THEN xWrite := FALSE; END_IF END_IF ATTENTION To perform the clock should be used time and date values within the following valid range: 00:00:00 hours of 01/01/2000 to 12/31/2035 23:59:59 hours, otherwise , is reported an error through the STATUS output parameter. For details of the STATUS output parameter, see the section RTC_STATUS. 5.7.2. RTC Data Structures The reading and setting function blocks of the Nexto Series CPUs RTC use the following data structures in its configuration: 5.7.2.1. EXTENDED_DATE_AND_TIME This structure is used to store the RTC date when used the function blocks for date reading/setting within milliseconds of accuracy. It is described in the table below: Structure Type BYTE BYTE WORD EXTENDED_DATE_ BYTE AND_TIME BYTE BYTE WORD Variable byDayOfMonth ByMonth wYear byHours byMinutes bySeconds wMilliseconds Description Stores the day of the set date. Stores the month of the set date. Stores the year of the set date. Stores the hour of the set date. Stores the minutes of the set date. Stores the seconds of the set date. Stores the milliseconds of the set date. Table 147: EXTENDED_DATE_AND_TIME 186 5. CONFIGURATION 5.7.2.2. DAYS_OF_WEEK This structure is used to store the day of week: Enumerable Value 0 1 2 DAYS_OF_WEEK 3 4 5 6 7 Description INVALID_DAY SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY Table 148: DAYS_OF_WEEK Structure 5.7.2.3. RTC_STATUS This enumerator is used to return the type of error in the RTC setting or reading and it is described in the table below: Enumerator RTC_STATUS Value NO_ERROR (0) UNKNOWN_COMMAND (1) DEVICE_BUSY (2) DEVICE_ERROR (3) ERROR_READING_OSF (4) ERROR_READING_RTC (5) ERROR_WRITING_RTC (6) ERROR_UPDATING_SYSTEM _TIME (7) INTERNAL_ERROR (8) INVALID_TIME (9) INPUT_OUT_OF_RANGE (10) SNTP_NOT_ENABLE (11) Description There is no error. Unknown command. Device is busy. Device with error. Error in the reading of the valid date and hour flag. Error in the date and hour reading. Error in the date and hour writing. Error in the update of the system's date and hour. Internal error. Invalid date and hour. Out of the limit of valid date and hour for the system. Error generated when the SNTP service is not enabled and it is done an attempt for modifying the time zone. Table 149: RTC_STATUS 5.7.2.4. TIMEZONESETTINGS This structure is used to store the time zone value in the reading/setting requests of the RTC's function blocks and it is described in table below: Structure Type TIMEZONESETTINGS INT INT Variable iHour iMinutes Description Set time zone hour. Set time zone minute. Table 150: TIMEZONESETTINGS 187 5. CONFIGURATION Note: Function Blocks of Writing and Reading of Date and Hour: different libraries of NextoStandard, which have function blocks or functions that may perform access of reading and writing of date and hour in the system, are not indicated. The NextoStandard library has the appropriate interfaces for writing and reading the system's date and hour accordingly and for informing the correct diagnostics. 5.8. User Files Memory Nexto Series CPUs have a memory area destined to the general data storage, in other words, the user can store several project files of any format in the CPU memory. This memory area varies according to the CPU model used (check Memory section). In order to use this area, the user must access a project in the MasterTool IEC XE software and click on the Devices Tree, placed at the program left. Double click on the Device item and, after selecting the CPU in the Communication Settings tab which will be open, select the Files tab and click on Refresh, both in the computer files column (left) and in the CPU files column (right) as shown on figure below. Figure 112: User Files Access After updating the CPU column of files, the root directory of files stored in the CPU will be shown. Then it will be possible to select the folder where the files will be transferred to. The "InternalMemory" folder is a default folder to be used to store files in the CPU's internal memory, since it is not possible to transfer files to the root directory. If necessary, the user can create other folders in the root directory or subfolders inside the "InternalMemory" folder. In order to perform a file transfer from the microcomputer to the CPU just select the desired file in the left column and press the "»" key located in the center of the screen, as shown in figure below. The download time will vary depending on file size and cycle time (execution) of the current application of the CPU and may take several minutes. The user does not need to be in Run Mode or connected to the CPU to perform the transfers, since it has the ability to connect automatically when the user performs the transfer. 188 5. CONFIGURATION Figure 113: Files Transference ATTENTION The files contained in the folder of a project created by MasterTool IEC XE have special names reserved by the system in this way cannot be transferred through the Files tab. If the user wishes to transfer a project to the user memory, you must compact the folder and then download the compressed file (*.zip for example). In case it is necessary to transfer documents from the CPU to the PC in which the MasterTool IEC XE software is installed, the user must follow a very similar procedure to the previously described, as the file must be selected from the right column and the button "«" pressed, placed on the center of the screen. Furthermore, the user has some operation options in the storing files area, which are the following: New directory : allows the creation of a new folder in the user memory area. Delete item : allows the files excluding in the folders in the user memory area. Refresh : allows the file updating, on the MasterTool IEC XE screen, of the files in the user memory area and in the computer. Figure 114: Utilization Options ATTENTION For a CPU in Stop Mode or with no application, the transfer rate to the internal memory is approximately 150 Kbytes/s. 189 5. CONFIGURATION 5.9. CPU's Informative and Configuration Menu The access to the Informative Menu, the Nexto CPU Configuration and the detailed diagnostics, are available through levels and to access the menu information, change level and modify any configuration, a long touch is required on the diagnostic button and to navigate through the items on the same level, a short touch on the diagnostic button is required. See One Touch Diag section to verify the functioning and the difference between the diagnostics button touch types. The table below shows the menu levels and each screen type available in the CPUs, if they are informative, configurable or to return a level. Level 1 HARDWARE LANGUAGES NETWORK SOFTWARE BACK Level 2 TEMPERATURE CONTRAST DATE AND TIME BACK ENGLISH PORTUGUES ESPANOL BACK NET 1 IP ADDR. NET 1 MASK BACK FIRMWARE BOOTLOADER AUX. PROC. BACK - Level 3 CONTRAST LEVEL >ENGLISH >PORTUGUES >ESPANOL - - - Type Informative Configurable Informative Return level Configurable Configurable Configurable Return level Informative Informative Return level Informative Informative Informative Return level Return level Table 151: CPU Menu Levels As shown on Table 151, between the available options to visualize and modify are the main data necessary to user, as: Information about the hardware resources: · TEMPERATURE CPU Internal temperature (Ex.: 36 C 97 F) · CONTRAST Contrast setting of the CPU frontal display · DATE AND TIME Date and time set in the CPU (Ex.: 2001.01.31 00:00) Changing the menu language on the CPU: · PORTUGUES Changes the language to Portuguese · ENGLISH Changes the language to English · ESPANOL Changes the language to Spanish Visualization of information about the network set in the device: · NET 1 IP ADDR. Address (Ex.: 192.168.0.1) · NET 1 MASK Subnet mask (Ex.: 255.255.255.0) Information about the software versions: · FIRMWARE CPU software version (Ex.: 1.0.0.0) · BOOTLOADER CPU bootloader version (Ex.: 1.0.0.0) · AUX. PROC. CPU auxiliary processor version (Ex.: 1.0.0.0) 190 5. CONFIGURATION The figure below describes an example of how to operate the Nexto CPUs menu through the contrast adjust menu procedure from the Statusscreen. Besides to make the configuration easy, it is possible to identify all screen levels and the touch type to navigate through them, and to modify other parameters as Language and the Memory Card, using the same access logic. The short touch shows the contrast is being incremented (clearer) and in the next touch after its maximum value, it returns to the minimum value (less clear). The long touch shows the confirmation of the desired contrast and its return to the previous level. Figure 115: Contrast Adjust Besides the possibility of the Nexto CPUs menu to be closed through a long touch on the screen diagnostic button BACK from level 1, there are also other output conditions that are described below: Short touch, at any moment, in the other modules existent on the bus, make the CPU disconnect from the menu and show the desired module diagnostic. Idle time, at any level, superior to 5 s. 5.10. Function Blocks and Functions 5.10.1. Special Function Blocks for Serial Interfaces The special function blocks for serial interfaces make possible the local access (COM 1 AND COM 2) and also access to remote serial ports (expansion modules). Therefore, the user can create his own protocols and handle the serial ports as he wishes, following the IEC 61131-3 languages available in the MasterTool IEC XE software. The blocks are available inside the NextoSerial library which must be added to the project so it's possible to use them (to execute the library insertion procedure, see MasterTool IEC XE Programming Manual MP399609, section Library). The special function blocks for serial interfaces can take several cycles (consecutive calls) to complete the task execution. Sometimes a block can be completed in a single cycle, but in the general case, needs several cycles. The task execution associated to a block can have many steps which some depend on external events, that can be significantly delayed. The function block cannot implement routines to occupy the time while waits for these events, because it would make the CPU busy. The solution could be the creation of blocking function blocks, but this is not advisable because it would increase the user application complexity, as normally, the multitask programming is not available. Therefore, when an external event is waited, the serial function blocks are finished and the control is returned to the main program. The task treatment continues in the next cycle, in other words, on the next time the block is called. Before describing the special function blocks for serial interfaces, it is important to know the Data types, it means, the data type used by the blocks. 191 5. CONFIGURATION Data type SERIAL_BAUDRATE SERIAL_DATABITS SERIAL_HANDSHAKE SERIAL_MODE Options Description BAUD200 Lists all baud rate possibilities (bits per second) BAUD300 BAUD600 BAUD1200 BAUD1800 BAUD2400 BAUD4800 BAUD9600 BAUD19200 BAUD38400 BAUD57600 BAUD115200 DATABITS_5 Lists all data bits possibilities. DATABITS_6 DATABITS_7 DATABITS_8 Defines all modem signal possibilities for the configurations: Controls the Nexto CPU RS-232C port. The transmitter is enabled to start the transmission and dis- RS232_RTS abled as soon as possible after the transmission is finished. For exam- ple, can be used to control a RS- 232/RS-485 external converter. Controls the RS-232C port of the RS232_RTS_OFF Nexto CPU. The RTS signal is al- ways off. Controls the RS-232C port of the RS232_RTS_ON Nexto CPU. The RTS signal is al- ways on. Controls the RS-232C port of the Nexto CPU. In case the CTS is dis- abled, the RTS is enabled. Then waits for the CTS to be enabled RS232_RTS_CTS to get the transmission and RTS restarts as soon as possible, at the end of transmission. Ex: Control- ling radio modems with the same modem signal. Controls the RS-232C port of the RS232_MANUAL Nexto CPU. The user is responsible to control all the signals (RTS, DTR, CTS, DSR, DCD). NORMAL_MODE Serial Communication Normal Operation mode. Serial Communication Extended EXTENDED_MODE Operation mode in which are provided information about the re- ceived data frame. Defines all configuration parameters of the serial port: BAUDRATE Defined in SERIAL_BAUDRATE. 192 5. CONFIGURATION Data type SERIAL_PARAMETERS SERIAL_PARITY SERIAL_PORT SERIAL_RX_CHAR_ EXTENDED Options Description DATABITS Defined in SERIAL_DATABITS. STOPBITS Defined in SERIAL_STOPBITS. PARITY Defined in SERIAL_PARITY. HANDSHAKE Defined in SE- RIAL_HANDSHAKE. Byte quantity which must be re- ceived to generate a new UART in- terruption. Lower values make the TIMESTAMP more precise when UART_RX_THRESHOLD the EXTENDED MODE is used and minimizes the overrun errors. However, values too low may cause too many interruptions and delay the CPU. MODE Defined in SERIAL_MODE. When true, all the received byte during the transmission will be dis- ENABLE_RX_ON_TX charged instead going to the RX line. Used to disable the full-duplex operation in the RS-422 interface. ENABLE_DCD_EVENT When true, generates an external event when the DCD is modified. ENABLE_CTS_EVENT When true, generates an external event when the CTS is modified. PARITY_NONE List all parity possibilities. PARITY_ODD PARITY_EVEN PARITY_MARK PARITY_SPACE List all available serial ports (COM 10, COM 11, COM 12, COM 13, COM 1 COM 14, COM 15, COM 16, COM 17, COM 18 and COM 19 expan- sion modules). COM 2 Defines a character in the RX queue in extended mode. RX_CHAR Data byte. RX_ERROR Error code. RX_TIMESTAMP Silence due to the previous character or due to another event which has happen before this character (serial port configuration, transmission ending). It has some fields which deliver information regarding RX queue status/error, used when the normal format is utilized (no error and timestamp information): RX_FRAMING_ERRORS Frame errors counter: character incorrect formation no stop bit, incorrect baud rate, among other since the serial port configuration. Returns to zero when it reaches the maximum value (65535). 193 5. CONFIGURATION Data type SERIAL_RX_QUEUE_ STATUS Options Description Parity errors counter, since the se- RX_PARITY_ERRORS rial port configuration. Returns to zero when it reaches the maximum value (65535). Interruption errors counter, since the serial port configuration, in RX_BREAK_ERRORS other words, active line higher than the character time. Returns to zero when it reaches the maximum value (65535). FIFO RX overrun errors counter, since the serial port configuration, RX_FIFO_OVERRUN_ in other words, error in the FIFO ERRORS RX configured threshold. Returns to zero when it reaches the maxi- mum value (65535). RX queue overrun errors counter, in other words, the maximum charac- RX_QUEUE_OVERRUN_ ters number (1024) was overflowed ERRORS and the data are being overwritten. Returns to zero when it reaches the maximum value (65535). Sum the last 5 error counters RX_ANY_ERRORS (frame, parity, interruption, RX FIFO overrun, RX queue overrun). RX_REMAINING Number of characters in the RX queue. List of critic error codes that can be returned by the serial func- tion block. Each block returns specific errors, which will be de- scribed below: NO_ERROR No errors. Return the parameters with invalid values or out of range: - SERIAL_PORT ILLEGAL_* - SERIAL_MODE - BAUDRATE - DATA_BITS - PARITY - STOP_BITS - HANDSHAKE - UART_RX_THRESHOLD - TIMEOUT - TX_BUFF_LENGTH - HANDSHAKE_METHOD - RX_BUFF_LENGTH PORT_BUSY Indicates the serial port is being used by another instance HW_ERROR_UART Hardware error detected in the UART. HW_ERROR_REMOTE Hardware error at communicating with the remote serial port. 194 5. CONFIGURATION Data type SERIAL_STATUS SERIAL_STOPBITS Options Description Time-out while waiting for the CTS CTS_TIMEOUT_ON enabling, in the RS-232 RTS/CTS handshake, in the SERIAL_TX block. Time-out while waiting for the CTS CTS_TIMEOUT_OFF disabling, in the RS-232 RTS/CTS handshake, in the SERIAL_TX block. Time-out while waiting for the TX_TIMEOUT_ERROR transmission ending in the SE- RIAL_TX. Time-out while waiting for all char- RX_TIMEOUT_ERROR acters in the SERIAL_RX block or the SERIAL_RX_EXTENDED block. FB_SET_CTRL_ NOT_ALLOWED The SET_CTRL block can't be used in case the handshake is different from RS232_MANUAL. FB_GET_CTRL_ NOT_ALLOWED The GET_CTRL block can't be used in case the handshake is different from RS232_MANUAL. FB_SERIAL_RX_ The SERIAL_RX isn't available for NOT_ALLOWED the RX queue, extended mode. FB_SERIAL_RX_ EXTENDED_NOT_ALLOWED The SERIAL_RX_EXTENDED isn't available for the RX queue, normal mode. DCD_INTERRUPT_ NOT_ALLOWED The interruption by the DCD signal can't be enabled in case the serial port doesn't have the respective pin. The interruption by the CTS sig- nal can't be enabled in case CTS_INTERRUPT_ the handshake is different from NOT_ALLOWED RS232_MANUAL or in case the serial port doesn't have the respec- tive pin. The interruption by the DSR signal DSR_INTERRUPT_ NOT_ALLOWED can't be enabled in case the serial port doesn't have the respective pin. (Nexto CPUs don't have this signal in local ports) NOT_CONFIGURED The function block can't be used before the serial port configuration. INTERNAL_ERROR Indicates that an internal problem has ocurred in the serial port. STOPBITS_1 List all Stop Bits possibilities. STOPBITS_2 STOPBITS_1_5 Table 152: Serial Function Blocks Data types 195 5. CONFIGURATION 5.10.1.1. SERIAL_CFG This function block is used to configure and initialize the desired serial port. After the block is called, every RX and TX queue associated to the serial ports and the RX and TX FIFO are restarted. Figure 116: Serial Configuration Block Input parameters REQUEST PORT PARAMETERS Type Description BOOL This variable, when true, enables the function block use. SERIAL_PORT Select the serial port, as described in the SERIAL_PORT data type. This structure defines the serial port conSERIAL_PARAMETERS figuration parameters, as described in the SERIAL_PARAMETERS data type. Table 153: SERIAL_CFG Input Parameters 196 5. CONFIGURATION Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - ILLEGAL_SERIAL_MODE - ILLEGAL_BAUDRATE - ILLEGAL_DATA_BITS - ILLEGAL_PARITY - ILLEGAL_STOP_BITS - ILLEGAL_HANDSHAKE - ILLEGAL_UART_RX_THRESHOLD - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - DCD_INTERRUPT_NOT_ALLOWED - CTS_INTERRUPT_NOT_ALLOWED - DSR_INTERRUPT_NOT_ALLOWED Table 154: SERIAL_CFG Output Parameters Utilization example in ST language, after the library Nexto Serial is inserted in the project: PROGRAM UserPrg VAR Config: SERIAL_CFG; Port: SERIAL_PORT := COM1; Parameters: SERIAL_PARAMETERS := (BAUDRATE := BAUD9600, DATABITS := DATABITS_8, STOPBITS := STOPBITS_1, PARITY := PARITY_NONE, HANDSHAKE := RS232_RTS, UART_RX_THRESHOLD := 8, MODE :=NORMAL_MODE, ENABLE_RX_ON_TX := FALSE, ENABLE_DCD_EVENT := FALSE, ENABLE_CTS_EVENT := FALSE); Status: SERIAL_STATUS; END_VAR //INPUTS: Config.REQUEST := TRUE; Config.PORT := Port; 197 5. CONFIGURATION Config.PARAMETERS := Parameters; //FUNCTION: Config(); //OUTPUTS: Config.DONE; Config.EXEC; Config.ERROR; Status := Config.STATUS; //If it is necessary to treat the error. 5.10.1.2. SERIAL_GET_CFG The function block is used to capture the desired serial port configuration. Figure 117: Block to Capture the Serial Configuration Input parameters REQUEST Type BOOL PORT SERIAL_PORT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Table 155: SERIAL_GET_CFG Input Parameters Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. 198 5. CONFIGURATION Output parameters STATUS PARAMETERS Type SERIAL_STATUS SERIAL_PARAMETERS Description In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - NOT_CONFIGURED This structure receives the serial port configuration parameters, as described in the SERIAL_PARAMETERS data type. Table 156: SERIAL_GET_CFG Output Parameters Utilization example in ST language, after the library is inserted in the project: PROGRAM UserPrg VAR GetConfig: SERIAL_GET_CFG; Port: SERIAL_PORT := COM1; Parameters: SERIAL_PARAMETERS; Status: SERIAL_STATUS; END_VAR //INPUTS: GetConfig.REQUEST := TRUE; GetConfig.PORT := Port; //FUNCTION: GetConfig(); //OUTPUTS: GetConfig.DONE; GetConfig.EXEC; GetConfig.ERROR; Status := GetConfig.STATUS; //If it is necessary to treat the error. Parameters := GetConfig.PARAMETERS; //Receive the parameters of desired serial port. 5.10.1.3. SERIAL_GET_CTRL This function block is used to read the CTS, DSR and DCD control signals, in case they are available in the serial port. A false value will be returned when there are not control signals. 199 5. CONFIGURATION Figure 118: Block Used to Visualize the Control Signals Input parameters REQUEST Type BOOL PORT SERIAL_PORT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Table 157: SERIAL_GET_CTRL Input Parameters Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS CTS_VALUE DSR_VALUE DCD_VALUE BOOL BOOL BOOL Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - FB_GET_CTRL_NOT_ALLOWED - NOT_CONFIGURED Value read in the CTS control signal. Value read in the DSR control signal. Value read in the DCD control signal. Table 158: SERIAL_GET_CTRL Output Parameters 200 5. CONFIGURATION Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Get_Control: SERIAL_GET_CTRL; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //INPUTS: Get_Control.REQUEST := TRUE; Get_Control.PORT := Port; //FUNCTION: Get_Control(); //OUTPUTS: Get_Control.DONE; Get_Control.EXEC; Get_Control.ERROR; Status := Get_Control.STATUS; Get_Control.CTS_VALUE; Get_Control.DSR_VALUE; Get_Control.DCD_VALUE; //If it is necessary to treat the error. 5.10.1.4. SERIAL_GET_RX_QUEUE_STATUS This block is used to read some status information regarding the RX queue, specially developed for the normal mode, but it can also be used in the extended mode. Figure 119: Block Used to Visualize the RX Queue Status Input parameters REQUEST Type BOOL PORT SERIAL_PORT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Table 159: SERIAL_GET_RX_QUEUE_STATUS Input Parameters Output parameters Type DONE BOOL EXEC BOOL Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. 201 5. CONFIGURATION Output parameters Type ERROR BOOL STATUS SERIAL_STATUS RXQ_STATUS SERIAL_RX_ QUEUE_STATUS Description This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - NOT_CONFIGURED Returns the RX queue status/er- ror, as described in the SE- RIAL_RX_QUEUE_STATUS data type. Table 160: SERIAL_GET_RX_QUEUE_STATUS Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Get_Status: SERIAL_GET_RX_QUEUE_STATUS; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; Status_RX: SERIAL_RX_QUEUE_STATUS; END_VAR //INPUTS: Get_Status.REQUEST := TRUE; Get_Status.PORT := Port; //FUNCTION: Get_Status(); //OUTPUTS: Get_Status.DONE; Get_Status.EXEC; Get_Status.ERROR; Status := Get_Status.STATUS; //If it is necessary to treat the error. Status_RX := Get_Status.RXQ_STATUS; //If it is necessary to treat the error of the RX. 5.10.1.5. SERIAL_PURGE_RX_QUEUE This function block is used to clean the serial port RX queue, local and remote. The UART RX FIFO is restarted too. 202 5. CONFIGURATION Figure 120: Block Used to Clean the RX Queue Input parameters REQUEST Type BOOL PORT SERIAL_PORT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Table 161: SERIAL_PURGE_RX_QUEUE Input Parameters Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS Description This variable is true when the block is completely executed. It's false otherwise. This variable is true while the block is being executed. It's false otherwise. This variable is true when the block concludes the execution with an error. It's false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - NOT_CONFIGURED Table 162: SERIAL_PURGE_RX_QUEUE Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Purge_Queue: SERIAL_PURGE_RX_QUEUE; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //INPUTS: Purge_Queue.REQUEST := TRUE; Purge_Queue.PORT := Port; //FUNCTION: 203 5. CONFIGURATION Purge_Queue(); //OUTPUTS: Purge_Queue.DONE; Purge_Queue.EXEC; Purge_Queue.ERROR; Status := Purge_Queue.STATUS; //If it is necessary to treat the error. 5.10.1.6. SERIAL_RX This function block is used to receive a serial port buffer, using the RX queue normal mode. In this mode, each character in the RX queue occupy a single byte which has the received data, storing 5, 6, 7 or 8 bits, according to the serial interface configuration. Figure 121: Block Used to Read the Reception Buffer Values Input parameters REQUEST Type BOOL PORT RX_BUFFER_ POINTER SERIAL_PORT POINTER TO BYTE RX_BUFFER_ LENGTH UINT RX_TIMEOUT UINT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Pointer of a byte array to receive the buffer values. Specify the expected character number in the byte array. In case more than the expected bytes are available, only the expected quantity will be read from the byte array, the rest will be leaved in the RX queue (maximum size equal to 1024 characters). Specify the time-out to receive the expected character quantity. In case it is smaller than the necessary to receive the characters, the RX_TIME-OUT_ERROR output from the STATUS parameter will be indicated. When the specified value, in ms, is equal to zero, the function will return the data within the buffer. Table 163: SERIAL_RX Input Parameters 204 5. CONFIGURATION Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS RX_RECEIVED UINT RX_REMAINING UINT Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - ILLEGAL_RX_BUFF_LENGTH - RX_TIMEOUT_ERROR - FB_SERIAL_RX_NOT_ALLOWED - NOT_CONFIGURED Returns the received characters number. This number can be within zero and the configured value in RX_BUFFER_LENGTH. In case it is smaller, an error will be indicated by the function block. Returns the number of characters which are still in the RX queue after the function block execution. Table 164: SERIAL_RX Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Receive: SERIAL_RX; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..1023] OF BYTE; //Max size. Status: SERIAL_STATUS; END_VAR //INPUTS: Receive.REQUEST := TRUE; Receive.PORT := Port; Receive.RX_BUFFER_POINTER := ADR(Buffer_Pointer); Receive.RX_BUFFER_LENGTH := 1024; //Max size. Receive.RX_TIMEOUT := 10000; //FUNCTION: Receive(); //OUTPUTS: 205 5. CONFIGURATION Receive.DONE; Receive.EXEC; Receive.ERROR; Status := Receive.STATUS; Receive.RX_RECEIVED; Receive.RX_REMAINING; //If it is necessary to treat the error. 5.10.1.7. SERIAL_RX_EXTENDED This function block is used to receive a serial port buffer using the RX queue extended mode as shown in the Serial Interfaces Configuration section. Figure 122: Block Used for Reception Buffer Reading Input parameters REQUEST PORT RX_BUFFER_ POINTER RX_BUFFER_ LENGTH RX_TIMEOUT Type BOOL SERIAL_PORT POINTER TO RIAL_RX_CHAR _EXTENDED UINT UINT Description This variable, when true, enables the func- tion block use. Select the serial port, as described in the SERIAL_PORT data type. SE- Pointer of a SE- RIAL_RX_CHAR_EXTENDED array to receive the buffer values. Specify the expected character number in the SERIAL_RX_CHAR_EXTENDED array. In case more than the expected bytes are available, only the expected quantity will be read from the byte array, the rest will be leaved in the RX queue (maximum size equal to 1024 characters). Specify the time-out to receive the expected character quantity. In case it is smaller than the necessary to receive the characters, the RX_TIMEOUT_ERROR output from the STATUS parameter will be indicated. When the specified value, in ms, is equal to zero, the function will return the data within the buffer. Table 165: SERIAL_RX_EXTENDED Input Parameters 206 5. CONFIGURATION Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS RX_RECEIVED UINT RX_REMAINING UINT RX_SILENCE UINT Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - ILLEGAL_RX_BUFF_LENGTH - RX_TIMEOUT_ERROR - FB_SERIAL_RX_EXTENDED_NOT _ALLOWED - NOT_CONFIGURED Returns the received characters number. This number can be within zero and the configured value in RX_BUFFER_LENGTH. In case it is smaller, an error will be indicated by the function block. Returns the number of characters which are still in the RX queue after the function block execution. Returns the silence time in the RX queue, measured since the last received character is finished. The time unit is 10 µs. This output parameter type is important to detect the silence time in protocols as MODBUS RTU. It might not be the silence time after the last received character by this function block, as it is only true if RX_REMAINING = 0. Table 166: SERIAL_RX_EXTENDED Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Receive_Ex: SERIAL_RX_EXTENDED; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..1023] OF SERIAL_RX_CHAR_EXTENDED; Status: SERIAL_STATUS; 207 5. CONFIGURATION END_VAR //INPUTS: Receive_Ex.REQUEST := TRUE; Receive_Ex.PORT := Port; Receive_Ex.RX_BUFFER_POINTER := ADR(Buffer_Pointer); Receive_Ex.RX_BUFFER_LENGTH := 1024; //Max size. Receive_Ex.RX_TIMEOUT := 10000; //FUNCTION: Receive_Ex(); //OUTPUTS: Receive_Ex.DONE; Receive_Ex.EXEC; Receive_Ex.ERROR; Status := Receive_Ex.STATUS; //If it is necessary to treat the error. Receive_Ex.RX_RECEIVED; Receive_Ex.RX_REMAINING; Receive_Ex.RX_SILENCE; 5.10.1.8. SERIAL_SET_CTRL This block is used to write on the control signals (RTS and DTR), when they are available in the serial port. It can also set a busy condition for the transmission, through BREAK parameter and it can only be used if the modem signal is configured for RS232_MANUAL. Figure 123: Block for Control Signals Writing 208 5. CONFIGURATION Input parameters REQUEST Type BOOL PORT RTS_VALUE RTS_EN DTR_VALUE DTR_EN SERIAL_PORT BOOL BOOL BOOL BOOL BREAK BOOL Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Value to be written on RTS signal. Enables the RTS_VALUE parameter writing. Value to be written on DTR signal. Enables the DTR_VALUE parameter writing. In case it's true, enables logic 0 (busy) in the transmission line. Table 167: SERIAL_SET_CTRL Input Parameters Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - FB_SET_CTRL_NOT_ALLOWED - NOT_CONFIGURED Table 168: SERIAL_SET_CTRL Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Set_Control: SERIAL_SET_CTRL; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //INPUTS: Set_Control.REQUEST := TRUE; 209 5. CONFIGURATION Set_Control.PORT := Port; Set_Control.RTS_VALUE := FALSE; Set_Control.RTS_EN := FALSE; Set_Control.DTR_VALUE := FALSE; Set_Control.DTR_EN := FALSE; Set_Control.BREAK := FALSE; //FUNCTION: Set_Control(); //OUTPUTS: Set_Control.DONE; Set_Control.EXEC; Set_Control.ERROR; Status := Set_Control.STATUS; //If it is necessary to treat the error. 5.10.1.9. SERIAL_TX This function block is used to transmit a data buffer through serial port and it is only finalized after all bytes were transmitted or after time-out (generating errors). Figure 124: Block for Values Transmission by the Serial Input parameters REQUEST Type BOOL PORT TX_BUFFER_ POINTER TX_BUFFER_ LENGTH SERIAL_PORT POINTER TO BYTE UINT TX_TIMEOUT UINT DELAY_BEFORE_ TX UINT Description This variable, when true, enables the function block use. Select the serial port, as described in the SERIAL_PORT data type. Pointer of a byte array to transmit the buffer values. Specify the expected character number in the byte array to be transmitted (TX queue maximum size is 1024 characters). Specify the time-out to complete the transmission including the handshake phase. The specified value, in ms, must be positive and different than zero. Specify the delay, in ms, between the function block call and the transmission beginning. This variable can be used in communications with some modems. 210 5. CONFIGURATION Input parameters Type CLEAR_RX_ BEFORE_TX BOOL Description When true, the RX queue and the UART FIFO RX are erased before the transmission beginning. This behavior is typical in half-duplex master/slave protocols. Table 169: SERIAL_TX Input Parameters Output parameters Type DONE BOOL EXEC BOOL ERROR BOOL STATUS SERIAL_STATUS TX_TRANSMITTED UINT Description This variable is true when the block is completely executed. It is false otherwise. This variable is true while the block is being executed. It is false otherwise. This variable is true when the block concludes the execution with an error. It is false otherwise. It is connected to the variable DONE, as its status is showed after the block conclusion. In case the ERROR variable is true, the STATUS structure will show the error found during the block execution. The possible states, already described in the SERIAL_STATUS data type, are: - NO_ERROR - ILLEGAL_SERIAL_PORT - PORT_BUSY - HW_ERROR_UART - HW_ERROR_REMOTE - ILLEGAL_TX_BUFF_LENGTH - ILLEGAL_TIMEOUT - CTS_TIMEOUT_ON - CTS_TIMEOUT_OFF - TX_TIMEOUT_ERROR - NOT_CONFIGURED Returns the transmitted byte number which must be equal to TX_BUFFER_LENGTH, but can be smaller in case some error has occurred during transmission. Table 170: SERIAL_TX Output Parameters Utilization example in ST language, after the library is inserted in the project and the serial port configured: PROGRAM UserPrg VAR Transmit: SERIAL_TX; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..9] OF BYTE := [0,1,2,3,4,5,6,7,8,9]; Status: SERIAL_STATUS; END_VAR //INPUTS: 211 5. CONFIGURATION Transmit.REQUEST := TRUE; Transmit.PORT := Port; Transmit.TX_BUFFER_POINTER := ADR(Buffer_Pointer); Transmit.TX_BUFFER_LENGTH := 10; Transmit.TX_TIMEOUT := 10000; Transmit.DELAY_BEFORE_TX := 1000; Transmit.CLEAR_RX_BEFORE_TX := TRUE; //FUNCTION: Transmit(); //OUTPUTS: Transmit.DONE; Transmit.EXEC; Transmit.ERROR; Status := Transmit.STATUS; //If it is necessary to treat the error. Transmit.TX_TRANSMITTED; 5.10.2. Inputs and Outputs Update By default, the local bus and CPU integrated I/O are updated on every execution cycle of MainTask. The Refresh functions allows to update these I/O points asynchronously at any point of user application code. When the function blocks to update the inputs and outputs are not used, the update is performed every cycle of the Main- Task. ATTENTION At the startup of a CPU of this series, the inputs and outputs are only updated for reading and prepared for writing when the MainTask is performed. All other system tasks that run before MainTask will be with the inputs and outputs invalid. 5.10.2.1. REFRESH_INPUT This function block is used to update the specified module inputs without the necessity to wait for the cycle to be completed. It is important to notice that the filters configured in the MasterTool IEC XE and the update time of the module inputs will have to be considered in effective time of the inputs update in the application developed by the user. ATTENTION The REFRESH_INPUT function must only be used in MainTask. To update inputs in other tasks, the option Enable I/O update per task must be selected, for further information about this option, consult Table 37. ATTENTION REFRESH_INPUT function does not support inputs that have been mapped to symbolic variables. For proper operation it is necessary that the input is mapped to a variable within the memory direct representation of input variables (%I). ATTENTION The REFRESH_INPUT function updates only the direct variables %I that are declared in the "Bus: I/O Mapping" tab of the module addressed in the respective rack/slot of the function. In the case of communication modules/interfaces (MODBUS, Profibus, etc.), the update does not include the direct variables of the device mappings. 212 5. CONFIGURATION Figure 125: Block for Input Updating Input parameters byRackNumber bySlotNumber Type BYTE BYTE Description Rack number. Position number where the module is connected. Table 171: REFRESH_INPUT Input Parameters Possible TYPE_RESULT: OK_SUCCESS: Execution success. ERROR_FAILED: This error is returned if the function is called for a module that has only outputs, or also if the option Always update variables (located in the module's configuration screen, tab I/O Mapping ) is not checked. ERROR_NOTSUPPORTED: The called routine is not supported by the product. ERROR_PARAMETER: Invalid / unsupported parameter. ERROR_MODULE_ABSENT: The module is absent in the bus. ERROR_MODULE_NOTCONFIGURED: The module is not configured in the application. ERROR_MODULE_NOTRUNNING: The module is not running (is not in operational state). ERROR_MODULE_COMMFAIL: Failure in the communication with the module. ERROR_MODULE_NOTFOUND: The module was not found in the application or is not supported. Utilization example in ST language: PROGRAM UserPrg VAR Info: TYPE_RESULT; byRackNumber: BYTE; bySlotNumber: BYTE; END_VAR //INPUTS: byRackNumber := 0; bySlotNumber := 10; //FUNCTION: Info := REFRESH_INPUT (byRackNumber, bySlotNumber); //Function call. //Variable "Info" receives possible function errors. 5.10.2.2. REFRESH_OUTPUT This function block is used to update the specified module outputs. It is not necessary to wait until the cycle is finished. It is important to notice that the update time of the module outputs will have to be considered in the effective time of the outputs update in the application developed by the user. ATTENTION The REFRESH_OUTPUT function must only be used in MainTask. To update outputs in other tasks, the option Enable I/O update per task must be selected, for further information about this option, consult Table 37. 213 5. CONFIGURATION ATTENTION REFRESH_OUTPUT function does not support inputs that have been mapped to symbolic variables. For proper operation it is necessary that the input is mapped to a variable within the memory direct representation of input variables (%Q). ATTENTION The REFRESH_OUTPUT function updates only the direct variables %Q that are declared in the "Bus: I/O Mapping" tab of the module addressed in the respective rack/slot of the function. In the case of communication modules/interfaces (MODBUS, Profibus, etc.), the update does not include the direct variables of the device mappings. Figure 126: Block for Output Updating Input parameters byRackNumber bySlotNumber Type BYTE BYTE Description Rack number. Position number where the module is connected. Table 172: REFRESH_OUTPUT Input Parameters Possible TYPE_RESULT: OK_SUCCESS: Execution success. ERROR_FAILED: This error is returned if the function is called for a module that has only inputs, or also if the option Always update variables (located in the module's configuration screen, tab I/O Mapping ) is not checked. ERROR_NOTSUPPORTED: The called routine is not supported by the product. ERROR_PARAMETER: Invalid / unsupported parameter. ERROR_MODULE_ABSENT: The module is absent in the bus. ERROR_MODULE_NOTCONFIGURED: The module is not configured in the application. ERROR_MODULE_NOTRUNNING: The module is not running (is not in operational state). ERROR_MODULE_COMMFAIL: Failure in the communication with the module. ERROR_MODULE_NOTFOUND: The module was not found in the application or is not supported. Utilization example in ST language: PROGRAM UserPrg VAR Info: TYPE_RESULT; byRackNumber: BYTE; bySlotNumber: BYTE; END_VAR //INPUTS: byRackNumber := 0; bySlotNumber := 10; //FUNCTION: //Function call. Info := REFRESH_OUTPUT (byRackNumber, bySlotNumber); //Variable "Info" receives possible function errors. 214 5. CONFIGURATION 5.10.3. PID Function Block ATTENTION The PID function block described up to previous revision L of this manual became obsolete and was removed from this manual. The PID, PID_INT and PID_REAL function blocks described up to revision C of MP399609, also became obsolete and were also removed from newer versions of that manual. Users that need description of these obsolete function blocks due to maintenance reasons must use revision C of MP399609. Function blocks PID, PID_INT and PID_REAL must not be used in new projects. These function blocks were replaced by newer function blocks with additional resources, like autotuning and support to cascade, override and feed-forward controls. These new function blocks are described in MU214610, and are available after version 1.1.0.0 of library NextoPID. 5.10.4. Timer Retain The timer retain is a function block developed for applications as production line clocks, that need to store its value and restart the counting from the same point in case of power supply failure. The values stored by the function block, are only zero in case of a Reset Cold, Reset Origin or a new application Download (see the MasterTool IEC XE User Manual - MU299609), when the counters keep working, even when the application is stopped (Stop Mode). ATTENTION It is important to stress that, for the correct functioning of the Timer Retain blocks, the variables must be declared as Retain (VAR RETAIN). It's also important to notice that in simulation mode, the Timer Retain function blocks do not run properly due to need the Nexto CPU for correct behavior. The three blocks already available in the MasterTool IEC XE software NextoStandard library are described below (for the library insertion proceeding, see MasterTool IEC XE Programming Manual MP399609, section Library). 5.10.4.1. TOF_RET The function block TOF_RET implements a time delay to disable an output. When the input IN has its state changed from (TRUE) to (FALSE), or a falling edge, the specified time PT will be counted and the Q output will be driven to (FALSE) at the end of it. When the input IN is in logic level 1 (TRUE), the output Q remain in the same state (TRUE), even if this happened in the middle of the counting process. The PT time can be changed during the counting as the block assumes the new value if the counting hasn't finished. Figure 127 depicts the TOF_RET block and Figure 128 shows its graphic behavior. Figure 127: TOF_RET Block Input parameters IN Type BOOL PT TIME Description This variable, when receives a falling edge, enables the block counting. This variable specifies the block counting limit (time delay). Table 173: TOF_RET Input Parameters 215 5. CONFIGURATION Output parameters Type Q BOOL ET TIME Description This variable executes a falling edge as the PT variable (time delay) reaches its maximum value. This variable shows the current time delay. Table 174: TOF_RET Output Parameters Figure 128: TOF_RET Block Graphic Behavior Utilization example in ST language: PROGRAM UserPrg VAR RETAIN bStart : BOOL := TRUE; TOF_RET : TOF_RET; END_VAR // When bStart=FALSE starts counting TOF_RET( IN := bStart, PT := T#20S); // Actions executed at the end of the counting IF (TOF_RET.Q = FALSE) THEN bStart := TRUE; END_IF 5.10.4.2. TON_RET The TON_RET implements a time delay to enable an output. When the input IN has its state changed from (FALSE) to (TRUE), or a rising edge, the specified time PT will be counted and the Q output will be driven to (TRUE) at the end of it. When the input IN is in logic level 0 (FALSE), the output Q remain in the same state (FALSE), even if it happens in the middle of the counting process. The PT time can be changed during the counting as the block assumes the new value if the counting hasn't finished. Figure 129 depicts the TON_RET block and Figure 130 shows its graphic behavior. Figure 129: TON_RET Function Block 216 5. CONFIGURATION Input parameters IN Type BOOL PT TIME Description This variable, when receives a rising edge, enables the function block counting. This variable specifies the block counting limit (time delay). Table 175: TON_RET Input Parameters Output parameters Type Q BOOL ET TIME Description This variable executes a rising edge as the PT variable (time delay) reaches its maximum value. This variable shows the current time delay. Table 176: TON_RET Output Parameters Figure 130: TON_RET Block Graphic Behavior Utilization example in ST language: PROGRAM UserPrg VAR RETAIN bStart : BOOL; TON_RET : TON_RET; END_VAR // Quando bStart=TRUE starts counting TON_RET( IN := bStart, PT := T#20S); // Actions executed at the end of the counting IF (TON_RET.Q = TRUE) THEN bStart := FALSE; END_IF 5.10.4.3. TP_RET The TP_RET function block works as a trigger. The timer which starts when the IN input has its state changed from (FALSE) to (TRUE), that is, a rising edge, it is increased until the PT time limit is reached. During the counting, the Q output 217 5. CONFIGURATION is (TRUE), otherwise it is (FALSE). The PT time can be changed during the counting as the block assumes the new value if the counting has not finished. Figure 131 depicts the TP_RET and Figure 132 shows its graphic behavior. Figure 131: TP_RET Function Block Input parameters IN Type BOOL PT TIME Description This variable, when receives a rising edge, enables the function block counting. This variable specifies the function block counting limit (time delay). Table 177: TP_RET Input Parameters Output parameters Q ET Type BOOL TIME Description This variable is true during the counting, otherwise is false. This variable shows the current time delay. Table 178: TP_RET Output Parameters Figure 132: TP_RET Block Graphic Behavior Utilization example in ST language: PROGRAM UserPrg VAR RETAIN bStart : BOOL; TP_RET : TP_RET; END_VAR // Configure TP_RET TP_RET( IN := bStart, PT := T#20S); 218 5. CONFIGURATION bStart := FALSE; // Actions executed during the counting IF (TP_RET.Q = TRUE) THEN // Executes while the counter is activated ELSE // Executes when the counter is deactivated END_IF 5.10.5. ClearRtuDiagnostic This function isn't supported by this CPUs' Series. 5.10.6. ClearEventQueue The ClearEventQueue function available by the LibRtuStandard library can be used when it's needed to clear the CPU's event queue and of all instanced drivers. According to table below the function's execution result is going to be showed in its output variable. Name OK_SUCCESS ERROR_FAILED ERROR_NOTSUPPORTED ERROR_PARAMETER ERROR_MODULE_ABSENT ERROR_MODULE_NOTCONFIGURED ERROR_MODULE_NOTRUNNING ERROR_MODULE_COMMFAIL ERROR_MODULE_NOTFOUND ENUM (UDINT) 0 1 2 3 16 17 18 19 20 Result Description Success General error The called routine is not supported by the product Invalid/unsupported parameter The module is absent in the bus The module is not configured in the application The module is not running (isn't in operational state) Failure in the communication with the module The module wasn't found in application or is not supported Table 179: ClearEventQueue Function Results Using example in ST language, where the function call is going to clear the events queue, and consequently, reset the communication drivers events queue usage diagnostics T_DIAG_DNP_SERVER_1.tClient_*.tQueueDiags.wUsage: PROGRAM UserPrg VAR ClearEventQueueStatus : TYPE_RESULT; END_VAR ClearEventQueueStatus := ClearEventQueue(); 219 5. CONFIGURATION 5.11. User Web Pages Also called Web Visualization, or simply Webvisu, this feature allows to implement a simplified SCADA embedded into the PLC. The Visualization screens are developed on the same enviroment of the PLC application using MasterTool IEC XE. Once the application is downloaded, the PLC starts a web server hosting this special web page. The complete information about this functionality can be found on Help of MasterTool IEC XE. 5.12. Management Tab Access Developed to perform configuration and diagnostics access to some features. The Management tab of the System Web Page has its access protected by user and password, with admin as the default value for both fields. On the Management tab, there are other resources such as System, Network, USB Device, Firewall, OpenVPN, and FTP Server. The resources available on this tab vary according to the features available for the controller used and can only be accessed after the user has logged in, as shown in the figure below. Figure 133: Management Tab Access 5.12.1. System Section In the System section, you can perform a CPU firmware update. For cases in which the update is done remotely (through a radio or satellite connection, for example), the minimum speed of this link must be 128 kbps. 5.12.2. Network Section Designed to assist in the usability of the controller, the Network section (figure below) allows you to change network addresses and run the Network Sniffer. 220 5. CONFIGURATION Figure 134: Network Section 5.12.2.1. Network Section Configurations 5.12.2.1.1. Defined by Application The Mode field defines which configuration the controller should load for its interfaces. This field can be configured as Defined By Web Page or Defined By Application. When set to Defined by Application, the interface table is disabled, not allowing changes, as shown in the figure below. In this mode, the settings applied to the controller are those defined by the application. ATTENTION The table for network configuration is displayed only when there is no application on the controller or the controller is not running. It is not possible to change the network settings while an application is running on the controller. Below is an image with Defined by Application mode selected, showing the interface table disabled. 221 5. CONFIGURATION Figure 135: Interfaces Table - Application Mode 5.12.2.1.2. Defined by web page For the Defined by web page mode, the interface table remains enabled, as shown in the figure below. In this mode, the user can configure the IP Address, Netmask, and Gateway of each of the available Ethernet interfaces. Figure 136: Interfaces Table - Web Mode To have the settings applied to the controller, simply click the Apply button. This process checks if there were any errors in the configuration made and, if so, displays a message on the browser screen indicating the error. If your settings are correct, 222 5. CONFIGURATION after clicking Apply, a confirmation window appears in your browser to apply the new settings. By clicking OK, the settings are sent to the controller and applied. ATTENTION When making network changes in the controller, the interfaces will be restarted, which may cause a communication loss. This is especially true when changing the IP address value. When applying settings using the Defined by Application mode, the controller will assume the configuration that was defined by the loaded application. If there is no application, the current configuration will be maintained, with only the configuration mode being changed. Using the Defined by Web Page mode, the addresses indicated on the web page will be loaded. ATTENTION The Defined by Web Page mode configures the interfaces to operate in Simple Mode. 5.12.2.2. Network Sniffer The network sniffer, shown in the figure below, can be used to observe traffic on physical interfaces, except for USB devices such as modems and wifi adapters. It has two basic settings: Number of Packets: This is the number of packets you want to capture. The configured value of this parameter must be within the range of 1 to 25000 packets; Idle Timeout (seconds): If there is no packet traffic on the interface after this configured timeout, Sniffer is terminated. It can be configured with values between 1 and 3600 seconds. Only a few moments after the screen opens will the Run button, which starts Sniffer's execution, become available. The Download button will only be unlocked if there is a Sniffer related file available for download. If the Sniffer has never been run or the file is deleted, the button will not be available. When running the Network Sniffer, the page will disable the edit fields, the Download button will be locked, and the Run button will become the Stop button, as shown in the figure below. Figure 137: Network Sniffer Running The Stop button can be used to end the sniffer execution at any time after it has been started. 223 5. CONFIGURATION For each of the interfaces on which Sniffer runs, it generates a .pcap file. These files are named according to the name of the controller and the interface that was analyzed, for example, NX3008_NET1.pcap. These files are found inside a .zip file, also named according to the name of the controller, for example, NX3008_capture.zip. At the end of the sniffer execution, a message is displayed asking whether or not to automatically download the generated files. These files are stored in the InternalMemory folder of the User Files Memory and can be accessed through the controller's programming software. The downloaded file is always in the .zip extension, which groups the other files. If any problems occur related to insufficient memory due to the generation of sniffer files, it will be indicated to the user. It is recommended to try running the analyzer again with a smaller Number of Packets configuration. The network sniffer can terminate its execution for three reasons: insufficient memory, idle time limit of interfaces exceeded, and manual cancellation. 5.13. SNMP 5.13.1. Introduction SNMP (Simple Network Management Protocol) is a protocol widely used by network administrators to provide important information and diagnostic equipment present in a given Ethernet network. This protocol uses the concept of agent and manager, in which the manager sends read requests or write certain objects to the agent. Through a MIB (Management Information Base) the manager is aware of existing objects in the agent, and thus can make requests of these objects, respecting the read permissions or writing the same. MIB is a collection of information organized hierarchically with each object of this tree is called OID (Object Identifier). For all equipment with SNMP, it is mandatory to support MIB-II. In this MIB are described key information for managing Ethernet networks. 5.13.2. SNMP nas UCPs Nexto The CPUs of the Nexto Series behave as agents in SNMP communication. The information made available through SNMP cannot be manipulated or accessed through the user application, requiring an external SNMP manager to perform access. The table below contains the objects available in the Nexto CPUs. This feature is available after firmware version 1.4.0.33 of the Nexto Series CPUs supports the protocols SNMPv1, SNMPv2c and SNMPv3, and support the MIB-II, where required objects are described in RFC-1213. OID 1.3.6.1.2.1.1 1.3.6.1.2.1.2 1.3.6.1.2.1.3 1.3.6.1.2.1.4 1.3.6.1.2.1.5 1.3.6.1.2.1.6 1.3.6.1.2.1.7 1.3.6.1.2.1.11 1.3.6.1.2.1.31 Name System Interfaces At IP ICMP TCP UDP SNMP ifMib Description Contains name, description, location and other equipment identification information. Contains information of the machine's network interfaces. The ifTable (OID 1.3.6.1.2.1.2.2) has the indexes 6 and 7 available, which can be viewed by the network interfaces statistics NET 1 and NET 2, respectively, of the Nexto Series CPUs. Contains information of the last required connections to the agent. Contains statistical connections using IP protocol. Contains statistical connections using ICMP protocol. Contains statistical connections using TCP protocol. Contains statistical connections using UDP protocol. Contains statistical connections using SNMP protocol. Extension to Interfaces, OID 1.3.6.1.2.1.2. Table 180: MIB II Objects Nexto Series SNMP Agent By default, the SNMP agent is activated, i.e., the service is initialized at the time the CPU is started. The access to the agent information is via the Ethernet interfaces NET 1 and NET 2 of the Nexto Series CPUs on TCP port 161. So when the service is active, the agent information can be accessed through any one of the two Ethernet interfaces, if available. It is not possible to provide agent information through Ethernet interfaces NX5000 modules. In figure below an example is shown SNMP manager, in which some values are read. 224 5. CONFIGURATION Figure 138: SNMP Manager Example For SNMPv3, in which there is user authentication and password to requests via SNMP protocol, is provided a standard user described in the User and SNMP Communities section. If you want to disable the service, change the SNMPv3 user or communities for SNMPv1 / v2c predefined, you must access the System Web Page of the CPU. For details, see the Configuration SNMP section. 5.13.3. Private MIB The Private MIB has been discontinued since June 2019. 5.13.4. Configuration SNMP SNMP settings can be changed through the System Web Page, in the CPU Management tab in the SNMP menu. After successful login, the current state of the service (enabled or disabled) as well as the user information SNMPv3 and communities for SNMPv1 / v2c can be viewed. The user can enable or disable the service via a checkbox at the top of the screen. It's also possible to change the SNMPv3 information by clicking the Change button just below the user information. Will open a form where you must complete the old username and password, and the new username and password. The other user information SNMPv3 cannot be changed. To change the data of SNMPv1/v2c communities, the process is similar, just click the Change button below the information community. A new screen will open where the new data to the rocommunity and rwcommunity fields will be inserted. If you fail any of the fields blank, their community will be disabled. That way, if the user leaves the two fields blank, access to the SNMP agent will only be possible through SNMPv3. If the user wants to return to the default settings, it must be manually reconfigure the same according to the User and SNMP Communities section. Therefore, all current SNMP configurations will be kept in the firmware update process. These options are shown in figure below. 225 5. CONFIGURATION Figure 139: SNMP status configuration screen ATTENTION The Username and Password to access the agent via SNMP protocol are the same used to login on the SNMP Settings web page. 5.13.5. User and SNMP Communities To access the SNMPv1 / v2c of the Nexto Series CPUs, there are two communities, according to table below. Communities rocommunity rwcommunity Default String Public Private Type Only read Read and Write Table 181: SNMPv1/v2c Default Communities info It's possible to access SNMPv3 using default user, see table below: Username administrator Type rwuser Authentication Protocol Password MD5 administrator Privacy Protocol - Privacy Password - Table 182: SNMPv3 Default User info For all settings of communities, user and password, some limits must be respected, as described on the following table: Configurable item rocommunity rwcommunity V3 User V3 Password Minimum Size 8 Max Size 30 30 30 30 Allowed Characters [0-9][a-z][A-Z]@$*_. [0-9][a-z][A-Z]@$*_. [0-9][a-z][A-Z]@$*_. [0-9][a-z][A-Z]@$*_. Table 183: SNMP settings limits 226 5. CONFIGURATION 5.14. Device 5.14.1. User Management and Access Rights It provides functions to define users accounts and to configure the access rights to the project and to the CPU. Using the software MasterTool IEC XE, it's possible to create and manage users and groups, setting, different access right levels to the project. Simultaneously, the Nexto CPUs have an user permissions management system that blocks or allows certain actions for each user group in the CPU. For more information, consult the MasterTool IEC XE User Manual MT8500 MU299609, in the User Management and Access Rights section. 5.14.2. PLC Settings On this tab of the generic device editor, you make the basic settings for the configuration of the PLC, for example the handling of inputs and outputs and the bus cycle task. Figure 140: PLC Settings Parameter Application for I/O handling Refresh I/Os in stop Behavior of the outputs at stop Description Application that is responsible for the I/O handling. TRUE: The values of the input and output channels are also refreshed when the PLC is in STOP mode. If the watchdog detects a malfunction, the outputs are set to the predefined default values. FALSE: The values of the input and output channels in STOP mode are not refreshed. Handling of the output channels when the controller enters STOP mode: Retain values: The current values are retained. All outputs to default value: The default values resulting from the I/O mapping are assigned. Execute program: The handling of the output values is controlled by a program contained in the project which is executed in STOP mode. Enter the name of the program in the field on the right. 227 5. CONFIGURATION Parameter Always update variables Bus cycle task Force variables for the I/O mapping Activate diagnostics for devices Display I/O warnings as errors Enable symbolic access for I/Os Description Globally defines whether or not the I/O variables are updated in the bus cycle task. This setting is effective for the I/O variables of the slaves and modules only if "deactivated" is defined in their update settings. Deactivated (update only if used in a task): The I/O variables are updated only if they are used in a task. Enabled 1 (use bus cycle task if not used in any task): The I/O variables in the bus cycle task are updated if they are not used in any other task. Enabled 2 (always in bus cycle task): All variables in each cycle of the bus cycle task are updated, regardless of whether they are used and whether they are mapped to an input or output channel. Task that controls the bus cycle. By default the task defined by the device description is entered. By default, the bus cycle setting of the superordinate bus device applies (use cycle settings of the superordinate bus). This means that the device tree is searched upwards for the next valid definition of the bus cycle task. TRUE: When compiling the application, two global variables are created for each I/O channel which is mapped to a variable in the I/O Mapping dialog. TRUE: The CAA Device Diagnosis library is integrated in the project. An implicit function block is generated for each device. If there is already a function block for the device, then either an extended function block is generated (example: EtherCAT) or another function block instance is added. This then contains a general implementation of the device diagnostics. Warnings concerning the I/O configuration are displayed as errors. TRUE: Input and output variables(VAR_INPUT and VAR_OUTPUT) are automatically created for the I/O channels of the device. For this purpose, an extended function block is created for each slave. The basis is the existing function block of the slave. This kind of automatically generated function block can be accessed directly in the application code. Table 184: PLC Settings 228 6. MAINTENANCE 6. Maintenance One feature of the Nexto Series is the abnormality diagnostic generation, whether they are failures, errors or operation modes, allowing the operator to identify and solve problems which occurs in the system easily. The Nexto CPUs permit many ways to visualize the diagnostics generated by the system, which are: One Touch Diag Diagnostics via LED Diagnostics via System Web Page Diagnostics via Variables Diagnostics via Function Blocks The first one is an innovating feature of Nexto Series, which allows a fast access to the application abnormal conditions. The second is purely visual, generated through two LEDs placed on the panel (DG and WD) and also through the LEDs placed in the RJ45 connector (exclusive for Ethernet connection). The next feature is the graphic visualization in a WEB page of the rack and the respective configured modules, with the individual access allowed of the operation state and the active diagnostics. The diagnostics are also stored directly in the CPU variables, either direct representation (%Q) or attributed (AT variable), and can be used by the user application, for instance, being presented in a supervisory system. The last ones present specific conditions of the system functioning. These diagnostics function is to point possible system installation or configuration problems, and communication network problems or deficiency. 6.1. Module Diagnostics 6.1.1. One Touch Diag The One Touch Diag (OTD), or single touch diagnostics, is an exclusive feature the Nexto Series brings for the pro- grammable controllers. With this new concept the user can verify the diagnostics of any module connected to the system straight on the CPU graphic display with a single touch on the module Diagnostic Switch. This is a powerful diagnostic tool which can be used offline (with no need of supervisory or programming software) making easier to find and solve quickly possible problems. The diagnostics key is placed on the CPU upper part, in an easy access place and, besides giving active diagnostics, allows the access to the navigation menu, described in the Configuration CPU's Informative and Configuration Menu section. The figure below shows the CPU switch placement: Figure 141: Diagnostic Switch With only a short touch, the CPU starts to show the bus diagnostics (when active, otherwise shows the "NO DIAG" message). Initially, the Tag is visualized (configured in the module properties in the MasterTool IEC XE software, following 229 6. MAINTENANCE the IEC 61131-3 standard), in other words, the name attributed to the CPU, and after that all diagnostics are shown, through CPU display messages. This process is executed twice on the display. Everything occurs automatically as the user only has to execute the first short touch and the CPU is responsible to show the diagnostics. The diagnostics of other modules present on the bus are also shown on the CPU graphic display by a short press in the diagnostic module button, in the same presentation model of diagnostics. The figure below shows the process starting with the short touch, with the conditions and the CPU times presented in smaller rectangles. It is important to stress the diagnostics may have more than one screen, in other words, the specified time in the block diagram below is valid for one of them. Figure 142: CPU Diagnostics Visualization Before all visualization process be concluded, it is just to give a short touch on the diagnostic switch, at any moment, or press the diagnostic switch from any I/O module connected to the bus. Also, it is important to observe that the One Touch Diag could be available when the module could be in Operational Mode. In case a long touch is executed, the CPU goes to navigation menu, which is described in the Configuration CPU's Informative and Configuration Menu section. 230 6. MAINTENANCE The table below shows the difference between the short touch time, the long touch time and stuck button. Touch type No touch Short touch Long touch Locked Switch Minimum time - 60 ms 1s 20.01 s Maximum time 59.99 ms 0.99 s 20 s () Indication condition Release More than 1 s till 20 s Diagnostics indication, see on Table 190 Table 185: One Touch Time The messages presented on the Nexto CPU graphic display, correspondent to the diagnostics, are described in the Diagnostics via Variables section, on Table 190. If any situation of stuck button occur in one of the I/O modules, the diagnostic button of this module will stop of indicate the diagnostics on CPU graphic display when is pressed. In this case, the CPU will indicate that there is a module with active diagnostics. To remove this diagnostic from the CPU, a hot swap must be done in the module where the diagnostic is active. For further details on the procedure for viewing the diagnostics of the CPU or other bus modules, see description in the User Manual Nexto Series MU214600. 6.1.2. Diagnostics via LED This product have a LED for diagnostic indication (LED DG) and a LED for watchdog event indication (LED WD). The Tables 186 and 187 show the meaning of each state and its respective descriptions. 6.1.2.1. DG (Diagnostic) Green Off On Off Blinking 2x Blinking 3x Off Red Off Off On Off Off Blinking 4x Description Not used All applications in execution mode (Run) All applications in stopping mode (Stop) Bus modules with diagnostic Data forcing Configuration or hardware error in the bus Causes No power supply. Hardware problem - - At least, a bus module, including the CPU, is with an active diagnostic Some memory area is being forced by the user through MasterTool IEC XE The bus is damaged or is not properly configured Priority 3 (Low) 3 (Low) 1 2 0 (High) Table 186: Description of the Diagnostic LEDs States 6.1.2.2. WD (Watchdog) 231 6. MAINTENANCE Red LED Off Blinking 1x On Description No watchdog indication Software watchdog Hardware watchdog Causes Normal operation User application watchdog Damaged module and/or corrupted operational system Priority 3 (Low) 2 1 (High) Table 187: Description of the Watchdog LED States Notes: Software Watchdog: In order to remove the watchdog indication, make an application reset or turn off and turn on the CPU again. This watchdog occurs when the user application execution time is higher than the configured watchdog time. The diagnostics can be checked in the Exception.wExceptionCode variable, see on Table 194. Hardware Watchdog: In order to reset any watchdog indication, as in the WD LED or in the Reset.bWatchdogReset operand, the module must be disconnected from the power supply. In order to verify the application conditions in the module restart, see configurations on Table 37. 6.1.2.3. RJ45 Connector LEDs Both LEDs placed in the RJ45 connectors, help the user in the installed physical network problem detection, indicating the network Link speed and the existence of interface communication traffic. The LEDs meaning is presented on table below. Yellow · · X Green · - Meaning Network LINK absent 10 Mbytes/s network LINK 100 Mbytes/s network LINK Ethernet network transmission or reception occurrence, for or to this IP address. Blinks on Nexto CPU demand and not every transmission or reception, in other words, it may blink on a lower frequency than the real transmission or reception frequency Table 188: Ethernet LEDs Meaning 6.1.3. Diagnostics via System Web Page Besides the previously presented features, the Nexto Series brings to the user an innovating access tool to the system diagnostics and operation states, through a System Web Page. The utilization, besides being dynamic, is very intuitive and facilitates the user operations. The use of a supervisory system can be replaced when it is restricted to system status verification. To access the desired CPU's System Web Page, it is just to use a standard browser (Internet Explorer 7 or superior, Mozilla Firefox 3.0 or superior and Google Chrome 8 or superior) and type, on the address bar, the CPU IP address (Ex.: http://192.168.1.1). First, the CPU information is presented, according to Figure 143: 232 6. MAINTENANCE Figure 143: Initial Screen There is also the "System Overview" tab, which can be visualized through the Rack or the present module list (option on the screen right side). While there is no application on the CPU, this page will display a configuration with the largest available rack and a standard power supply, connected with the CPU. When the Rack visualization is used, the modules that have diagnostics blink and assume the red color, as shown on Figure 144. Otherwise a list with the system connected modules, Tags and active diagnostics number is presented: Figure 144: System Information When the module with diagnostics is pressed, the module active(s) diagnostic(s) are shown, as illustrated on Figure 145: ATTENTION When a CPU is restarted and the application goes to exception in the system's startup, the diagnostics will not be valid. It is necessary to fix the problem which generates the application's exception so that the diagnostics are updated. 233 6. MAINTENANCE Figure 145: System Diagnostics In case the Status tab is selected, the state of all detailed diagnostics is shown on the screen, as illustrated on Figure 146: Figure 146: System Status The user can choose to visualize two language options: Portuguese and English. Simply change in the upper right part of the screen to the desired language. 6.1.4. Diagnostic Explorer The Diagnostic Explorer is the inclusion of the diagnostics via WEB in the MasterTool IEC XE, in order to make the process faster and direct. The access to this feature happens in two ways: 234 6. MAINTENANCE - Accessing the "Diagnostic Explorer" option in the device tree, placed on the MasterTool IEC XE screen left, and putting the correct IP in the field indicated on Figure 147. Remembering that for the diagnostics page to be shown, the user must be connected to the CPU ( Initial Programming Login section). Figure 147: Diagnostic Explorer Screen - Right-clicking on the module and selecting "Diagnostics", the Diagnostic Explorer is opened, directing for the module status page. 6.1.5. Diagnostics via Variables The Nexto Series CPUs have many variables for diagnostic indication. There are data structures with the diagnostics of all modules declared on the bus, mapped on the variables of direct representation %Q, and defined symbolically through the AT directive, in the GVL System_Diagnostics created automatically by the MasterTool IEC XE. The table below summarizes the diagnostic byte/words division: Byte 0 to 3 4 to 558 Description CPU summarized diagnostics. CPU detailed diagnostics. Table 189: CPU Diagnostics Division 6.1.5.1. Summarized Diagnostics The table below shows the meaning of each CPU summarized diagnostic bit: Direct Variable Variable Bit - - 0 Diagnostics sage Mes- AT Variable DG_Module.tSummarized.* Description NO DIAG CONFIG. MISMATCH bConfigMismatch There is no active diagnostic. TRUE There is a configuration problem in the bus, as the module inserted in the wrong position. 235 6. MAINTENANCE Direct Variable Variable Bit 1 2 %QB(n) 3 4 5 6 7 0 1 %QB(n+1) 4 6 0 Diagnostics sage Mes- AT Variable DG_Module.tSummarized.* Description ABSENT MODULES SWAPPED MODULES NON-DECLARED MODULES MODULES W/ DIAGNOSTICS MODULES W/ FATAL ERROR MODULES W/ PARAM. ERROR BUS ERROR HARDWARE FAILURE SOFTWARE EXCEPTION COM1 CONF. ERROR NET1 CONF. ERROR INVALID DATE/TIME bAbsentModules bSwappedModules bNonDeclaredModules bModulesWithDiagnostic bModuleFatalError bModuleParameterError bWHSBBusError bHardwareFailure bSoftwareException bCOM1ConfigError bNET1ConfigError bInvalidDateTime FALSE The bus is configured correctly. TRUE One or more declared modules are absent. FALSE All declared modules were detected in the bus. TRUE There are changed modules in the bus. FALSE There are no changed modules in the bus. TRUE One or more modules in the bus were not declared in the configuration. FALSE All modules were declared. TRUE One or more modules in the bus are with active diagnostic. FALSE There is no active diagnostic in the modules in the bus. TRUE One or more modules in the bus are in fatal error. FALSE All modules are working properly. TRUE One or more modules in the bus have parameterization error. FALSE All modules are parameterized. TRUE Master indication there is failure in the WHSB bus. FALSE The WHSB bus is working properly. TRUE CPU hardware failure. FALSE The hardware is working properly. TRUE One or more exceptions generated by the software. FALSE No exceptions generated in the software. TRUE Some error occurred during, or after, the COM 1 serial interface configuration. FALSE The COM 1 serial interface configuration is correct. TRUE Some error occurred during, or after, the NET 1 Ethernet interface configuration. FALSE The NET 1 Ethernet interface configuration is correct. TRUE The date or hour are invalid. FALSE The date and hour are correct. 236 6. MAINTENANCE Direct Variable Variable Bit 1 %QB(n+2) 2 3 0 1 %QB(n+3) 2 3 4 Diagnostics sage Mes- AT Variable DG_Module.tSummarized.* Description RUNTIME RESET OTD SWITCH ERROR WRONG CPU SLOT ABSENT RACK DUPLICATED RACK INVALID RACK NON DECLARED RACK DUPLICATED SLOT bRTSReset bOTDSwitchError bWrongCPUSlot bAbsentRacks bDuplicatedRacks bInvalidRacks bNonDeclaredRacks bDuplicatedSlots TRUE The RTS (Runtime System) has been restarted at least once. This diagnostics is only cleared in the system restart. FALSE The RTS (Runtime System) is operating normally. TRUE True in case the OTD key has been locked for more than 20 s at least once while the CPU was energized. This diagnostic is only cleared in the system restart. FALSE The key is not currently locked or was locked while the CPU was energized. TRUE - The CPU is plugged on a slot different to the declared in user application. FALSE - The CPU is properly plugged on slot declared in user application. TRUE One or more declared racks are absent. FALSE There are no absent racks. TRUE There are racks with a duplicated identification number. FALSE There are no racks with a duplicated identification number. TRUE There are racks with an invalid identification number. FALSE There are no racks with an invalid identification number. TRUE There are racks with a nondeclared identification number. FALSE There are no racks with a nondeclared identification number. TRUE There are some duplicated slot address. FALSE There are no duplicated slot address. Table 190: CPU Summarized Diagnostics Notes: Direct Representation Variable: "n" represents the value set in the CPU through the MasterTool IEC XE software, such as initial address diagnostics. AT Directive: In the description of the symbolic variables which use the AT directive to make the mapping in direct addressing variables, the syntax that must be put before the desired summarized diagnostic is DG_Module.tSummarized, when the Module word is replaced by the used CPU. E.g. for the incompatible configuration diagnostic it must be used the variable: DG_NX3010.tSummarized.bConfigMismatch. The AT directive is a word reserved in the programming software, used only for diagnostic indication. Configuration Mismatch: The incompatible configuration diagnostic is generated if one or more modules of the rack does not correspond to the declared one, so, in the absence or different modules conditions. The modules inserted in the bus that were not declared in the project are not considered. Swapped Modules: If only two modules are changed between themselves in the bus, then changed diagnostic can be identified. Otherwise, the problem is treated as "Incompatible Configuration". 237 6. MAINTENANCE Modules with Fatal Error: In case the modules with fatal error diagnostic is true, it must be verified which is the problematic module in the bus and send it to Altus Technical Assistance, as it has hardware failure. Module with Parameterization Error: In case the parameterization error diagnostic is true, it must be verified the module in the bus are correctly configured and if the firmware and MasterTool IEC XE software version are correct. If the problem occurred when inserting a module on the bus, make sure the module supports hot swapping. Bus Error: Considered a fatal error, interrupting the access to the modules in the bus. In case the bus error diagnostic is true, an abnormal situation due to the hot exchange configuration selected might have occurred or a hardware problem in the bus communication lines, then, contact Altus Technical Assistance. Hardware Failure: In case the Hardware Failure diagnostic is true, the CPU must be sent to Altus Technical Assistance, as it has problems in the RTC, auxiliary processor, or other hardware resources. Software Exception: In case the software exception diagnostic is true, the user must verify his application to guarantee it is not accessing the memory wrongly. If the problem remains, the Altus Technical Support sector must be consulted. The software exception codes are described next in the CPU detailed diagnostics table. Diagnostic Message: The diagnostics messages can be visualized by the CPU graphic display using the OTD key or using the CPU's System Web Page. 6.1.5.2. Detailed Diagnostics The tables below contain Nexto Series' CPUs detailed diagnostics. It is important to have in mind the observations below before consulting them: Visualization of the Diagnostics Structures: The Diagnostics Structures added to the Project can be seen at the item "Library Manager" of MasterTool IEC XE tree view. There, it is possible to see all data types defined in the structure. Counters: All CPU diagnostics counters return to zero when their limit value is exceeded. Direct representation variable: "n" represents the value configured at the CPU through MasterTool IEC XE as the initial diagnostics address. AT Directive: At the description of symbolic variables that use the AT directive to map it in direct mapping variables, the syntax to be used before the desired summarized diagnostic is DG_Module.tDetailed., where the word Module must be replaced by the CPU being used. The AT directive is a reserved word of the programmer, and some symbolic variables that use this directive indicate diagnostics. Direct representation %QD(n+4) %QB(n+8) %QB(n+12) Size DWORD AT Variable DG_Modulo.tDetailed.* Target. dwCPUModel BYTE ARRAY(4) BYTE ARRAY(4) Target. abyCPUVersion Target. abyBootloaderVersion Description NX3003 = 0x3003 NX3004 = 0x3004 NX3005 = 0x3005 NX3010 = 0x3010 NX3020 = 0x3020 NX3030 = 0x3030 Firmware version. Bootloader version. Table 191: Target Detailed Diagnostics Group Description Direct representation Size %QX(n+20).1 BIT %QX(n+20).2 BIT AT Variable DG_Module.tDetailed.* Hardware. bRTCFailure Hardware. bThermometerFailure 1 Description The main processor is not enabled to communicate with the RTC (CPU's clock). Failure in the communication between the thermometer and the main processor. Table 192: Hardware Detailed Diagnostics Group Description 238 6. MAINTENANCE Direct representation Size %QW(n+21) WORD %QB(n+23) BYTE AT Variable DG_Module.tDetailed.* Exception. wExceptionCode Exception. byProcessorLoad Description Exception code generated by the RTS. See Table 194. Level, in percentage (%), of charge in the processor. Table 193: Exception Detailed Diagnostics Group Description Note: Exception Code: the code of the exception generated by the RTS (Runtime System) can be consulted below: Code 0x0000 0x0010 0x0012 0x0013 0x0014 0x0015 0x0016 0x0017 0x0018 0x0019 0x001A 0x001B 0x001C 0x001D 0x001E 0x0021 0x0022 0x0023 0x0024 0x0025 0x0026 0x0050 Description There is no exception code. Watchdog time of the IEC task expired (Software Watchdog). I/O configuration error. Checksum error after the program download. Fieldbus error. I/O updating error. Cycle time (execution) exceeded. Program online updating too long. External references not resolved. Download rejected. Project not loaded, as the retentive variables cannot be reallocated. Project not loaded and deleted. Out of memory stack. Retentive memory is corrupted and cannot be mapped. Project can be loaded but causes a drop later on. Target of startup application does not match to the current target. Scheduled tasks error. Downloaded file Checksum with error. Retentive identity is not correspondent to the current identity of the boot project program IEC task configuration failure. Application working with wrong target. Illegal instruction. Code 0x0051 0x0052 0x0053 0x0054 0x0055 0x0056 0x0057 0x0058 0x0059 0x0100 0x0101 0x0102 0x0103 0x0104 0x0105 0x0150 0x0151 0x0152 0x0153 0x0154 0x0155 0x0156 0x0157 Description Access violation. Privileged instruction. Page failure. Stack overflow. Invalid disposition. Invalid maneuver. Protected page. Double failure. Invalid OpCode. Data type misalignment. Arrays limit exceeded. Division by zero. Overflow. Cannot be continued. Watchdog in the processor load of all IEC task detected. FPU: Not specified error. FPU: Operand is not normal. FPU: Division by zero. FPU: Inexact result. FPU: Invalid operation. FPU: Overflow. FPU: Stack verification. FPU: Underflow. Table 194: RTS Exception codes 239 6. MAINTENANCE Direct representation Size %QB(n+24) BYTE AT Variable DG_Module.tDetailed.* WebVisualization. byConnectedClients Description Clients number connected to the WebVisualization. Table 195: WebVisualization Detailed Diagnostics Group Description Direct representation Size %QB(n+25) BYTE %QW(n+26) %QW(n+28) %QW(n+30) %QW(n+32) WORD WORD WORD WORD AT DG Vari- able_Modulo.tDetailed.* RetainInfo. byCPUInitStatus RetainInfo. wCPUColdStartCounter RetainInfo. wCPUWarmStartCounter RetainInfo. wReserved_0 RetainInfo. wRTSResetCounter Description CPU Startup Status: 01: Hot start 02: Warm Start 03: Cold Start Note: These variables are reset in every powerup. Cold Startup Counter: It will be incremented only due to the CPU hot removal in the bus and not due to the MasterTool IEC XE Cold Reset command. (0 to 65535) Warm Startup Counter: It will only be incremented during the sequence of system powerups and not due to the MasterTool IEC XE Hot Reset command. (0 to 65535). Reserved. Counter of resets performed by RTS (Runtime System). (0 to 65535). Table 196: RetainInfo Group Detailed Diagnostics Direct representation Size %QX(n+36).0 BIT %QX(n+36).1 BIT AT Variable DG_Module.tDetailed.* Reset. bBrownOutReset Reset. bWatchdogReset Description The CPU was restarted due a failure in the power supply in the last startup. The CPU was restarted due the active watchdog in the last startup. Table 197: Reset Detailed Diagnostics Group Description Note: Brownout Reset: The brownout reset diagnostic is only true when the power supply exceed the minimum limit required in its technical characteristics, remaining in low-voltage, i.e. without undergoing any interrupt. The CPU will identify the drop in supply and will indicate the power failure diagnostic. When the voltage is reestablished, the CPU will automatically reset and will indicate the brownout reset diagnostic. Direct representation Size %QX(n+37).0 BIT %QX(n+37).1 BIT %QD(n+38) DINT AT Variable DG_Module.tDetailed.* Thermometer. bOverTemperatureAlarm 1 Thermometer. bUnderTemperatureAlarm 1 Thermometer. diTemperature 1 Description Alarm generated due internal temperature at 85 C or above it. Alarm generated due internal temperature at 0 C or under it. Temperature read in the internal sensor of the CPU. Table 198: Thermometer Detailed Diagnostics Group Description Note: Temperature: In order to see the temperature directly in the memory address, a conversion must be made, since the data size is DINT and monitoring is done in 4 bytes. Therefore, it's recommended to use the associated symbolic variable, because it already provides the final temperature value. 240 6. MAINTENANCE Direct representation Size %QB(n+42) BYTE %QD(n+43) %QD(n+47) %QW(n+51) %QW(n+53) %QW(n+55) %QW(n+57) %QW(n+59) %QW(n+61) DWORD DWORD WORD WORD WORD WORD WORD WORD AT Variable DG_Module.tDetailed.* Serial.COM1. byProtocol Serial.COM1. dwRXBytes Serial.COM1. dwTXBytes Serial.COM1. wRXPendingBytes Serial.COM1. wTXPendingBytes Serial.COM1. wBreakErrorCounter Serial.COM1. wParityErrorCounter Serial.COM1. wFrameErrorCounter Serial.COM1. wRXOverrunCounter Description Protocol selected in the COM 1: 00: Without protocol 01: MODBUS RTU Master 02: MODBUS RTU Slave 03: Other protocol Counter of characters received from COM 1 (0 to 4294967295). Counter of characters transmitted from COM 1 (0 to 4294967295). Number of characters left in the reading buffer in COM 1 (0 to 65535). Number of characters left in the transmission buffer in COM 1 (0 to 65535). The transmitter is holding the data line at zero for too long, according to the databit configured. The received frame has the mismatched parity bit. The received frame has the wrong start point, usually caused by a noise or baud rate mismatch. When the receive ring buffer is full and starts to lose the old frames (too many frames not treated by the device). Table 199: Serial COM 1 Detailed Diagnostics Group Description Note: Parity Error Counter: When the serial COM 1 is configured Without Parity, this error counter won't be incremented when it receives a message with a different parity. In this case, a frame error will be indicated. Direct representation %QX(n+92).0 %QW(n+93) %QX(n+93).0 %QX(n+93).1 %QX(n+93).2 %QX(n+93).3 %QB(n+95) %QB(n+111) %QB(n+127) %QB(n+143) %QB(n+161) %QB(n+165) Size BIT WORD BIT BIT BIT BIT STRING (15) STRING (15) STRING (15) STRING (17) BYTE ARRAY(4) BYTE ARRAY(4) AT Variable DG_Modulo.tDetailed.* Ethernet.NET1. bLinkDown Ethernet.NET1. wProtocol Ethernet.NET1. wProtocol. bMODBUS_RTU_ETH_Client Ethernet.NET1. wProtocol. bMODBUS_ETH_Client Ethernet.NET1. wProtocol. bMODBUS_RTU_ETH_Server Ethernet.NET1. wProtocol. bMODBUS_ETH_Server Ethernet.NET1. szIP Ethernet.NET1. szMask Ethernet.NET1. szGateway Ethernet.NET1. szMAC Ethernet.NET1. abyIP Ethernet.NET1. abyMask Description Indicates the state of the link in NET 1. Selected protocol in NET 1: 00: Without protocol MODBUS RTU Client via TCP. MODBUS TCP Client. MODBUS RTU Server via TCP. MODBUS TCP Server. NET 1 IP Address. NET 1 Subnet Mask. NET 1 Gateway Address. NET 1 MAC Address. NET 1 IP Address. NET 1 Subnet Mask. 241 6. MAINTENANCE Direct representation %QB(n+169) %QB(n+173) %QD(n+179) %QD(n+183) %QD(n+187) %QD(n+191) %QW(n+199) %QW(n+201) %QW(n+209) %QW(n+211) Size BYTE ARRAY(4) BYTE ARRAY(6) DWORD DWORD DWORD DWORD WORD WORD WORD WORD AT Variable DG_Modulo.tDetailed.* Ethernet.NET1. abyGateway Ethernet.NET1. abyMAC Ethernet.NET1. dwPacketsSent Ethernet.NET1. dwPacketsReceived Ethernet.NET1. dwBytesSent Ethernet.NET1. dwBytesReceived Ethernet.NET1. wTXDropErrors Ethernet.NET1. wTXCollisionErrors Ethernet.NET1. wRXDropErrors Ethernet.NET1. wRXFrameErrors Description NET 1 Gateway Address. NET 1 MAC Address. Counter of sent packages through NET 1 port (0 to 4294967295). Counter of received packages through NET 1 port (0 to 4294967295). Counter of sent bytes through NET 1 port (0 to 4294967295). Counter of received bytes through NET 1 port (0 to 4294967295). Counter of connection losses in the transmission through NET 1 port (0 to 65535). Counter of errors of collision in the transmission through NET 1 port (0 to 65535). Counter of connection losses in the reception through NET 1 port (0 to 65535). Counter of errors of frame in the reception through NET 1 port (0 to 65535). Table 200: Ethernet NET 1 Detailed Diagnostics Group Description Direct representation Size %QB(n+219) BYTE %QD(n+220) DWORD %QD(n+224) DWORD AT Variable DG_Module.tDetailed.* UserFiles. byMounted UserFiles. dwFreeSpacekB UserFiles. dwTotalSizekB Description Indicates if the memory used for recording user files is able to receive data. Free memory space for user files in Kbytes. Storage capacity of the memory of user files in Kbytes. Table 201: UserFiles Detailed Diagnostics Group Description Note: User Partition: The user partition is a memory area reserved for the storage of data in the CPU. For example: files with PDF extension, files with DOC extension and other data. Direct representation Size %QB(n+229) BYTE %QW(n+230) WORD %QW(n+232) WORD AT Variable DG_Module.tDetailed.* UserLogs. byMounted UserLogs. wFreeSpacekB UserLogs. wTotalSizekB Description Status of memory in which are inserted the user logs. Free space in the memory of user logs in Kbytes. Storage capacity of the memory of user logs in Kbytes. Table 202: UserLogs Detailed Diagnostics Group Description Direct representation Size %QB(n+245) BYTE AT Variable DG_Module.tDetailed.* WHSB. byHotSwapAndStartupStatus Description Informs the abnormal situation in the bus which caused the application stop for each mode of hot swapping. See Table 204 for more information. 242 6. MAINTENANCE Direct representation Size %QD(n+247) %QD(n+375) DWORD ARRAY (32) DWORD ARRAY (32) %QB(n+503) BYTE AT Variable DG_Module.tDetailed.* WHSB. adwRackIOErrorStatus WHSB. adwModulePresenceStatus WHSB. byWHSBBusErrors Description Identification of errors in I/O modules, individually. For more information about this diagnostic, see the notes below. Status of presence of declared I/O modules in buses, individually. For more information about this diagnostic, see the notes below. Counter of failures in the WHSB bus. This counter is restarted in the energization (0 to 255). Table 203: WHSB Detailed Diagnostics Group Description Notes: Bus modules error diagnostic: Each DWORD from this diagnostic array represents a rack, whose positions are represented by the bits of these DWORDS. So, Bit-0 of the DWORD-0 is equivalent to position zero of the rack with address zero. Each one of these Bits is the result of an OR logic operation between the Incompatible Configuration (bConfigMismatch), absent modules (bAbsentModules), swapped modules (bSwappedModules), module with fatal error (bModuleFatalError) diagnostics and the operational state of the module in a certain position. Module presence status: Each DWORD from this diagnostic array represents a rack, whose positions are represented by the bits of these DWORDS. So, Bit-0 from DWORD-0 is equivalent to position zero of the rack with address zero. So, if a module is present, this bit will be true. It's important to notice that this diagnostic is valid for all modules, except power supplies, CPUs and non-declared modules, e.g. those that are not in the rack on the respective position (bit remains in false). Situations in which the Application Stops: The codes for the possible situations in which the application stops can be consulted below: Code 00 01 02 03 04 05 06 07 08 Enumerable Description INITIALIZING This state is presented while other states are not ready. Application in Stop Mode due to hardware watchdog re- RESET_WATCHDOG set or runtime reset, when the option "Start User Application After a Watchdog Reset" is unmarked. ABSENT_MODULES_HOT_SWAP_ DISABLED Application in Stop Mode due to Absent Modules diagnostic being set when the Hot Swap Mode is "Disabled" or "Disabled, for declared modules only". CFG_MISMATCH_HOT_SWAP_ DISABLED Application in Stop Mode due to Configuration Mismatch diagnostic being set when the Hot Swap Mode is "Disabled" or "Disabled, for declared modules only". Application in Stop Mode due to Absent Modules diag- ABSENT_MODULES_HOT_SWAP_ STARTUP_CONSISTENCY nostic being set when the Hot Swap Mode is "Enabled, with startup consistency" or "Enabled, with startup consistency for declared modules only". Application in Stop Mode due to Incompatible Config- CFG_MISMATCH_HOT_SWAP_ STARTUP_CONSISTENCY uration diagnostic being set when the Hot Swap Mode is "Enabled, with startup consistency" or "Enabled, with startup consistency for declared modules only". APPL_STOP_ALLOWED_TO_RUN Application in Stop Mode and all consistencies executed successfully. The application can be set to Run Mode. Application in Stop Mode and all consistencies executed APPL_STOP_MODULES_NOT_READY successfully, but the I/O modules are not able to start the system. It is not possible to set the application to Run Mode. Application in Stop Mode and all consistencies executed APPL_STOP_MODULES_GETTING_ READY_TO_RUN successfully. The I/O modules are being prepared to start the system. It is not possible to set the application to Run Mode. 243 6. MAINTENANCE Code 09 10 11 12 13 14 15 16 Enumerable NORMAL_OPERATING_STATE MODULE_CONSISTENCY_OK APPL_STOP_DUE_TO_EXCEPTION DUPLICATED_SLOT_HOT_SWAP_ DISABLED DUPLICATED_SLOT_HOT_SWAP_ STARTUP_CONSISTENCY DUPLICATED_SLOT_HOT_SWAP_ ENABLED NON_DECLARED_MODULE_HOT_ SWAP_STARTUP_CONSISTENCY NON_DECLARED_MODULE_HOT_ SWAP_DISABLED Description Application in Run Mode. Internal usage. Application in Stop Mode due to an exception in the CPU. Application in Stop Mode due to Duplicated Slots diagnostic being set when the Hot Swap Mode is "Disabled" or "Disabled, for declared modules only". Application in Stop Mode due to Duplicated Slots diagnostic being set when the Hot Swap Mode is "Enabled, with startup consistency" or "Enabled, with startup consistency for declared modules only". Application in Stop Mode due to Duplicated Slots diagnostic being set when the Hot Swap Mode is "Enabled, without startup consistency". Application in Stop Mode due to Non Declared Modules diagnostic being set when the Hot Swap Mode is "Enabled, with startup consistency". Application in Stop Mode due to Non Declared Modules diagnostic being set when the Hot Swap Mode is "Disabled". Table 204: Codes of the Situations in which the Application Stops Direct representation Size %QB(n+504) BYTE %QX(n+505).0 BIT AT Variable DG_Module.tDetailed.* Application. byCPUState Application. bForcedIOs Description Informs the operation state of the CPU: 01: All user applications are in Run Mode 03: All user applications is in Stop Mode There is one or more forced I/O points. Table 205: Application Detailed Diagnostics Group Description Direct representation Size %QD(n+506) DWORD %QD(n+510) DWORD %QD(n+514) DWORD AT Variable DG_Module.tDetailed.* Rack. dwAbsentRacks Rack. dwDuplicatedRacks Rack. dwNonDeclaredRacks Description Each bit presents a rack identification number, if the bit is TRUE, it means the rack is absent. Each bit presents a rack identification number, if the bit is TRUE, it means that more than one rack is with the same identification number. Each bit presents a rack identification number, if the bit is TRUE, it means there is a rack configured with a non-declared identification number. Table 206: Rack Detailed Diagnostics Group Description Direct representation Size %QD(n+520) DWORD AT Variable DG_Module.tDetailed.* ApplicationInfo. dwApplicationCRC Description 32 bits CRC of Application. When the application is modified and sent to the CPU, a new CRC is generated. Table 207: ApplicationInfo Detailed Diagnostics Group Description 244 6. MAINTENANCE Direct representation Size %QX(n+532).0 BIT %QB(n+533) BYTE %QW(n+534) %QW(n+536) %QD(n+538) %QB(n+542) WORD WORD DWORD BYTE %QB(n+543) BYTE %QB(n+544) %QB(n+545) %QW(n+546) %QB(n+548) %QB(n+549) %QB(n+550) %QB(n+551) %QW(n+552) BYTE BYTE WORD BYTE BYTE BYTE BYTE WORD AT Variable DG_Modulo.tDetailed.* SNTP. bServiceEnabled SNTP. byActiveTimeServer SNTP. wPrimaryServerDownCount SNTP. wSecondaryServerDownCount SNTP. dwRTCTimeUpdatedCount SNTP. byLastUpdateSuccessful SNTP. byLastUpdateTimeServer SNTP.sLastUpdateTime. byDayOfMonth SNTP.sLastUpdateTime. byMonth SNTP.sLastUpdateTime. wYear SNTP.sLastUpdateTime. byHours SNTP.sLastUpdateTime. byMinutes SNTP.sLastUpdateTime. bReservedAlign SNTP.sLastUpdateTime. bySeconds SNTP.sLastUpdateTime. wMilliseconds Description SNTP Service enabled. Indicates which server is active: 00: None active server. 01: Active Primary Server. 02: Active Secondary Server. Counter of times in which the primary server is unavailable (0 to 65535). Counter of times in which the secondary server is unavailable (0 to 65535). Counter of times the RTC was updated by the SNTP service (0 to 4294967295). Indicates status of the last update: 00: It was not updated. 01: Last update failed. 02: Last update was successfully. Indicates which server was used in the last update: 00: None update. 01: Primary Server. 02: Secondary Server. Day of the last update of the RTC. Month of the last update of the RTC. Year of the last update of the RTC. Hour of the last update of the RTC. Minute of the last update of the RTC. Reserved for alignment. Second of the last update of RTC. Millisecond of the last update of RTC. Table 208: SNTP Detailed Diagnostics Group Description 6.1.6. Diagnostics via Function Blocks The function blocks allow the visualization of some parameters which cannot be accessed otherwise. The function regard- ing advanced diagnostics is in the NextoStandard library and is described below. 6.1.6.1. GetTaskInfo This function returns the task information of a specific application. Figure 148: GetTaskInfo Function Below, the parameters that must be sent to the function for it to return the application information are described. 245 6. MAINTENANCE Input parameter psAppName psTaskName pstTaskInfo Type POINTER TO STRING POINTER TO STRING POINTER TO stTaskInfo Description Application name. Task name. Pointer to receive the application information. Table 209: GetTaskInfo Input Parameters The data returned by the function, through the pointer informed in the input parameters are described on table below. Returned Parameters Size dwCurScanTime DWORD dwMinScanTime dwMaxScanTime dwAvgScanTime DWORD DWORD DWORD dwLimitMaxScan dwIECCycleCount DWORD DWORD Description Task cycle time (execution) with 1 µs resolution. Task cycle minimum time with 1 µs resolution. Task cycle maximum time 1 µs resolution. Task cycle average time with 1 µs resolution. Task cycle maximum time before watchdog occurrence. IEC cycle counter. Table 210: GetTaskInfo Output Parameters Possible ERRORCODE: NoError: success execution; TaskNotPresent: the desired task does not exist. Example of utilization in ST language: PROGRAM UserPrg VAR sAppName : STRING; psAppName : POINTER TO STRING; sTaskName : STRING; psTaskName : POINTER TO STRING; pstTaskInfo : POINTER TO stTaskInfo; TaskInfo : stTaskInfo; Info : ERRORCODE; END_VAR //INPUTS: sAppName := 'Application'; //Variable receives the application name. psAppName := ADR(sAppName); //Pointer with application name. sTaskName := 'MainTask'; //Variable receives task name. psTaskName := ADR(sTaskName); //Pointer with task name. pstTaskInfo := ADR(TaskInfo); //Pointer that receives task info. //FUNCTION: //Function call. Info := GetTaskInfo (psAppName, psTaskName, pstTaskInfo); //Variable Info receives possible function errors. 246 6. MAINTENANCE 6.2. Graphic Display The graphic display available in this product has an important tool for the process control, as through it is possible to recognize possible error conditions, active components or diagnostics presence. Besides, all diagnostics including the I/O modules are presented to the user through the graphic display. For further information regarding the diagnostic key utilization and its visualization see One Touch Diag section. On figure below, it is possible to observe the available characters in this product graphic display and, next, its respective meanings. Figure 149: CPU Status Screen Legend: 1. Indication of the CPU status operation. In case the CPU application is running, the state is RUN. In case the CPU application is stopped, the state is STOP and, when is stopped in an application depuration mark, the state is BRKP. For further details, see CPU Operating States section. 2. COM 1 traffic indication. The up arrow () indicates data transmission and the down arrow () indicates data reception. For further information regarding the COM 1 interface see Serial Interfaces section. 3. Indication of the CPU active diagnostics quantity. In case the number shown is different than 0 (zero), there are active diagnostics in the CPU. For further details regarding their visualization on the CPU graphic display, through diagnostic key, see One Touch Diag section. 4. Forced variables in the CPU indication. In case the "F" character is shown in the graphic display, a variable is being forced by the user, whether symbolic, direct representation or AT. For further information regarding variable forcing see Writing and Forcing Variables section. Besides the characters described above, Nexto CPUs can present some messages on the graphic display, correspondent to a process which is being executed at the moment. The table below present the messages and their respective descriptions: Message FORMATTING... FORMATTING ERROR WRONG FORMAT INCORRECT PASSWORD TRANSFERRING... TRANSFERRING ERROR TRANSFERRING COMPLETE TRANSFERRING TIMEOUT CPU TYPE MISMATCH Description Indicates the CPU is formatting the memory card. Indicates that an error occurred while formatting the memory card by the CPU. Indicates that the memory card format is incorrect. Indicates the typed password is different from the configured password. Indicates the project is being transferred. Indicates there is been an error in the project transference caused by some problem in the memory card or its removal during transference. Indicates the transference has been executed successfully. Indicates a time-out has been occurred (communication time expired) during the project transference. Indicates the CPU model is different from the one configured in the project within the memory card. 247 6. MAINTENANCE Message VERSION MISMATCH APPLICATION CORRUPTED APPLICATION NOT FOUND CRC NOT FOUND MCF FILE NOT FOUND NO TAG NO DESC MSG. ERROR SIGNATURE MISSING APP. ERROR RESTARTING APP. NOT LOADED LOADING APP. WRONG SLOT FATAL ERROR HW-SW MISMATCH UPDATING FIRMWARE RECEIVING FIRMWARE UPDATED UPDATE ERROR REBOOTING SYSTEM... Description Indicates the CPU version is different from the one configured in the project within the memory card. Indicates the application within the memory card is corrupted. Indicates there is no application in the memory card to be transferred to the CPU. Indicates that the CRC application does not exist. Indicates there is no MCF file in the memory card. There is no configured tag for the CPU in the MasterTool IEC XE. There is no configured description for the CPU in the MasterTool IEC XE. Indicates that there are error(s) on diagnostics message(s) of the requested module(s). Indicates the product presented an unexpected problem. Get in contact with Altus Technical Support sector. Indicates that occurred an error in the application and the Runtime is restarting the application. Indicates that the runtime will not load the application. Indicates that the runtime will load the application. Indicates that the CPU is in an incorrect position in the rack. Indicates that there are serious problems in the CPU startup such as CPU partitions that were not properly mounted. Please, contact Altus customer support. Indicates that the CPU hardware and software are not compatible because the product presented an unexpected problem. Please, contact Altus customer support. Indicates the firmware is being updated in the CPU. Indicates the updating file is being transferred to the CPU. Shows the firmware version updated in the CPU. Indicates an error has occurred during the CPU firmware updating, caused by communication failure or configuration problems. Indicates the CPU is being restarted for the updating to have effect. Table 211: Other Messages of the Graphic Display 6.3. System Log The System Log is an available feature in the MasterTool IEC XE programmer. It is an important tool for process control, as it makes it possible to find events on CPU that may indicate error conditions, presence of active components or active diagnostics. Such events can be viewed in chronological order with a resolution of milliseconds, with a storage capacity of up to one thousand log entries stored in the CPU internal memory, that can't be removed. In order to access these Logs, just go to the Device Tree and double-click on Device, then go to the Log tab, where hundreds of operations can be seen, such as: task max cycles, user access, online change, application download and upload, application synchronization between CPUs, firmware update between another events and actions. In order to view the Logs, just need to be connected to a CPU (selected Active Path) and click on . When this button is pressed the Logs are displayed and updated instantly. When the button is not being pressed the Logs will be hold in the screen, it means, these button has two stages, one hold the logs state being updated and in the state the updating is disabled. To no longer show the Logs, press . It is possible to filter the Logs in 4 different types: warning(s), error(s), exception(s) and information. Another way to filter the messages displayed to the user is to select the component desired to view. 248 6. MAINTENANCE The Log tab's Time Stamp is shown by MasterTool after information provided by the device (CPU). MasterTool can display the Time Stamp in local time (computer's time) or UTC, if UTC time checkbox is marked. ATTENTION If the device's time or time zone parameter are incorrect, the Time Stamp shown in MasterTool also won't be correct. For further information about the System Logs please check the MasterTool IEC XE User Manual MU299609 and the RTC Clock and Time Synchronization subsection of this manual. ATTENTION The system logs of the Nexto Series CPUs, starting in firmware version 1.4.0.33, are reloaded in the cases of a restart of the CPU or a reboot of the Runtime System, that is, it will be possible to check the older logs when one of these situations occurs. 6.4. Not Loading the Application at Startup If necessary, the user can choose to not load an existing application on the CPU during its startup. Just power the CPU with the diagnostics button pressed and keep it pressed for until the message "APP. NOT LOADED" is shown in the screen. If a login attempt is made, MasterTool IEC XE software will indicate that there is no application on the CPU. For reloading the application, the CPU must be reset or a new application download must be done. 6.5. Common Problems If, at power on the CPU, it does not work, the following items must be verified: Is the room temperature within the device supported range? Is the rack power supply being fed with the correct voltage? Is the power supply module inserted on the far left in the rack (observing the rack by the front view) followed by the Nexto Series CPU? Are there network devices, as hubs, switches or routers, powered, interconnected, configured and working properly? Is the Ethernet network cable properly connected to the Nexto CPU NET 1 or NET 2 port and to the network device? Is the Nexto Series CPU on, in execution mode (Run) and with no diagnostics related to hardware? If the Nexto CPU indicates the execution mode (Run) but it does not respond to the requested communications, whether through MasterTool IEC XE or protocols, the following items must be verified: Is the CPU Ethernet parameters configuration correct? Is the respective communication protocol correctly configured in the CPU? Are the variables which enable the MODBUS relations properly enabled? If no problem has been identified, consult the Altus Technical Support. 6.6. Troubleshooting The table below shows the symptoms of some problems with their possible causes and solutions. If the problem persists, consult the Altus Technical Support. 249 6. MAINTENANCE Symptom Does not power on CPU Screen shows the mes- sage WRONG CPU SLOT Does not communicate Possible Cause Lack of power supply or incorrectly powered. CPU in a wrong position. Damaged CPU or rack. Bad contact or bad configuration. Solution Verify if the CPU is connected properly in the rack. Power off and take off all modules from the bus, but the power supply and the CPU. Power on the bus and verify the power supply functioning, the external and the one in the rack. Verify if the supply voltage gets to the Nexto power supply contacts and if is correctly polarized. The CPU must be placed in slots 0 and 1 of rack 0. Put there in the correct position, turn it off and on again. Replace the CPU or rack unit and see if the problem persists. Verify every communication cable connection. Verify the serial and Ethernet interfaces configuration in the MasterTool IEC XE software. Table 212: Troubleshooting 6.7. Preventive Maintenance It must be verified, each year, if the interconnection cables are connected firmly, without dust accumulation, mainly the protection devices. In environments subjected to excessive contamination, the equipment must be periodically cleaned from dust, debris, etc. The TVS diodes used for transient protection caused by atmospheric discharges must be periodically inspected, as they might be damaged or destroyed in case the absorbed energy is above limit. In many cases, the failure may not be visual. In critical applications, is recommendable the periodic replacement of the TVS diodes, even if they do not show visual signals of failure. Bus tightness and cleanness every six months. For further information, see Nexto Series Manual - MU214600. 250