Jump to content
  • PLC programming technology and HMI interface design English database

    PLC, DCS, HMI and SCADA product application technical articles

    xiangjinjiao
    In the previous article, we talked about what a UDT is, how to create User-Defined Data Types (UDT), and the advantages of using UDTs in your project. In this article, we will show one way to use UDT in your PLC programming.
    Contents:
    Old tank simulator function block. New tank simulation FB with UDT. Calling the new tank simulation FB. Adding a new tag to the UDT. Conclusions. UDT in PLC Programming
    In our last few articles, we used the same tank simulator system to explain many concepts, like closed-loop control and PID controllers. In this article, we will use the same tank simulator to show how we can use the concept of UDTs in our programming.
    Old Tank Simulator Function Block
    In the old tank simulator system we defined some internal parameters for the sake of reusing the function block as many times as we wanted. See picture 1.

    picture 1. Tank simulator FB.
    As you see from the picture, in the function block interface we defined some inputs and some InOuts, these parameters should be provided when the FB is called.
    For example, if we called the FB to simulate tank 1 and called it again to represent tank 2, we need to provide the parameters for each tank to the related called function block. See picture 2.

    picture 2. Simulation of tank 1 and tank 2.
    You can see that for each FB call, we have to assign the related tags. For tank 1 simulation we should assign tags of tank 1 to the called FB. And the same for the tank 2 simulation.
    New tank simulation FB with UDT:
    Now, we want to use the UDT “Tank” that we defined in the last article to simulate our tanks. We will create a new simulation function block. See picture 3.

    picture 3. Add new tank simulation FB.
    The new simulation function block has the same logic as the old FB, but in this simulation function, we will use the defined UDT “Tank” as an InOut internal tag as you see from the picture.
    So instead of having your function block parameters declared in the different areas of the FB interface, now it will be just one tag that carries all needed information of the tank.
    Calling the new tank simulation FB:
    To call the new simulation function, we choose to call it inside a cyclic interrupt OB, to make sure the execution of the function block is not affected by the main logic OB1 cycle time as we explained with PIDs.
    So we need to first create a new cyclic interrupt OB. See picture 4.

    picture 4. Adding a cyclic interrupt to call tanks 3 and 4.
    You can choose the cyclic time as you see fit, in our case we set it to 3000 microseconds or 3 milliseconds.
    Now, you can drag and drop your “Tank Simulator with UDT” FB into your cyclic interrupt to call the FB. A call option window will appear, giving the FB data instance whatever name you like. See picture 5.

    Picture 5. Call your FB.
    After calling the FB, you know need to assign the parameters related to the tank you want to simulate. See picture 6.

    picture 6. Assign tank parameters to the FB call.
    Notice that you have only one parameter to fill for the function block. And it is the UDT tag that you have created. Which already contain all tank parameters that the function block needs.
    We want to simulate Tank_03 so we will assign the tag to the FB call. See picture 7.

    picture 7. Drag and drop your tag.
    The function block call for tank 3 looks simpler than the call of tank 1 with the old simulator FB without UDTs. See picture 8.

    picture 8. Tank 1 and tank 3 calling differences.
    Can you see the difference between the two tanks calls? You have to provide all the parameters of the function block in the case of without UDTs. imagine if you have to simulate 50 tanks with this simulator. It will be very boring and time-consuming to assign all these parameters, not to mention, to declare them first for each tank.
    But in the case of the simulator with UDTs, you can call as many as you want and it won’t take much time or effort. See picture 9.

    picture 9. Calling many other tanks.
    Now, imagine that you have to add a new variable to your simulation. For example, you want to add an Outflow Warning signal. With the old simulator function block without UDT, This will mean that you have to declare this new tag for each tank and you have to add it one by one to each time you call a tank.
    But with UDTs, you only need to update the UDT you created and add the new tag you want. See picture 10.

    picture 10. Adding a new tag to the UDT.
    When you make any changes to the UDT, you won’t even need to update the function call. Because the call parameter is the same, the changes were made inside the parameter itself. See picture 11.

    picture 11. No need to recall the FB.
    However, you still need to recompile your PLC project or at least the data block so the changes to the UDT can be updated. See picture 12.

    picture 12. Recompile to update the changes to the UDT.
    After you compile all the changes to the UDT will be automatically updated to all declared tags of this UDT. See picture 13.

    picture 13. All tags are now updated.
    Conclusion
    You can use the UDTs in your project to make your programming faster and easier to follow. Using UDTs will also make it easier to make changes to your functions and function blocks.

    leikang
    When you are working in a PLC system, it is necessary to understand what faults occur in the PLC modules. If a PLC programmer does not understand what fault is coming in the PLC and how to solve it, then he will take a very long time to troubleshoot the system.
    Every PLC and its modules have LEDs on them for visual easing and troubleshooting. Their detailed description is also given in their user manuals. So, it is important to understand how these LEDs function and once you get them, fault diagnosis becomes a very easy task for PLC programmers.
    In this post, we will learn the concept of fault diagnosis in PLC.
    PLC Fault Diagnosis
    Let us have a look at some of the most general types of faults which can be identified with PLC LED’s:
    Run LED is used to denote whether the module is functioning properly or not. If it is on continuously, then it means that the module is working properly. If this LED is off, then the module is faulty or off.
    Err LED is used to denote whether the module is in error or not. If it is on continuously, then it is an internal module error. If it is flashing, then it means either the module is not configured properly or there is some issue in the PLC hardware connected to it. If it is off, then it means there is no fault in the module.
    I/O LED is used to denote the exact status of the PLC IOs connected with the module. If it is on continuously, then it means there is some supply voltage error or short circuit. If it is off, then it means there is no error in the IO’s connected.
    Channel LED is used to show the status of individual channels. If the LED is on continuously, then it means the channel is functioning properly. If it is flashing, then there is some error in it (broken wire or value out of range). If it is off, then it means the channel is not configured at all.
    Some communication modules like Modbus RTU have a truth table of the LEDs, signifying each value of the same.
    LED Indications in PLC
    They are mostly as in the below table:

    Note: The LED indications may vary based on the PLC model and brand. The above table is an example from one of the PLC models in the market.
    Some communication modules like Modbus TCP/IP have slightly complicated LED diagnostics. But it is important to understand them for troubleshooting.
    The module is running if the run LED is on and stopped if the LED is off. If Err LED is flashing, then it means the module is in error and if it is flashing, then it means either the module is not configured properly or there is some issue in the backplane if it is connected.
    If the network status LED is off, then it means that the module is not communicating with any device; if it is on, then it is communicating with at least one device; if it flashing, then it means some duplicate IP address has been detected or some time out error.
    In this way, we saw some general fault diagnoses in PLC.

    leigehong
    We all know how PLC is important in today’s automation era, so many popular PLC brands are there i.e. Siemens, Yokogawa, AB, ABB, GE, etc. On these PLC controllers, so many LED indications are provided to understand different states of the controller, but to know the status first we need to understand the meaning of those indications.
    LED Indications on GE Make PLC
    In this article we are going to understand LED indications of one of GE PLCs, specifically for the CPL series, also we will understand the functioning of various ports available on the controller.
    In this article, we are going to explain about LED indications of the CPL-410 model of GE make PLC.
    About CPL 410 Model
    This PAC (Programmable Automation Controller) system which is called RX3iCPL410 is facilitated with an inbuilt Linux server, it supports programming languages like Ladder logic, Structured text, Functional block diagram, and C.
    Contains 64Mb of configurable data and program memory, 32K bits for discrete input & output, and 32K words for analog input & output. Bulk memory also supported for data exchange
    It supports up to 768 program blocks, one block having 128KB in size, also it supports 4 Nos of independent ethernet LAN (10\100\1000).
    Up to 32 Nos Modbus TCP IP clients are permitted, 48 Nos of SRTP (Service Request Transport Protocol) can run simultaneously, and 16 simultaneous Modbus TCP IP server connections.
    This PLC can handle operating temperatures up to -40 to 70 Degrees C, it is a DIN rail mount device, supports an 18-30 VDC supply, and does not require a special power supply.
    It has been facilitated with five ethernet ports in front and one RJ45 connection on the bottom side, An OLED display is available to navigate and monitor various statuses of the CPU, also many switches with LED indications are available to monitor the status and go through the settings.
    We can program and configure the CPU using Proficy Machine Edition software, this system can easily create and redundant system with a 100ms cutover time to the secondary PLC.
    Okay, so now we are going to discuss the LED indications for this particular GE PLC model CPL-410.
    In the below image we can see a lot of indications and communication ports, in Fig 1 PLC is without any connections and Fig 2 is with running communication channels.

    Fig 1 (Left) and Fig 2 (Right)
    So, Let’s Start from the top-right corner.
    µSD: This slot is to insert a Micro-SD card; the Micro SD Card is used for external storage or load programs; it has a protective cover to prevent damage.
    DISP: You can access to Display menu navigation on OLED Display and make changes as per requirement, using this button you can access LAN Settings, Control status, I/O Status, Device information, Linux OS settings, Redundancy information, and Redundancy commands, we can check configured IP of each LAN connection.
    SEL: You can guide to selection with this indication cum button for any setting modification where you can navigate your options as per your requirement.
    RUN:  Being used to run commands to PLC, it activates the OLED menu to select RUN enabled or RUN disabled mode from the PLC, in Run condition green indication will blow just below to run button.
    STOP: It is being used to send a Stop command to PLC, you can select Stop Enabled or Stop Disabled by using this button for PLC.
    PHY PRES: TPM (Trusted Platform Module) Physical Presence indication cum selection, this will blow the green light in healthy condition.
    SSD: Solid State Disk Activity, Green indication in healthy condition. This is for checking the healthiness of Solid State Disk or drive where data is being stored.
    TEMP: This indicates that the controller met with overtemperature, it will indicate an amber LED indication when the temperature goes beyond the limit.
    OK: This signal indicates that the CPU is OK and in Healthy condition.
    OE: Output enabled, green indication when it is OK.
    FRC: When we apply force to any module or equipment, a yellow indication will glow which shows that the Force signal is enabled.
    FLT: This indication will glow with a red light when a System Fault is present, A system fault happens in case of an issue with any module.
    IO:  This LED indicates the healthiness of IO network status; green indication will glow in healthy condition.
    RACT: A redundant system is a must to avoid process failure in case of any issue with the primary controlling system, also close monitoring is required on the redundant system to ensure availability all the time, RACT LED indication will indicate that Redundancy active or Active redundant unit, indication will be green when redundant devices are active, this LED will be getting activated once Hot Stand by Redundant CPU is ready.
    RBOK: This indicates that the Redundant Backup Unit is OK, the indication will be green.
    GPOK: After Linux booted successfully and restarted the CPU, This LED indication will blink green and indicate that the General purpose is OK, i.e., an Operating system in healthy condition or ready for user logins or we can say that Linux is running.
    PWR: Power is ON, also we can reset the controller with this button, we have to hold the PWR button to reset the PLC, in healthy condition it will glow green.
    Communication Ports in PLC
    Let’s have some understanding about communication ports:
    USB1: This port is assigned to Linux and it can be used to have access to keyboards, Memory sticks, Pen drives, and other memory devices with properly installed drivers.
    USB2: This port is assigned to the controller runtime PACS (Programmable Automation Controller)
    LAN: LAN ports are being used to configure plant communication packages and Hot Standby redundancy where two LAN3 group ports are being used to fulfill this purpose. they provide a high-speed data synchronization link between the two CPUs. Connect the upper LAN3 port of the Primary CPU to the upper LAN3 port of the Secondary CPU and connect the lower LAN3 port of the Primary to the lower LAN3 port of the Secondary.
    Front panel LAN:
    -LAN-1: This port is un-switchable and connects to the uppermost RJ45 connector.
    -LAN-2: Connects in middle two RJ45 connectors and it can switch internally.
    -LAN-3: Will connect in lower two RJ45 connectors, these ports are also able to switch internally, this port is being used to provide hot standby redundancy to the system.
    Underside LAN:
    -RJ45: This port supports Serial IO protocol, also this port is assigned to the Linux system itself.
    LAN Port’s speed and healthiness of link is very crucial for proper communication, let’s have a look at the upper and lower indications of LAN port and the meaning of that indication.
    LAN Ports-Status (upper indication): Green indication: The corresponding link has been established, Blinking green: Traffic detected, Off, No connection.
    LAN Ports-Speed (lower indication): Green On: Data speed is 1 Gbps or 100 Mbps, Off: Network data speed is 10 Mbps
    See the below figure to understand indications for LAN ports.

    Fig 3
    Other Ports Available on the Bottom Side of PLC
    RJ45: This is a serial COM port, where we can connect a communication channel with an RJ45 connector, we can use this port for direct ethernet connection, or we can communicate Modbus or serial communication channel using a TCP IP converter (Serial to Ethernet). Kindly note that the RJ connector comes with 8 pins and connect with wires which are combined in twisted pair, this twisted pair help to decrease cross talk and cancel electromagnetic interference.
    Below ports are available on the bottom side of PLC (Fig.4)

    Fig 4
    Display Port:  It’s a Video Display Port, we can use this port to transmit video and audio simultaneously, or separately. DP can transmit signal in rage to 144Hz to 4k.
    EFA: This is an IICS (Informatica Intelligent Cloud Services) Cloud port, this is could cloud-based service for integration and data management, using this platform you can configure connections, create users, run, schedule, and monitor activities or tasks.
    EPCSS:  Energy Pack Control & Status Signal, it’s a terminal block with 5 Nos of wiring terminals. Although EPCSS is optional to use when it is used, it allows the PLC Controller to save its current state upon loss of power.
    24DC IN: Three-wire terminal block for 24V DC power supply to PLC.
    Let’s have a look at the summary of all LED indications in Fig. 5

    Fig 5
    So, this was a basic understanding of LED indications and various ports of GE make PLC.

    leizuofa
    When you are developing a PLC program, you need to ensure that it is tested and validated properly before showing it to the customer. This is because a PLC program has many parts in it, like logic, configuration, settings, etc.
    So, it is necessary to test and validate each and every part, regardless of which program will malfunction. If there are bugs in configuration or logic, then the system will malfunction at the site.
    To avoid this, most programmers spend hours testing the PLC logic and it is a very important step done by them. In this post, we will learn the testing and validation process of PLC development.
    Testing and Validation in PLC Development
    Some of the points related to PLC testing and validation are mentioned below.

    Gather stakeholders for an initial meeting to discuss the scope, objectives, and requirements of the PLC project. Formulate the objectives and acceptance criteria for both testing and validation. Allocate resources, including team members, hardware, and software tools, required for the testing and validation process. Prepare detailed functional design specifications (FDS) that will serve as the foundation for PLC program development and testing. Develop the initial code blocks and routines based on the functional design specifications. Write test plans specifically for unit testing, identifying what each unit should accomplish and how to test it. Execute the unit tests, following the test plans and recording results for each function or routine. Create test plans for integration testing, outlining how different code blocks and routines will be combined and tested as a single entity. Perform integration testing, validating the whole program’s functionality and interoperability with other systems. Develop the FAT protocol, specifying the criteria that the system must meet to be considered acceptable. Conduct the FAT based on the FAT protocol in a simulated environment to ensure all requirements are met. Draft detailed validation protocols that define how validation will be carried out, what will be checked, and what constitutes acceptable results. Review the validation protocols and obtain approvals from quality assurance and other stakeholders. Implement the validation protocols, document results, and identify any deviations or failures. Create a SAT protocol, focusing on the real-world environment where the PLC system will operate. Conduct SAT to verify that the PLC system works reliably in its intended operating environment. Prepare comprehensive documentation of the testing and validation activities, results, and any corrective actions taken. Obtain final approval from all stakeholders, ensuring the PLC system is both tested and validated. Set up processes to monitor the PLC system’s performance and schedule regular re-testing and re-validation activities. Archive all PLC project documentation and code, and formally close out the project. The above steps provide a simple guide for preparing testing and validation in a new PLC development project.
    Let us have a look at some important steps one by one which need to be followed till the end for proper functioning.
    IO Mapping
    PLC functions according to inputs and outputs. So, the very first step in testing the program is checking IO mapping in PLC. You have to either force each digital input on the simulation or give actual hardware input to the PLC.
    One by one, if the mapping is proper, then the same will be reflected in your graphics and program. This verifies digital inputs. Follow the same process for analog inputs. But, for analog inputs, you have to give multiple raw counts rather than just one count.
    A wide range of counts gives you a proper idea of whether the channel is functioning properly or not. Then, for digital outputs, you have to force them one by one. If the PLC outputs are turning on and off according to the sequence, then your DO mapping is proper.
    Follow the same process for analog outputs and give a wide range of raw counts instead of a single count. You will get a proper idea of whether the AO channel is functioning properly or not.
    Communication Protocols Checking
    Once the IOs have been verified in the PLC program, the next step is to check communication and network addresses. Suppose a PLC has an Ethernet port and a Modbus RTU port. You have connected an HMI to the Ethernet port and three VFDs to the Modbus port. Modbus port is being used to transfer and receive data with VFD, like current, frequency, voltage, etc.
    These mappings have been done by you in the PLC logic. You have to first check the Ethernet port by testing whether the IP is pinging or not; and whether it is communicating with HMI or not. Then, you have to establish Modbus communication and check whether the data is being communicated properly with PLC or not.
    This clears your hardware part completely because you can now communicate data properly to the field; either through hard IO or soft IO. These two basic steps are the first step in your validation.
    Manual Mode
    Some systems have manual mode without critical interlocks and some systems have manual mode with critical interlocks. To check manual mode, you have to turn on each and every output step by step and check whether the actual physical output is turning on or not.
    This first step verifies whether the physical DO or AO has been properly linked with manual mode buttons or not. Then, you have to generate corresponding alarms and check whether the output is turning off or not.
    Only the linked outputs should turn off. The remaining outputs should not be impacted. This ensures that all the outputs have been linked properly in the program with proper interlocks. Because, once the manual mode has been cleared, it will be confirmed that the physical outputs can be turned on manually and auto mode can then be checked more easily.
    Directly checking auto mode logic will confuse the programmer as to what output is getting on or off. Verifying manual mode will ensure that individual outputs are being turned on or not.
    Auto Mode
    The next big step is checking auto mode. The auto mode comes as a verifying sequence with interlocks. Every system is given a control logic document that shows how the sequence works with proper interlocks and output matrix.
    The PLC programmer has to ensure that when any sequence is running, the corresponding outputs are turning on / off accordingly or not. Also, the sequence is running properly with interlocks or not?
    Auto mode logic when made must be mostly divided into four parts
    Turning on the outputs, Writing the sequence flow, Linking interlocks and alarms, and Showing the current running status. This technique makes the program flow very easy to look at and troubleshoot.
    One should try to avoid the constant use of set–reset coils and ladder logic. Ladder logic is easy to use, but when run in simulation online, it consumes time to troubleshoot.
    Also, set-reset coils are difficult to manage, because once a set coil is used, then care must be taken to reset it somewhere. Otherwise, the bit will remain set if the condition is not written properly.
    In this way, we saw the testing and validation process in PLC development.

    xiangjinjiao
    PLC programming has five types of languages – ladder logic, instruction list, structured text, functional block diagram, and sequential flow chart. Each type of PLC language has its own merits and demerits. While some of the languages look good visually and are easy to troubleshoot, other languages have lower memory consumption and faster processing speed.
    One of the most basic PLC languages used is the instruction list. It is not as famous as other languages and is used only by a few PLC programmers due to outdated technology, but still available in almost all the software of PLC manufacturers. In this post, we will see the concept of instruction list language in PLC.
    What is an Instruction List?
    A PLC program written in Instruction List language consists of a series of instructions that are executed sequentially by the logic controller. Each instruction is represented by a single program line and consists of the following components:
    Line number Current value (in online mode only) Instruction operator Operand(s) Optional comment Basically, if you have seen traditional assembly language used in microprocessors, then you would easily relate to this language. It can also be termed as a mixture of ladder logic and structured text. Ladder logic in the sense that instructions must be written in a linear way, and structured text in the sense that mnemonics are used in words.
    Refer to the below image for more understanding. The first image shows a PLC logic written in ladder language. The logic is – %M3 will turn on if %M0 is on and %M1 is on or %M2 is on.

    Now, refer to the below logic for the instruction list. You can see that each line has only one component – the first line has %M0, and the second line has %M1 doing AND logic with the next line.
    The third line has %M2 doing OR logic with the previous line, the fourth line closes the commands and the fifth line turns on the output %M3. It is thus a representation of both the ladder logic and structured text.

    Components of Instruction List
    The main components of a PLC instruction list are mentioned below.
    Line number – Four-digit line numbers are generated when you create a new program line and are managed automatically by the software. It can be seen in the above figure as 0000 to 0004. Current values – In online mode, you can see the current values of each element, as shown in the below figure. It is indicated as true or false in the below image during online animation. Instruction operators – This operator is a type of command for executing an instruction. It can also be termed as the input side and output side of the logic written. It is a mnemonic symbol that is used to denote the type of command to be performed on the output side, and also how the output side will execute it. For example, in the above image, LD stands for load which starts the execution by loading the value of the first bit, AND / OR denotes logical instructions and ST denotes storing values of the result in the destination bit. Comment – This is optional. It allows the programmer to write any comment to help him troubleshoot the logic easily.
    Instruction List in PLC Programming
    Some of the instructions list of PLC are mentioned below.
    LD – Loads the Boolean value of the operand into the accumulator. LDN – Loads the negated Boolean value of the operand into the accumulator. LDR – Loads the Boolean value of the operand into the accumulator when the value changes from 0 to 1 (rising edge). LDF – Loads the Boolean value of the operand into the accumulator when the value changes from 1 to 0 (falling edge). AND – It performs an AND operation between the previous result and the current operand. ANDN – It performs an AND operation between the previous result and the inverse of the current operand. ANDR – It performs AND operation between the previous result and the rising edge of the current operand. ANDF – It performs an AND operation between the previous result and the falling edge of the current operand. OR – It performs OR operation between the previous result and the current operand. NOT – It performs the inverse operation of the operand. ST – It takes the value of the result generated. STN – It takes the inverse value of the result generated. S – It does the set operation of the operand. R – It does the reset operation of the operand. Apart from these, it has other instructions too like jump, subroutine, end, AND with, OR with, etc. depending on the PLC manufacturer.
    In this way, we saw the concept of the instruction list in PLC programming.

    xiangjinjiao
    Whenever a PLC programmer visits a site for commissioning or for some service call, he must know what tools he must have with him before beginning work. This is because most of the sites are very remote and not all materials will be easily accessible if forgotten to be taken along. So, if he takes proper care and takes the necessary materials along with him, then he can get his work done easily.
    There is generally a lot of confusion when programmers read the to-do list; so, I thought to mention it simply so that they can grasp it quickly.
    PLC Programmer Tools
    The main tools required for a PLC programmer are mentioned below.
    Laptop with PLC Software Installed USB to PLC Interface Cables Ethernet Cables Screwdriver Set Electrical Test Meters (Multimeter) Wire Strippers Wire Cutters Terminal Block Screwdriver Electrical Tape Portable Hard Drive or USB Flash Drive RJ45 Crimping Tool Serial Converters (RS232 to USB, etc.) IP Configuration Tools (optional) Label Maker for Tagging Wires Industrial Ethernet Switch Loop Calibrator for Analog Signals Insulated Pliers Notebook and Pen for Documentation Portable Printer for On-Site Labels Anti-static Wrist Strap Note: The tools required can vary depending on the specific PLC brand, model, and the nature of the site work. Always ensure to also carry the necessary personal protective equipment (PPE).

    In this post, we will see the tools required for a PLC programmer to carry at the site.
    Proper Laptop
    This is the first and foremost basic requirement. A poor laptop with a broken screen/hardware or slow RAM performance or low in memory can hamper the work of the programmer badly. All the pre-requisite software must be present in the laptop, which the programmer has used of.
    Any incorrectly installed software can break down his work in a very bad way. All his communication ports must function properly. The laptop charger must be proper. Apart from this, the network adapters like Wi-Fi must be functioning properly.
    Programming Cables
    When a PLC programmer goes to the site, he is basically going to connect to some automation device. For that, all the pre-requisite programming cables must be present along with him. He must check these cables at the office before going to the site.
    For example, if a PLC has a USB port, LAN port, and RS485 port, then he must at least carry USB and LAN cables, which are easily available. Carrying only one cable is risky.
    Pen drive / Portable Hard Disk
    External storage is a must requirement because you can require it anytime for transferring files or storing backups. The storage must have adequate free space for storing data whenever required.
    Nowadays, many automation devices come with a USB (pen-drive) port; so carrying it is an added advantage for safety, if the cables don’t work.
    Mouse
    At the site, PLC programmers most of the time face pressure to complete tasks on time. Working with laptop touchpads consumes a lot of time.
    Also, graphic designing becomes hectic with a laptop touchpad. So, carrying a USB mouse along helps them to complete the task very easily.
    Screwdriver Set
    A screwdriver is a very important tool for a PLC programmer. If he faces any wiring issues at the site or if the wireman needs some extra help from him, then screwdrivers of various sizes will be very useful.
    Also, the PLC programmer can independently work on some electrical wiring without the help of someone, to quickly resolve any issue.
    Wire Stripper
    Similar to screwdrivers, wire strippers also play an important role. If there comes a sudden requirement for a lot of wiring to be done, then a PLC programmer can independently do it by just stripping wire ends and doing the wiring as required.
    Network Connectivity
    As a PLC programmer can require online support access many times, it is required that the SIM card has enough data and the speed must be good enough to support it.
    Usually, there are chances too that the SIM card you have will have limited access to the site. In this case, take the help of local engineers for their data, or even better, you can carry a network dongle for optimum usage.
    Stationary Items
    It would be good if the PLC programmers carries stationery items like notepads, pens, markers, etc. for their writing purposes. Many times, writing something during work helps programmers remember things during stressful conditions.
    Also, as there is constant pressure from customers to get the work done, writing things makes the work easier for programmers.
    In this way, we saw the necessary tools required for a PLC programmer to carry at the site.

    xiangjinjiao
    In industrial automation, there are three types of IOs – Local, Remote, and Distributed. It defines whether the IOs are in a local electrical panel or a remote network panel. It is decided based on the location of field instruments from the panel. Different types of automation manufacturers have corresponding modules in their make, for working with remote IOs.
    One such famous brand is Rockwell. In Rockwell PLC, the most used network adapter for IO communication is the AENT module. This module can be connected at a location other than the local PLC and is connected to it through Ethernet communication. The corresponding IOs are interfaced with the AENT module.
    In this post, we will see the concept of the AENT module in Rockwell PLC.
    AENT Module in Rockwell PLC

    As discussed earlier, an AENT module is a type of remote IO adapter. The module does not have any CPU in it; it is just a network interface used to communicate field IO’s with the main PLC through Ethernet IP protocol. That means no logic can be written in the module as it will only read and write data of IO modules configured with it to the main PLC CPU.
    You can connect a maximum of 64 IO modules with an AENT module, for interfacing. It is generally identified by the 1734-AENT series. Not only IO data, but you also get each and every diagnostic of the IO’s through this module. This makes troubleshooting much easier.
    The module communication takes place through Ethernet IP protocol, and it has RJ45 ports in it for this. It can communicate in either half-duplex or full-duplex mode. The standard power supply for this module is 24V DC.
    IP Address Configuration
    There are three general methods through which IP address is set in the module –
    By setting the switches on it (it has three numbers which denote the last three digits of the IP address) Using BootP/DHCP software available from Rockwell Using IP configuration software available from Rockwell. Once you set the IP address, you can then use the module for your communication with the main PLC.
    In the PLC software (Studio 5000), the IO modules must be configured in this AENT module. These modules then communicate their IO status to the main CPU through the AENT module. This module can be used in star topology or tree topology.
    LED Diagnostics
    The module has the following LED in it for diagnostics – module status, network status, network activity, POINT Bus status, System power, and Field power. You can get a detailed description of each of the LEDs by reading its catalog. This helps in the detailed troubleshooting of the module.
    One thing to be noted is that the power supply connected to the module can drive only a maximum of 10 IO modules; so, a power supply module is required after every 10 modules connected in the AENT.
    Chassis Size
    One of the most important terms related to this module is chassis size. Chassis size means the number of modules connected with AENT. For example, if 19 IO modules are used, then you must set the chassis size in the AENT configuration to 20.
    The adapter stores this chassis size setting in non-volatile storage. When the adapter’s non-volatile chassis size does not match the actual number of modules present on its backplane, the adapter will not make any I/O connections. Also, once you are online, you are required to set this size online apart from offline configuration. After this step only you can use the module for communicating IO values with the main CPU.
    AENT module is a higher range of adapter and so, is used only with three types of PLCs – Control Logix, Compact Logix, and Flex Logix. In this way, we saw the concept of the AENT module used in Rockwell PLC.

    caixiaofeng
    In this article we will talk about decentralized Peripherals or distributed IOs, we are not going to look into the TIA Portal, we are just going to discuss what is Distributed IOs and why we need it.
    Contents:
    What are External Peripherals or distributed IOs? A simple example to explain the need for Distributed IOs. o 1 machine with a PLC on the machine.
    o 1 machine with the PLC is far away in a safe place.
    o 2 or more machines with the same PLC
    o having an already installed machine with different IO modules (GSD files)
    conclusion External Peripherals
    Distributed IO devices, are devices used in automation and control systems. They act as intermediaries between the central controller (PLC) and different sensors and actuators installed in your automation process. Imagine them as messengers that collect information from sensors and deliver commands to actuators.
    Distributed IO
    This distributed approach simplifies wiring, instead of having all the wires go directly to the PLC, you install these distributed IO devices at the machine side. They collect information from sensors (like temperature or movement) and send commands to actuators (like motors or valves). This makes the whole system work smoothly, with less wiring, and it’s also easier to manage and expand which results in improving system flexibility.
    In the next section, we will use some examples to explain the idea and the need for the Distributed IO in a simpler way.
    Simple example to explain the need for Distributed IO
    Let’s assume that we have a production machine, this machine is controlled via a PLC, any type of PLC, see picture 1.

    Picture 1. Production machine controlled via a PLC.
    As you can see, the PLC controlling the machine is installed on the field at the machine side. As we know PLCs are designed to be able to operate at harsh environments, so it is not totally a bad idea to install the PLC at the machine side, as we know it will be able to withstand the different operating conditions related to the machine, wither it is high ambient temperature, humidity, vibration, etc.
    Now, what if we need to modify our process and increase the control we have over the machine, meaning we need to increase the number of inputs and outputs of the machine, this will mean that we will need to get a bigger PLC with higher number of IOs, or at least we will need to add IOs modules to the current PLC.
    You should know that adding extra IO modules to the current PLC will depend on the PLC you have chosen for your project because each PLC has the maximum number of IOs that you can add it to the PLC.
    So if the extra number of IOs that we need will exceed the maximum number of IOs I can add to the PLC, then I will have to get a bigger PLC, and it will mean rewriting your software to the new PLC or at least migrating your project. See picture 2.

    picture 2. Bigger PLC for new machine extension.
    So, with the new extension, we had to get a bigger PLC.
    NOW, we said that the PLC can be installed in the field and it is designed to withstand harsh environments, but usually, that is not what is done, and usually, the PLC is installed far away in a well-conditioned and protected place like an MCC room.
    This means that every Input or output signal of our process will have to be connected from the machine side to the PLC is the MCC room, so if I have 100 IOs signals then I will have to pull 100 signal cables between the machine and the PLC. And if I need to make any future extension I will have to pull the extra new cables. See picture 3.

    Picture 3. Installing the PLC inside the MCC room.
    As you can see, we now have to pull a cable between the PLC and the machine for each IO signal that we have in our process. This can be acceptable in a small machine with a small number of IOs, but not so much with a large process that has many IOs.
    Because this will include pulling a large number of cables, this will increase the cost of this process and also will introduce new problems that need to be taken care of, like cable raceways, EMC compatibility, cable trays, and more extra considerations.
    And here is where the External Peripherals or Distributed IO modules become very useful. See picture 4.

    Picture 4. Using Distributed IO device.
    A distributed IO module is simply an IO module that can be installed at the machine side to collect all inputs of the process and send it to the PLC and also gets the output signal from the PLC and sends it to related actuating devices.
    As you can see from the picture, the connection between the PLC and the machine is now done by pulling a communication cable between the Distributed IO device and the PLC. Distributed IO devices have many communication capabilities, in our example, we assumed a Profinet communication, hence the green color.
    Using a Distributed IO device will give you the advantage of extending your process IOs without needing to install a larger PLC. You will just add the new IOs to your device and the communication between the PLC is still the same using the Profinet or any other communication method.
    You can even have a completely new machine controlled with the same PLC, you will just have to pull a new communication cable from the PLC to the new machine. See picture 5.

    picture 5. Controlling 2 machines with the same PLC.
    As you can see, to control a completely new machine with my PLC, I would only need one additional communication cable from the PLC and the machine. Offcourse you need to make sure that your PLC capabilities can handle processing and controlling the two machines.
    One more thing, Distributed IOs can be used with different PLC brands, meaning I can use different brands of distributed IOs with Siemens PLC. See picture 6.

    picture 6. Using different brands of Distributed IOs.
    As you can see in the picture one machine is using a SIEMENS distributed IO device and the other machine is using a Schneider distributed IO device and both of them will be controlled via the same PLC.
    Conclusion
    Distributed IO devices are used to extend the reach of a control system, allowing for the connection of a large number of sensors and actuators over long distances. Distributed IOs reduces the amount of wiring required compared to a traditional machine-PLC signal connection. It’s easy to add or remove devices in a distributed IOs system, making it highly scalable and reliable.

    caixiaofeng
    In a previous article, we gave a simple introduction to the concept of Distributed IO devices, what are they, and why we need them.
    In this article, we will show how to configure a distributed IO device in our PLC project. As usual, we are focused on the Siemens and TIA Portal systems, so we will show that using Siemens ET200S distributed IO.
    Contents:
    Hardware Configuration of Distributed IO Devices. Assign the IO module to a controller. Download the Configuration to the actual hardware Module. Hardware Configuration of Distributed IO Devices
    The hardware configuration of any Distributed IO device simply means assigning that IO device to a certain controller in your project, so that the Input signal from this IO will go to that PLC and the output command will come from that PLC.
    Let’s add a PLC to our project and see how we can proceed. See picture 1.

    picture 1. Add PLC to our project.
    As you can from the PLC we just added, the PLC already has some centralized IOs, but in this article, we assume that we have a part of the machine that is far away and I need to connect to the PLC, in that case, we would use a Distributed IO device that will be installed at the machine part and it will have all the IOs related to that part of the machine and the Distributed IO device will then communicate with the PLC via a suitable type of communication method like Profinet or Profibus.
    Distributed IO in a PLC Project
    Let’s add our ET200S device. See picture 2.

    picture 2. Add the IO module you need.
    As you can see from the picture, there are a lot of different IO modules you can choose from depending on your application.
    We will choose the standard ET200S module. See picture 3.

    picture 3. Drag and drop the ET200s module
    As you can see from the picture, just drag and drop the IO module into the Network view of your project. Note that we choose the Profinet interface for the IO module to be the same as our PLC.
    After adding the ET200S module to our project we can start adding our inputs and outputs modules to the ET200S, you can find all the IOs compatible with the chosen module from the hardware catalog bar on the right, see picture 4.

    picture 4. Add the IOs to the ET200S.
    As you can see from the picture, I can add the IOs by dragging and dropping them to the empty areas. The maximum number of IOs I can use with the ET200S depends on the type and specification of it.
    To add your inputs and outputs modules, just drag it and drop it from the hardware catalog on the right, see picture 5.

    picture 5. Drag and drop the IOs you need.
    Assign the IO module to a controller
    Now, that you added the Distributed IO module to your project, you will notice that the IO device is not assigned or connected to any Controllers. See picture 6.

    Picture 6. The added IO module is not assigned to PLC.
    Another way to see that the Distributed IO module is not assigned to any controllers is that there are no addresses assigned to my IOs. As it is not connected to any controllers, see picture 7.

    picture 7. Addresses are not defined.
    As you can see in the picture, there I and O addresses area are blank, indicating they are yet to be assigned to a controller. So we need to assign the IO module to a PLC.
    To assign the IO module to a controller, we need to go to Network view, select the IO module, then right click and press the “Assign to new DP master/IO controller”, see picture 8.

    picture 8. Assign the IO module to a controller.
    After you press the “Assign to new DP master/IO controller”, the select IO controller window will appear, where you can choose the PLC you want to assign the IO module to, in our project we only have one controller, so the window will show only one option. See picture 9.

    picture 9. Select IO controller window.
    Once you press OK, the IO module will be assigned to the PLC. And now, if you check the device view of the IO module, you will find the inputs and outputs now have been assigned addresses in the project, which means they are now belong to a certain PLC controller. See picture 10.

    Picture 10. IO module now have assigned addresses.
    Download the Configuration to the actual hardware Module
    And that is how you can select and configure a distributed IO module and assigned it to a PLC in your project.
    However, there is something that you should know,
    YES, we did assigned our IO module to the PLC, but that was only done in the software side (TIA Portal). The actual Hardware IO device still doesn’t know it is assigned to that PLC.
    That means If I downloaded my project to the PLC it will be complied and downloaded successfully, but when the PLC need to contact with the IO device to get an input or give an output command it won’t be able to find the device, even though there is a communication cable between the two. And an error will be given by the PLC.
    To solve this, I have to do something called “ASSIGN DEVICE NAME”
    To do that, just right click on the IO device and press assign device name, this will open the following window, see picture 11.

    picture 11. Assign device name.
    When you click the assign device name the “assign PROFINET device name” window will appear. See picture 12.

    picture 12. Assign device name window.
    This procedure is done with hardware devices, but as we don’t have the hardware component and only simulating we can’t see it here.
    But, simply when you choose the PC/PG interface and click update you should find your IO device, then you just choose assign device name to assign the device name to the actual IO hardware module.
    Once that is done, you can now use this IO device as a normal IO of the PLC. And you can find the IO module inside the PLC project tree because now it is part of the PLC. See picture 13.

    Picture 13. The IO module belongs to PLC project tree.

    leizuofa
    There are many ways where PLCs can communicate and talk to each other, in this article we will talk about one of these methods which is how to establish Siemens communication between PLCs using the i-device function to make PLC-to-PLC data transfer.
    What is the I-Device function?
    The I-Device function can be used to exchange data between two PLCs very easily. An I-Device is simply a PLC that is used as an IO device. That means the PLC will act as an IO module providing inputs and receiving outputs with the other PLC.
    I-device function enables PROFINET to communicate not only with subordinate devices like IO controllers, but also IO communication with other higher-level or central controllers as an IO device.
    Siemens Communication between PLCs
    Most of the S7 family PLCs support the I-Device feature but some controllers don’t depending on the firmware version for example:
    S7-300 (from firmware version V3.2) S7-1200 (from firmware version V4) You can simply know if your controller has the I-device feature or not by going into your PLC PROFINET interface properties and checking for the “operating mode” option. See pictures 1a and 1b.

    picture 1a. PLC doesn’t support I-device
    From the picture, we can’t see the “operating mode” option, so we know that PLC doesn’t support the I-device feature.

    Picture 1b. PLC supports the I-device feature
    As you see from the picture, this PLC supports the I-device feature.
    A PLC with the “Intelligent IO device” configuration is called an I-Device. An I-Device is like a standard IO device and needs to be handled like one. This means that the I-Device is also connected to a higher-level IO controller.
    So , an I-device will act as an IO module, but it is also still a PLC, so it still acts as a controller if you want it to.
    Data exchange concept
    The guiding principle of the I-Device method is to use the known process image in a CPU. From the higher-level IO controller’s view, communicating to an I-Device is similar to communicating to a distributed IO with the usual read and write processes at inputs and outputs.
    From the I-Device’s view, data transfer to a higher-level IO controller is also analog to the data transfer to the local or assigned distributed IO via inputs and outputs.
    I-device Configuration options
    There are two possibilities for configuration:
    Configuring an I-Device within a project. Configuring an I-Device that is used in another project When configuring an I-Device for another project, STEP 7 enables you to do this by exporting a configured I-Device in a GSD file. The GSD file can be imported in the other project or the other engineering system like other GSD files.
    This allows not only for communication within the project, but also communication across projects and data exchange between different manufacturers in a tried and tested way. We will show that in another article.
    In this article, we will show the Configuration of the I-device within the same Siemens PLC project.
    I-device configuration within the same PLC project
    We will assume that we have two PLCs in our project, CPU 1516-3 PN/DP which will act as the controller in this configuration, and CPU 1214C which will act as the I-device. 
    Start by adding the two PLCs into your TIA Portal project and setup a Profinet connection between them. See picture 2.

    picture 2. Setup connection between two PLCs.
    Now, we need to configure the CPU 1214C PLC as an I-device.
    You do that by going to the Profinet interface properties and from the operating mode option you click on the IO device option. See picture 3.

    picture 3. Select IO device.
    After that, you need to assign the I-device to a higher-level controller which is the CPU 1516-3 PN/DP PLC in our project.
    To do that just select that PLC from the Assigned IO controller drop-down list. See picture 4.

    picture 4. Assign the I-device to the controller.
    After that, the I-device is now connected and assigned to the controller PLC. See picture 5.

    picture 5. The I-device is assigned to the controller PLC.
    The next step is to exchange the data between the I-device and the controller with what is known as transfer areas.
    Creating a transfer area
    Transfer areas are the IO areas that are used to exchange data between the I-Device and the higher-level IO controller.
    Go to the “I-Device Communication” section. Click the first field of the “Transfer areas” column. TIA Portal will create a predefined name that you are able to change. As you can see from picture 6.

    picture 6. Create a transfer area
    Select the type of communication relationship: currently, only CD can be selected. See picture 7.

    Picture 7. Choose CD communication option.
    Once you select the CD option, a transfer area will be created and the addresses of the IO controller and I-device will be automatically created. See picture 8.

    Picture 8. Transfer area is created.
    The addresses are pre-assigned automatically, if required, you can adjust the addresses to your environment and specify the length of the transfer area to be transferred consistently.
    To create another transfer area as before, just press the “add new”, see picture 9.

    picture 9. Add new transfer area.
    As we said before, data exchange is based on the simple processing image concept, which means you always send an output and receive an input.
    Also note that the arrow you see in previous picture indicates the flow of information between the I-device and the controller. So if I send data from the controller to the I-device then the arrow will be from the controller to I-device and the address of controller will be output and address of I-device will be input and vise verse as you can see from previous picture.
    Also keep in mind that it is always better to rename your transfer areas to proper indicating names. See picture 10.

    Picture 10. Rename your transfer areas.
    Loading the PLC project
    To load the PLC project data, select both controllers one after the other in the project navigation and load the project into the respective module.
    Note that, because we don’t have actual hardware devices, we can’t simulate this feature.

    leigehong
    In a previous article, we talked about the PUT command and how we use it to communicate between two PLCs wither they are in the same project or in two different projects. In this article, we are going to talk about the GET command used for the Siemens PLC-to-PLC communication project for data exchange.
    What is the GET command?
    Just like the put command a GET command is a TIA Portal built-in function block FB that is used exclusively for S7-Family CPUs to get data from a remote partner PLC to a local PLC. Opposite to the PUT command, instead of putting data from PLC_1 into PLC_2 the GET command will get data from the PLC_2 into PLC_1.
    When using GET command, I would have two PLCs, where I need to get data from one PLC called partner to another PLC called local.  The Local PLC is where the GET command will be programmed.
    In addition to a Profinet connection between the two PLCs. Some configurations must be done to the partner PLC, to enable it to be accessed by the other PLC.
    We will create a sample project to show how to use the GET command.
    Siemens PLC-to-PLC Communication Project
    We will assume a sample project where we have two PLCs in the same project, PLC_1 which will act as the local PLC and PLC_2 which is the partner PLC.
    To create a situation where we need to use the GET command, we will assume that we want to read/get an integer from the partner PLC_2 to the local PLC_1.
    First, let’s create a new project and add the two PLCs. See picture 1.

    picture 1. Create a new project and add two PLCs.
    Now, we need to configure the partner PLC_2 to enable the GET access from PLC_1. We also need to prepare the data that will be moved from PLC_2 into PLC_1.
    First, we need to allow the access of the GET command to the PLC_2 that will give the data. See picture 2.

    picture 2. Allow GET command access.
    As you see from the picture, we allow the GET command to access the PLC_2 from the Properties of the PLC_2, in the Protection and security option, click on the
    “Permit access with PUT/GET communication from remote partner”
    Now, I am allowed to read/get data from the partner PLC_2 using the GET command.
    NEXT, we want to create the data that will be moved to the PLC_1, we assumed that PLC_1 wants to get an integer from PLC_2.
    We will define an integer tag named “ SendDataToPLC_1” this integer tag will be read from PLC_2 into PLC_1. See picture 3.

    picture 3. Define data to be moved to PLC_1
    And that is it; this is the entire configuration you need to prepare from the PLC_2 side to be able to receive data through the GET command.
    NOW, we go to PLC_1, in PLC_1 we want to create logic where we use the GET command to read data from the PLC_2.
    As we did in the last article, we will just drag and drop the GET command into our Main OB1. See picture 4.

    picture 4. Drag and drop the GET command
    Note that, the GET command is found in the S7 communication folder, as it is an exclusive function for S7 family PLC, because it involves safety issues. Remember in picture 2 when we allowed the use of GET command it was in the Security and Protection attribute of the PLC properties as it is related to PLC safety and protection.
    When you drag and drop the GET command into your, you will asked to create a data block instance as the GET command is essentially a function block FB.  See picture 5.

    picture 5. Create a data instance for the GET command.
    Now, that we added the GET command to our logic, we need to start configuring the GET block as we did before with the put command. To open the configuration views of the GET command press the small blue icon on top of the block. See picture 6.

    picture 6. Open configuration view.
    We have two main parameters to configure, the connection parameter and the block parameter. See picture 7.

    picture 7. GET block configuration.
    As you can see from the picture, the Local PLC is the PLC where the GET command is called. Whereas the Partner PLC is the one that will give the data, it is also the same one which we allowed the GET access for. In our project the partner PLC is PLC_2.
    You can see also from the picture that the partner is empty and we have to select the PLC. See picture 8.

    picture 8.  Different option in the partner list
    As you can see, we have two different options to select from for the Partner PLC.
    Unspecified is when the PLCs are of different TIA Portal project and if the PLCs are of the same TIA Portal project, then you will find the other PLC in the list. 
    When you choose the PLC_2 option as our PLCs are in the same project, the connection configuration will be automatically filled in. See picture 9.

    picture 9. PLC_2 as partner
    Because both PLCs are in the same project, when I choose the PLC_2 option, all connection parameters will be automatically filled in.
    On the other hand, if the partner PLC is from a different project, then I will choose Unspecified option, and in that case I will have to fill in some data such as the Partner PLC IP address. See picture 10.

    picture 10. Partner PLC as unspecified.
    As you can see, when the partner is Unspecified, then you will need to manually add some information such as the partner PLC IP address.
    You can also see that we need to add a subnet to the local PLC_1. To do that, you just go to the Profinet properties of the PLC_1 and select to add a new subnet. See picture 11.

    Picture 11. Add subnet for PLC_1
    After adding a new Subnet to PLC_1, the connection parameter configuration will be complete. See picture 12.

    picture 12. Connection parameter is complete.
    The next configuration we need to take care of is the block parameter.
    In the block parameter we define the data that will be moved between the two PLCs and also the trigger signal that will allow the start of execution of the GET block. See picture 13.

    picture 13. Block parameter.
    As you can see, we need to define the trigger signal for the GET block and we also need to define what data will be moved from PLC_2 (Read area ADDR_1) and where will this data go (Store area RD_1).
     We already define the ADDR_1 before which is the SendDataToPLC_1 integer tag we defined inside PLC_2.
    NOW, we will define the store area for that integer tag and the trigger signal. See picture 14.

    picture 14. Define trigger signal and store area
    After we defined the trigger signal, ADDR_1 and the RD_1, we will fill in these parameter to the block configuration. See picture 15.

    Picture 15. Fill in the block parameter
    Now, the configuration of the GET block is finished and you can see that the Block is now ready to be downloaded and run. See picture 16.

    picture 16. GET block
    The GET block is now configured and once the trigger signal is active the block will read the ADDR_1 from PLC_2 and write it into RD_1 in PLC_1.

    leigehong
    A PLC retrofitting project involves updating or replacing the old PLC (Programmable Logic Controller) system with a newer and more advanced version. This is done to improve performance, add new features, or maintain compatibility with modern technologies, all while minimizing the need to completely replace existing equipment.
    PLC Retrofitting Project
    When you are working in any system, be it industrial automation or anything else, it is not always necessary that you will commission a fully new plant.
    There are times when an old plant is not running properly as per desired results. This means not the whole system, only some parts. It may be a PLC system or electrical system or mechanical system.
    Instead of changing the whole system, it is better to replace only that part with a new one. The remaining systems will be maintained as it is. This is called retrofitting. It is a very important aspect for engineers to learn.
    In this post, we will see the steps related to retrofitting of a PLC system.
    Why is PLC Retrofitting required?

    When you have a PLC system, you are bound to be in a condition where sometimes it will fail. It’s a natural consideration for any system (not only PLC) and it does not mean that the PLC system fails every time. It is a worst-case scenario taken into the picture.
    Now, apart from PLC, the remaining systems of electrical and mechanical are working fine. The common causes of PLC system replacement needs are – repeated bugs in logic, obsolete PLC which has become failed and not available anymore in market, repeated firmware or hardware failures in PLC, and no service available.
    In these cases, instead of replacing the whole system, the best option is to replace only PLC system. This is called PLC retrofitting job. Basically, you are either upgrading the PLC to a new one or completely replacing it with a new brand.
    This reduces costing, does not impact the original working plant, saves time and increases reliability. Basically, the plant working logic will remain same; you are just replacing it with a new hardware and running the plant.
    Procedure for the PLC retrofitting project
    The very first step is to study the control panel drawing of PLC. Every PLC has its own different version of wiring and also sink-source concept. So, it is necessary that you first understand the original wiring done. This will help you to prepare new IO list according to your current PLC. Because if you go with same IP list blindly, you will mostly face wiring issues at site when you install the new PLC
    Get the old program if possible. If it is not possible, then develop a new fresh logic in office before going to site. Also, test the logic with customer or the best case, the end client. The end client will help the most because they have operated the old PLC system and can help in solving queries quickly. The customer can help in deep checking the process. If the program is tested before going to site, then it will drastically reduce your time at site.
    Try to match the screens and develop the graphics as it is with the old running ones. This will help the operators to run the plant more easily as they are used to with.
    Once your logic and graphics are ready, plan for site with the wireman. The wireman will first replace the new PLC in place of old one, and then cross check all points with multimeter. This is to ensure whether all the points have been connected or not as per new wiring. One important thing to note down is that retrofitting requires a proper shutdown, so do ensure before planning site visit.
    Once the wiring has been loop checked without power, then power up the system and download your latest programs in PLC and graphics. Now, first of all, you have to check the IO’s. This is a very crucial step, because you are replacing old wiring with new ones. All the IO’s in the field must respond in the same way as it was functioning earlier. Without this, you cannot run the plant in auto or manual mode.
    Now, check the logic written and see whether it is executing as per earlier system or not. All the safety interlocks, permissive conditions, sequences and other logic must work in the same way as old system. This must be approved by both the customer and end client for verification and mention in the report if it is working properly.
    Make all the final reports, store final backup, and take photos and videos of the running system. This ensures a completion report for the retrofitting PLC project that you have done.
    PLC Project Summary
    Evaluate the existing PLC system, identify retrofitting needs, and determine project objectives, scope, and constraints. Design a detailed new system plan, ensuring integration with existing machinery and network, and develop a migration strategy. Backup all programs, data, and documentation from the current system and prepare a recovery plan. Procure the new PLC and any additional hardware, ensuring compatibility and availability. Prepare the installation site with necessary safety measures and schedule downtime if required. Decommission the old PLC system and install the new PLC and related hardware. Transfer or rewrite program logic to the new PLC, testing all functions and communication. Perform comprehensive testing of the new system, validate performance, and make necessary adjustments. Train personnel on new system operations and maintenance, and update or create system documentation. Officially switch to the new PLC system, monitor closely for issues, and provide necessary support. Conduct a post-implementation review to assess success, document lessons learned, and plan future maintenance or upgrades.

    leikang
    In the last articles, we discussed how to establish a connection between two PLCs using the TCON and TDISCON blocks and how to move data between them using the TSEND and TRCV blocks.
    Transferring Data Across PLC Systems
    In this article, we will learn a new instruction that can be used to communicate and transferring data across PLC systems using TSEND_C and TRCV_C blocks.
    TSEND_C
    The TSEND_C instruction is a TIA Portal instruction that is used to set up and establish a connection between two PLCs. Once the connection has been set up and established, it will be automatically maintained and monitored by the PLC.
    The TSEND_C instruction is executed asynchronously and has the following functions:
    Setting up and establishing a communication connection similar to TCON block. Sending data via an existing communication connection similar to TSEND block. Terminating or resetting the communication connection similar to TDISCON. Hence, the name compact is giving to the TSEND_C as it acts as more than 3 blocks in the same time.
    TRCV_C
    The TRCV_C instruction is also a TIA Portal instruction that is used to set up and establish a connection between two PLCs. Once the connection has been set up and established, it will be automatically maintained and monitored by the PLC.
    The “TRCV_C” instruction is executed asynchronously and implements the following functions in sequence:
    Setting up and establishing a communication connection similar to TCON. Receiving data via an existing communication connection similar to TRCV. Terminating or resetting the communication connection similar to TDISCON. Hence, the name compact is given to the TRCV_C as it acts as more than 3 blocks at the same time.
    Using TSEND_C and TRCV_C in our PLC project
    In the last article, when we needed to establish and move to send data from PLC_1 into PLC_2 we had to use three different blocks in each PLC. See picture 1.

    picture 1. Logic inside PLC_1
    As you can see, we used the TCON and TDISCON blocks to establish and reset the connection and we used TSEND to send the data from PLC_1. And the same was done for the PLC_2. See picture 2.

    picture 2. Logic of PLC_2
    Again, we used the TCON and TDISCON blocks to establish and reset the connection and we used TRCV to receive the data from PLC_1. 
    Now, we want to replace all these blocks and try to use the TSEND_C and TRCV_C instead to achieve the same functionality.
    First, in PLC_1 where we need to send data, we will use the TSEND_C block, just drag and drop the block inside the main OB1. See picture 3.

    picture 3. Add TSEND_C block.
    As the TSEND_C is essentially a function block, you will be asked to create a data instance. See picture 4.

    picture 4. Create an instance for the TSEND_C
    The TSEND_C looks similar to the TSEND block in the sense that you need to make some configurations and add some signals. See picture 5.

    picture 5. TSEND_C block
    Now, we need a signal for the REQ and Data to send and also to configure the connection. For the REQ signal, we created a SendData tag.
    Also, we can just drag and drop the data block that we created last article which we need to send it to PLC_2, we can just drag it and drop at the DATA input of the block. See picture 6.

    picture 6. Configuration of TSEND_C block.
    To configure the connection parameter for the block, we can press the small configuration icon on top of the block to open the configuration view.
    The configuration view will look something very similar to that of the TCON block. See picture 7.

    picture 7. Connection parameter of TSEND_C
    We already showed how to configure the connection parameter in previous articles, so we can just do the same as we did with the TCON block, see picture 8.

    picture 8. Configuration of connection parameter
    With this connection configuration, we finished all configurations of the TSEND_C.  Notice how much faster it was compared to configuring TCON, TDISCON, and TSEND blocks.
    Now, we need to add the TRCV_C to the PLC_2 so it can receive the data sent from PLC_1.  In the main OB1 of PLC_1 just drag and drop the TRCV_C into your logic. see picture 9. Remember to create a data instance for the TRCV_C block.

    picture 9. Add the TRCV_C
    Once the TRCV_C is added to your logic, we need to configure it. As we did with the TSEND_C we need to add a signal to enable the data receive and also we need to add the data block we will save the data inside. See picture 10.

    picture 10.TRCV_C
    We defined a RecieveData tag as the EN_R signal. See picture 11.

    picture 11. Define EN_R tag
    Remember to uncheck the “optimized block access” option of the data block or the block won’t work as we showed last articles.
    Next, we need to configure the connection parameters of the TRCV_C block, as we did with the TSEND_C just keep in mind that the unspecified Partner PLC is now the PLC_1 see picture 12.

    picture 12. Connection parameter of TRCV_C
    PLC Project Simulation
    Now that we have configured the TSEND_C and TRCV_ C block, we want to simulate our project and see how they will work but first, we will create a simple logic to automatically update the data of PLC_1 which will be sent to PLC_2. See picture 13.

    picture 13. Simple logic to update data automatically.
    Now let’s compile and start a simulation for our project.  The first thing you will notice is that PLC_1 and PLC_2 will try to establish a connection right away because we set up the TSEND_C and TRCV_C they automatically try to establish a connection. That is why there will be a connection between the two PLCs. See picture 14.

    Picture 14. Connection is established directly.
    As you can see the connection between the PLCs is directly established, because the CONT parameter in the TSEND_C and TRCV_C is set to TRUE, which means the block will automatically try to establish a connection with the partner PLC. We can put any controlling signal in here to control the connection establishment.
    The other thing you can see is that the REQ of the TSEND_C and the EN_R of the TRCV_C are set to FALSE, and that is why there will not be any data moving between the PLCs. See picture 15.

    picture 15. No data transfer between PLCs.
    If the REQ signal of the TSEND_C is set to true, the PLC_1 will try to send the data but it will wait for the other PLC to enable the data to be received, see picture 16.

    picture 16. REQ is true.
    As you can see the SendData is TRUE, but no data was sent because the RecieveData is still false.
    The PLC_2 will only receive data from PLC_1 only when the ReceiveData is set to true. See picture 17.

    picture 17. Data is sent to PLC_2
    As you can see when the RecieveData is true. Data will be sent from PLC_1 into PLC_2, However, you can see that the data inside the two PLCs are different because the data of PLC_1 changes automatically as per the simple logic we made before. That means the EN_R signal allows the transfer of data one time, when I need to transfer data again this signal has to become false and then true again.
    Check out the attached TIA Portal project and see the data transfer between PLCs.

    leikang
    In this article, you will learn the PLC example to control LEDs via switches and understand the ladder logic explanation.
    This PLC example is designed for engineering students to learn and practice the ladder logic. The implementation of the same PLC program for industrial usage will be different.
    PLC Example
    Design a PLC ladder logic for the following application.
    We are using three switches to control three LED’s.
    If any 1 Switch is ON, then LED I will be ON.
    If any 2 Switches are ON, then LED II will be ON.
    If all the 3 Switches are ON, then LED III will be ON.
    In the previous article, we discussed the same PLC example using toggle switches, Learn the logic.
    Inputs
    The required digital inputs are listed below.
    Switch 1: I0.0
    Switch 2: I0.1
    Switch 3: I0.2
    Outputs
    The required digital outputs are listed below.
    Motor 1: Q0.0
    Motor 2: Q0.1
    Motor 3: Q0.2
    Ladder Diagram to Control LEDs Via Switches

    Ladder Logic Explanation
    For this application, we have used EcoStruxure Machine Expert Basic v1.2 software for the PLC programming. In the above program, we have used Normally Open Contacts as well as Normally Closed Contacts for Switch 1 (I0.0), Switch 2 (I0.1), and Switch 3 (I0.2) In Rung0, when any 1 switch (Normally Copen Contact) is turned ON and the other 2 switches (Normally Closed Contacts) are OFF, then LED 1 will turn ON. To turn ON LED 2 Rung1, any 2 switches that are as Normally Open Contacts should be ON and the other remaining 1 switch as Normally Closed Contact should be OFF. For LED 3 to be ON, switch 1, switch 2 and switch 3 in Rung2 are connected in series, thus implementing AND logic gate. LED 3 will TURN ON when all the three switches are turned ON. When Any 1 Switch is ON

    The signal flows through switch 1 as it is in true state. In false state, switch 2 and switch 3 also pass signal to the outputs. Therefore, LED 1 will be ON.

    LED I will TURN ON when switch 2 is turned ON and switch 1 and switch 3 are OFF as these are in normally closed contact state.

    When switch 3 will be ON and other 2 switches which are normally closed contacts will be OFF, then LED 1 will turn ON.
    Turning ON more than one switch will break the circuit. The Normally Closed Contact, when in true state, will not allow signal. As a result, LED 1 will be OFF.
    When Any 2 Switches are ON

    LED 2 will TURN ON when switch 1, switch 2 are turned ON and Switch 3 is OFF. The switch 3 as Normally Closed Contact, in false state, will allow signal to pass through it.

     When switch 1 and switch 3 are turned ON and switch 2 is OFF, LED 2 will turn ON. Switch 2 will allow signal when in false state.

    The signal flows through switch 2 and switch 3 as these are in true state. In false state, switch 1 also pass signal to the outputs. Therefore, LED 2 will be ON.
    When more than two inputs are turned ON, the Normally Closed Contact used for the third switch will not close the circuit in true state. Therefore, the LED 2 will get OFF.
    When All 3 Switches are ON

    When all the three switches SWITCH 1 (I0.0), SWITCH 2 (I0.1), SWITCH 3 (I0.2) are turned ON, LED 3 will be ON and will turn OFF other Two outputs.

Apply for friendship links:WhatsApp or E-mail: admin@plchmis.com
×
×
  • Create New...