Category Archives: PAC

Troubleshooting industrial control systems – Tips and pointers

December 6, 2017HMI, PAC, PLC, Systems, VFDDrives & Systems

Everything is hooked up but something isn’t working. It worked before but not right now. Or, it’s a new system and you haven’t got it working yet. In any case, troubleshooting industrial controls systems usually involves a repeatable approach or pattern of actions.

1. Break the system down into components.

There is a root cause to what is going wrong. Each system is made of of multiple components – software and hardware. To zero in on the root cause, check if each part/component/sub-part of the system works. Example: PLC not communicating with VFD over Modbus. Questions to ask and things to check:

Check if the VFD responds to Modbus polls from a Modbus simulator on your computer.
Alternately, if there is another PLC, preferably identical, hook it up to the drive and download the same program. Check if it communicates.
If there is another VFD available, preferably one that is known to be functional. Also preferable if its of the same type, hook that up to the PLC. Check if it communicates.

Note: Check that the communication settings in the PLC and VFD are correct.

The concept here is to test individual components to zero in on the root cause.

2. Go deep into the workings of each sub-component- including inputs, outputs and the software when possible.

This becomes easier if you know which subsection of each component may be suspect. To the communications breakdown example above, it could be the serial port ( hardware) or the serial communication settings( software). This provides for immediate leads to follow.

In any case, when troubleshooting industrial controls address the obvious first, and then go deeper into each sub-component. Confirm that everything is plugged in and powered up correctly. Can’t count the number of times something wasn’t working … because it wasn’t powered up.

3. Bring in alternative/replacement components, if available.

This includes replacement cables. Depends on the stage / I.e development, legacy/installed. This is noted described in item 1 above. The implication here is to consider carrying spare parts to a site when possible. If this is not possible, consider alternatives like software to test for specific functionality.

4. Don’t alter too many characteristics at a time.

Issues are sometimes a combination of two things happening. Example: PLC won’t communicate with an HMI. The HMI was replaced and the problem persists. The old HMI was connected back in and the PLC replaced,- the problem remained. Replaced the PLC and HMI and figured out that some kind of wiring issue had taken out the serial ports on both devices. Moral of the story: Check one component and then consider combinations.

5. Use software where possible.

One example noted in item 1 above. Another example for ethernet communications troubleshooting is a tool like Wireshark.

Use case: Watch communication lines for packets coming through and sequence of events.

6. Document testing and troubleshooting efforts.

Write down the sequence of tested items. Makes a big difference after you go through several hours of troubleshooting and forget what has been tested. Also, take pictures as much as possible. Helps when recapping items covered or when researching sub components in front of your computer.

7. Consider the environment, timing and non- obvious of issues.

Time and space are at the core of things. Noise from close by systems, or an environmental effect at the same time of day may cause intermittent issues. This goes back to non-obvious factors to consider.

There may be non-obvious factors that may affect things. One example is a electrical noise issues. Co-located power wiring or bad grounding practices could affect this.

Another example of a non-obvious factor may be related to people or process factors. Example: an operator may be shutting down a device or parts of a system and not powering them up again correctly.

Another example: someone updated the firmware to one of the devices and it doesn’t communicate to the other devices any more. The problem here may be more of a process issue but knowing if the firmware was recently updated provides leads for next steps.

PLC Programming Languages and Google Trends

August 6, 2016PAC, PLC, ProgrammingDrives & Systems

Based on Google Trends, ladder diagram seems to be the most searched language. However, past PLC programming trends are no indicator of future requirements.

Each language has its pros and cons. With most 61131-3 compliant environments, the great thing is that each part of a PLC program can be written with a different language. This allows for the usage of the right language for the right purpose or application.

PLC’s continue to have more features, and applications are increasingly applying these new features. Examples: Data handling with arrays, sequencing state diagrams, more math, … A ladder diagram is not a good way to utilize or apply some of these functions. Fortunately, the alternative is not too difficult to pick up.

What are some of the underlying factors that keep the ladder diagram preference going?

Ladder diagram is similar to a electrical control schematic with rails on each end. This makes it a easier for maintenance folks and electricians to troubleshoot it if the need arises.
A large proportion( PLC count) of PLC’s sold go into ‘simpler’ applications. These applications are covered by the small and mid-range PLC market. The applications may be start/stop, sequencing and boolean logic based for the most part. These are great application grounds for ladder diagrams.
Some PLC programming environments have a strong ladder editor. That combined with other features such as a live, animated view of the system when logged in with the ladder environment make it appealing. Other environments animate when logged in using any of the languages.
We all like what worked before. Even when it doesn’t work well enough anymore. Until we have to do something different to stay in business. And then change is imminent and accelerated.

Why will the industrial control world need more than ladder diagram moving forward?

Much more connectivity. PLC’s handle much more than just logic. They connect to other devices on the factory floor and at the plant level or even remotely.
Data handling. PLC’s today have sufficient memory to track and control thousands of data points. The tools to handled these data points are best applied in non-ladder languages. Example: Arrays, file handlers, math functions..

Based on the above evolutions in industrial control, the following points need to be considered:

Every language has its benefits, don’t get intimidated just based on familiarity.
Consider what needs to be done before picking a language
Stay open minded.

Ladder is good for viewing inputs and outputs and basic functions with triggers and timers. Structured text is good for math and data manipulation. Function block diagram is good for getting a graphical overview of a system. Sequential function chart is good for state based system organization. On larger PLC programs, all of them can be used for different parts.

The following Automation.com article covers the languages at a high level, with some details on pros and cons of each.

Going back to some of the other PLC programming trend observations

Interestingly, the term ‘structured text’ is strongly related to ‘CODESYS’ and ‘61131’ search terms. Note: The table embedded below shows the ‘Rising’ terms by default. Click on the ellipsis like button on the bottom right and select ‘Top’ to see the others.

Another interesting observation with regards to search cycles. July and December seems to be down-cycle parts on most years. Might it be tied to mid year and end year vacation times? Summer and winter breaks maybe?

On average, ladder diagram gets nearly double the search volume compared to structured text. This is followed by function block diagram which got about one third of the search volume relative to ladder diagram. Sequential function chart is a faraway fourth with about one tenth of the search volume relative to ladder diagram. Note, these are averages and there may be measurement errors due to exact search terms and various languages. Also, various vendors do have slightly different names for the languages compared to the IEC61131-3 names.

If you have a specific reason why you pick one language over another, leave a comment below.

PLC Program State Diagram : CASE Structures in Structured Text

July 30, 2016PAC, PLC, Programming, SystemsIEC61131-3, PLC Programming Patterns, Structured TextDrives & Systems

There are several ways to implement a PLC program state diagram. One of the best ways is using a CASE structure in Structured Text. This statement is specifically true for PLC programs that need to handle a state -to-multi-state system. The benefit of good state-based organization makes troubleshooting easier. It also helps with readability and maintainability of a program.

IEC61131-3 helps with organizing PLC programs

The IEC61131-3 software model helps the organization and sequencing. It defines the ability to ‘divide and conquer’ a larger system down to individual program units ( program organization units or POU’s in 61131-3 lingo). Also, the ability to have multiple tasks helps organize the sequence of the execution of program units. The standard also specifies Sequential Function Chart as the environment to organize a PLC program.

Having said that, if you are to build a sequence with a point -to-multipoint state diagram, a CASE structure in Structured Text is probably the most effective way to do it. We shall examine this in a little more depth.

Why CASE structure in ST?

When one state executes, all other states do not. This is unlike the ladder diagram environment where a rung is within the execution path even if the logic within it is not currently active.
Any state can be transitioned to any other state and vice versa.

Example:

PLC program sequence with multiple states — Some systems require for one state to be able to transition to multiple other options for states.

Example: While running, a machine has to operate several different sequences:

one sequence for when there is a power loss condition
a different sequence when a jam is detected
another sequence when an analog input goes below a threshold

This does not mean that the entire program has to be in Structured Text

One of the benefits of the 61131-3 standard is that each program organization unit can be written in a different language. The I/O interface can be written in ladder diagram. This helps maintenance folks provide the first line of troubleshooting by checking I/O statuses.The main program operation can be written with the step/state based Sequential Function Chart. The RUN operation with all the logic

There is much confusion on the internet and probably in perception among PLC programmers about which language is best for a step/state based program. Ladder diagrams have been around for a long time which has led to much bias towards it. Also, it is relatively easy for maintenance personnel to work with it. However, all facts considered, it is not the best for organizing a state based system. The preference for ladder ( besides the above points) is also strongly tied to the way one of the major PLC programming platform is/was structured.

Moving forward, a mixed programming language approach is best. It helps speed up troubleshooting and development of PLC programs. It also will cover better analytics and data handling in PLC’s with the usage of arrays.

What would a CASE structure for a Multi-State PLC Program Look Like?

The frame of one might look like follows:

Frame of a State Diagram with a CASE Structure in ST

There are going to be programmers who use SFC for state diagrams. Then there is a part of the community who ( for various reasons) will be using ladder logic. If there is a point to be made for any of these selections, submit your thoughts in the comments section below.

CODESYS Declaration Examples: Variables, Arrays, Function Blocks…

June 13, 2016CODESYS, PAC, PLC, Programming, SoMachineDrives & Systems

There are many ways to implement variable declaration in CODESYS. It can be easy to forget the syntax or specifics on some of them. This post covers them for reference. Also, a couple of programmer cautionary comics from XKCD at the bottom… 😀

Variable Declarations:

VarName : INT ;

Variable with located memory address

VarName AT % MW123: INT;

Variables with Initial Value:

VarName : INT := 23;

Variable initial values can be tied to another variable of the same data type:

VarName: INT:= VarName2;

where:

VarName2:= INT;

Declaring STRING with defined length:

VarName2 :STRING(40);

With the above, a string of 40 characters is created. Each character is one byte.

Declaring STRING with initial assignment:

VarName :STRING:= ‘HELLO WORLD’;

Declaring Arrays with Initial Value:

Array1: ARRAY[1..5] OF INT := [1,2,3,4,5];

Without initial value it would just be:

Array1: ARRAY[1..5] OF INT;

Some other notes about arrays:

The first element can be element zero, i.e.

Array1: ARRAY[0..5] OF INT;

Multi-dimensional Arrays:

Array1: ARRAY[0..5,0..2] OF INT;

Array1: ARRAY[0..5,0..2,0..4] OF INT;

Declaring Pointers:

PointerToStrArray : POINTER TO STRING ( 9 );

Declaring Pointers to Arrays:

PointerToStrArray : POINTER TO ARRAY[1..10] OF STRING ( 9 );

In both the pointer examples above, the pointer values can be loaded with the ADR function. More on that here.

Declaring Function Blocks with Inputs:

Declaring an OFF delay timer from the Standard library with an initialized preset time

OffDelayTimer: TOF:= (PT:=T#2S);

The above declaration method can also be used with the preset time tied to another variable of type time:

OffDelayTimer: TOF:= (PT: = PresetTime);

where the PresetTime is declared as follows:

PresetTime: TIME := T#2s;

One of the positive points of a textual variable declaration area is the option to copy and paste. In some programming environments, the alternate to a textual declaration is a tabular or table based variable declaration area. Some table based ( or tabular) variable areas might include a pull-down menu of options for each declaration. This may help someone who is beginning to learn in an environment.

Nevertheless, in the long term, textual declarations are more flexible. Another benefit is opens up the option to generate the variable declaration externally- in Excel for example. The external declaration is useful for larger projects with multiple programmers. In Excel, a name can be created and multiple versions of a variable generated with prefixes or suffixes to that name. One example may be:

For a variable called SysRun:

The local variable could be SysRun_Local

The status to be fed to a SCADA system could be SysRun_SCADA

Instead of typing out: SysRun_Local: BOOL; and SysRun_SCADA: BOOL; , the entire declaration process can be automated in Excel and then copied and pasted into CODESYS.

To wrap up for now..

Comments in variable declaration field are important. It helps the next person who reads the code/program. It might even help you make sense of your work, in the future. Also, for function blocks, the comments on the same line as a variable become the description of input pins when the cursor hovers over a pin.

Include comments with variable declaration. Comments help refresh your memory or serve as a guide for the next user. — Include comments with variable declarations.Comments help refresh your memory or serve as a guide for the next user.

There are probably other useful points and methods of variable declarations in CODESYS that are not included here. If one comes mind, please comment below.

…

PLC Programming Quickstart Guide : First 60 minutes of most PLC Programming Environments – Part 3- PLC Programming tools

June 5, 2016PAC, PLC, ProgrammingDrives & Systems

This is part 3 of the PLC programming quickstart. The checklist continues with items 5 and 6. This part will cover PLC programming tools in the development environments . To recap the items covered in the previous two parts.

I/O Declaration : Find the methods and location of I/O declaration for the PLC program.
Variable declaration: Find the location and types of variables supported.
PLC Logic: Check on the location of program organization units (POU’s) . Check on applicability of programs, functions and function blocks.
Task Configuration: Are the POU’s to be executed organized by task. If so, check on the location functionality of the task manager.

This part will cover 2 more items. Step 5 is to explore the general environment and program language editors. Step 6 is the function in the environment.

5. Environment, Editors, Toolbars

There is often more than one way to do things in the programming environment. Get to know the locations and options of the tools and editor specific functions.

A good starting point is usually the toolbox and toolbars. In SoMachine and CCW, selecting View in the menu bar at the top yields a selection of toolbars and functions available in the environment.

In SoMachine and CCW, the toolbox shows up on the right side of the screen.

The toolbox objects and functions in SoMachine for ladder

The other option for adding objects into a program is using the object icons in the toolbar at the top, below the menus.

PLC programming environment tools — Objects at the top

Another place to check is the contextual options available when using the right click button. For example, in the ladder environment, right clicking in a rung ( or network as it is referred to in IEC terminology) brings up the objects that can be added.

Contextual right click as a PLC programming tool — Right click in the ladder editor brings up objects that can be added

This also applies to other parts of the environment. For example, right clicking in the device directory brings up items that can be added in a specific context.

Adding ethernet device in the PLC programming tool — Right click in the Ethernet network setting brings up the option to add a device

This shows us there are often multiple ways to accomplish the same outcome. An coil can be added by dragging and dropping it from the toolbox. A coil can be added by right clicking on the rung/network. A coil can be added from the menu bar at the top.

The right click also pulls up some contextual options in the CCW environment.

PLC Programming tools in CCW — Adding functions and objects in CCW by using a right click and the selector.

PLC programming environment - CCW - — Adding a new program with a right click

Find the way that you feel most comfortable using. There is no right and wrong to it.

6. Functions and libraries

Any task becomes harder without the right tools. For a long time, I was re-creating a periodic ON-OFF function using two timers until I discovered a function called BLINK in CODESYS. The same applied to a simple scaling function block. I later found one already built into SoMachine. The moral of the story is to figure out what is available in the environment early. It will save time and effort. It will reduce the amount of code that gets written.

There are a set of functions that are used in most PLC programs. These include timers, triggers and PID function blocks. Knowing where these functions are and how they are used is next on this checklist.

To find the basic functions:

check toolbox from previous step.
if there is a library manager, check the libraries
review the help files

For instance, in SoMachine, the Util and Toolbox libraries are worth a review. They contain functions to simplify programming..scaling, limit checking, PID,…

They are located in the Library Manager.

Library Manager – Util library functions

Final point about familiarizing with a PLC environment, browse through the help files. There may be details about implementing different functions. The structure of the help files in SoMachine and CCW includes a content list and a search function. Browse through the content list. If anything, this may show you the functions and terminology in the environment.

In summary, the tools and functions in a PLC programming environment will make or break the programming experience. Some key steps on getting up to speed:

Familiarize yourself and explore the environment prior to starting a project.
Exploration will include clicking (including right clicks : 0) through all the functions, object and menus on-screen.
Browse through the functions libraries and toolboxes.
Browse through the help files.

If a question comes up while doing the above, note it down. Check with the vendor or refer to any example projects that may be available.

Happy programming on your next PLC project!

PLC Programming Quickstart Guide : First 60 minutes of most PLC Programming Environments – Part 2

May 17, 2016CODESYS, PAC, PLC, Programming, RockwellPOU, taskDrives & Systems

The PLC programming quickstart checklist is intended for a user to learn a new PLC programming environment. This applies to users who have programmed PLC’s before and also for someone new to PLC’s. Continuing from part 1 with checklist item 3:

3. Program logic

This is where the code is going to be.

IEC 61131-3 is the reference standard for PLC programming languages. In 2016, all major PLC platforms have some level of compliance to this standard. The standard does allow for partial compliance and requires manufacturers to declare specfics of their compliance with a statement. A quick introduction to the standard is available at the PLCopen site.

Per the standard, logic can be written as one of the following 3 types of program organization units (POU’s):

Programs
Functions
Function Blocks

PLCopen covers an overview of these types in a presentation here.

Adding these POU’s to the program usually occurs on the left side of the screen. There are some differences on how this is done in various environments.

In SoMachine which uses CODESYS V3, a POU is added by right clicking the Application directory and selecting Add Object>> POU. Subsequently, the option to add a Program, Function or Function Block pops up.

The POU types and options do vary in terminology and operation from platform to platform. In CCW, the Programs are added under the Program directory header. Function blocks are added under a separate header called User Defined Function Blocks.

When adding a program, the user is usually prompted to define the language chosen for that POU. When playing with a new environment, here is where you will find out the languages supported ( other than in the literature).

It would be advisable to select the different languages and test drive them. At the very least, select the language you will use and play around with the development environment. A later part will cover the specific items to look for in the language chosen.

Some questions to ask, that does vary from platform to platform is:

Can a program call another program?
When a function block is updated, does it automatically update every instance?
Can program execution order be arranged?

The final question takes us to checklist item 4…

4. Task Configuration

The importance of a ‘task’ is that it gives the PLC programmer control over what parts of the code to run and when. Task configuration covers the order , timing and triggers of execution. For example,

A cyclic task may be configured to execute every 20ms.
An acyclic, freewheeling task may be set to occur per the processor execution cycle for the POU as defined.
An event triggered task may run only when an input is triggered.

If a part of the code needs to have a higher priority over other parts, it may be defined in a task of its own. It could also be set to execute with a shorter cycle time, if required.

SoMachine tasks are configured under the Task Configuration header. Multiple tasks can be defined with the number varying based on the specific PLC used. CCW does not have a specific task configuration section. Programs noted in programs section are executed in order. The order can be changed, as required. CCW does have an interrupt option that can be used to trigger specific logic as required.

Key takeaway here is to note the differences in the number of tasks and sequencing options for programs/POU’s in various environments.

PLC Programming Quickstart Guide : First 60 minutes of most PLC Programming Environments – Part 1

May 15, 2016CODESYS, PAC, PLC, ProgrammingDrives & Systems

Most control engineers and PLC users are going to encounter several PLC platforms over a career span. Whether through jobs at different companies or through migration of control platforms, the need to adapt and learn new programming environment is an essential part of the job. As I go through this process with a new platform, the following checklist was developed as a ‘quickstart guide’ when programming in a new PLC platform.

The good news is that most PLC programming platforms use a very similar set of features. The features are called using different names by different vendors. In many cases, even the layout of the program is similar. There is usually a directory on the left side of the screen, a message window at the bottom…etc.

So, this post will be Part 1 of a multi-part series about the key things to look out for in a new PLC programming environment. The way this will be set up is as follows:

Several programming platforms will be referenced in examples; SoMachine (CODESYS), SoMachine HVAC and Rockwell CCW. I’m very familiar with SoMachine and CODESYS, new to SoMachine HVAC and never used Rockwell Automation’s CCW before.

The intent would be to get proficient enough in a new environment to write simple to intermediate programs. We will save more advanced features for another discussion.

I/O Declaration

The basic function of a PLC is to be able to accept inputs and control outputs. In most current PLC programming environments, the inputs and outputs are referred to in the logic using variable/tag names or pre-assigned terminal designations.

If a PLC program is to be looked upon as a story, the main characters would be the variables and the I/O. They are the subject.

So, the key questions when encountered with a new environment is:

Where are input and output variables or tag names assigned?

How are they called in the program- pre-assigned name or user-defined names?

Common approaches:

The I/O tags or their user assigned tag/symbol names are declared in one place and then available to be called throughout the program. They are essentially similar to global variables.

Some of the terms used for these names include symbols (CODESYS), tags (often used in SCADA environments and aliases (alternate references to a I/O point in Rockwell controllers)

In SoMachine the input and output mapping can be addressed using either the address assigned to the terminal input( this is referred to as direct addressing) or a user-defined symbol name.

In CCW, I/O is addressable in code using either the pre-assigned name or an alias.

Between the pre-assigned name and the user-defined name, both are usable in this case. With the usage of the pre-assigned name in SoMachine, a pop-up usually occurs to advise the user to use symbolic addressing for ease of maintenance and modification.

Variable declaration

Once the I/O is declared and accessible in the program, the next point of interest would be to figure out where and how variables are declared. Some variables can be pre-planned if we know the functions they will be plugged into. Others may be added on the fly.

The two main types of variables are the local and global variables. Local variables can be called from the POU that it is declared in. Global variables are accessible anywhere in the project.

Some environments allow for variables to be declared textually. Others require a tabular declaration with a pull down for the data type. The textual declaration may involve a little more typing, however, the benefit is that it is more flexible and supports copy and pasting variable names. For larger projects, variables can be created in a spreadsheet separately and then pasted into the PLC program project. The benefit of a separate variable creation is that variations of the variable name for SCADA purposes and also the generation of memory locations can be performed easily and quickly in a spreadsheet.

For textual declarations, observe the syntax used for various data types. Some key questions here are:

How are variables given an initial value?

How are persistent or retain variables created ( to keep values through power cycles)?

How are arrays declared?

Regarding the point about retain and persistent variables. In CODESYS, the retain variables holds a value through power cycles. Persistent variables hold a value through program downloads.

In SoMachine, retain variables are declared using the VAR_RETAIN header in the variable declaration section.

Variables to be kept through program downloads are declared in a separate object.

Persistent Variables to hold a value through program downloads

Next part will cover the program types or POU’s as referenced by the IEC 61131-3 standard…

PLC Program Debugging Checklist: 5 Things to do to correct errors during PLC Program development

May 12, 2016PAC, PLC, Programmingdebugging, TroubleshootingDrives & Systems

So, you’re programing in a PLC platform that is new to you. The functions, tools and syntax may be different from what you are used to. As you get acquainted with them, there are probably going to be errors showing up in the message list when a build or compile is performed. The following are 5 things to do to debug or correct these errors when developing a PLC program.

Checklist item 1: Compile as you go (don’t wait until the end) and check the messages

a. About compiling often: Nobel Prize winner Daniel Kahneman in his book ‘Thinking, Fast and Slow’ states a correlation between the ability to build expertise on a topic and the speed and quality of feedback during the process of learning. The inference of this in building PLC programs, specifically in an environment you are new to, is:

Compile or build the program often
Decipher the compile errors and messages accurately.

Some programs or programming environments are going to take longer to compile so this habit is dependent on the environment too.

b. The second part about deciphering the error message accurately is highly reliant on the environment itself. For instance, I am working in an IEC 61131-3 environment called SoMachine HVAC. The error message said ‘Token not found’ and pointed to an inexistent line number in the POU. After using Step 2 below, it turned out that one of the variables had a period/dot (.) in front of it which is acceptable in the CODESYS environment but not in the new environment. Removed the period/dot and the error message went away.

About checking the messages, observe if there are root cause messages that are effecting other error conditions. In CODESYS for instance, addressing the errors at the top of the error message list often results in the solving of multiple other errors that are lower in the list.

Checklist item 2: Check the help files and any example programs available

Some environments may have a manual. Some may have a good Help section. On either one of those, browse through the contents of the manual and Help files. When a problem arises, it may come in handy.

Another good reference is an example program. Trying to figure out how a read operation is performed over a comms network? Or maybe just the usage of a simple CASE structure sequence? Having one good written up program helps and can serve as a ‘go to’ program. When starting in a new environment, ask the vendor for some example code and programs.

Checklist item 3: Test only the suspect function, in a separate POU.

The idea here is to test the function and its utilization method. If you are using the function wrongly then this step will pick that up. Break the function down to the arguments that are fed to it. Check if any one of the arguments are of incorrect type of using wrong syntax. The ideal case is if the compiler picks up the error and tells you what is wrong but that is not always the case.

Checklist item 4: Comment out sections of the program and check if the errors persists.

As is common in tackling any engineering feat, ‘divide and conquer’. Comment out sections of the code and perform compiles systematically. Start with the section you suspect to be the root cause and then expand from there.

A note about the psychology of debugging; sometimes it is easy to blame the problem on the programming environment or a vendor. You might be telling yourself ‘This programming environment is buggy’ or ‘It’s not user friendly’. Try to quash this, have some faith and be bullish about solving the problem. This has helped me tackle problems much quicker rather than going back and forth with tech support or giving up only to find a simple solution I had overlooked.

Checklist item 5: Build your go to resource list … and Google away

Document your findings somewhere. Preferably somewhere searchable. This step takes time but will save you time later. Also, when someone comes to you for help, you will have something to give them – which helps me since I work for a vendor.

As stated above, collect examples from the vendor. I collect examples from colleagues, previous projects, development team…

Vendors may also have an online FAQ list, forum or wiki page. Get to know those resources.

Another resource maybe online forums like PLCTalk. For CODESYS, check out the CODESYS forum.

Hope this helps as a debug checklist. If there are any other methods out there, please add them to the comments section below. Given the thousands of hours controls engineers and PLC programmers spend debugging, there is probably a part 2 that needs to happen on this topic.

PLC Programming Patterns- The Debounced Threshold/Limit

September 26, 2015CODESYS, PAC, PLC, ProgrammingCODESYS, PLC, PLC Programming PatternsDrives & Systems

Patterns in PLC Programming: The threshold + timer function – Debounced Threshold

PLC programs are frequently made up of the same sets of functions or patterns of logic. These patterns perform commonly required control routines. Examples include threshold detection for alarm purposes, input/output mapping and scaling functions, to name a few. These combination of functions make up re-usable patterns or function sets that form the building blocks of a PLC program.

Repeated usage of some functions in a PLC programming environment holds true to the universal 80/20 rule ;20% of the functions available in a programming environment( such as timers and logic functions) would probably be used to build 80% of PLC programs.

The debounced alarm/threshold pattern is one of these commonly required PLC programming patterns. This pattern is probably better written in ladder diagram (instead of any of the other 61131-3 languages), for two reasons:

Maintenance personnel will be able to view the status of the process/monitored variable, associated timer and output all in the same place
It can be programmed in 2 rungs of ladder compared to more than 10 lines of code.

The ladder diagram version could look something like this:

Alarm ACTIVE

Note: An Auto/Manual Reset Provision is built into the Alarm Reset Timer rung.

Alarm NOT ACTIVE

The following pattern is the debounce pattern for detecting limit breaches along with a timer, written in Structured Text for the CODESYS environment. As described above, the structured text version takes more space and possibly looks more intimidating specifically to someone who is used to the ladder environment.

CODESYS-LimitThresholdScreenCap

The plain text version of the structured text version is attached below:

PROGRAM DeBounced_Limit

VAR

irProcessValue : REAL; (*Process value scaled from analog input signal*)

rProcessLowLimit : REAL; (*User defined process value low limit alarm threshold*)

qxLowLimitAlarm : BOOL;(*Low limit alarm bit*)

LowLimitAlarmTimer : TON; (*Process value low limit alarm trigger debounce timer*)

LowLimitAlarmResetTimer : TON; (*Process value low limit alarm reset debounce timer*)

LowLimitDebounceT : TIME; (*Process value low limit alarm trigger debounce time*)

LowLimitResetDebounceT : TIME; (*Process value low limit alarm reset debounce time*)

xAutoReset : BOOL;(*User enabled alarm auto reset function*)

ixUserReset : BOOL;(*User triggered alarm reset function for manual reset*)

END_VAR

(*If value is lower than low limit, start timer, else reset timer*)

IF irProcessValue < rProcessLowLimit THEN

LowLimitAlarmTimer(in:=TRUE, PT:=LowLimitDebounceT);

ELSE

LowLimitAlarmTimer(in:=FALSE);

END_IF

(*If timer lapses, trigger alarm bit*)

IF LowLimitAlarmTimer.Q THEN

qxLowLimitAlarm:=TRUE;

END_IF

(*If value is higher than low limit, start alarm reset timer, else reset debounce timer*)

IF irProcessValue > rProcessLowLimit THEN

LowLimitAlarmResetTimer(in:=TRUE, PT:=LowLimitResetDebounceT);

ELSE

LowLimitAlarmResetTimer(in:=FALSE);

END_IF

(*If timer lapses, and system permits auto-reset, reset alarm bit*)

(*If the system does not permit auto-reset, add user invoked reset bit here*)

IF LowLimitAlarmResetTimer.Q AND (xAutoReset OR ixUserReset) THEN

qxLowLimitAlarm:=FALSE;

END_IF

CODESYS Pointers and Dereferencing

September 26, 2015CODESYS, PAC, PLC, ProgrammingCODESYS, PLC, PointersDrives & Systems

Pointers and Arrays in CODESYS

The CODESYS language supports the usage of pointers which is essentially a variable that stores the location of another variable or data point instead of its value. The actual value of a variable that a pointer points to can be retrieved by dereferencing the pointer.

What could it be used for?

1.Storing the location of the variable saves space specifically when pointing to large data points or structures.

Pointers allow for sorting and re-arrangement of data sequences without actually changing the location of the original data points. To characterize in a diagram:

Going down the path of object oriented programming in PLC’s/PAC’s, this supports abstraction by separating the usage, manipulation and parts of an object from the original object itself. This helps reduce the PLC code required to handle every scenario and also helps in situation where the original object can not be manipulated because its hardcoded to an input ( for example).

Example:

Let’s say the array of data on the left side of the diagram above is read (as inputs) from a set of 4 drives controlling 4 pumps. From top of the array to the bottom Array location 0 would be for Pump 1 , location 1 for Pump 2 …..location 4 for Pump 4.

If the data is each of the pumps runtime, the pointers to the runtime allow for it to be sorted and stored in the pointer of arrays without changing the order of the original array which is important, as the original array of runtime data may be hardcoded to the actual input or read values from the drives.

Secondly, when the decision is made to call a pump to run, the same mechanism of pointers and arrays and de-referencing can be used to point to the command word of each of the pumps on a communication bus.

The end result is the amount of code required in determining which of the pumps to run is reduced.

What does the syntax look like in CODESYS?

To create a pointer:

The address operator or ADR is used.

Let’s say the variables are:

PROGRAM PLC_PRG

VAR

j: INT;

k:INT;

pointToJ: POINTER TO INT;

END_VAR

The pointer assignment would be:

in plain text:

pointToJ:=ADR( j);

Note: ADR is a CODESYS operator and not an operator prescribed in IEC61131-3.

To de-reference a pointer:

The ^ operator is used to de-reference pointers.

Example:

in plain text:

k:=pointToJ^;

This would yield the value of integer j.