The Library for Basic Processes (LBP) for Beginners, Part 1: Siemens PLCs

Libraries are the basic building blocks of any large project, and their main value lies in their modularity and reusability by developers. A good library handles the repetitive, low-level work and exposes it through a clean, straightforward interface. A great library goes a step further: it stays flexible as requirements change, and it’s still easy for operators of all technical backgrounds to use through the human-machine interface (HMI). At DMC, we’re a little biased towards the Open PLC Library (we helped develop it!), but there are plenty of great alternatives that deserve the spotlight as well. 

This blog will be a supplement for the basic documentation for the Siemens Library of Basic Processes (LBP), and this article will address some beginner coding tips for Programmable Logic Controllers (PLCs). In particular, we’ll be discussing three critical library blocks – LBP_OpDig, LBP_AnaRead, and LBP_Vlv. 

Be on the lookout for later installments, where we tackle the associated HMI elements. 

What’s in the LBP?

The Library of Basic Processes (LBP) supports the integration of basic hardware on a PLC program and simplifies visualization on an HMI. It contains 23 pre-built Function Blocks (FBs) for typical hardware modules, including counters, PID controllers, analog and digital inputs, valves, and motors.

Function blocks are built robustly using structured text (SCL), and users can quickly create multiple instances of the same block and easily apply them throughout their project. When instantiated, every Function Block creates an associated Data Block (DB) that holds status information such as the real-time state of the module, fault conditions, and operational values. It also contains input and output parameters for controlling the module, including setpoints, feedback, and control variables. The DB’s design ensures smooth interfacing with HMI faceplates by organizing the data in a structured format that aligns with the visualization elements. 

What are the Hardware and Software Requirements for the LBP?

First, make sure that your project is configured to handle the LBP. The LBP is compatible with the S7-1200, S7-1200 F, S7-1500, and S7-1500 F family of controllers. For visualization, the LBP works on all Comfort Panels and Unified Comfort Panels. If you intend to simulate a program on your development computer, S7-PLCSIM versions 14 and beyond are compatible.  
 
On a software level, you’ll need TIA Portal V19 or above for development. Additionally, for developing the HMI, you’ll need one of the following WinCC versions, or any later versions: 

• WinCC Comfort/Advanced V17 
• WinCC Runtime Advanced V17 
• WinCC Professional and Runtime Professional V19 
• WinCC V8 
• WinCC Open Architecture 3.19 
• WinCC Unified V18 

LBP_OpDig – Digital Value Processing

The first signal that we’re tackling is the Digital Output (DO). As the name would suggest, hardware that only has DO signals don’t have inputs, but depend on internal logic to decide when they are active. Examples include status LEDs, alarm buzzers, or really any components that quickly convey critical system information to operators. This is the simplest of our LBP blocks, and a good place to start.  

Inputs

The identName input is where you’ll be putting the real-world name for this module, such as “Green LED.” During HMI configuration, you will be able to call this value and display it as the title on the associated HMI faceplate. 

Warning: If you’re intending to implement language translations, the identName string can’t be passed into a text list, which is the conventional method for dynamizing translations. This marks one of the main pitfalls of the LBP, so keep this in mind before going down the rabbit hole. 

The indOn bool is where you’ll attach the internal logic that determines whether our output should be activated. In our example of the Green LED above, this could be as simple as checking if our system is in the Run state with a simple logic gate and passing the true value into the input. 

The panels input/output is a handy feature that lets us simplify our connection between the PLC and any HMIs that we plan on adding to the system. The LBP has a handy datatype called the LBP_typeMultiplex that contains all the possible tags that we might pass to an HMI and neatly packages them, so we don’t have to worry about it. All that we have to do is go to our LBP library within the project, open the PanelsBlock, and add as many LBP_typeMultiplex array entries to the Panels array as we have HMIs.  

See Figure 2: PanelsBlock DB Interface below for an example where we have two HMIs. 

After configuring this, just link “PanelsBlock“.Panels to the panels input/output on your LBP_OpDig block. Note that every LBP block will need this panels link configured, but you only need to complete the initial setup once. 

Outputs

ENO is the Enable Output Bool. It is true when the block successfully executes, which should be always. 

The On Bool is self-explanatory. When the DO is on, this output is on. 

LBP_AnaRead – Analog Value Processing

The LBP_AnaRead block is another critical block that processes raw analog sensor data and applies necessary scaling to output a value that is meaningful to the end user. Examples are numerous and include pressure, temperature, and moisture sensors.  

Inputs

• We treat the identName and panels inputs identically to our previous example. 
• The mode input is critical to appropriately scaling our raw values. There are currently 8 available modes of processing the data: 
  • Mode 0 changes the output to the valueAlt input blindly without any calculations. This is helpful for override situations or simulation testing. 
  • Mode 1 is for Unipolar data. We want to use this mode when the raw value input is bounded between 0 and a positive number. 
  • Mode 2 is for Bipolar data when the raw data can range from a negative to a positive value. 
  • Modes 3 through 7 apply a multiplier of .1, .01, 1, 10, and 100 (respectively) to the raw value. This is for when your raw data is off by only a couple of orders of magnitude. A good example is if you have a voltage reading between 0V and +10V, and you want the output reading to be a percentage; you can employ mode 6 for an easy conversion. 
• rangeBegin and rangeEnd dictate the range of the processed output. They are only relevant when using the unipolar and bipolar interpolation modes. 
• limitAH, limitWH, limitWL, and limitAL represent the thresholds at which an alarm and/or warning is triggered for the module. 
  • These thresholds are not dynamically adjustable. For scenarios like system initialization or shutdown, where alarms might not be needed, external logic is required to suppress or manage these conditions. 
  • Disabling alarms outright is tricky. While setting thresholds outside the expected range can work, it is not always considered best practice, as it may lead to unexpected edge case behavior. 
  • If you find yourself in need of dynamic alarms, one potential solution could be to create a wrapper for the LBP_AnaRead block, which can take logic in a similar fashion to the LBP_OpDig block above to write to an internal LBP_AnaRead block and change the thresholds accordingly. This is most easily accomplished when you configure your system as a state machine, since you can just use simple logic checks for a desired state. 
• The timeout and hysteresis parameters dictate how long a threshold can be violated before triggering an error, and numerically how far back into the ‘safe’ range a value must go before resetting alarms. These parameters help reduce false alarms caused by noisy signals near threshold limits. 
• valueAlt, as mentioned before, is an override value that ignores any processing steps. What goes in, typically via manual HMI override, is what comes out and is used for future processing. 

Outputs

• AH, WH, WL, and AL are Booleans that are true when any of the respective alarms or warnings are active. They stand for Alarm High, Warning High, Warning Low, and Alarm Low, respectively, and are analogous to another typical convention of High High, High, Low, and Low Low alarms. Alarms usually place the system into a faulted state, whereas warning simply write messages to the terminal while continuing normal operation. These errors are very helpful during early testing and simulation because they help developers quickly visualize and debug error logic.
• ErrorHigh and ErrorLow signal whether the processed output is outside of the rangeBegin and rangeEnd inputs. Typically, it’s best to consider these errors to be of the same level of severity as an alarm, as it typically indicates a hardware malfunction and the system should fault out. 
• The value output, of course, is our post-processed value. It’s the value that shows up on our HMI and is used for future calculations throughout our project. 

LBP_Vlv – Simple Valve

The final library block that we’re covering is the LBP_Vlv, used for ‘simple’ valves that only take digital inputs for open and close. There are other function blocks for Analog Valves and 3-way valves, but we’ll only be tackling this one. The valve differs from our other library blocks because it can be operated in four ways: automatic mode, where commands occur according to a programmed sequence; in manual mode, where a user on the HMI can override the current valve command; local mode, where an in-person operator can send a command that overrides all others; and repair mode, where all controls and error messages are disabled. 

Inputs

The identName and panels inputs function identically to previous examples. The remaining inputs fall into a few main categories. 

Feedback Inputs

• indClosed and indOpened 
  • These Boolean inputs provide feedback on the valve’s current position. 
  • If both inputs are simultaneously true (indicating conflicting feedback) or the feedback doesn’t match the command within the specified timeout, the valve enters a faulted state. This robust error detection ensures the valve operates as expected in real-world systems. 

System Override Inputs

These inputs handle external conditions or system states that can influence valve behavior. 

• indTripOk 
  • Indicates whether the emergency stop (e-stop) has been triggered. 
  • True: The system is functioning normally. 
  • False: The e-stop has been tripped. 
  • Use Cases: 
    • To stop valve operation immediately upon e-stop activation, wire the e-stop to this input. 
    • If the valve should participate in a shutdown procedure instead of entering an error state, pass True to bypass this condition. 
• indErr and indWarn
  • External Boolean signals indicating error or warning states for the valve. 
  • True: Triggers error or warning behavior in the valve. 
  • False: Ignores external errors or warnings, leaving handling to other parts of the code. 
• indInterlock 
  • True: Prevents the valve from opening, even if commanded to do so. 
  • To invert behavior (prevent closing instead of opening), set lockClose to True. 

Mode-Specific Inputs

• indRepair 
  • Activates repair mode, disabling all controls and error messages. 
  • Useful for maintenance or troubleshooting. 
• indLocal
  • Activates local mode, allowing an in-person operator to control the valve directly. 
  • When active, the cmdLocOpen input overrides all other commands. 
• cmdAut and cmdAutoOpen 
  • cmdAut: Activates automatic mode. 
  • cmdAutoOpen: Determines whether the valve should open (True) or closed (False) during automatic operation. 
  • This is used for typical programmed sequences. 

Control and Reset

• cmdReset 
  • Used to reset the valve after it enters an error state. 
  • Must be pulsed to True to clear errors and resume normal operation. 
  • Typically wired up to either a physical button and/or a button on the HMI. 
• timeout
  • The timeout duration for two main types of errors: 
    • Timeout errors, where indClosed or indOpened does not become true after being sent the appropriate command 
    • Plausibility errors, where the valve reports true values for both indClosed and indOpened 
  • This value being greater than zero helps avoid nuisance errors caused by brief mismatches or delays in feedback. 

Outputs

• The close and open outputs are how commands are sent to our hardware. If a given valve is normally (i.e. default state) closed, link the open output to its Q address. If your valve is normally open, link your valve to the close output. 
• collectError, collectWarning, and collectMaintenance signal that the valve is reporting an error, warning, or call for maintenance, respectively. You can ignore collectWarning since the basic valves don’t throw warnings (this was likely included for consistency among the library). 
• modeAut is a feedback status bool—a True value signals that the valve is in Auto mode. 
• reset is another feedback status bool indicating if the reset input is active. 
• intError returns a Word datatype to indicate what error is thrown. 

Note on Simulating the LBP_Vlv block

Despite being a common practice during offline development, the LBP_Vlv block does not have any built-in simulation support. If you want to validate your project’s state logic via simulation, you’ll need to create an external function.  

The easiest method is to create a function block (let’s call it Vlv_Sim) that, for a given valve, takes the input that you would normally link to your cmdAutoOpen and overrides the feedback values accordingly. It’s advisable to add a TON timer before these overrides to avoid race conditions and to give yourself some time to breathe between steps so that you can see what’s actually occurring in your code.  

Once you’ve created this simulation block, at the top of your Main code, create another block that contains an instance of your Vlv_Sim for each valve in your system. Create a global variable to enable this simulation block, and you’re good to go. 

Next Steps

With this, we’ve covered the most basic steps to instantiate three very common function blocks using the Siemens Library of Basic Processes. Next, we’ll look to connect the dots between the PLC and the HMI. Stay tuned for Part 2 of this series, where we’ll take the information stored on our LBP Data Blocks and link them to pre-built faceplates, neatly displaying our data and making it easy to digest for our end users.  

Ready to take your project to the next level? Contact us today to learn more about our Manufacturing Automation solutions and how we can help you achieve your goals.