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:
- 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.
- The Hub Flow processes the raw data in order to get the values it needs.
- 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:
- 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 anenergy_consumption
Variable—because it has no need for that data.
- For example, if an app needs to know if the S7 detects a problem or not, then it subscribes to the
- The Flow writes a new value into a Hub Variable.
- Peakboard Hub notifies all the Peakboard apps that are subscribed to the Hub Variable.
- 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 nowTRUE
, then it might change a status indicator from green to red. Or it may send an automated email to a manager.
- For example, if an app sees that
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. |
Here’s what our three Variables look like after creation:
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:
- Edit the variable.
- Go to the Peakboard Hub tab
- Under Peakboard Hub Variables, select the corresponding Hub Variable.
Whenever our local variables updates, the Flow automatically updates the Hub Variables.
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:
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).
Build and deploy the Hub Flow
The Flow automatically runs every 10 seconds. Every 10 seconds, it does the following:
- Reload the Siemens S7 data source, in order to get new data from the S7.
- Execute the function that processes the raw S7 data and updates the local variables. (This automatically updates the Hub Variables.)
We deploy the Hub Flow and it starts working right away:
You can see that the Flow updates the Hub Variables with the data from the S7:
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.
This video shows what our app looks like when the S7 detects an error:
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.