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, CAD drawings, SCADA packages and virtual machines. These are some of the resident software suites on the average automation or control professionals computer today. This post is mainly about the hardware needs to get the job done.
Picking a laptop for automation and control engineers
Based on recent discussions on PLCTalk, the specifications vary based on preference. Some of the common requirements mentioned:
A 15″ screen laptop is the sweet spot for ease of travel and ease of troubleshooting while onsite. Anything less makes the onsite work, specifically if programming is involved, a little harder. Anything more makes for a bulky laptop to travel with.
Last year, I had two programmers show up in PLC programming classes with Surface Book style tablets. With the i7 processors, the Surface performed well. With the screen size, they struggled in maneuvering through the programming environment. Followed up with one of them this year and they had moved back to a larger screen laptop. PLC Programming with the magnifying tool in Windows is not practical.
The recommendation is a i7 type processor with 3GHz clock. My current machine has a 2.8GHz spec and has been great. Performance with 2 VM’s , HMI software and PLC software running simultaneously noted on screen cap below.
The RAM requirements vary. With virtual machines being a common place to house several different control software suites- PLC and SCADA environments, RAM requirements are a minimum of 16GB .
Based on a the Windows performance monitor, having one HMI software, one PLC programming environment and one VM took the memory usage up to about 14GB. Note, this number is based on the allocation on your VM’s. Also, it may vary based on the various software suites.
A PLC programmer laptop option needs to have lots of RAM. I would recommend 32GB.
The SSD seems to be the way to go. They are generally more shock resistant. Working with PLC’s often means being onsite at various locations. This may even apply to plant based folks who may have to carry Also they are quieter.
Requirement would be at least 500GB.
Most industrial automation software suites have traditionally been Windows based. Having said that, much feedback I have received regarding MacBook (Pro’s) have been quite positive in terms of performance. That sentiment it shared on this thread.
Mac users may use Boot Camp to get Windows running. Alternatively, many do report using VM’s.
I use Windows 7 Professional. Windows 8 compatibility is common among software suites out there currently. Some even support Windows 10. Having said that, industrial automation is usually slow to adapt to new OS versions. Some have reported good results and some report problems. This uncertainty keeps me at Windows 7.
Hooking up to a power source onsite can sometimes be cumbersome. The tradeoff on some of the more powerful machines has been that the battery drains quickly. Consensus is that the MacBook Pro runs all day on a single charge. This goes back to the OS discussion above.
My quad core Lenovo W541 holds a charge for about 1.5 hours. I don’t hold the battery requirement to high on my priority list. If you do, check it out while shopping. Be cautious, as the advertised values might not hold true. They are dependent on your performance and usage.
One absolute comparison, is to check the ampere-hours (Ah) ratings among your options.
Numeric keypad might help for some work functions. If the laptop doesn’t come with one, there are USB connectable options online.
DVD players can be left out as Installers are increasing available in downloadable software packages. If required, a portable DVD player can be used.
Back-lit keyboards may be useful for work in environments that are not well lit. Not a requirement I considered but noted in the thread.
The actual picks:
I’ve used Dell’s, HP’s andLenovo’s in recent years. My pick for stability and performance right now is the Lenovo. It may be biased to the hardware specs on this current unit. The previous units also had good specs for their time.
In all, the package is probably going to be about USD$2000 or higher. Shopped during the Black Friday sale last year and Lenovo had a great deal on the W series. Probably due to that series being phased out. The price was down to $1700-ish for a 32GB RAM, i7, 500GB SSD setup.
The threads discussing the topic on PLCTalk are here and here.
This site seems to offer Modbus simulator and OPC tools. With the Modbus tool, there is an indication of a succesful connection. There is an evaluation version of the software downloadable. The full version is not free.
There seem to be several Modbus simulators and polling tools offered here. This software is also not free. There seems to be a trial version that works for 10 minutes at a time for the first 30 days. This software includes options to log data to Excel and text files. It is unclear if there is confirmation of ‘good connection’ provided per the original question.
There is also an option create a custom frame which might be useful for testing and debugging purposes.
This is a free, open -source project built on a framework called qt. New to me, interesting concept. There is a bus monitor to see live frames. The latest update was in February 2016. Seems promising mostly 4 and 5 star ratings from its 9 reviews.
Finally, the software I have used for Modbus TCP testing. Schneider Electric has a free serial and Modbus TCP tester software. Unlike ModScan and some of the other options out there, this tool doesn’t include a live frame by frame view of communications.
In all cases, the option to automatically scan ‘live/open’ registers on a network didn’t seem to be something common on the market ( keyword:automatic). For Modbus networks with communications already up and running, the best bet would be to use a a communication viewer screen. This would show the frames on the network with addresses, commands and responses.
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.
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: 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:
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.
While the title states PLC ethernet network addresses, this post applies to any device on ethernet. With ethernet growing rapidly in industrial automation, and many if not most control engineers not having a mainstream IT networking background, this is a primer on the topic of IP addressing and subnets.
Ethernet connectivity is included on many if not most newer PLC’s and industrial automation devices. As such, basic knowledge of Ethernet networks is a requirement for control engineers and automation personnel. The topic has come up several times over the last few months on PLCTalk. This weeks pick is a post by PLCTalk longtime user Operaghost. It is from March 2016 and covers some important notes about networks and subnetworks ( subnets).
The post has been published here with permission from Operaghost. Operaghost’s text is in blue. Some parts are expanded further with the diagrams below.
Subnetworking is used to define a specific division out of a larger network. The ‘Subnet mask’ is applied to an IP address to define the ‘network prefix’ for the subnet. The rest of the available bits in an address becomes host addressable addresses within the subnet. More details here
The original question by WillM is as follows ( in green):
Simple question but I want to be certain. Lets say you have 2 separate PLCs on a network with the following configuration…
PLC 1 192.168.1.1 255.255.255.0
PLC 2 192.168.1.2 255.255.0.0
If i set my PC up with the following… 192.168.1.X 255.255.255.0 or 192.168.1.X 255.255.0.0
Will I be able to access both PLCs without having to change the subnet?
I’ve tested it and it works. I’ve read up on subnets and in my head it works but someone has told me there may be issues. My understanding is that both IP addresses are within the smaller Subnet of 255.255.255.0 so if my laptop was set to 255.255.0.0 it would be accessible.
Am i missing something or is it ok?
There were several responses in between, and then Operaghost’s descriptive response ( in blue below):
Ok, there is some misinformation going on here. Yes, what you described will work.
But the mixed subnet masks is usually not a good idea just from a organization aspect. But it is certainly allowed.
So this may be more background than you wanted, but I wanted to set the record straight.
Breakdown of IP Address Ranges for Networks
Class A addresses range from 188.8.131.52 – 127.255.255.255. So for example, 10.0.0.1 starts with a 10 so it is a Class A address. Class A addresses use 8 bits to represent the network address and 24 bits to represent the individual hosts. So with Class A I could have 128 individual networks with each network containing over 2 billion host devices.
The bit level representation here is in reference to the 4 octets being made up of one byte each. The entire IP address breaks down into 32 bits ( diagram above).
Class B addresses range from 184.108.40.206 – 220.127.116.11. So for example, 172.16.0.1 starts with a 172 so it is a Class B address. Class B addresses use 16 bits to represent the network address and 16 bits to represent the individual hosts. So with Class B I could have 16,384 individual networks with each network containing over 65,000 host devices.
Class C addresses range from 192.0.0.0 – 18.104.22.168. So for example, 22.214.171.124 starts with a 201 so it is a Class C address. Class C addresses use 24 bits to represent the network address and 8 bits to represent the individual hosts. So with Class C I could have over 2 million individual networks with each network containing over 256 (actually 254) host devices.
We won’t get into Class D or E.
Class A Typically use a subnet mask of 255.0.0.0 255 = 8 consecutive 1 bits followed by 24 consecutive 0 bits is often known as “/8”
Class B Typically use a subnet mask of 255.255.0.0 255.255 = 16 consecutive 1 bits followed by 16 consecutive 0 bits is often known as “/16”
Class C Typically use a subnet mask of 255.255.255.0 255.255.255 = 24 consecutive 1 bits followed by 8 consecutive 0 bits is often known as “/24”
This is what is known as CLASSFUL Addressing. This basically meant if 192.168.1.1 was your IP address, then 255.255.255.0 was your subnet mask. Automatic, no ifs ands or buts.
Classless and Classful Addressing
But once IP addresses started to dwindle in availability, we saw how wasteful this addressing scheme really can be. So today, it is not required and most networking people have abandoned it. We can instead use CLASSLESS addressing. But, you don’t really want to mix methods as it can be very confusing and frustrating.
So with CLASSLESS it is now commonplace to see a mix of address classes and subnets. So your example of 192.168.1.2 with a subnet of 255.255.0.0 is a perfectly acceptable CLASSLESS address. So the whole idea of Class A, B, and C are not terribly relevant with the classless addressing scheme.
Your address of 192.168.1.X with a subnet of 255.255.0.0 is simply saying that this is a network identified as 192.168.0.0. The first IP address in the range is known as the network address. The mask is identifying that the last address on your network would be 192.168.255.255. Now the very first address and the very last are reserved so (256 x 256) – 2 = 65,534 devices could all be on the same network. That is potentially a very large network. One device sending a broadcast message would go to all of those devices.
Your address of 192.168.1.X with a subnet of 255.255.255.0 is saying that this is a network identified as 192.168.1.0. The mask is identifying that the last address on your network would be 192.168.1.255. So 254 devices. That is a much smaller network. One device sending a broadcast message would be contained to only go to those devices. 192.168.0.0 would be a completely separate network as would 192.168.2.0 and so on.
But what if your network didn’t require 250+ devices. What if it only needed to handle 10 devices. If we assigned 192.168.1.x with a subnet of 255.255.255.0 we would potentially be wasting 240+ IP addresses that we could use elsewhere.
So the mask of 255.255.255.0 is typically referred to as “/24” as it represents 24 consecutive 1 bits representing the network. The remaining 8 zero bits is where we get how many hosts we can have. But if we change how many network bits are used then we can affect how many host bits are available. So are not stuck with 256 or 65,000 as our only choices.
255.255.252.0 or /22 = 1024 (-2 reserved) hosts per network 255.255.254.0 or /23 = 512 (-2 reserved) hosts per network 255.255.255.0 or /24 = 256 (-2 reserved) hosts per network 255.255.255.128 or /25 = 128 (-2 reserved) hosts per network 255.255.255.192 or /26 = 64 (-2 reserved) hosts per network 255.255.255.224 or /27 = 32 (-2 reserved) hosts per network 255.255.255.240 or /28 = 16 (-2 reserved) hosts per network 255.255.255.248 or /29 = 8 (-2 reserved) hosts per network 255.255.255.252 or /30 = 4 (-2 reserved) hosts per network
So using /28 as our mask we can “sub-network” a typical range into many separate networks.
We could have the network start at 192.168.1.0 and end at 192.168.1.15 We could have another network start at 192.168.1.16 and end at 192.168.1.31 We could have another network start at 192.168.1.32 and end at 192.168.1.47 etc, etc…..
This idea of sub-netting is much more common in the IT world where they have a set number of IP addresses available and they cannot be wasted through a wasteful addressing scheme. In the controls world, we typically have had relatively small networks that have been isolated from the enterprise so our addressing methods didn’t really matter all that much. Today though we are seeing our control networks connecting to the enterprise network and knowing these addressing schemes becomes quite important.
So I have gone on much longer than I intended and I am sure I lost people along the way. But I wanted to make sure we understand that classless addressing is here to stay which makes the whole idea of Class A, B, and C mostly irrelevant.
Some of the guys at the office just got back from a SoMachine Motion CODESYS session in Germany. One of them noted a CODESYS tip/trick to change the variable name prefixes or suffixes that will save programmers a lot of time and tedious work.
Holding down the Alt key allows for a vertical highlighting feature.
From the example above:
Changing the word ‘Read’ to ‘Write’ can be done in one quick update for the entire list:
This is useful for common parts of a variable name, like above. Other examples may include:
Change user defined data type names on a set of assignments.
Adding a prefix to a mirror set of variables- e.g. SCA to variables shared with a SCADA system.
Look out for:
‘Copy and paste’ ( Ctrl-C, Ctrl-V) is a large source of PLC program bugs and errors. Severalarticles on programming cover the ‘copy and paste’ issues in depth. A cool feature like this Alt-key highlighting might feed the problem.
As such, practice caution. Saving a few minutes in tedious work is good as long as it doesn’t cause hours of troubleshooting later. Follow through with a visual check to pick up errors. Copy and paste does not negate the need for System 2 thinking which is the conscious and logical thinking instead of the subconscious and automatic thinking.
Having said that, this is one CODESYS trick I wished I had learnt a few years ago. Thank you, Jared.
The industrial automation world is increasingly connected. One of the projects this week involved a remote desktop session with a customer in the Midwest , from my NC location. The two of us were trying to log in to a PLC located in Alabama through a cloud based service. This is when I realized the utility of the multi IP setting on gateway devices.
An increasing number of PLC, drives and HMI’s include Ethernet based protocols as standard. Many also allow program updates via the ethernet connection. This makes it easier to implement remote access solutions for troubleshooting and maintenance purposes. Set up the IP addresses for the control devices, use a gateway device from eWon, InHand Networks or Netbiter and you’re ready to go.
The Reason for Multiple IP Subnets on the Remote Network
Our PLC on this project was a Modicon M251. On this setup, for various reasons, the PLC program download for the M251 had to be through the Ethernet 1 port( M251 has two separate Ethernet networks embedded). The field devices connected to it ( drives, HMI) were on Ethernet 2. The customer wanted to retain access to the webservers of the field devices when they connected remotely. Occasionally they also needed to log in to the PLC and update the program.
So, in short, we had to connect to Ethernet 1 of the PLC but the gateway device had its IP settings set to the Ethernet 2 port.
To illustrate the setup:
Drives, HMI and PLC Ethernet network 2 located on the 192.168.3.xx subnet
PLC program download port on Ethernet network 1 located on 192.168.4.xx subnet
Multi IP setting on IG601
This is where the InHand IG601 multiple IP LAN could be useful. Typically, the gateway device would need to set to the same IP subnet as the PLC, HMI or remote network. When there are multiple subnets in the remote network then the gateway device would have to be changed to access each of the subnets. The IG601 solves this as it can be set up with multiple IP addresses. Both M251 ethernet networks were set up with the corresponding gateway IP address on the IG601 as the gateway address:
Ethernet 1 at 192.168.4.3 was set up to look at 192.168.4.1 which was set up as one of the IP’s on the IG601.
Ethernet 2 at 192.168.3.3 was set up to look at 192.168.3.1 which was set up as the other IP on the IG601.
In the IG601 configuration, the multi-IP setting is easily setup in the Network>LAN settings.
The multi-IP feature was tested on my test setup and worked well.
Items to look out for during the M251/SoMachine and InHand IG601 setup
1. If the M251 IP address is altered, it may take a power cycle for it to take effect. If possible, set this up and test it before shipping the PLC or while onsite with it.
2. The gateway IP address needs to be set up on the M251 for both ports- Ethernet 2 and Ethernet 2. On this note, try to set and follow rules of setting the gateway IP address on your remote systems. Example : use xxx.xxx.xxx.1 for the gateway IP …etc.
3. The setup of the IG601 was covered in a previous postabout connecting to a Modicon M241. Having done this twice before, I still slipped up with one setting on the IG601. That is to set the cellular Access Number to *99***1# instead of leaving it blank. Not sure what this means but the system registered on the AT&T network after that setting was made.
Hope this helps save a controls engineer some energy and potentially hours/days of travel time just to perform a PLC program update or some troubleshooting. Thank you to the folks at InHand Network for their guidance on this back when I first set it up.
Amazingly, I went through this post without saying IoT or IIoT once. 🙂
Drop a line in the comments section below with questions or comments on this setup.
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… 😀
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;
Declaring STRING with defined length:
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;
Array1: ARRAY[0..5,0..2] OF INT;
Array1: ARRAY[0..5,0..2,0..4] OF INT;
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.
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.
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.
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 other option for adding objects into a program is using the object icons in the toolbar at the top, below the menus.
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.
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.
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.
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.
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.