Posted on

Comparing IO-Link and Modbus Protocols in Industrial Automation

In the realm of industrial automation, the seamless exchange of data between sensors, actuators, and control systems is critical for optimizing performance, increasing efficiency, and enabling advanced functionalities. Two widely used communication protocols, IO-Link and Modbus, have emerged to facilitate this data exchange. In this blog, I’ll analyze the characteristics, strengths, and weaknesses of both protocols to help you choose the right communication standard for your industrial application.

IO-Link: transforming industrial communication for advanced applications

IO-Link is a relatively new communication protocol designed to provide seamless communication between sensors and actuators and the control system. It operates on a point-to-point communication model, meaning each device on the network communicates directly with the IO-Link master or gateway. IO-Link offers features like bidirectional process data exchange, parameterization, device diagnostics, and plug-and-play functionality, making it an ideal choice for advanced industrial applications.

IO-Link key features:

    • Bidirectional communication: IO-Link allows data exchange not only from the IO-Link master to the devices but also from devices to the IO-Link master, enabling real-time diagnostics and enhanced control.
    • Device parameterization: IO-Link supports remote device configuration, reducing downtime during device replacement or maintenance.
    • Diagnostics: The protocol provides extensive diagnostic capabilities, allowing for proactive maintenance and minimizing production interruptions, including condition monitoring.
    • Flexibility: IO-Link supports a plethora of smart devices, both digital and analog devices, signal converters, and condition monitoring sensors, providing compatibility with a wide range of sensors and actuators, and is manufacturer-independent.

Modbus: a time-tested protocol power industrial communication

Modbus is a widely adopted communication protocol introduced in the late 1970s. Initially designed for serial communication, it has evolved and now includes TCP/IP-based versions for Ethernet networks. Modbus operates on a master-slave architecture, where a single master device communicates with multiple slave devices. Due to its simplicity and ease of implementation, Modbus remains popular in many industrial applications.

Modbus key features:

    • Simplicity: Modbus is a straightforward protocol, making it easy to implement, and troubleshoot, especially in smaller networks.
    • Versatility: Modbus can be used over various physical communication media, including serial (RS-232/RS-485) and Ethernet (TCP/IP).
    • Widely supported: A vast array of devices and system support Modbus due to its long-standing presence in the industry.
    • Low overhead: Modbus has minimal message overhead, making it suitable for simple and time-critical applications.

Now, let’s compare IO-Link and Modbus based on several crucial factors:

    • Speed and data capacity:

   – IO-Link offers higher data transfer rates, making it suitable for applications requiring real-time data exchange and high precision.

– Modbus operates at lower speeds, limiting its suitability for applications with demanding data transfer requirements.

    • Complexity and configuration:

   – IO-Link’s advanced features may require more complex configuration and setup, but its bidirectional communication, device parameterization capabilities, and remote diagnostics make it more versatile.

   – Modbus’ simplicity makes it easier to configure and deploy, but it lacks the bidirectional communication and parameterization features found in IO-Link.

    • Device compatibility:

   – IO-Link’s compatibility with both digital and analog smart devices, and being manufacturer-independent, ensures a much broader range of sensor and actuator support.

   – Modbus is compatible with various devices, but its support for analog devices can be limited in comparison to IO-Link.

    • Diagnostics and maintenance:

   – IO-Link’s comprehensive diagnostics facilitate proactive maintenance and rapid issue resolution.

   – Modbus provides basic diagnostics, but they may not be as extensive or real-time as those offered by IO-Link.

    • Industry adoption:

   – IO-Link adoption is growing in industrial automation, especially in applications that demand high performance, advanced capabilities, and support of IIOT.

   – Modbus has been widely adopted over the years and remains prevalent, especially in legacy systems or simpler applications.

Both IO-Link and Modbus are valuable communication protocols in industrial automation, each with its strengths and weaknesses. IO-Link excels in high-performance applications that demand real-time data exchange, bidirectional communication, and advanced diagnostics. On the other hand, Modbus remains a viable option for simpler systems where ease of implementation and broad device support are essential.

The choice between IO-Link and Modbus depends on the specific requirements of your industrial application, the level of complexity needed, and the devices you plan to use. Understanding the capabilities of each protocol will empower you to make an informed decision, ensuring your communication system optimally supports your automation needs.

Posted on

Using MQTT Protocol for Smarter Automation

In my previous blog post, “Edge Gateways to Support Real-Time Condition Monitoring Data,” I talked about the importance of using an edge gateway to gather the IoT data from sensors in parallel with a PLC. This was because of the large data load and the need to avoid interfering with the existing machine communications. In this post, I want to delve deeper into the topic and explain the process of implementing an edge gateway.

Using the existing Ethernet infrastructure

One way to collect IoT data with an edge gateway is by using the existing Ethernet infrastructure. With most devices already communicating on an industrial Ethernet protocol, an edge gateway can gather the data on the same physical Ethernet port but at a separate software-defined number associated to a network protocol communication.

Message Queue Telemetry Transport (MQTT)

One of the most commonly used IoT protocols is Message Queue Telemetry Transport (MQTT). It is an ISO standard and has a dedicated software Ethernet port of 1883 and 8883 for secure encrypted communications. One reason for its popularity is that it is designed to be lightweight and efficient. Lightweight means that the protocol requires a minimum coding and it uses low-bandwidth connections.

Brokers and clients

The MQTT protocol defines two entities: a broker and client. The edge gateway typically serves as a message broker that receives client messages and routes them to the appropriate destination clients. A client is any device that runs an MQTT library and connects to an MQTT broker.

MQTT works on a publisher and subscriber model. Smart IoT devices are set up to be publishers, where they publish different condition data as topics to an edge gateway. Other clients, such as PC and data centers, can be set up as subscribers. The edge gateway, serving as a broker receives all the published data and forwards it only to the subscribers interested in that topic.

One client can publish many different topics as well as be a subscriber to other topics. There can also be many clients subscribing to the same topic, making the architecture flexible and scalable.

The edge gateway serving as the broker makes it possible for devices to communicate with each other if the device supports the MQTT protocol. MQTT can connect a wide range of devices, from sensors to actuators on machines to mobile devices and cloud servers. While MQTT isn’t the only way to gather data, it offers a simple and reliable way for customers to start gathering that data with their existing Ethernet infrastructures.

Posted on

Understanding Image Processing Standards and Their Benefits

In the industrial image processing world, there are standards – GenICam, GigE Vision, and USB3 Vision – that are similar to the USB and Ethernet standards used in consumer products. What do these image processing standards mean, and what are their benefits?

The GenICam standard, which is maintained by the European Machine Vision Association (EMVA), serves as a base for all the image processing standards. This standard abstracts the user access to the features of a camera and defines the Standard Feature Naming Convention (SFNC) that all manufacturers use so that common feature names are used to describe the same functions.

Additionally, manufacturers can add specific “Quality of Implementation” features outside of the SFNC definitions to differentiate their products from ones made by other manufacturers. For example, a camera can offer specific features like frame average, flat field correction, logic gates, etc. GenICam/GigE Vision-based driver and software solutions from other manufacturers can also use these features without any problem.

“On-the-wire” standards

USB3 Vision and GigE Vision are “on-the-wire” interfaces between the driver and the camera. These standards are maintained by the Automated Imaging Association (AIA). You are probably familiar with “on-the-wire” standards and their advantages if you have used plug-and-play devices like USB memory sticks, USB mice, or USB hard disks. They work together without any problem, even if they are made by different manufacturers. It’s the same thing with GenICam/GigE Vision/USB3 Vision-based driver/software solutions. The standards define a transport layer, which controls the detection of a device, configuration (register access), data streaming (device detection), and event handling, and connects the interface to GenICam (Figure 1).

USB3 Vision builds on the GigE Vision standard by including accessories like cables. The mechanics are part of the standard and defines lockable cable interfaces, as one example. This creates a more robust interface for manufacturing environments.

Are standards a must-have?

Technically, standards aren’t necessary. But they make it possible to use products from multiple manufacturers and make devices more useful in the long term. For a historical comparison, look at USB 2.0 cameras and GigE Vision. USB 2.0 industrial cameras were introduced in 2004 and only worked with proprietary drivers (Figure 2) between the client and Vision Library/SDK and between the driver and camera. Two years later, Gigabit Ethernet cameras were introduced with the GigE Vision image processing standard, which didn’t require proprietary drivers to operate.

In the case of a system crash, users of the USB 2.0 cameras wouldn’t know whether the proprietary driver or the software library was to blame, which made them difficult to support. During the decision phase of selecting sensors and support, the customer had to keep the product portfolio in mind to meet their specifications. Afterward, the application was implemented and only worked with the proprietary interfaces of the manufacturer. In case of future projects or adaptions –for example, if a new sensor was required –it would have been necessary for the manufacturer to offer this sensor. Otherwise, it was necessary to change the manufacturer, which meant that a new implementation of the software was necessary as well. In contrast, flexibility is a big advantage with Gigabit Ethernet cameras and GigE Vision: GigE Vision-compliant cameras can be used interchangeably without regard to the manufacturer.

Despite this obvious benefit, USB cameras are more prevalent in certain image processing fields like medicine, given that the applications define the camera’s sensor resolution, image format and image frequency (bandwidth), and the environment for the purpose of cable length, frame grabber, or digital camera solution. With such tightly-defined requirements, USB cameras solve the challenges of these applications.

It’s hard to believe, but a few years ago, there weren’t any standards in the image processing market. Each manufacturer had its own solution. These times are gone – the whole market has pulled together, to the benefit of customers. Because of the standards, the interaction between hardware, driver, and software delivers the experience of a uniform piece. The quality of the market is improved. For the customer, it is easier to make product decisions since they are not locked into one company’s portfolio. With standards-compliant products, the customer can always choose the best components, independent of the company. With GenICam as a base, the image processing market offers the best interface for every application, either with GigE Vision or USB3 Vision.

Posted on

IO-Link Safety: What It Is and Isn’t

Comparing “IO-Link” and “Safety” to “IO-Link Safety”

There are many I/O blocks that have “IO-Link” and “Safety” in their descriptions, which can cause some confusion about which safety features they include. Here’s an overview of different safety-named blocks and how they compare to IO-Link Safety.

Safety Network Blocks

These blocks have I/O ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). OSSD—output switching signal devices—send 24-volt signals over two wires to confirm that a device is operating in a safe condition. If 0 volts are detected in either signal, besides their safety-checking 0-volt pulses, it’s read as a safety event that signals the machine to go into a safe state. Safety network blocks are only for standard (non-network) safety devices. These blocks communicate directly back to a Safety Controller over safety protocols like CIP Safety, PROFIsafe, etc. These blocks typically can monitor between 8-16 standard safety devices. There is no intelligence built into the safety devices.

Safety Network Blocks with IO-Link

Blocks in this category usually have a mixture of I/O ports on them. The ports can range from standard I/O to standard IO-Link communication, and in addition, include ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). These blocks communicate over the safety protocols with only a few ports to connect standard (non-network) safety devices. There is some versatility with these blocks since you can wire standard sensors, IO-Link devices, and safety devices to it. The drawback is, you will always run short of the port style you need and, in the end, use more blocks to cover either the safety or IO-Link needs of the application. There is no intelligence built into the safety devices.

Safety over IO-Link Blocks

In this system/architecture, there are standard IO-Link Masters communicating to the Safety PLCs/Controllers over standard protocols like EtherNet/IP, PROFINET, etc. Connected to the IO-Link Ports of these Masters are Safety over IO-Link devices, currently limited to only Safety over IO-Link hubs. The Safety PLCs/Controllers communicate via safety protocols like PROFIsafe to the standard IO-Link Master, and then using the IO-Link communication channel, they bridge the gap to the Safety over the IO-Link hub via the “black channel.” These Safety over IO-Link hub’s ports use Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. This system provided a “gap filler” while IO-Link Safety was being developed. In this system/architecture, the standard IO-Link Masters allowed standard IO-Link devices and Safety over IO-Link hubs to be connected to any ports. This brought even more versatility to an application and the beginnings of the benefits of IO-Link. Still, there is no intelligence built into the safety devices.

IO-Link Safety

IO-Link Safety adds a safety communication layer to IO-Link. The difference between this and Safety over IO-Link is that this safety layer applies to both the IO-Link Master and IO-Link Safety devices. Within a CIP Safety or PROFIsafe network, the safety communication protocol has top priority over standard EtherNet/IP or PRIFONET data if both are existing on the same physical network. The same is true for IO-Link Safety: both standard and safety IO-Link protocols can exist on the same physical cable between the IO-Link Master ports and IO-Link Safety devices, with IO-Link Safety carrying the top priority. For a deep dive into the IO-Link Safety protocol, I suggest visiting the IO-Link Consortium’s website at io-link.com. In this system/architecture, you have IO-Link Safety Masters, which communicate to the Safety PLCs/Controllers over safety protocols like CIP Safety, PROFIsafe, etc. The ports on the Masters can utilize Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. Pin 4 can also be used to carry standard IO-Link and IO-Link Safety communication to standard IO-Link devices and IO-Link Safety devices, respectively. This allows for the most versatile safety solution in the market–IO-Link Safety Masters that can accept standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices. Intelligence in the IO-Link Safety devices is now available.

Benefits of IO-Link Safety

    • IO-Link Safety devices are fieldbus neutral: you just need to specify the IO-Link Safety Master to match the Safety PLCs/Controllers protocol.
    • IO-Link Safety Master port versatility: standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices can be connected.
    • Parameter storage: standard IO-Link and IO-Link Safety device’s parameters can be stored for ease of device replacement.
    • Smart IO-Link Safety device data: more data available, like internal temperature, humidity, number of cycles, power consumption, diagnostics, etc.
    • Simplified wiring: IO-Link Safety devices are still connected to the IO-Link Master port with a standard 3 to 4 conductor cable.
    • IIoT fit: IO-Link Safety gives more visibility to upper-level systems like SCADA, allowing safety device-level monitoring.

I am looking forward to seeing how quickly IO-Link Safety will be accepted, with how IO-Link numbers have skyrocketed over the last few years. The future looks great for IO-Link with IO-Link Safety, IO-Link Wireless and in the future, Single-Pair Ethernet (SPE). With all these new capabilities, what application can’t IO-Link support?

Posted on

Reduce the Number of Ethernet Nodes on Your Network Using IO-Link

Manufacturers have been using industrial Ethernet protocols as their controls network since the early 1990s. Industrial Ethernet protocols such as Ethernet/IP, ProfiNet, and Modbus TCP were preferred over fieldbus protocols because they offered the benefits of higher bandwidth, open connectivity and standardization, all while using the same Ethernet hardware as the office IT network. Being standard Ethernet also allows you to remotely monitor individual Ethernet devices over the network for diagnostics and alarms, delivering greater visibility of the manufacturing data.

With Ethernet as the key technology for Industry 4.0 and digitalization, more and more devices will have Ethernet capabilities. Typical industrial Ethernet nodes on a plant floor could include PLC controllers, robots, I/O devices for sensors, actuators, flowmeters, transducers and manifolds. While, it’s great getting all the data and diagnostics of the entire manufacturing process, having every device connected via Ethernet has some downfalls. It can lead to larger Ethernet networks, which can mean more costs in hardware such as routers, switches and Ethernet cables, and some Ethernet software license costs are based on the number of Ethernet nodes being used in the network.

Also, as more Ethernet devices are added to a network, the Ethernet network itself can get more complex. Each individual Ethernet device requires an IP address. If an Ethernet node stopped working and needed to be replaced, an operator would need to know the previous IP address of the device and have quick access to the manual with instructions on how to assign the previous IP address to the new device. Someone must also manage the IP addresses on the network. There will need to be a list of the IP addresses on the network as well as the available ones, so when a new Ethernet device is added to the network, a duplicate address is not use

One way to reduce the number of Ethernet nodes while still getting device data and diagnostics is by using IO-Link for field device communications. IO-Link is an open point-to-point communication standard for sensors and actuators published by IEC (International Electrotechnical Commission) as IEC 61131-9. Since it’s fieldbus and manufacturer independent, there is a long list of manufacturer devices that come with IO-Link. Each IO-Link device can then be brought back to a single Ethernet node, through an IO-Link to Ethernet gateway. Since it’s open technology, there are also multiple manufacturers that make different IO-Link to industrial Ethernet gateways.

On the IO-Link to Ethernet gateway, each channel has an IO-Link master chipset. It is designed to automatically communicate and provide data as soon as an IO-Link device is connected to a port. So, there is no addressing or additional setup required. IO-Link is point to point, so it’s always a single IO-Link device connected to a single port on the gateway using a standard sensor cable. Depending on the number of IO-Link devices to be connected to a single Ethernet node, IO-Link gateways can come in 4, 8 or 16 device channels. This graphic (image 1) shows six IO-Link devices connected to a single 8-channel Ethernet gateway. This gateway then communicates back to the Ethernet PLC controller as a single IP address with a standard Ethernet cable. Without using IO-Link, this might require all six devices to be industrial Ethernet devices. Each device would have its own IP address to set up, along with six Ethernet cables going back to a 6-port managed switch before going to the PLC controller.

 

1
Image 1: Six IO-Link devices connected to a single 8-channel Ethernet gateway.

IO-Link Devices Connected:

  1. Device I/O Hub used to connect to 16 standard discrete sensors/photoeyes.
  2. Valve Manifold used to control up to 24 coils.
  3. Visual Indicator Light
  4. RFID Processor System
  5. Pressure Sensor
  6. IO-Link to Standard Analog (0-10V or 4-20ma) Converter
Posted on

Why Train on Industrial Ethernet?

trainingAn industrial Ethernet network is vastly different from an office Ethernet network in several key ways, and the key to optimizing your industrial network in light of these differences, is hands-on training.

First of all, the environment in industrial applications can degrade the actual cable itself. Some cable manufacturers actually rate their cables’ ability to withstand these environmental factors. They use the acronym MICE, and rate the cable as appropriate for one of three environments: M1I1C1E1 for office environments, M2I2C2E2 for light industrial environments, and M3I3C3E3 for industrial environments. The letters actually stand for: Mechanical factors such as shock and vibration, Ingress from moisture, Climatic factors such as temperature and sunlight, and Electromagnetic interference such as noise caused by inductive loads, welders, variable frequency drives, etc. Other cable vendors observe the recommendations of ODVA and offer cables that are ODVA compliant.

Secondly, industrial Ethernet networks can have a high amount of multicast traffic. In the early years of Ethernet hubs were used to link devices. The problem is that information coming into one port of a hub was redirected to all of the other ports on the hub. With the advent of switches, unicast traffic was now directed to only the port for the intended recipient device. This is true for both managed and unmanaged switches: they both handle unicast traffic well. The problem for the unmanaged switch comes when you encounter multicast traffic. Since an unmanaged switch does not employ IGMP Snooping (Internet Group Management Protocol), the switch does not know what to do with multicast traffic. It starts acting like the old hubs: it directs all multicast traffic to all ports. With a managed switch and with IGMP Snooping turned on, the switch knows exactly where to send this multicast traffic and directs it only to the intended recipients. Multicast traffic can be anything from produced tags to input modules configured for multicast. These can be very common in industrial applications using PLCs.

Thirdly, we now have tools available in many switches and routers to prioritize the traffic on an Ethernet network. This becomes especially important when you have high-speed applications, motion applications, or time synchronization applications. In the past all Ethernet data was equal. The feedback coming from a servo drive had to wait just as long as a person trying to get online with a PLC. Now many automation vendors are marking their data with priority codes. Allen-Bradley marks their data in layer three with DSCP markings, and Siemens uses layer two markings with PCP marks, for instance (a VLAN tagging mechanism). In either case, if your switch or your routers are not configured properly to recognize and use these priority codes, you are not taking advantage of the QoS feature that could help get your important data through first (Quality of Service).

Only through proper training can you learn not only what the key issues are but also how to properly deploy your hardware to fully optimize your network. Balluff offers hands-on training with actual automation equipment, switches, and routers to help you do just that. You can learn more about the courses Balluff has to offer at www.balluff.us.

Posted on

1 Visual Way to Improve Operator Performace

Many manufacturers I talk to are excited about the possibilities that our new Smart Light technology, used in level mode, brings to their production or machines.  Here’s a video if you havent seen it yet:

It works over virtually any industrial network with an open standard called IO-Link, which I’ve discussed many times in previous posts.

What I’m really impressed with is the number of people integrating the level mode as a quick and easy way to give instantaneous feedback to an operator on their performance to a quota or as a count-down timer.  Here you can see in the middle of the right photo a bright green bar light just to the left of the red kanban rack.  There are multiple of these lights in this image.

Tesla Motors Blog – Factory Upgrade

This light is a five zone Smart Light operating in level mode.  As the cycle time winds down, the light decreases in value until there is no more time, at that point it flashes bright red to notify the operator to cycle to the next vehicle.  It keeps the production on track and helps operators know quickly and easily how much time remains.  What I’ve been told is nice about this is how bright the light is and that it is easily install-able without a controls cabinet or slice i/o j-box like you can see in the photo.  Others like it because it makes the data visual from all over, where HMIs require you to stand right in front of them for information.

So if you are trying to think about ways to visualize data in your process or production to operators or managers, there are many others out there already using Smart Light for that application. Check it out.

Posted on

Rise of the Robots – 3 Ways to Be On Their Team

While originally a mixed reviewed 1994 console video game, the recently published report by The Boston Consulting Group titled “The Rise of Robotics”  really made me realize how important it is that we embrace robotics in our manufacturing processes.  And I strongly agree with this statement: “Because robots can sharply improve productivity and offset regional differences in labor costs and availability, they’ll likely have a major impact on the competitiveness of companies and countries alike.”  They studied the growth of the usage of robots in personal, commercial, military and industrial use and the numbers were quite powerful.  Of interest to me is the rise in industrial robotics; doubling in 5 years from $5.8b to $11.0b in 2015.  And the growth is expected to more than double again by 2025 to $24.4b in the industrial space.

What this means for manufacturers, machine builders and component suppliers is we need to make sure our people are trained to support this growth and that we we have strong peripheral technologies to support robots as they grow and expand.  Even today there are some great technologies available in sensors and controls that make robotic integration easier for manufacturing companies.

So here are the three ways to make sure you are your robot’s ally.

  1. Maximize Their Payload!

    No one wants to be treated like they can’t help… especially your robots, they want you to utilize them and feel appreciated.  For most robotics right now, payload size & payload weight is a limiting factor.  Mini sensing products with precision switch points, small form factors and low mass allow for the design of low weight, compact payloads without limiting the functionality or speed of the robot.

  2. Keep them Working!

    A working robot is a happy robot.  By adding flexible tooling or quick-change tooling to the end-effector of a robot you can have one arm perform multiple functions and keep idle arms to a minimum, increasing their value and “happiness.”  Multiple products are out there to allow for this, however there is a technology that allows for sensor connections through inductive coupling that dramatically decreases repair issues and downtime due to tool changer pins.

  3. Remove the Chains!  

    What’s the deal with cable dress packs… they look like really bad suspenders sometimes… you see them, you don’t like how they look, but you need it to keep your pants on… I guarantee that robots don’t like these things either… And with all that flexing something in there will fail regularly.  There are some great technologies to reduce the sensor cables running on the arm and add flexibility and they are supported by the open standard IO-Link (discussed in other posts here!).

So as you integrate robots more and more into the manufacturing we are doing, please start thinking how to align yourself as a robot’s ally.  Because I know I want to be on this guy’s team…

Posted on

Stop Industrial Network Failures With One Simple Change

Picture1

It’s the worst when a network goes down on a piece of equipment.  No diagnostics are available to help troubleshooting and all communication is dead.  The only way to find the problem is to physically and visually inspect the hardware on the network until you can find the culprit.  Many manufacturers have told me over the past few months about experiences they’ve had with down networks and how a simple cable or connector is to blame for hours of downtime.

2013-08-19_Balluff-IO-Link_Mexico_Manufactura-de-Autopartes_healywBy utilizing IO-Link, which has been discussed in these earlier blogs, and by changing the physical routing of the network hardware, you can now eliminate the loss of communication.  The expandable architecture of IO-Link allows the master to communicate over the industrial network and be mounted in a “worry-free” zone away from any hostile environments.  Then the IO-Link device is mounted in the hostile environment like a weld cell and it is exposed to the slag debris and damage.  If the IO-Link device fails due to damage, the network remains connected and the IO-Link master reports detailed diagnostics on the failure and which device to replace.  This can dramatically reduce the amount of time production is down.  In addition the IO-Link device utilizes a simple sensor cable for communication and can use protection devices designed for these types of cables.  The best part of this is that the network keeps communicating the whole time.

If you are interested in learning more about the benefits that IO-Link can provide to manufacturers visit www.balluff.us.

Posted on

Light it Up! Industrial Stack Lights are old news…

I am seriously excited about the new Smart Light.  It will revolutionize how we automate and interface with people working in the manufacturing environment.  If you didnt watch this video… you need to watch this video.

Even if you don’t know what a stack light is, you will want one of these for your discotec to light it up!

Operating on the open communication protocol IO-Link that I have discussed in previous posts, I think this single part number will improve the factory for:

  • an operator wanting to know when to refill a feederbowl, position a part, or empty a full output bin
  • a maintenance guy needing to know what cell is causing the machine downtime
  • a plant manager wanting to know the machine output, speed, productivity

If you want more information on how this works visit the Smart Light webpage.