Are machine diagnostics overburdening our PLCs?

In today’s world, we depend on the PLC to be our eyes and ears on the health of our automation machines. We depend on them to know when there has been an equipment failure or when preventative maintenance is needed. To gain this level of diagnostics, the PLC must do more work, i.e. more rungs of code are needed to monitor the diagnostics supplied to the sensors, actuators, motors, drives, etc.

In terms of handling diagnostics on a machine, I see two philosophies. First, put the bare bones minimum in the PLC. With less PLC code, the scan times are faster, and the PLC runs more efficiently. But this version comes with the high probability for longer downtime when something goes wrong due to the lack of granular diagnostics. The second option is to add lots of diagnostic features, which means a lot of code, which can lessen downtime, but may throttle throughput, since the scan time of the PLC increases.

So how can you gain a higher level of diagnostics on the machine and lessen the burden on the PLC?

While we usually can’t have our cake and eat it too, with Industry 4.0 and IIoT concepts, you can have the best of both of these scenarios. There are many viewpoints of what these terms or ideas mean, but let’s just look at what these two ideas have made available to the market to lessen the burden on our PLCs.

Data Generating Devices Using IO-Link

The technology of IO-Link has created an explosion of data generating devices. The level of diversity of devices, from I/O, analog, temperature, pressure, flow, etc., provides more visibility to a machine than anything we have seen so far. Utilizing these devices on a machine can greatly increase visibility of the processes. Many IO-Link masters communicate over an Ethernet-based protocol, so the availability of the IO-Link device data via JSON, OPC UA, MQTT, UDP, TCP/IP, etc., provides the diagnostics on the Ethernet “wire” where more than just the PLC can access it.

Linux-Based Controllers

After using IO-Link to get the diagnostics on the Ethernet “wire,” we need to use some level of controller to collect it and analyze it. It isn’t unusual to hear that a Raspberry Pi is being used in industrial automation, but Linux-based “sandbox” controllers (with higher temperature, vibration, etc., standards than a Pi) are available today. These controllers can be loaded with Codesys, Python, Node-Red, etc., to provide a programming platform to utilize the diagnostics.

Visualization of Data

With IO-Link devices providing higher level diagnostic data and the Linux-based controllers collecting and analyzing the diagnostic data, how do you visualize it?  We usually see expensive HMIs on the plant floors to display the diagnostic health of a machine, but by utilizing the Linux-based controllers, we now can show the diagnostic data through a simple display. Most often the price is just the display, because some programming platforms have some level of visualization. For example, Node-Red has a dashboard view, which can be easily displayed on a simple monitor. If data is collected in a server, other visualization software, such as Grafana, can be used.

To conclude, let’s not overburden the PLC with diagnostic; lets utilize IIoT and Industry 4.0 philosophy to gain visibility of our industrial automation machines. IO-Link devices can provide the data, Linux-based controllers can collect and analyze the data, and simple displays can be used to visualize the data. By using this concept, we can greatly increase scan times in the PLC, while gaining a higher level of visibility to our machine’s process to gain more uptime.

Adding a higher level of visibility to older automation machines

It’s never too late to add more visibility to an automation machine.

In the past, when it came to IO-Link opportunities, if the PLC on the machine was a SLC 500, a PLC-5, or worse yet, a controller older than I, there wasn’t much to talk about. In most of these cases, the PLC could not handle another network communication card, or the PLC memory was maxed, or it used a older network like DeviceNet, Profibus or ASi that was maxed. Or it was just so worn out that it was already being held together with hope and prayer. But, today we can utilize IIoT and Industry 4.0 concepts to add more visibility to older machines.

IIOT and Industry 4.0 have created a volume of products that can be utilized locally at a machine, rather than the typical image of Big Data. There are three main features we can utilize to add a level of visibility: Devices to generate data, low cost controllers to collect and analyze the data, and visualization of the data.

Data Generating Devices

In today’s world, we have many devices that can generate data outside of direct communication to the PLC.  For example, in an Ethernet/IP environment, we can put intelligent devices directly on the EtherNet/IP network, or we can add devices indirectly by using technologies like IO-Link, which can be more cost effective and provide the same level of data. These devices can add monitoring of temperature, flow, pressure, and positioning data that can reduce downtime and scrap. With these devices connected to an Ethernet-based protocol, data can be extracted from them without the old PLC’s involvement.  Utilizing JSON, OPC UA, MQTT, UDP and TCP/IP, the data can be made available to a secondary controller.

Linux-Based Controllers

An inexpensive Raspberry Pi could be used as the secondary controller, but Linux-based open controllers with industrial specifications for temperature, vibration, etc. are available on the market. These lower cost controllers can then be utilized to collect and analyze the data on the Ethernet protocol. With a Linux based “sandbox” system, many programming software packages could be loaded, i.e. Node-Red, Codesys, Python, etc., to create the needed logic.

Visualization of Data

Now that the data is being produced, collected and analyzed, the next step is to view the information to add the extra layer of visibility to the process of an older machine. Some of the programming software that can be loaded into the Linux-based systems, which have a form a visualization, like a dashboard (Node-Red) or an HMI feel (Codesys). This can be displayed on a low-cost monitor on the floor near the machine.

By utilizing the products used in the “big” concepts of IIOT and Industry 4.0, you can add a layer of diagnostic visualization to older machines, that allows for easier maintenance, reduced scrap, and predictive maintenance.

Defining Your Next Network Architecture: Cost Effectiveness

In my previous blog entry, Defining Your Next Network Architecture: Topologies and Global Standards, I addressed two topics to consider when moving from the “bus” to the “net”.  Here is the next topic I feel you should consider.

Cost Effectiveness – how can we lower the cost and not lose functionality?

Continue reading “Defining Your Next Network Architecture: Cost Effectiveness”

Defining Your Next Network Architecture: Topologies and Global Standard

As many machine builders, OEMs, individual plants, and large corporations decide to move from the “bus” to the “net” (Profibus or DeviceNet to Profinet or EtherNet/IP) they have a chance to look at all the new architectures available and decide on which is the best for them.  Here are the first two topics to take into consideration:

Continue reading “Defining Your Next Network Architecture: Topologies and Global Standard”

Where does IO-Link go in 2011?

As I sit and ponder what 2011 will look like, only one thought comes to mind, the endless possibilities of IO-Link.

I have written many entries on IO-Link and as I see it there are much more to come.  Why more IO-Link?  The answer is simple; we have just scratched the surface of the potential of what an IO-Link system can offer an end-customer or OEM.  Let’s talk about a few upcoming milestones in 2011 to look forward to:

Continue reading “Where does IO-Link go in 2011?”

IO-Link Scalability Animation Video


Share

How can I use IO-Link in my application?  How is IO-Link scalable?  If these are questions you still have, watch this animation describing the scalability of IO-Link.  To learn more about Balluff’s IO-Link offering, click here

Defining IP Ratings and NEMA Ratings

Share

As I was preparing to write my blog entry, I was browsing my e-mail and came across an article in the October Issue of TIA Newsletter (Totally Integrated Automation) from Automation World, concerning IP Ratings.  I found the article , very informative as it broke down the different degrees of IP ratings, as well as some similarity and differences between IP ratings and NEMA ratings.  I only wish there was some information involving IP69K. 

This article, IP Ratings – What are they and what do they mean,  is a great starting point to learn about IP Ratings, I suggest you stop by and read it. 

For more information about IP67, check out The Secret of IP67 Protection.

IP67 Network I/O Islands: Why? Are there other options?

Share/Bookmark

Typical IP67 network topologies involve stand-alone I/O modules, providing 8 to 16 points of I/O per module.  In some applications multiple stand-alone modules could be mounted within inches of each other.  Thus was introduced the IP67 Network I/O Island, a modular IP67 I/O solution that allowed 8 to 60 plus I/O points to be connected to only one network node.  This solution provided initial costs savings by reducing the number of network nodes used in an application, but brought along some new problems.  One problem involved exceeding long sensor /actuator cordsets, with a centralized I/O solution remote sensors needed cordsets of 5, 10, or even 15 plus meters in length.  The second issue was cordset management; imagine tracing a suspect cordset to the network I/O island with 60 plus connectors hanging off of the front of the unit.

IP67 Network I/O Island
IP67 Network I/O Island

Continue reading “IP67 Network I/O Islands: Why? Are there other options?”