What is a Zelio smart relay (PLC)?
The Zelio is a programmable industrial automation and control product. It may be called a “smart relay” or a small Programmable Logic Controller (PLC). The device is produced by Schneider Electric as part of Modicon. The family includes devices such as the 10 point SR3 B101BD, as pictured in Figures 1 and 2 all the way to the 26 point SR3BD262BD. Expansion modules are also available such as the digital SR3XT141BD and analog SR3XT43BD.
This engineering brief serves as an introduction to the Zelio smart relay and the Banner Engineering K100 Pro Daylight Visible Beacon. It also features the Schneider Electric Wireless ZBRRA and ZBRM22B0 series as described in this earlier brief. We explore the control of the Banner K100PBLGYR (default configuration) and the Schneider Zelio Soft programming.
The primary reason for this article is to show a system-level integration of the Schneider wireless pushbuttons and logic such as the Modicon Zelio. Here we use the Banner beacon to provide immediate and highly visible feedback so that the user knows that the respective pushbuttons have activated the system. I trust this article will inspire you to integrate these devices into your next project.
Figure 1: Picture showing the test setup for the Zelio smart relay, wireless pushbutton, and Banner beacon. Note the Schneider SRUSB01 USB programming cable in the lower right corner.
Figure 2: Close up image of the Schneider SR3 B101BD Zelio smart relay and the ZBRRA two-channel wireless receiver.
What programming language is used by the Zelio Logic smart relay?
The Zelio is programmed using either traditional ladder logic or function block. To be more precise, the function block implementation is a clever combination of Function Block (FB) and Sequential Function chart (SFC). In many respects, Zelio is like the Crouzet implementation. For example, this introduction to SFC is equally applicable to the Crouzet PLCs and the Zelio smart relay.
What materials are required to program a Zelio smart relay?
The Zelio smart relay is programmed using the Zelio Soft development suite. An adapter is required to connect the Zelio to the PLC. There are three options including:
- SR2 USB01 USB cable as pictured in Figure 1
- SR2 BTC01 Bluetooth adaptor (Discontinued in Feb 2024)
- SR2 CBL01 serial with DB9 connector
How is the ZBRRA two-channel wireless receiver connected to the Zelio?
The ZBRRA wireless receiver features relay outputs. To the outside world, each channel appears as a SPDT relay. These relays are connected in a sourcing configuration with the output sent the Zelio 24 VDC inputs.
Tech Tip: Mastery of the terms sourcing (PNP) and sinking (NPN) are essential to work in industrial control and automation systems. Assuming a conventional flow of current (positive to negative) the sourcing device supplies current to a load. This implies that the sourcing device is in the positive side of the load acting as a switch turning on the power. Conversely, the sinking device is on the return side of the load. It completes the circuit by providing a ground return. For further discussion, please see this note regarding PNP vs NPN sensors as interfaced with the PLC.
How is the Banner K100 Beacon physically connected to and then controlled by the Zelio?
The Banner K100 beacon as shown in Figure 1 features a 5-wire interface. The colors and control actions are shown in Figure 3. Note that this particular Banner beacon does not use the gray wire as it is reserved for enhanced devices that feature an audible alarm. See this link to explore members of the K100 family including programmable devices with audible alert.
From your digital logic class, you will recall that three independent wires may be used to control eight unique states. Recall:
\log_2(8) = 3
This is reflected in Figure 3 where we see that the color and animation states are controlled via the beacon’s black, brown, and white input wires. As an example, consider the operation when the wires are set to 1, 1, 0 respectively. With the default setting, the beacon will display a bright yellow flash at a 1 Hz rate. Note that the 8th state is not shown on the chart. This occurs when all control wires are off resulting in no display form the beacon.
The physical connections between the Banner beacon and the Zelio PLC are very simple. Since the smart relay has relay-based outputs, the PNP (sourcing) configuration as shown in Figure 3 was used. A daisy chain with dual wire ferrules was used for simplicity. This can be seen with a close inspection of Figure 1.
Figure 3: Excerpt from the Banner K100 Beacon datasheet showing the physical wiring and resulting color and animation.
What does the demo program do?
The objective is to demonstrate the devices chosen in Figure 1. Here, we see the Schneider Harmony dual wireless pushbutton plus receiver, the Zelio smart relay, and the Banner beacon. The chosen program performs three based operations:
-
On / Off control: Here the red and green pushbuttons are used to toggle a process. This is reflected in the beacon by activating the green for on and the flashing yellow for off as shown in Video 1.
-
Banner demonstration: When both pushbuttons are simultaneously held for 5 seconds, the Zelio will enter a test mode. With continued button holding, the Zelio will walk down the binary chart as shown in Figure 3 with a new Banner beacon mode chosen once every 5 seconds.
-
Fault demonstration: The Zelio will enter a fault mode when the leftmost button on its front panel is pressed. This may be cleared by pressing the second button. The beacon will strobe red for the duration of the fault.
Video 1: Basic on off control using the wireless pushbuttons.
Video 2: Test mode for the Banner beacon. A new mode is automatically selected every five seconds.
How does the demo program work?
A complete introduction to the Zelio function block programming is beyond the scope of this article. However, we can point out the highlights for each of the three operating modes.
Download the program here:
ZelioWirelessBanner.zm2 (59.8 KB)
Importance of the warm and cold restart
Defensive PLC programming requires that all components be initialized into a known safe state. This is accomplished using the STATUS as shown in Figure 4 with its red caution symbol. We use the cold warm and cold resets to set the state of the running and notRunning logic.
Tech Tip: PLC programming requires extensive testing to ensure that the corner cases have been discovered and protected against. For example, there is a hazard when the system comes out of the Banner demonstration mode. Here the last pushbutton released determines if the mechanism will enter a running or a notRunning state. A lockout function should be added demanding both pushbuttons be released before starting. This is left for you as an exercise. The code could also benefit from a consolidated state-based mechanism. This would be a good application of the Zelio’s Sequential Function Chart (SFC) elements.
Operation of the Cam block to hold the Banner beacon’s test configuration
Recall that the chosen Banner beacon is a three-wire device with 8 unique operating states with the zero state where the unit is powered down. As a test function it is desirable to show each of the beacon’s unique states. The natural way to control such a device is to use the CAM block as shown in Figure 4.
As described in this earlier article the Cam block is like a programmable Look Up Table (LUT) as suggested in Figure 5. Here we see the individual outputs as column headings and the CAM states as the rows. In this application we are using 8 unique states and three outputs. Close inspections shows that the binary values from the beacon’s Figure 3 data sheet have been copied into the CAM block. Inspection of Figure 4 shows that the S1, S2, and S3 outputs have been routed to the Zelio’s Q1, Q2, and Q3 respectively.
How is the CAM block advanced?
The CAM block is controlled by timers as shown in the upper portion of Figure 4. Notice that the first On-Delay Timer (TON) is used to detect that both pushbuttons have been held for 5 seconds. The second TON is used to advance the cam using the pulseNextTest variable.
This pulsed signal required some explanation as it is one of the essential building blocks for PLC programming. Notice that the output signal (“Q” in traditional languages) is routed to the CAM block. Also notice that pulseNextTest has a feedback path to the reset input of the TON. The result is a self-resetting TON block; for as long as testMode is active, the TON will send a pulse once every 5 seconds.
Tech Tip: The concept of “pulse” is closely associated with the PLC’s program scan. Recall that the PLC program is cyclical with the operation of each block performed at a rate of several hundred to several thousand of times per second. Suppose the TON has advanced causing the output (Q signal) to be high. On the next program scan, TON block will examine its input and find an active reset signal. It will reset itself thereby clearing the pulseNextTest signal. This operation will continue to provide a pulse once every 5 seconds for as long as the TON is enabled.
Troubleshooting pulsed signals in a PLC can be difficult as they are narrow and hard to observe. For example, a common misunderstanding is that the pulse may be seen in the simulator or online debugging tools. This has caused many hours of wasted effort as the display software is not fast enough to see the pulse. On a related note, a pulsed signal cannot be physically observed from a PLC with a relay-based output. The pulse on time is typically less than the time it takes for the relay to activate. Solid state (PNP) PLC outputs are faster but even then, a digital oscilloscope with single sweep capture is required to see the pulse.
Figure 4: Picture of the graphic Zelio Soft program to control the banner beacon.
Figure 5: Programming matrix for the CAM block. Note the similarity to the Banner matrix from Figure 3 with the addition of an 8th do nothing block.
Program organization
The Zelio program as shown in Figure 3 feature a variety of graphical and text methods to connect the blocks. Generally, using text names is cleaner especially as the complexity of the program increases. The text option eliminates the challenges associated with overlapping lines.
As a set of best practices using function block programming:
-
White space and grouping are important. Grouping by function leads to greater readability. White space makes it easier to find the groups.
-
Use logic AND and logic OR to associate functionality. For example, the PLC outputs are driven by OR gates. This allows multiple parts of the program to set an output pin. Following our white space plus text naming tips allows us to quickly determine what will activate an I/O pin. Likewise, the display blocks are controlled by AND gates. Consequently, a given display block will activate under a specific set of conditions.
-
Signal and notSignal are often required in a program. We accomplish this by using a not gate. Following our grouping technique, we physically place the not gate close to the associate block. In doing so, signal and notSignal are in close proximity.
-
The final tip is to add comments indicating the purpose of the block. For example, adding the note “TON 5 sec” makes the purpose of the multifunction timer block clear. Likewise adding comments such as “Running” and “Fault” indicate the purpose of the display block.
-
There are certainly more topics to explore. Perhaps in the future we can explore how to identify the corner cases, error handling, and best practices for SFC operations. Also, it may be useful to contrast and compare this FB / SFC solution with the Zelio LD programming.
-
Do you have tips for programming the Zelio? If so, please leave your recommendation in the space below.
Parting thoughts
This has been a fun demonstration project. The Schneider Electric Zelio smart relay (small PLC) was easy to program using the graphical function block language. The commonality with the Crouzet family of PLCs is a benefit as programming skills are easily transferred across platforms. The Schneider Electrics wireless pushbuttons and Banner Engineering beacon were also easy to implement and performed flawlessly.
Kindly provide comments and feedback in the space below. Implementation ideas for any of the three products is greatly appreciated.
Best Wishes,
APDahlen
Return to the Industrial Control and Automation Index
About the Author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians. Dahlen has returned to his Northern Minnesota home and thoroughly enjoys researching and writing articles such as this.