Hub Flows III - One PLC to Feed Them All - Using Peakboard Flows to share and distribute Siemens S7 values

Published in hubflows

Hub Flows III - One PLC to Feed Them All - Using Peakboard Flows to share and distribute Siemens S7 values

March 01, 2023 6 mins read

Hub Flows let you run automated tasks the background, without any user interaction. We covered the basics of Hub Flows in Part I and Part II of our Hub Flows series. In this article, we’ll take a look at another typical use case with Hub Flows.

The scenario

Imagine you have a Siemens S7 PLC in your factory. The S7 “knows” what a machine is currently doing. It knows if a machine is running smoothly, and if there’s a problem, it knows what root cause is.

Now, imagine that you have a large number of Peakboard applications that need the information from the S7. For example, you have Peakboard Boxes at different places in your factory, with different dashboards, and they all use the same information from the S7.

It’s not a good idea to have all these Peakboard apps connect to the S7 on their own, because it might overload the S7. Siemens PLCs do not support a large number of incoming connections.

The proper solution

Instead, you should create a Hub Flow. It works like this:

  1. The Hub Flow connects to the S7 and retrieves the necessary data. None of the Peakboard apps connect to the S7, so there’s only one connection that the S7 has to handle.
  2. The Hub Flow processes the raw data in order to get the values it needs.
  3. The Hub Flow stores each value inside its own Hub Variable. It overwrites any previous value in the Hub Variable.
    • For example, you might have a boolean Hub Variable that reports whether the S7 detects a problem or not.

The Hub Flow automatically runs every 10 seconds. Whenever it runs, it repeats steps 1 to 3.

The Peakboard app

You also need to connect your Peakboard applications to the Hub variables. Here’s what that looks like:

  1. If a Peakboard application needs the S7’s data, then it subscribes to the Hub Variables that the Flow publishes. An application only subscribes to the Variables that it needs.
    • For example, if an app needs to know if the S7 detects a problem or not, then it subscribes to the problem_detected Hub Variable. It does not need to subscribe to other Variables, like an energy_consumption Variable—because it has no need for that data.
  2. The Flow writes a new value into a Hub Variable.
  3. Peakboard Hub notifies all the Peakboard apps that are subscribed to the Hub Variable.
  4. If an application is notified, it processes the new data, and updates its dashboard accordingly.
    • For example, if an app sees that problem_detected is now TRUE, then it might change a status indicator from green to red. Or it may send an automated email to a manager.

This architecture is based on a publish-subscribe pattern.

Now, let’s build an example based on what we’ve just discussed.

Prepare the Hub Variables

First, we create three Hub Variables in the Hub Portal.

Hub Variable Data type Description
IsRunning Boolean Whether the connected machine is running.
RunningSpeed Number The speed that the machine is running at, if it’s running. Otherwise it’s 0.
ErrorMessage String The error message, if the machine encounters a problem. Otherwise, it’s an empty string.

image

Here’s what our three Variables look like after creation:

image

Create the Flow

In Peakboard Designer, we create a new Flow project.

We create three local variables that match the Hub Variables. We use the same names and data types.

We also connect each variable to their respective Hub Variables:

  1. Edit the variable.
  2. Go to the Peakboard Hub tab
  3. Under Peakboard Hub Variables, select the corresponding Hub Variable.

Whenever our local variables updates, the Flow automatically updates the Hub Variables.

image

Prepare the data source

Next, we create a data source for the S7 data. We use the standard Siemens S7 data source.

We configure it to give it access to the three variables on the S7:

image

Write the variables

Next, we create a simple function that takes the values from the S7 data source and writes the data into local variables (remember, any changes to the local variables are automatically sent to the Hub Variables).

image

Build and deploy the Hub Flow

The Flow automatically runs every 10 seconds. Every 10 seconds, it does the following:

  1. Reload the Siemens S7 data source, in order to get new data from the S7.
  2. Execute the function that processes the raw S7 data and updates the local variables. (This automatically updates the Hub Variables.)

image

We deploy the Hub Flow and it starts working right away:

image

You can see that the Flow updates the Hub Variables with the data from the S7:

image

Consume the data

Now, let’s create a Peakboard app that uses the data from this Hub Flow.

We create three variables and bind them to the three Hub Variables. These variables work like normal variables, except that they update automatically whenever the corresponding Hub Variables change.

Next, we add a couple of controls to visualize the three variables:

  • An icon control for IsRunning, built with conditional formatting.
  • A gauge control for RunningSpeed.
  • A text control for ErrorMessage. It defaults to Running, if there’s no error.

image

This video shows what our app looks like when the S7 detects an error:

image

Conclusion

We showed how you can decouple a PLC from the Peakboard apps that need its data. By using Hub Flows and Hub Variables, you can build a highly scalable architecture—even when direct connectivity to the PLC is very limited, like with the S7.

Unlike our previous example with the SAP caching, in this example, the data transfer (of the variables) happens in real-time. This means that the Peakboard apps don’t have to query the data on a regular basis.