Jump to content
DMC PLC Programming Inc
 
Phoenix Control Systems Ltd
 
Automation Ready Panels
 
Control Systems International
 
Shawa Technocrafts Pvt Ltd
 
Text Link ads rent Buy now
DMC PLC Programming Inc
Phoenix Control Systems Ltd
 
Automation Ready Panels
Control Systems International
 
Shawa Technocrafts Pvt Ltd
Text Link ads rent Buy now
  • English
    русский
    Español
    Deutsch
    简体中文
  • Show all categories

    PLC programming technology and HMI interface design English database

    PLC, DCS, HMI and SCADA product application technical articles
    caixiaofeng
    Programmable Logic Controller (PLC) Questions and Answers
    This PLC is being used to start and stop an electric motor, and also to shut it down automatically if any of three “shutdown” conditions occur:
    Excessive vibration Overcurrent (overload heater contact) High winding temperature Motor Trip Logic using PLC Programming

    The status of each shutdown contact is as follows:
    Vibration contact: closed when okay, opens when vibration becomes excessive Overload contact: closed when okay, opens when overloaded Temperature contact: open when okay, closes when hot Draw a PLC ladder-logic program to start and stop this motor.
    Be sure to make the program latching so that the operator does not have to hold the Start button to keep the motor running.
    Answer:
    Do you find any mistakes in the logic? Share with us through comments.

    caixiaofeng
    In today’s world of industrial automation, data is a very important part. Getting instant data from sources and using them for different purposes is as crucial as running a system.
    Everyone usually knows how to integrate SCADA with various database systems, like SQL servers. However many ignore the power of PLC in integrating with databases. They too can be used for this purpose.
    PLC with SQL Database

    If we use PLC, programmers can work with them in emergency situations like SCADA failure and get their work done by coding it appropriately. In this post, we will see how to use PLC with SQL database.
    For those who are not familiar with SQL server, it is a database management tool which stores a large amount of data in real time format sequentially, and queries are written in it either through some external source, like a PLC, for retrieving data.
    For storing data in it, logic is written in PLC which when executed stores data in SQL. This is a simple concept, which is explained further in the post more briefly for it’s advantages.
    Scheduler PLC
    Suppose you have a very large-scale system where the operator has to feed hundreds of time schedules for operating particular functions every day. Instead of using vast coding and variables in PLC for storing data entered in SCADA and operating it once the time arrives, just feed all the variable data to the SQL server through PLC every time a new recipe is created.
    The SQL will store real-time date and time of the values entered and will give operators option of choosing them according to date and time filtered. For example, the SQL has five entries from 1st Oct to 5th Oct for various types of schedules entered. The benefit is that the operator can choose any one required and then run the system.
    If SQL was not there, he would have to run only one option of either 1st Oct or any other date. Or else, he would have to utilize memory of SCADA or PLC, which is waste of data and coding. This same thing becomes easier through SQL server.
    Another advantage is that SCADA code size becomes reduced and it would be used for other purposes. Scheduling is used in many applications and using PLC for it along with SQL makes system more efficient.
    Sequencing
    Consider a plant having 10 sequences. Every sequence has a barcode reader in it for starting the action on the required product. If the barcode is read in SCADA, then the corresponding data feed to PLC or in short, SCADA is the medial intervene for initiating communication between PLC and data; then just directly connect PLC with SQL.
    SQL will directly communicate with PLC for determining barcodes and other data for starting or stopping a sequence. Such bulk data from plant sequences helps reduce coding in SCADA and makes system faster to operate. Because PLC is written with coding for sequence operation, why not directly connect it with SQL and use the system.
    Synchronize multiple PLCs
    There are many applications where one PLC in a location needs data from another PLC location for doing a work. In that case too, traditionally SCADA is used for integrating all the PLC’s and managing them.
    In that case, if PLCs are directly connected to the SQL server, data will be synchronized through the date and time of SQL; thus, eliminating problems of multiple RTC (real-time clock) synchronization of PLCs.
    Also, PLC will directly communicate with other PLC for asking any data or give any data through the SQL server. Any alarm or event in a PLC will also be communicated to other PLC and would help in tracking real-time records.
    Handshaking
    Handshaking is a process where one party is acknowledged by the other party that the job has been completed. Basically, it is a response required so that the party can start its other work. This method works well with PLC and SQL servers.
    The SQL server can directly communicate with PLC by sending event notifications in real time, or alarm notification data in real-time. This means, suppose that the job has taken 3 days to complete.
    Then the completion acknowledgment will be sent as a separate event to the PLC, and as it also has 3 days of data in it, the operator can view the whole process in SCADA reports easily. So, handshaking is an important reason for communicating PLC with SQL directly.
    PLC Database Basics
    Establish a connection between the PLC and the SQL database using middleware or a gateway that facilitates communication between industrial network protocols and database languages. Select a communication protocol that both the PLC and the SQL database can understand, such as OPC UA, Modbus TCP, or any other protocol supported by your PLC and middleware. Configure the PLC to send and receive data by setting up the necessary parameters, registers, or tags that will be read from or written to. This might involve programming the PLC using its respective software to ensure it’s ready for data exchange. Set up the SQL database by creating a new database or configuring an existing one to store data from the PLC. Define tables, columns, and data types that align with the data structure being sent from the PLC. Map each PLC data point to the corresponding field in the SQL database. Ensure that the data types are compatible and that the mapping makes logical sense for the application’s needs. Implement data transfer logic using scripts or database stored procedures. Determine how often data should be transferred, under what conditions, and whether the transfer should be triggered by events or on a schedule. Test the communication between the PLC and the SQL database thoroughly. Check for any errors or data mismatches and ensure that the system behaves as expected under various conditions. Continuously monitor the system for operational integrity, data accuracy, and any anomalies. Set up alerts or notifications for system errors or significant events. Regularly review and update the system as needed to accommodate changes in the PLC setup, database structure, or additional requirements. Keep documentation updated for any system changes. Ensure security measures are in place for both the PLC and the SQL database to protect against unauthorized access and data breaches. Consider implementing encryption, firewalls, and secure access protocols.
    xiangjinjiao
    This article is about the PLC programming troubleshooting method. In industrial PLCs where thousands of inputs and outputs are used, and we know how lengthy PLC programs are, depends on the application or plant usage.
    Troubleshoot Siemens PLC Programs
    Some times, People may change the logic parameters unknowingly and it may lead to a fault. Even some faults are created during the logic design stage due to the complexity of the design. The siemens plc software has different handy tools available in it to troubleshoot the faults generated in the programs.
    Faults can be like overlapping of addressing, multiple same output instances, memory bit address overlapping,  many times a single program is used to work over and over, etc.
    To find out such problems, there are four types of windows available in the siemens software which will help us to troubleshoot the issues.
    They are:
    Cross Reference Call Structure Assignment List Dependency Structure Let discuss how to use them in our program for troubleshooting and where to find them in the software.
    Cross Reference
    Cross-reference is used to find all the digital & analog inputs and outputs used in the logics. It will help us to know about the number of times the I/O’s are used in the program and also take users directly to the specific location of the I/O’s in the logic pages.
    Here is an example of one of the programs, in which you can see how the cross-reference table looks like. It contains all the information like addressing, the language of the program, used inputs and outputs, etc.

    Call Structure
    When you want to know which block is used in programming then call structure is used.
    This is a reversal of cross-reference function in which we get to know that how many times SFC, FB block are used in OB (Organization Block) and here we get to know that how many times OB used in SFC and FBs.

    Assignment List
    The assignment list is a very useful feature when it comes to knowing that how many inputs, outputs, timers and counters used in our application and how many of them are still remaining, so we can use them in future logics.

    Dependency Structure
    Dependency structure is used to show where each and every block used within the programming.
    But in step 7 it won’t take you directly on location however in TIA PORTAL it will take you to the location where the program is written.

    NOTE:
    To open these windows in step 7, use the info as shown in Drawing. After clicking on display you have the options.

    In TIA PORTAL, follow the below step shown in the drawing.

    xiangjinjiao
    At this post i will give some basic instructions which are from my personal experience in order to give you a guide for how troubleshooting in automation systems (PLC/DCS) is :
    Automation systems troubleshooting has in general the same tactic in order to find the solution of system’s fault.
    Nevertheless, depends the complexity and the size of application and the specific automation system, the troubleshooting steps would be a little different or more complicated.
    The best knowledge is obtained through practice and actual troubleshooting conditions. Practice again and again is the solution in my opinion. Any supplement and comments are welcome!!
    Troubleshoot a PLC System

    Before we proceed, we agree that modern automation systems have PLCs for controlling the application. If we have a small application then the system possibly has a microPLC (or nanoPLC) or another type of compact controller (many times this depends of the application).
    I said modern automation systems because in the past (before PLCs/other compact controllers be well known and used by automation development companies), the control of an automation system was going on only with relays.
    Investigate the Controller’s program
    The first thing we should do, is to find out if we have the right conditions fulfilled for the operation that is faulty. To do this we should find the “mind” of our system.
    This “mind” is the controller (either this is a kind of PLC or another type of compact controller). If we don’t have the right conditions fulfilled, then we should investigate the controller’s programme for finding out the origin of the problem (ALWAYS check messages appear at SCADA.This will guide faster to the solution because at SCADA appear important information such as fault/alarm description or a specific address in PLC).
    The thing that we will find out is... 
    either a faulty signal from hardware (eg a digital signal from a button or a digital signal from a mechanical switch or a digital signal from a relay’s contact that “does not come” to controller’s input or an analog signal which has wrong values) or a faulty signal from another software system (eg SCADA).
    Investigate the conditions that came from hardware
    When we conclude for the origin of the problem, then we leave for a while controller’s programme and go out to check our conclusions.
    We should already have find the drawings of automation system in order to see the connections for the components we want to check.
    For example, if we find out that we have a digital signal from a button which “does not come” to controller’s input, then we take our multimeter and go to check the button.
    If the button is OK, then we investigate if there is any fuse between button and controller’s input. If there is, then we check it.
    If the fuse is OK, then we investigate the route of the cable. 
    Maybe we have a cut cable.If the cable is OK, then maybe we have hardware problem to the controller’s input and maybe we should change this input module with a new one or otherwise fix it (the repairs should be done by qualified staff).
    Investigate the hardware after the outputs of our controller
    If we conclude that we have the right conditions, then we should check the components that we have between controller and the faulty equipment (we mean the equipment that doesn’t work as it should).
    For example, if we have an industrial furnace that does not close its door (even though we have the conditions for closing the door from programme), maybe we have a faulty relay that energizes from PLC (or other controller) for closing the door.
    If the relay is OK, then maybe we have problem with the motor that is responsible for closing the door. We should check motor for its status (motor coils, mechanical parts) 
    If the motor is OK, we should check the voltage values come to motor’s input (with our multimeter) and also check the cable for its status if multimeter’s measurements are not right.
    If the voltage and cable are OK, then maybe we have a jam somewhere at the door-furnace construction.
    Power units are a “plus”!
    Generally, when we have power units (drives) in our automation system in order to drive a motor, then we should have together the manual of the specific power unit.
    That’s because power units have a digital display or 7-segment led displays or simple LEd’s for informing us about the fault that exists inside them or at the driven motor.
    This is very useful for engineers and technicians. Also, modern power units have special algorithms for checking motor status, voltage and current values etc.
    For example, if a motor is overheated, the drive will inform us about it because it checks continuously the temperature sensor (eg thermistor) which is located inside motor’s enclosure.
    Then we should check the motor if it is overheated actually or we have a faulty temperature sensor that we should replace it.
    Check controllers status
    Some times, when the CPU of our PLC detects an unacceptable condition at the programme’s flow, then it goes to “STOP” mode and possibly a led flashes and indicates this malfunction.
    Also, if any other malfunction is going on to the system, some led’s indicate the kind of fault (refer to controller’s manual for more information). Same behavior have in general any kind of controller is established in an automation system.
    Safety systems
    Many automation systems (often production machines) have in their design some “safety systems” like “Pilz” or “Siemens Sirius”.
    These are smart compact controllers for monitoring situations like protective door opening or Emergency-Stop. When something of these occurs, the safety system stops the operation of the automation system for human and machine protection.
    In order to reset the automation system to the functional state, there are special instructions in safety systems manuals.
    The conclusion for all the above is to have a step by step tactic in troubleshooting. Passing time and getting more experience, maybe we will bypass some steps, specifically if we are the staff responsible for the maintenance of a system which we come across every day.
    However, a good tactic is to be organised and patient. Good luck to your efforts!
    xiangjinjiao
    In this post, we will understand how to filter digital and analog inputs in a PLC.
    As the topic says, filtering is a means to remove unwanted spikes in the signals received in PLC. Its role is to eliminate the fluctuations and pass only proper signal changes at a particular time to the PLC.
    Inside a PLC, the filter circuitry comes first and then comes the PLC input processing circuitry, which accepts the final filtered input and uses it for its logic.

    PLC Digital Input Filters
    Let us first consider the digital input. The role of input with a filter is to accept a digital field input and pass it to a processing circuit through the filter.
    If you see the below image, there are two parts.
    First of all, the green circle indicates that the input change will be passed and the red circle shows that the input change will not be passed.
    In the first (above) part, there are two changes where there are many fluctuations and that input changes will be bypassed.
    There are two changes where there are no fluctuations and that input change will be passed to the processing circuit. The same is the theory with the second (below) part. This is possible by filtering.

    Filtering is defined by a factor or time. Suppose you set a time of 3 ms. The role of the filter is to accept only that input change that stays higher than 3 ms.
    If the input changes before 3 ms, then that input will not be considered and will be ignored. This means that short and high-frequency interference pulses will be neglected.
    This logic is the same as a debounce timer that we write in the PLC logic.
    In the below image, the lamp will turn on only when the start button input remains high for 3 seconds.
    This is the same logic used in a digital pass filter. It will pass on the input change to the processing part only when that input maintains a state (high or low) for the set time.

    Apart from time, as discussed, some PLCs have the option of setting a factor instead of time.
    The factor calculates the internal time and decides the level of filtering. Higher the factor value, the higher the filtering power.
    PLC Analog Input Filters
    Now, let us see the filtering in analog inputs. As analog inputs are variable in nature, the filter logic for them cannot be implemented the same as for digital inputs.
    So, in analog inputs, averaging logic is used. The filter will average the values attained in a particular set time and give an average final value for that time.
    Refer to the below image for the study.

    The first one – the blue color has a factor of 1.
    The second one – the green color has a factor of 2.
    The third one – the orange color has a factor of 3.
    The fourth one – the brown color has a factor of 4.
    As the value of the filter factor increases, you can see that the shape of the signal improves by filtering the signal at a sharper value.
    In a set time, the filter will average the values that it gets from the input; and based on formulas used inside it, it will give the final average output per time.
    So, as the filter factor or weightage is increased, we get a finer value of an analog signal with less interference. Normally, a first-pass filter is used for this purpose.
    In this way, we conclude that filtering is of great use in reducing unwanted noise from the field input and passing proper values, which will also protect the PLC input circuit from damage; if any high or unwanted spikes occur.
    xiangjinjiao
    The main difference between DCS and PLC is the business model which we discussed with comparison of DCS Versus PLC Architecture.
    DCS versus PLC Architecture
    The DCS business model can be said to be based on a monolithic integrated system by a single manufacturer.
    DCS Architecture
    For a DCS the controller, I/O-subsystem, database server software, engineering software, and operator software are all a single monolithic unit designed together and only work with each other.
    It is not possible to use components from a third-party. It is not possible to use any of these components on some other system.
    A DCS uses I/O-subsystem network and control network based on standard Ethernet, but with a proprietary application protocol, and typically only with a particular approved model of Ethernet switches.

    Figure 1 In a DCS all components come from the same single manufacturer
    Only a specific version of Windows is permitted and only on one type of approved computer shipped from the DCS manufacturer.
    These restrictions enable the DCS manufacturer to test everything together very thoroughly, on a very large scale, heavily loaded, with many controllers and work stations.
    Applications like batch control, advanced control, and auto-tuning etc. are also tested together. This ensures there are no compatibility conflicts and unforeseen dependencies.
    Thorough large-scale testing is possible because there is essentially only one type of each component so only one or very few combinations.
    Third-party software is only permitted on separate “application stations” where it cannot conflict the native DCS applications and must be tested and approved by the DCS manufacturer; white-listed.
    A DCS is monolithic using the same brand I/O subsystem, controller, and software, and single computer and operating system platform. This has been thoroughly tested on very large scale.
    DCS Long Term Support
    Systems typically remain operational for 15 years or more. During this time there will be several Windows versions, service packs, hot fixes, lots of virus definition updates, and computer hardware will need to be replaced too.
    Typically DCS only support a single type of anti-virus software and whenever there is a new virus definition or when there is a Windows operating system service pack or hot fix, the entire monolithic suite of all hardware and software are tested together again by the system vendor prior to release ensuring the virus definition and service pack can be deployed without any compatibility conflicts.
    DCS Upgrade
    DCS versions are also upgraded as a single monolithic unit of all hardware and software such as I/O card firmware, controller firmware, server software, engineering station software, operator station software, as well as any other software are all upgraded together.
    Any time there is a new system version all these components have been thoroughly tested together on a large scale by the system manufacturer in advance ensuring they are all compatible with each other.
    Moreover, the online hotcutover process from earlier version to the new version has been thoroughly tested on a large scale ensuring smooth deployment at site.
    It is this reassurance that thorough and large-scale testing provides which makes DCS very popular with large installations like petrochemical complexes. Such testing is made practical by the few combinations in a monolithic system.
    PLC Architecture / Business Model
    The PLC business model can be said to be based on flexible architecture by a system integrator (SI).
    PLC Architecture
    The PLC architecture is very flexible where each component can be freely selected from any of many suppliers. The PLC is the CPU with configuration software and IO-subsystem.
    Sometimes the I/O-subsystem may come from a third-party. Even I/O cards that plug into the backplane may come from third-parties.
    The HMI software is typically from a third-party. A native OPC server from the PLC manufacturer is typically best, but third-party OPC servers are sometimes used.

    Figure 2 For a PLC components from different manufacturers are integrated
    Basically any PLC works with any I/O-subsystem, OPC server, and HMI software because standard protocols like PROFIBUS-DP, PROFINET, Modbus/RTU, Modbus/TCP, DeviceNet, and EtherNet/IP as well as OPC etc. are used.
    Networking gear, computers, and Windows version can be selected freely. Some components found not working are blacklisted.

    Figure 3 DCS uses a single supplier while PLC solutions combines multiple suppliers resulting in a large number of combinations
    Note: Now-a-days single PLC package supplier also available
    This flexibility enables hundreds of combinations of hardware and software making it impossible for these manufacturers to get together to test every possible combination of their hardware and software on each version of Windows before a plant decides to purchase.
    Some combinations may be tested by the manufacturers involved, but it may or may not be on large scale with heavy loading.
    A PLC permits any combination of I/O subsystem, CPU, and HMI/SCADA software, on a wide verity of computer and operating system platforms. Every combination cannot be tested.
    The PLC manufacturer may supply all hardware and software components, all from the same manufacturer as many PLC manufacturers have acquired HMI companies. If so, this particular combination may have been tested more thoroughly than the other combinations tested.
    Auxiliary third-party applications like batch control, advanced control, and auto-tuning etc. are generally not tested together as it results in an even greater number of combinations.
    PLC uses proprietary configuration software just like DCS. That is, you cannot use third-party configuration software for your PLC, just like a DCS.
    A native OPC server for the PLC is better than a third-party OPC server because the PLC configuration software generally automatically configures the address space for the OPC server.
    PLC Long Term Support
    During the 15 years or more of typical system operation there will be several Windows versions, service packs, hot fixes, lots of virus definition updates, and computer hardware will need to be replaced too.
    Typically PLC has no restriction on anti-virus software or Windows operating system version so again the number of combinations of virus definitions, service packs, and hot fixes becomes too vast and impractical for these manufacturers to get together to test every possible new combination before a deployment in plants to ensure there will be no compatibility conflicts when deployed on the large number of combinations of hardware and software.
    The PLC manufacturer may limit to a single anti-virus software and Windows version. If so, this particular combination may have been tested more thoroughly than the other combinations they test.
    PLC Upgrade
    For a PLC, hardware and software components are upgraded individually. That is, I/O-subsystem firmware, CPU firmware and configuration software, OPC server, HMI software, as well as any other software are all upgraded independent of each other.
    Taking different versions for each option of components into account, the number of combinations becomes orders of magnitude larger.
    This flexibility makes it impractical for these manufacturers to get together to test every possible combination of new versions before deployment in plants.
    Testing the hot-cutover of one combination of versions to another combination of versions becomes nearly impossible.
    The PLC manufacturer may supply all hardware and software components, limit to a single antivirus software and Windows version which are tested before deployment, and limit to single I/O-Subsystem Database Server Controller/PLC Operator Station / HMI, DCS, PLC system-wide version upgrades, and test hot-cutover before deployment.
    This way the flexibility of the PLC would be abandoned to achieve the robustness of a DCS.
    xiangjinjiao
    When you are working in an industrial automation system for PLC programming, you have requirements where you need to control a process gradually or in a step-by-step way.
    Control Algorithms
    You cannot directly just on or off a logic for getting your work done. It can have adverse effects on your actual PLC output. For this reason, there are various types of control methods available in a PLC program for appropriate actions.

    In this post, we will see the various control algorithm methods that are used in a PLC program.
    PID control
    This is by far the most famous method for control. PID uses a closed-loop mechanism for control. This means it will first get the feedback and based on what you desire, it will accordingly vary the output.
    For this, PID controller uses internal mathematical calculations with three parameters – proportion, integral, and derivative. So, if you want to control a chiller with a compressor, then the PLC will control the compressor output by first measuring the actual temperature and checking it with how much the user requires.
    Based on that difference every time, the compressor output will either be controlled gradually or turned on-off to maintain the temperature. For this, a PID block will be used in the PLC program for doing this task.
    Function generator
    This is a very simple type of control method. In the function generator, you have to define an input table of n values. Similarly, define an output table of n values.
    So, for example, if we define 10 value tables in both the input and output sides, we have a 10-size element. Now, these 10 elements will have different values. If you set 0-100 on the input side, then we have set 0-50 on the output side. These 10 elements are 10 ranges, meaning 0-10, 10-20, 20-30, and so on.
    Accordingly, the output side will be distributed into 10 elements from 0-5, 5-10, 10-15 and so on till 50. When a real-time input is between any value at the input side, the corresponding scaled output will be passed. Here, you have full flexibility to set the input and output table values.
    Fuzzy logic control
    Fuzzy logic is a relatively very good method for controlling an output. Normally, you have two binary states – 0 and 1. So, let us consider whether a valve can be opened or closed. But what if the valve is stuck in between? We do not know whether the valve is near to open state or closed state. In that case, it helps if there exists a state between 0 and 1. This helps to at least come closer to a possibility. This is called fussy logic.
    Here, you get to define values near 0 and 1. It can be like 0.9 or 0.2. Accordingly, you can control the outputs when it comes close to these values. And when it reaches the extreme limit, that is 0 or 1, you can fully open or close the valve.
    Before that, you can gradually operate the valves. This brings more precise control to the process. So, this control block allows for a collection of values that can be useful in unpredictable situations. It requires a lot of knowledge and expertise to correctly set the values and sets so that the logic works properly.
    Position proportional
    This logic will open or close a device by pulsing open or close contacts at some predefined timer set by the user. It is done for a pulse width proportional to the deviation between the required position and the current position.
    You have to set control parameters like how much minimum and maximum to limit the output, what the duration for which output will remain on, the rate at which the device should open or close in %/second, etc.
    The function block takes actual feedback, evaluates internal timers, and checks whether the opening or closing is happening within that desired rate or not. If not, then the corresponding open or closed pulse will be given.
    In this way, we saw the various control algorithm methods used in PLC programming.
    xiangjinjiao
    The most elementary objects in Ladder Diagram programming are contacts and coils, intended to mimic the contacts and coils of electromechanical relays.
    Contacts and coils are discrete programming elements, dealing with Boolean (1 and 0; on and off; true and false) variable states.
    Each contact in a Ladder Diagram PLC program represents the reading of a single bit in memory, while each coil represents the writing of a single bit in memory.
    Discrete input signals to the PLC from real-world switches are read by a Ladder Diagram program by contacts referenced to those input channels.
    In legacy PLC systems, each discrete input channel has a specific address which must be applied to the contact(s) within that program.
    In modern PLC systems, each discrete input channel has a tag name created by the programmer which is applied to the contact(s) within the program.
    Similarly, discrete output channels – referenced by coil symbols in the Ladder Diagram – must also bear some form of address or tag name label.
    To illustrate, we will imagine the construction and programming of a redundant flame-sensing system to monitor the status of a burner flame using three sensors.
    The purpose of this system will be to indicate a “lit” burner if at least two out of the three sensors indicate flame.
    If only one sensor indicates flame (or if no sensors indicate flame), the system will declare the burner to be un-lit.
    The burner’s status will be visibly indicated by a lamp that human operators can readily see inside the control room area.
    Our system’s wiring is shown in the following diagram:

    Each flame sensor outputs a DC voltage signal indicating the detection of flame at the burner, either on (24 volts DC) or off (0 volts DC).
    These three discrete DC voltage signals are sensed by the first three channels of the PLC’s discrete input card.
    The indicator lamp is a 120 volt light bulb, and so must be powered by an AC discrete output card, shown here in the PLC’s last slot.
    To make the ladder program more readable, we will assign tag names (symbolic addresses) to each input and output bit in the PLC, describing its real-world device in an easily-interpreted format.
    We will tag the first three discrete input channels as IN sensor A, IN sensor B, and IN sensor C, and the output as OUT burner lit.
    A ladder program to determine if at least two out of the three sensors detect flame is shown here, with the tag names referencing each contact and coil:

    Series-connected contacts in a Ladder Diagram perform the logical AND function, while parallel contacts perform the logical OR function. Thus, this two-out-of-three flame-sensing program could be verbally described as:
    “Burner is lit if either A and B, or either B and C, or either A and C”
    An alternate way to express this is to use the notation of Boolean algebra, where multiplication represents the AND function and addition represents the OR function:
    Burner_lit = AB + BC + AC
    Yet another way to represent this logical relationship is to use logic gate symbols:

    To illustrate how this program would work, we will consider a case where flame sensors B and C detect flame, but sensor A does not (Note1).
    This represents a two-out-of-three-good condition, and so we would expect the PLC to turn on the “Burner lit” indicator light as programmed.
    From the perspective of the PLC’s rack, we would see the indicator LEDs for sensors B and C lit up on the discrete input card, as well as the indicator LED for the lamp’s output channel:
    Note 1 : The most likely reason why one out of two flame sensors might not detect the presence of a flame is some form of misalignment or fouling of the flame sensor.
    In fact, this is a good reason for using a 2-out-of-3 flame detection system rather than a simplex (1-out-of-1) detector scheme: to make the system more tolerant of occasional sensor problems without compromising burner safety.

    Those two energized input channels “set” bits (1 status) in the PLC’s memory representing the status of flame sensors B and C. Flame sensor A’s bit will be “clear” (0 status) because its corresponding input channel is de-energized.
    The fact that the output channel LED is energized (and the “Burner lit” indicator lamp is energized) tells us the PLC program has “set” that corresponding bit in the PLC’s output memory register to a “1” state.
    A display of input and output register bits shows the “set” and “reset” states for the PLC at this moment in time:

    Examining the Ladder Diagram program with status indication enabled, we see how only the middle contact pair is passing “virtual power” to the output coil:

    Recall that the purpose of a contact in a PLC program is to read the status of a bit in the PLC’s memory.
    These six “virtual contacts” read the three input bits corresponding to the three flame sensors.
    Each normally-open “contact” will “close” when its corresponding bit has a value of 1, and will “open” (go to its normal state) when its corresponding bit has a value of 0.
    Thus, we see here that the two contacts corresponding to sensor A appear without highlighting (representing no “conductivity” in the virtual relay circuit) because the bit for that input is reset (0).
    The two contacts corresponding to sensor B and the two contacts corresponding to sensor C all appear highlighted (representing “conductivity” in the virtual circuit) because their bits are both set (1).
    Recall also that the purpose of a coil in a PLC program is to write the status of a bit in the PLC’s memory.
    Here, the “energized” coil sets the bit for the PLC output 0 to a “1” state, thus activating the real-world output and sending electrical power to the “Burner lit” lamp.
    Note that the color highlighting does not indicate a virtual contact is conducting virtual power, but merely that it is able to conduct power. Color highlighting around a virtual coil, however, does indicate the presence of virtual “power” at that coil.
    Contacts and relays are not just useful for implementing simple logic functions, but they may also perform latching functions as well.
    A very common application of this in industrial PLC systems is a latching start/stop program for controlling electric motors by means of momentary-contact push-button switches.
    As before, this functionality will be illustrated by means of an hypothetical example circuit and program:

    In this system, two push-button switches are connected to discrete inputs on a PLC, and the PLC in turn energizes the coil of a motor contactor relay by means of one of its discrete outputs.
    An overload contact is wired directly in series with the contactor coil to provide motor over-current protection, even in the event of a PLC failure where the discrete output channel remains energized ( note 2 ). The ladder program for this motor control system would look like this:
    Note 2 : While it is possible to wire the overload contact to one of the PLC’s discrete input channels and then program a virtual overload contact in series with the output coil to stop the motor in the event of a thermal overload, this strategy would rely on the PLC to perform a safety function which is probably better performed by hard-wired circuitry.

    Pressing the “Start” pushbutton energizes discrete input channel 6 on the PLC, which “closes” the virtual contact in the PLC program labeled IN switch Start.
    The normally-closed virtual contact for input channel 7 (the “Stop” pushbutton) is already closed by default when the “Stop” button is not being pressed, and so the virtual coil will receive “power” when the “Start” pushbutton is pressed and the “Stop” pushbutton is not.
    Note the seal-in contact bearing the exact same label as the coil: OUT contactor. At first it may seem strange to have both a contact and a coil in a PLC program labeled identically (Note 3 ), since contacts are most commonly associated with inputs and coils with outputs, but this makes perfect sense if you realize the true meaning of contacts and coils in a PLC program: as read and write operations on bits in the PLC’s memory.
    The coil labeled OUT contactor writes the status of that bit, while the contact labeled OUT contactor reads the status of that same bit. The purpose of this contact, of course, is to latch the motor in the “on” state after a human operator has released his or her finger from the “Start” pushbutton.
    Note 3 : A very common misconception among students first learning PLC Ladder Diagram programming is to always associate contacts with PLC inputs and coils with PLC outputs, thus it seems weird to have a contact bear the same label as an output. However, this is a false association. In reality, contacts and coils are read and write instructions, and thus it is possible to have the PLC read one of its own output bits as a part of some logic function. What would be truly strange is to label a coil with an input bit address or tag name, since the PLC is not electrically capable of setting the real-world energization status of any input channels.
    This programming technique is known as feedback, where an output variable of a function (in this case, the feedback variable is OUT contactor) is also an input to that same function.
    The path of feedback is implicit rather than explicit in Ladder Diagram programming, with the only indication of feedback being the common name shared by coil and contact.
    Other graphical programming languages (such as Function Block) have the ability to show feedback paths as connecting lines between function outputs and inputs, but this capacity does not exist in Ladder Diagram.
    A step-by-step sequence showing the operation and status of this simple program illustrates how the seal-in contact functions, through a start-up and shut-down cycle of the motor:

    This sequence helps illustrate the order of evaluation or scan order of a Ladder Diagram program. The PLC reads a Ladder Diagram from left to right, top to bottom, in the same general order as a human being reads sentences and paragraphs written in English.
    However, according to the IEC 61131-3 standard, a PLC program must evaluate (read) all inputs (contacts) to a function before determining the status of a function’s output (coil or coils).
    In other words, the PLC does not make any decision on how to set the state of a coil until all contacts providing power to that coil have been read.
    Once a coil’s status has been written to memory, any contacts bearing the same tag name will update with that status on subsequent rungs in the program.
    Step 5 in the previous sequence is particularly illustrative. When the human operator presses the “Stop” pushbutton, the input channel for IN switch Stop becomes activated, which “opens” the normally-closed virtual contact IN switch Stop.
    Upon the next scan of this program rung, the PLC evaluates all input contacts (IN switch Start, IN switch Stop, and OUT contactor) to check their status before deciding what status to write to the OUT contactor coil.
    Seeing that the IN switch Stop contact has been forced open by the activation of its respective discrete input channel, the PLC writes a “0” (or “False”) state to the OUT contactor coil.
    However, the OUT contactor feedback contact does not update until the next scan, which is why you still see it color-highlighted during step 5.
    A potential problem with this system as it is designed is that the human operator loses control of the motor in the event of an “open” wiring failure in either pushbutton switch circuit.
    For instance, if a wire fell off a screw contact for the “Start” pushbutton switch circuit, the motor could not be started if it was already stopped.
    Similarly, if a wire fell off a screw contact for the “Stop” pushbutton switch circuit, the motor could not be stopped if it was already running.
    In either case, a broken wire connection acts the same as the pushbutton switch’s “normal” status, which is to keep the motor in its present state.
    Some applications, this failure mode would not be a severe problem. Many applications, though, it is quite dangerous to have a running motor that cannot be stopped.
    For this reason, it is customary to design motor start/stop systems a bit differently from what has been shown here.
    In order to build a “fail-stop” motor control system with our PLC, we must first re-wire the pushbutton switch to use its normally-closed (NC) contact:

    This keeps discrete input channel 7 activated when the pushbutton is unpressed. When the operator presses the “Stop” pushbutton, the switch’s contact will be forced open, and input channel 7 will de-energize.
    If a wire happens to fall off a screw terminal in the “Stop” switch circuit, input channel 7 will de-energize just the same as if someone pressed the “Stop” pushbutton, which will automatically shut off the motor.
    In order for the PLC program to work properly with this new switch wiring, the virtual contact for IN switch Stop must be changed from a normally-closed (NC) to a normally-open (NO):

    As before, the IN switch Stop virtual contact is in the “closed” state when no one presses the “Stop” switch, enabling the motor to start any time the “Start” switch is pressed.
    Similarly, the IN switch Stop virtual contact will open any time someone presses the “Stop” switch, thus stopping virtual “power” from flowing to the OUT contactor coil.
    Although this is a very common way to build PLC-controlled motor start/stop systems – with an NC pushbutton switch and an NO “Stop” virtual contact – students new to PLC programming often find this logical reversal confusing.
    Perhaps the most common reason for this confusion is a mis-understanding of the “normal” concept for switch contacts, be they real or virtual. The IN switch Stop virtual contact is programmed to be normally-open (NO), but yet it is typically found in the closed state.
    Recall that the “normal” status of any switch is its status while in a resting condition of no stimulation, not necessarily its status while the process is in a “normal” operating mode.
    The “normally-open” virtual contact IN switch Stop is typically found in the closed state because its corresponding input channel is typically found energized, owing to the normally-closed pushbutton switch contact, which passes real electrical power to the input channel while no one presses the switch.
    Just because a switch is configured as normally-open does not necessarily mean it will be typically found in the open state! The status of any switch contact, whether real or virtual, is a function of its configuration (NO versus NC) and the stimulus applied to it.
    Another concern surrounding real-world wiring problems is what this system will do if the motor contactor coil circuit opens for any reason.
    An open circuit may develop as a result of a wire falling off a screw terminal, or it may occur because the thermal overload contact tripped open due to an over-temperature event. The problem with our motor start/stop system as designed is that it is not “aware” of the contactor’s real status.
    In other words, the PLC “thinks” the contactor will be energized any time discrete output channel 2 is energized, but that may not actually be the case if there is an open fault in the contactor’s coil circuit.
    This may lead to a dangerous condition if the open fault in the contactor’s coil circuit is later cleared. Imagine an operator pressing the “Start” switch but noticing the motor does not actually start.
    Wondering why this may be, he or she goes to look at the overload relay to see if it is tripped. If it is tripped, and the operator presses the “Reset” button on the overload assembly, the motor will immediately start because the PLC’s discrete output has remained energized all the time following the pressing of the “Start” switch.
    Having the motor start up as soon as the thermal overload is reset may come as a surprise to operations personnel, and this could be quite dangerous if anyone happens to be near the motor-powered machinery when it starts.
    What would be safer is a motor control system that refuses to “latch” on unless the contactor actually energizes when the “Start” switch is pressed. For this to be possible, the PLC must have some way of sensing the contactor’s status.
    In order to make the PLC “aware” of the contactor’s real status, we may connect the auxiliary switch contact to one of the unused discrete input channels on the PLC, like this:

    Now, the PLC is able to sense the real-time status of the contactor via input channel 5.
    We may modify the PLC program to recognize this status by assigning a new tag name to this input (IN contactor aux) and using a normally-open virtual contact of this name as the seal-in contact instead of the OUT contactor bit:

    Now, if the contactor fails to energize for any reason when the operator presses the “Start” switch, the PLC’s output will fail to latch when the “Start” switch is released.
    When the open fault in the contactor’s coil circuit is cleared, the motor will not immediately start up, but rather wait until the operator presses the “Start” switch again, which is a much safer operating characteristic than before.
    A special class of virtual “coil” used in PLC ladder programming that bears mentioning is the “latching” coil. These usually come in two forms: a set coil and a reset coil.
    Unlike a regular “output” coil that positively writes to a bit in the PLC’s memory with every scan of the program, “set” and “reset” coils only write to a bit in memory when energized by virtual power. Otherwise, the bit is allowed to retain its last value.
    A very simple motor start/stop program could be written with just two input contacts and two of these latching coils (both bearing the same tag name, writing to the same bit in memory):

    Note the use of a normally-open (NO) pushbutton switch contact (again!), with no auxiliary contact providing status indication of the contactor to the PLC. This is a very minimal program, shown for the strict purpose of illustrating the use of “set” and “reset” latching coils in Ladder Diagram PLC programming.
    “Set” and “Reset” coils ( Referred to as “Latch” and “Unlatch” coils )  are examples of what is known in the world of PLC programming as retentive instructions. A “retentive” instruction retains its value after being virtually “de-energized” in the Ladder Diagram “circuit.”
    A standard output coil is non-retentive, which means it does not “latch” when de-energized. The concept of retentive and non-retentive instructions will appear again as we explore PLC programming, especially in the area of timers.
    Ordinarily, we try to avoid multiple coils bearing the same label in a PLC Ladder Diagram program. With each coil representing a “write” instruction, multiple coils bearing the same name represents multiple “write” operations to the same bit in the PLC’s memory.
    Here, with latching coils, there is no conflict because each of the coils only writes to the OUT contactor bit when its respective contact is energized. So long as only one of the pushbutton switches is actuated at a time, there is no conflict between the identically-named coils.
    This raises the question: what would happen if both pushbutton switches were simultaneously pressed? What would happen if both “Set” and “Reset” coils were “energized” at the same time? The result is that the OUT contactor bit would first be “set” (written to a value of 1) then “reset” (written to a value of 0) in that order as the two rungs of the program were scanned from top to bottom.
    PLCs typically do not typically update their discrete I/O registers while scanning the Ladder Diagram program (this operation takes place either before or after each program scan), so the real discrete output channel status will be whatever the last write operation told it to be, in this case “reset” (0, or off).
    Even if the discrete output is not “confused” due to the conflicting write operations of the “Set” and “Reset” coils, other rungs of the program written between the “Set” and “Reset” rungs might be.
    Consider for example a case where there were other program rungs following the “Set” and “Reset” rungs reading the status of the OUT contactor bit for some purpose.
    Those other rungs would indeed become “confused” because they would see the OUT contactor bit in the “set” state while the actual discrete output of the PLC (and any rungs following the “Reset” rung) would see the OUT contactor bit in the “reset” state:

    Multiple (non-retentive) output coils with the same memory address are almost always a programming faux pax for this reason, but even retentive coils which are designed to be used in matched pairs can cause trouble if the implications of simultaneous energization are not anticipated.
    Multiple contacts with identical addresses are no problem whatsoever, because multiple “read” operations to the same bit in memory will never cause a conflict.
    The IEC 61131-3 PLC programming standard specifies transition-sensing contacts as well as the more customary “static” contacts. A transition-sensing contact will “actuate” only for a duration of one program scan, even if its corresponding bit remains active.
    Two types of transition-sensing Ladder Diagram contacts are defined in the IEC standard: one for positive transitions and another for negative transitions.
    The following example shows a wiring diagram, Ladder Diagram program, and a timing diagram demonstrating how each type of transition-sensing contact functions when stimulated by a real (electrical) input signal to a discrete channel:

    When the pushbutton switch is pressed and the discrete input energized, the first test lamp will blink “on” for exactly one scan of the PLC’s program, then return to its off state.
    The positive transition contact (with the letter “P” inside) activates the coil OUT test1 only during the scan it sees the status of IN test transition from “false” to “true,” even though the input remains energized for many scans after that transition.
    Conversely, when the pushbutton switch is released and the discrete input de-energizes, the second test lamp will blink “on” for exactly one scan of the PLC’s program then return to its off state.
    The negative-transition contact (with the letter “N” inside) activates the coil OUT test2 only during the scan it sees the status of IN test transition from “true” to “false,” even though the input remains de-energized for many scans after that transition:
    It should be noted that the duration of a single PLC program scan is typically very short: measured in milliseconds. If this program were actually tested in a real PLC, you would probably not be able to see either test lamp light up, since each pulse is so short-lived.
    Transitional contacts are typically used any time it is desired to execute an instruction just one time following a “triggering” event, as opposed to executing that instruction over and over again so long as the event status is maintained “true.”
    Contacts and coils represent only the most basic of instructions in the Ladder Diagram PLC programming language.
    xiangjinjiao
    Comparison instructions in PLC are used to test pairs of values to condition the logical continuity of a rung.
    Thus, comparison instructions would seldom, if ever, be the last instruction on a rung.
    Types of Comparison Instructions

    As an example, suppose a LES instruction is presented with two values. If the first value is less than the second, then the comparison instruction is true.
    Equal (EQU) Instruction

    Use the EQU instruction to test whether two values are equal. If source A and source B are equal, the instruction is logically true. If these values are not equal, the instruction is logically false.
    Source A must be an address.
    Source B can be either a program constant or an address.
    Values are stored in two’s complementary form.
    Not Equal (NEQ) Instruction

    Use the NEQ instruction to test whether two values are not equal.
    If source A and source B are not equal, the instruction is logically true.
    Source A must be an address.
    Source B can be either a program constant or an address.
    Values are stored in two’s complementary form.
    Less Than (LES) Instruction

    Use the LES instruction to test whether one value (source A) is less than another (source B).
    If source A is less than the value at source B, the instruction is logically true.
    Source A must be an address.
    Source B can be either a program constant or an address.
    Values are stored in two’s complementary form.
    Less Than or Equal (LEQ) Instruction

    Use the LEQ instruction to test whether one value (source A) is less than or equal to another (source B).
    If the value at source A is less than or equal to the value at source B, the instruction is logically true.
    Source A must be an address.
    Source B can be either a program constant or an address.
    Values are stored in two’s complementary form.
    Greater Than (GRT) Instruction

    Use the GRT instruction to test whether one value (source A) is greater than another (source B).
    If the value at source A is greater than the value at source B, the instruction is logically true.
    Greater Than Or Equal (GEQ) Instruction

    Use the GEQ instruction to test whether one value (source A) is greater than or equal to another (source B).
    If the value at source A is greater than or equal to the value at source B, the instruction is logically true.
    Masked Comparison for Equal (MEQ)

    Use the MEQ instruction to compare data at a source address with data at a compare address.
    The Use of this instruction allows portions of the data to be masked by a separate word.
    Source is the address of the value you want to compare.
    Mask is the address of the mask through which the instruction moves data.
    The mask can be a hexadecimal value.
    Compare is an integer value or the address of the reference.
    If the 16 bits of data at the source address are equal to the 16 bits of data at the compare address (less masked bits), the instruction is true.
    The instruction becomes false as soon as it detects a mismatch.
    Limit Test (LIM) Instruction

    Use the LIM instruction to test for values within or outside a specified range, depending on how you set the limits.
    The Low Limit, Test, and High Limit values can be word addresses or constants, restricted to the following combinations:
    If the Test parameter is a program constant, both the Low Limit and High Limit parameters must be word addresses. If the Test parameter is a word address, the Low Limit and High Limit parameters can be either a program constant or a word address. True/False Status of the LIM Instruction
    If the Low Limit has a value equal to or less than the High Limit, the instruction is true when the Test value is between the limits or is equal to either limit.

    If the Low Limit has a value greater than the High Limit, the instruction is false when the Test value is between the limits.

    xiangjinjiao
    Advanced PLC programming for defective parts sorting to distinguish between good and bad parts and then transport them via conveyors.
    Advanced PLC Programming for Defective Parts Sorting
    The below simulation shows the good and bad products identification and sorting the products based on their quality using PLC ladder logic.
    The conveyors are used to move the products. The conveyors are started and stopped when the products are delivered on the conveyor and during the drilling operation.
    The drill machine is used for drilling the products as per the design. Sometimes the drilling operation may damage the products.
    A sensor detects the quality of the products and a pusher is used to push the bad products into another storage bin.

    PLC Inputs and Outputs
    The below table lists the required inputs and outputs of the PLC system.
    Type Device No. Device name Operation Input X0 Drilling ON while drilling. Input X1 Part under drill One part is supplied when Y0 is ON: A large metal cube. Input X2 Drilled correctly ON when the part is drilled correctly. The previous result is cleared when drilling starts. Input X3 Drilled wrong ON when the part is detected at the left end. Input X4 Sensor ON when the part is detected at the right end. Input X5 Sensor ON when the part is detected in front of the pusher. Input X10 Sensor ON when the part is not drilled correctly. The previous result is cleared when drilling starts. Output Y0 Supply command The conveyor moves forward when Y1 is ON. Output Y1 Conveyor forward The conveyor moves forward when Y3 is ON. Output Y2 Start drilling Starts drilling when Y2 is ON (A process cycle that cannot be stopped partway). Output Y3 Conveyor forward Extends when Y5 is ON and retracts when Y5 is OFF. The pusher cannot be stopped in the mid-stroke. Output Y5 Pusher Extends when Y5 is ON and retracts when Y5 is OFF. The pusher cannot be stopped in the mid stroke. Program Description
    This project aims to differentiate between good and defective parts using sensors and sorting them accordingly. The project consists of two key areas: overall control and drill control.
    Overall Control
    There is a pushbutton named PB1 (X20) on the control panel. When you press PB1, it triggers the Supply command (Y0) for the hopper, causing it to supply parts. Releasing PB1 deactivates the Supply command, stopping the hopper.
    There is a switch, SW1 (X24), on the control panel. When you turn SW1 ON, the conveyors start to move forward. Turning SW1 OFF halts the conveyors.
    Drill Control
    Now let’s discuss the control of the drill:
    When the Part under the drill sensor (X1) within the drill is activated, the conveyor halts.
    The drilling process commences when the Start drilling command (Y2) is activated. It stops when the Drilling sensor (X0) is activated.
    After one complete cycle of drill operation, if Start drilling (Y2) is activated, either the Drilled correctly (X2) or Drilled wrong (X3) sensor is triggered.
    Note that the drill can’t be stopped mid-operation. In this PLC simulation, every third part is considered defective (A part with multiple holes also falls into the defective category).
    When the Detect part sensor (X10) in the pusher identifies a defective part, the conveyor stops, and the pusher moves the part onto the ‘Defective’ tray.
    Remember that when the actuating command for the pusher is ON, it fully extends. When the command is OFF, the pusher fully retracts.
    A part that passes inspection continues along the conveyor to the ‘OK’ tray located at the right end.
    PLC Programming

Apply for friendship links:WhatsApp or E-mail: admin@plchmis.com
Control Global
Automation Control
 
Automation World
Automation Net
 
Control Design
Control Engineering
 
Automation Direct
Direct Industry
×
×
  • Create New...