Category Archives: Systems

Control Panel Layout: Top Tips with some Photos

Amongst the control panel layout tips out there, some are practical, many are good and some are downright weird. There are is a wealth of it in the /PLC sub-reddit. Some of it is amusingly opiniated:

 

The following is my collection of top tips on control panel layouts. A few of the panel posts from Reddit are embedded below. Will add more pointers as I come across them.

 

Busbar candy
byu/Otherwise_Feed_3320 inPLC

1. Heat rises

Do the heat calculations. Enclosure vendors usually have free tools for this like this .

    • If ventilation is needed, fan at the bottom, exhaust at the top, not the other way around. Hot air rises and leaves the panel, cool air comes in the bottom.

2. Power protection components at the top. Circuit breakers, disconnects. The temperature rating on circuit breakers are usually higher than the average PLC, drive or anything that has electronics for that matter. Example here – 30A breaker from SE has an operational ambient of 158 degF/70 degC. Accessibility and safety is also better with power devices at the top. 

3. Incoming power. This really depends on the install site/location. If you have a choice, some would argue that’s it’s better for incoming power to come in from the bottom. With gravity, holes and inlets at the top of the panel have poor contingencies in the event of condensation or dirt coming in( or even water ingress- say NEMA 4/4X failure situations) . 

4. Wire labels, terminals, and wire markers

    • Avoid putting the label on the device. If the device gets replaced, the label goes with it.
    • Sometimes end users may require label on device also. Check before it gets to the FAT
    • Harmonize labelling such that it can be traced back to schematics. This will help with maintenance folks and any troubleshooting efforts.

5. Wireway

    • Vertical runs should intersect with a horizontal run such that the horizontal run stops the vertical cover from sliding down
    • Plan it out such that control wiring is separated from power wiring. If they intersect, make it perpendicular.
    • Read on to number 6.

6. Electromagnetic interference

      • Separate 480Vac and  24Vdc ( control and communications) wires. 
      • If they have to cross, it’s best done perpendicularly- ie. they cross at a 90 deg angle. Still avoid having them in proximity. Good explanation of this here
      • Additional sleeving or barriers for EMI mitigation if needed.

 

7. Spacing If the project allows for it, allow for some room between devices, PLC’s, drives, power supplies. This helps with maintenance accessibility. Also, it makes way for future expansions. More I/O if the PLC needs it, another drive …etc..

My new office 😉
byu/adi_dev inPLC

8. Ground connections

    • Spec grounding washers installed and properly torqued to bite through the paint

9. Network cabling

  • Use pre-terminated cables where possible. From a good vendor, reliability is better. 
  • From item 6 above, separate controls communications cables from the power wiring.

10. Maintenance and usability

  • Add a rack on door for reference material

 

“I´m tired boss…”
byu/andisosh inPLC

Will come back and add more as I find it…

 

Share

Back on the blog, ChatGPT and Real-time Industrial Comms. Protocols

After a 5 year break from Drives & Systems, I’ve returned! 

I’ve stayed active in the industrial automation space and worked through a range of machine automation projects at Schneider Electric over the last few years. From robotics and motion through HVAC and pump control systems. Lots learnt and and a lot to capture.  Hopefully capturing some of it here comes as a benefit to others.

Wasn’t sure what I was going to find here but I have come back to some interesting stats on the site. Also some good insight around PLC programming topics users engaged with most here. For instance users seem to have landed here while googling for info on Codesys arrays. This is a promising development in the industrial controls world, knowing that data structures are being used more at the PLC level. Will expand on some of this insight and the topic of arrays in PLC programming in a future post.  

For today, I’ve been exploring the usage of ChatGPT in industrial automation. The combination of large language model processing and reinforcement learning along with what seems to be a substantial data set has led to a pretty amazing outcome. More importantly, it will have some strong use cases in industrial automation too. The use cases from code generation to building specifications, data collection to troubleshooting will likely unfold more and more in the coming months and years. 

A query I took to ChatGPT recently was to compare a few different real time Ethernet communication protocols. While some of this may be outdated since the data references are from September 2021, the output generated was quick and definitely a great reference for automation industry folks.

Whether working through a specification or just looking to learn about the different protocols, this will come in handy. 

One important point, the quality of the query makes all the difference. For example when I queried a comparison with Sercos, the outcome was totally different from Sercos III which is newer. So be precise on the query. 

Network

EtherCAT

SERCOS III

Ethernet/IP with CIP motion

Architecture

Centralized controller to multiple devices

Centralized controller to multiple devices

Distributed control system (devices communicate directly)

Topology

Line, Tree, Star

Line or ring network

Star, Linear, Ring

Data Transmission

Asynchronous

Asynchronous

Synchronous

Data Transfer Rate

Up to 10 Gbps

Up to 100 Mbps

Up to 100 Mbps

Cycle Time

100 ns

31.25 μs

Up to 16 μs

Determinism

Highly deterministic Highly deterministic Moderately deterministic

Jitter

Very low

Low

High

Synchronization

Hardware-based

Hardware-based

Software-based

Scalability

Good

Limited

Good

Real-time Communication

Yes

Yes

Yes

Security

Good

Good

Good

Descriptions of each area of comparison:

Row Description
Architecture The relationship between the central controller and the network devices, including whether the network is centralized or distributed, and whether devices communicate directly with each other or through the central controller.
Topology The physical layout of the network, including whether it is a line, ring, or star network, and how devices are connected to the network.
Data Transmission The method used to transmit data on the network, including whether it is synchronous or asynchronous.
Data Transfer Rate The maximum rate at which data can be transferred on the network, typically measured in bits per second (bps) or megabits per second (Mbps).
Cycle Time The time it takes for one complete cycle of communication on the network, including the time it takes for the central controller to send a command to a device and receive a response.
Determinism The degree of consistency in the time it takes for communication to occur on the network, with high determinism indicating a consistent and predictable communication pattern.
Jitter The amount of variation in the time it takes for communication to occur on the network, with low jitter indicating a consistent and predictable communication pattern.
Synchronization The method used to synchronize communication between devices on the network, including whether it is hardware-based or software-based.
Scalability The ability of the network to accommodate a varying number of devices without significantly impacting its performance or requiring major changes to the network architecture.
Real-time Communication The ability of the network to support real-time communication, which is critical for industrial automation applications where precise timing is necessary.
Security The level of security provided by the network, including measures to prevent unauthorized access, data loss, or data corruption.

References:

 

Share

Troubleshooting industrial control systems – Tips and pointers

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.
Share

PLC Program State Diagram : CASE Structures in Structured Text

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?

  1. 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.
  2. 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
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.

 

Share

PLCTalk Pick of the Week: PLC Ethernet Network IP Addresses and Subnets

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

Bit representation of an IP address
Bit representation of an IP address

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 1.0.0.0 – 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 128.0.0.0 – 191.255.255.255. 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 – 223.255.255.255. So for example, 201.35.0.1 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.

Subnet Mask

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.

PLC ethernet network
IP Address with Subnet Mask

 

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

 

PLC ethernet network for larger device networks
IP Address with a subnet mask of 255.255.252.0 ( 22 bits)

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.

OG

The entire thread on PLCTalk can be read here.

Share

Multiple IP Settings, Modicon M251 PLC remote connections and the InHand Networks IG601

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.

Cellular Remote Access devices- eWon Cosy 131, InHand Networks IG601 and Netbiter EC350.
Cellular Remote Access devices- eWon Cosy 131, InHand Networks IG601 and Netbiter EC350.

 

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

Remote PLC gateway
Two ethernet networks and a cellular gateway. PLC program was to be updated remotely via the cellular gateway device.

 

 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.

Multi-IP LAN setting
Multi-IP setting page on the InHand IG601

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.

SoMachine Ethernet gateway address
Gateway addresses are set for both networks.

3. The setup of the IG601 was covered in a previous post about 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.

Remember to enter the access number as shown. It made a difference on my setup.
Remember to enter the access number as shown. It made a difference on my setup.

 

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.

Share

Remote PLC Connection: Connecting to a SoMachine M241 PLC using InHand Networks IG601 Cellular Gateway and Device Touch

 

The ability to connect to a PLC remotely (or HMI) and to pull data, access webservers and download programs is increasingly a requirement on industrial automation projects. Remote data access and program maintenance saves travel time to sites and simplifies daily operations. Some of the PLC features that enable this are:

  • Webserver on PLC and HMI: Allows data monitoring and some updates to PLC configurations

 

  • WebVisualization: These are customizable user interface pages that are embedded in the PLC. WebVisu is the CODESYS term for these HTML5 pages. Some examples of their usage from YouTube are noted here.

 

  • PLC Programming software remote gateway support: This is the ability for a PLC programming software to connect to remote Ethernet based devices. This could be for program downloads or regular program viewing.

This article will cover the steps for remotely connecting from the SoMachine PLC programming software to a remote M241 PLC. The InHand Networks IG601 cellular gateway device is used as the intermediary. Other examples of intermediary gateway devices may include Netbiter by HMS and eWon ( also by HMS now I believe).

Over the last few years, the criteria I have laid out for these devices have included the means to use them without the manufacturer’s cloud- based connection service. Simultaneously, keeping the option to route more secure connections through the cloud service, only when required, is a plus.

 

The criteria for the gateway device:

 

  • Ability to setup port forwarding at the gateway device
  • Ability to use a VPN connection for secure PLC program downloads
  • Ability to support a static IP at the gateway device and allow for the above mentioned VPN connection at the same time.

The InHand Networks IG601 meets these criteria. Getting this set up can be accomplished with two sets of steps. The InHand steps and the SoMachine steps.

InHand Networks Steps:

 

  1. Connect to the InHand Device Cloud at http://g.inhandnetworks.com/. For initial setup, follow instructions per the Device Manager configuration video.

 

  1. Install Device Touch on the connecting PC. The installer is available in the Device Cloud portal. The next steps will assume proper setup of the Device Cloud and connection using Device Touch on the local PC. Instructions on Device Touch are available at the following link.

 

NOTE: While in the Device Cloud, be sure to set up a site, a device and the PLC. I forgot to add the ‘Controller’ once. It took some time and a call to InHand’s support team to figure it out.

InHandsite_Gateway_PLC
InHand Device Cloud

 

  1. Open Device Touch on your computer and connect with your Device Cloud account. Once connected to the cloud. Connect to the specific site/gateway but selecting it and clicking on the ON/OFF slider bar.

InHandDeviceTouch
Device Touch connection

SoMachine Steps

  1. In SoMachine, configure connectivity in the SoMachine gateway. The gateway is accessible by double clicking on the root of the controller directory in the device tree.

SoMachine Gateway setup for Remote PLC Connection
SoMachine Gateway

5. The connection method is set to IP address. In the example, the remote controller IP address was set to 10.0.0.100 with a subnet mask of 255.255.255.0

ConnectionMode
IP Address connection mode

    6.  Per step 3 above, if Device Touch is active and the Maintenance Channel is on/ready (screen cap below), go to the Online menu and select Login.

 

IP Address Remote PLC
IP Address Connection Mode

NOTE: The update key on the gateway will not result in the detection of the controller in the Gateway list. Entering the IP address and selecting ‘Login’ actually triggers the process if searching for the device and placing it in the available controllers list in the Gateway. The Update button in the Gateway may not find remote devices. As such, the remote PLC may not show up even if by clicking on the Update button.

 

 

  1. The gateway will scan the remote network via the Device Touch adapter. Once the controller has been found, it will show up on the controller list in the gateway with a REM icon next to it.

RemotePLCDetected
Remote PLC detected

Note: The standard warning message indicating the pending connection to a controller will pop up prior to an actual login. Entering Alt-F will proceed with the connection and potential remote download of a program. Clicking the Cancel button will abort the connection.

 

Troubleshooting tip:

Should the remote controller not be detected using the IP address connection method above, restart the SoMachine gateway as shown in the screen cap below. Subsequently repeat step 4 above.

RestartPLCGateway
Restart SoMachine Gateway

Should questions or comments arise, put it in the comments section below.

 

 

 

Share

CODESYS Visualization (and WebVisualization)

A CODESYS Visualization or Viz, is a way to embed a graphical interface into a PLC program. Interfacing with the PLC programs visually allows for quicker troubleshooting among other benefits. Further to that WebVisualizations publish a CODESYS visualization in HTML5. This enables user access to a PLC visualizations via a web browser.

Several examples of Visualizations and WebVisualizations exist online. Visualization and WebVisualization screens are created with drag and drop objects which are configured instead of coded. This simplifies screen development instead of having to build Java or HTML based objects for web accessible screens on the PLC.

The collection of YouTube based Visualizations highlighted below showcase the possibilities with the various screen objects across various applications – some industrial and some exemplar/illustrative.

The first example  is of an elevator application built in CODESYS. Credit to donkeykowng on creating this for a school project.

The next example is of an industrial mixing process with multiple tanks with levels updated dynamically. Credit to tweektweak23.

The next two credited to Kye-Hun Park .
Tetris . This visulization was built in SoMachine 4.1 which uses CODESYS 3.5
Snake game
 
Combination of  2D conveying and tank on a filling application.
CNC application courtesy of Martin van rijn
Another tank level application. Credit to Huseyin Gevrek
Material handling example with a couple of axis of a pick and place and a conveyor.
Credit to binyam .yo
More recent update of Codesys includes support for multi-touch. (from CoDeSysMotion YouTube page)
 A key benefit of a visualization is that it allows for parts of the PLC program to be graphically represented and viewed without the PLC programming software. This is given that the programmer or designer of the system designs and embed appropriate visualizations to represent the system. Being able to pull up a graphical representation of the system on a PC/tablet/phone browser allows for preliminary  troubleshooting without too many people having to have the programming software license . If the problem  is beyond wiring , mechanical or I/O issues , then someone with the programming software can be dispatched.

 

Share

HMI Design Guidelines for every project

After building two user interfaces this year and having to formulate and review the rules for developing an effective set of screens each time, this is a list of seven items created from experience, client feedback and research.

7 HMI Design Guidelines

1. Do not use black or white for background. It appears that this would bring about good contrast and highlight objects onscreen but to the contrary, it succumbs to glare in many lighting conditions including sunlight and fluorescent lighting.

2. Low contrast general themes are better in industrial user interfaces for the following reasons: 1- It helps highlight situations that require awareness, 2- It’s not too eye catching as an industrial control system should be. Captivating graphics may steal from the actual intent.

3. Use graphs and trend information where possible. Visual aspects of monitored variables allowsfor easier troubleshooting. Historic view of what the variable has done whether a few minutes ago or a few hours ago helps operators with decision making. A trend can also captures a relative view of the current state with respect to limits and also in relation to other variables.

4. Articulate situations that are beyond acceptable or normal operating regions using bar graphs and colors( red, yellow green). This supports the notion of providing a relative view of the status of a process variable or condition.

5. Do not use too many elements that do not carry data significance. Example: An elaborate drawing of a plant or process with only 4 or 5 actual data fields may serve as a distraction. The idea is not to amaze users/operators/viewers with the graphics but to provide information and allow for efficient and optimal control.

6. Consider replacing color based information with shapes- helps with color blindness and confusion on the meaning of colors. Example: Does RED infer push to stop or currently stopped. Does green mean go or push to go?

7. Spacing between user input fields- avoid the proverbial ‘fat finger’. Example :Placing two input fields  together can cause  errors in data entry. Consider placing a label between input fields.

Share