Beckhoff TC HMI Image: https://www.beckhoff.com/en-us/products/automation/twincat-3-hmi/

HMI (Human Machine Interface) development is critical for any controls project allowing the operator to interface with the machine in the simplest manner possible.
Overall, there should be some framework in how the HMI interfaces with the PLC control variables via a control protocol interface (Modbus TCP, ADS, OPC-UA, Profinet etc.).
The selection of the control protocol interface between HMI & PLC is critical as it determines how easy an interface can be changed & expanded upon dependent on different equipment interfaces.
This will be a separate blog discussion later. 

HMI Variables used for both control and indication (bi-directional data) on the HMI should be separated from the variable data spaces used for only indication or only control.
Likewise, variables that are to be as used as retained configuration parameter variables (Config) for the machine should be in its own separate data space.
Polling of critical variables on the HMI should be dependent on the dynamics of the variable.
Typically process or motion control feedback variables such as displacement, speed, acceleration, rotation, flow, and pressure should be polled between 100 ms to 500 ms. State events or state transitions may be polled faster but one must consider that faster HMI polling will create general lag while running the HMI in debug or in run-time. Alarms and interlocks may be polled between 500 to 1000 ms. 

One should have a general screen structure or mockup of the HMI. 
An example Frac pump fleet control HMI mockup is shown below:

• An intuitive default boot-up or power-up screen showing the power-up states, overall machine state, and communication for mission critical equipment:​

General HMI development tips:

• The operator should have access to the E-Kill (all power-off) or E-Stop buttons as well as some indication of the overall machine state at all times on the top banner of the HMI.
• The operator should always have access to redundant preferably SIL rated E-Stop/E-Kill push buttons in his control station/cab/area.
• Set-point limits on the HMI should be read by the HMI and should be dynamic if the limits configurations can be changed in the PLC code.
• Alarm naming should be explicit in terms of priority (critical, fault, alarm, error, informational, config error) and condition (Over Limit/Warning, Under Limit/Warning, Timed Out etc.) in an intuitive color scheme.
• Use ISA, IEC, and NFPA guidelines for equipment indication color scheming for alarms and equipment conditions (reference: Control-Systems-Engineering-Exam-Reference-Manual_A-Practical-Study-Guide_3rd Edition.pdf):

When starting a new controls project, it’s important to know what you don’t know in terms of process control and hardware component control (electrical & mechanical) that your controls system is controlling and the limitations of both the process and the hardware.

First, it is important to develop a gap analysis or preliminary requirements from the stake holders such as the customer or internal customer starting from the component level design & control, working to the process and higher-level control design where multiple hardware components are controlled in parallel. This design process is called the bottom-up or inside-out design approach.

This design approach is somewhat time consuming initially but allows the controls engineers as well as the mechanical/electrical design engineers to have a better understanding of the process and hardware.
Then one can create a formal functional requirements document listing out the tasks to control each individual hardware component and later the design of the process or overall motion control.
This formal Functional Requirements Document (FRD) will have control tasks associated with each requirement. The requirement section can be tied to tasks in MS Project Management or Jira.
One can determine what tasks can be developed in parallel and which can be done sequential.
From there it is a matter of creating sprints or time intervals where a group of tasks can be completed during this time interval within the controls engineering team.

Having a formal functional requirements document is important as it is the road map for your control system product. It is important to allow for expandability for both controls hardware and software (via OOP), redundancy for mission critical sensors and actuators, and keeping things as simple as possible reducing software and hardware complexity which allows for better control code troubleshooting and maintenance.
​
Once the FRD is completed, then you can start selecting your sensors and actuators. Design the external sensor and actuator interface schematics which tie into you proposed PLC IO rack.
Next, design your PLC IO rack based on PLC bus & sensor/actuator power consumption.  
Add and link your PLC IO control variables to the IO modules in your PLC IO tree and create device driver to translate your IO module signal counts to actual physical signals (e.g., pressure, flow, velocity, etc.) and so forth.

Then you are off to the races with electrical & mechanical component control and high-level process/motion control! 

Simulation of plant dynamics are quite important when testing PLC/MCU controls that include state machines or active controllers such as PID controllers.  The complexity of the simulation to test the controls depends on the following factors:

• Are the physical dynamics a static process or a more complicated continuous process requiring differential equations representing continuous dynamics?
• Is the machine used to control the dynamics placed in a manufacturing environment or in a remote field location? More involved simulation and testing is required for remote field location deployments.
• In summary, it depends on the application that the controller is trying to control and if the unit can be pre-tested extensively on a test setup representing the actual physical dynamics before becoming operational.

For instance, motion control servo drives or VFDs with external controllers (PIDs) should be tuned for various load applications to obtain the required accelerations, decelerations, and constant speeds for load motion before being deployed on an actual motion unit in a manufacturing or field environment. In this case, simple simulation and testing consists of testing real loads in a test setup. In general, controls applications require a tailored simulation and testing environment.

State machines typically require conditional static Boolean events to actuate controls on or off and to transition between control states.

On the other hand, active continuous controllers such as PIDs, State space, LQR, Fuzzy logic, or Adaptive System ID or neural network controllers are required to run when the process or motion dynamics are running.
Some understanding and modelling of the dynamics to test the controls in a simulated test environment is required. The dynamics may be modelled as a linear nth order differential equation in the time domain, or the equations of motion can be easily modelled with MATLAB Simulink function blocks in the frequency s-domain. Of course they can be static (the dynamics are either on or off) for the static simulation case. 
​
In general, simulation environments can be classified as three types which will be discussed in the next section:
- Software in the Loop (SIL)
- Hardware in the Loop (HIL)
- Static simulation (typically on the controls PLC itself)

Software in the Loop (SIL):
Software in the loop consists of modelling the dynamics in software on a real-time system such as another PLC, NI PXI/CRIO system or a real-time hardware platform such as the MATLAB SpeedGoat platform where software cycle times are deterministic. The dynamics can be modelled, and the inputs and outputs of the plant dynamics can run deterministically and interface with the PLC controller.
​
An example of the dynamics for a simple servo drive/motor coupled & driving a rotary ball valve modelled in MATLAB Simulink is shown below.

​The equations of motion in the time domain are converted to the frequency s-domain and modelled in Simulink FBD format:

​With SIL systems, the controller can be modelled with the dynamics in a software environment to provide a proof-of-concept control system application.
​For instance, a state space feedback controller with the same rotary ball valve dynamics modelled in MATLAB Simulink is shown below with a step input and negative torque sinusoidal fluid pulsations on the valve:

​And response of the controller with valve, motor, and fluid dynamics in the time domain is shown below:

SIL systems are very versatile in that the dynamics and fidelity of the modelled dynamics can be easily changed and improved upon, and various types of controller applications can be switched out and tested for various dynamics. This allows for tabular system response comparisons between different types of controllers with different simulations. 

Hardware in the Loop simulation (HIL):
A HIL consists of creating a scaled model of the actual dynamics with actuators and sensors wired into the Control system. This simulation setup can be used to test new control type applications before deploying it out to the field where the machine controls must function the first or second time with minor tuning.
​
An example of the hardware for a drilling rig HIL system from the University of Houston is shown below: 

​The overall controls and instrumentation diagram of the above HIL system with rotational and axial motion systems is shown below: 

The advantages of the HIL system are that the actual dynamics are modelled albeit scaled down, and the control system team gets better insight and understanding of the dynamics and the control system. Some Disadvantages is that it can be more costly compared to a SIL system and less flexible hardware wise when the application changes.
​
Static software simulation:
Static simulation involves mimicking the behavior of the equipment and dynamics to test the basic control system functionality. Typically, the simulation consists of test variables already existing on the control system PLC/MCU, where these variables and values are manually toggled or ramped up or pre-described test scripts are executed to toggle these events and values.
This method is used to test the basic functionality of state machines and active controllers and is the most basic & simplest form of simulation.
Static simulation cannot be used to model more complicated dynamics and does not provide any deep insights into the dynamics. But this type of simulation is the most cost effective and nearly any control system engineer can develop this type of simulation with visualization. 

Practical Implementation
If implementing a PID controller in controls code, write the PID controller code away from the field, if possible, to avoid distractions and code mistakes especially if you are testing the code on active process or motion systems. This will allow you to make minor changes out in the field and save time and unnecessary disruptions testing out in the field. No one wants to manage or rewrite field developed spaghetti code that was created to “to make things work” without fully understanding most of the process being controlled. Typically, most PLCs can be run in simulation mode where you can add test variables to simulate the dynamics to a certain degree on your PLC where you can switch between modes and test your PID controller initial gains & logic. These initial gains are typically very small, I typically use only proportional and integral gains without a derivative term especially if I’m unsure how much noise rides on a feedback sensor signal.  Simulating certain dynamics are quite immediate on a PLC and have very little delay, you can simulate certain first and higher order dynamics in MATLAB Simulink running on a RTOS platform like Speedgoat for HIL simulation systems.

For initial small test gains, it is fine for the controller to respond slowly initially during field testing and then adjusting gains to improve responsivity, overshoot, and overall robustness. No one would like to see high overshoot initially and instability potentially causing equipment or process safety issues.  Keep in mind the PID controller can only be used for linear dynamics that respond to an input in a linear fashion. Note, linear dynamics may have a delay which can be accounted for using a delay term in your controller that may be dependent on the dynamics.

I prefer manually tuning for different levels of dynamics (levels of flow, pressure, velocity, acceleration/deceleration, load) and see how the system performs and add modular controls features to improve the PID controller performance (like gain scheduling for abnormal conditions that can be detected and compensated for etc.). 

Control Modes
Typically, most controls code will have two modes of operation, Manual and Auto operation. Manual mode is typically open loop while Auto mode is closed loop with controller and sensor feedback.

In motion control, it may be the Manual jog mode where a linear speed in the X, Y, or Z direction is specified, and the DC servo motor moves rotationally to match the constant linear speed.  Or it may be the Auto position mode, where a displacement is specified (X, Y, & Z position), and the Servo motors (X, Y, & Z motors) move to that position with given configured speeds and acceleration until the final displacement is met which is determined when the Servo 24 VDC pulses sent and received by the shaft encoder match. These configured parameterized speeds and accelerations would obviously change based on the size and shape of load one is trying to move in three-dimensional space. These configured parameters would be tuned to reduce displacement overshoot for various loads.

On the other hand, in process control, one will have a Manual speed mode for setting the speed of the VFD which will rotate an AC motor which is then coupled to a centrifugal or a positive displacement pump controlling the pressure and flow of the process fluid in a system. The Manual speed mode will open-loop control the speed of the motor and pump. It is important to note, the VFD will typically have its own internal cascaded PID control speed control loop with voltage output of the drive as speed feedback (Voltage relates to speed, Current relates to torque). The Auto mode may consist of Auto pressure mode or Auto flow mode which consists of a PID controller with an Analog pressure or flow sensor on the output of the pump fed back into the controller. The PID controller will take a pressure or flow set-point and pressure or flow sensor feedback and convert it to speed set-point into the VFD.

Bump-less transfer between modes
When switching from Manual to Auto modes while running the equipment, it is desired that the PID controller does not receive a step change in the set-point (from a zero set-point to a valid non-zero set-point).  To accomplish this, it is imperative that a Feed-forward term is added to the output of the PID controller.
For example, when switching from Manual to Auto mode, the Feed-forward term would be the current speed of the motor that is added to the output of the PID controller. In this way, the PID controller has a sense of where it currently is and does not overcompensate by starting from a zero set-point to a non-zero set-point. Likewise, for motion control one would use current displacement as the feedforward value for the controller output when switching from Manual to Auto mode while the Servo motors are moving. 

Resetting integral windup
When the operator switches back to Manual mode, it is critical that the PID controller resets the integral windup to zero, or the integral error term will increase over time when the set-point and feedback values do not match as the operator controls the equipment manually. Also, it is important to reset the Gains to default Gains if the Gains were changed due to gain scheduling. In general, when in Manual mode you do not want the Auto PID controller running. Also, if the Pump controls are held back by a closed valve while running in Auto, it is critical reset the integral windup so the PLC control does not overcompensate when the valve is re-opened and creates an unstable control system. An analogy in the aerospace world would be holding back a drone if it was give a set-point to go to 100 feet.  

Introduction:
PID control is the most well-known controller but is probably the most poorly implemented control method  when it comes to applying the control algorithm.
Most likely due to very little control theory is needed to apply the control method (plant transfer function left-hand pole-zero frequency/s-domain stability) and documentation is widely available to the layman or laywoman.
PID control can only be applied for linear plant dynamics (99% of applications), linear in the sense that if I apply an input into the actuator-plant transfer function block, the plant output responds in a deterministic manner (not random) and the output is linear.
For instance, if I spin the motor on a conveyor belt, the conveyor will linearly move faster, if I spin the motor faster then the conveyor will move faster in a proportional linear manner.  
Orbital vehicle maneuvers in space for example are highly angular dependent which are based on the space object reference to central point and thus non-linear.
A non-linear sliding controller may be a better method for controlling an object in space.
For other instances, PID control with feed-forward which predicts the plant dynamics based on some non-linear step condition can change immediately the performance of the PID control based on this step/threshold condition before controls become too erratic. In this case, the PID controls function for these known non-linear conditions and "one is shaping the pole-zero location of the plant transfer function."

Basic Applications:
PID control is excellent for a variety of linear applications including pump/valve pressure and flow control, fluid level control using pumps or valves, HVAC/Chiller temperature control, chemical pump concentration control, crane motion control, drilling feed and weight controls among other application. For whatever the application it is used in, the PID control must be running 2x as fast as the plant dynamics, this can be tested in the time domain by putting the PID controller in manual mode or bypassing it, putting a step input into the actuator that you are controlling and seeing how the fast the output of the plant dynamics responds. This determines how fast your PLC task times need to be set. Note, running the PID controls too quickly or sampling IO too quickly, specifically the feedback sensor used for control can cause noise to enter the PID control. When a Derivative term is used in the PID control, the noise can be amplified.

Elementary Theory:
Most PID control is implemented with negative feedback, where the feedback is subtracted from the set-point to give the error. The  PID control acts on this error to create an actuator input (error action/correction) which is used to control the plant dynamics (flow, pressure, etc.).  Positive feedback is where the sensor feedback is added to the set-point.
The Proportional term determines the amount of action that must taken based on the difference between the set-point and feedback. The Integral term is the action based on the difference between set-point and feedback over time, this is why integral windup is large when the PID control is forgotten to be turned off or the control action is held back (i.e. I hold a drone back with my hand when it is commanded to go to a height of 1000 ft).  The Derivative term is the control action based on how fast the feedback has changed compared to the set-point. A great table describing the affects of changing Kp, Ki, and Kd terms independently given by the PID controller wiki is shown below with overall PID equation:
 https://en.wikipedia.org/wiki/PID_controller

Fundamental Tuning:
Typical implementations of PID control do not use the Derivative term as this can cause instability of the control when sensor noise is entered into the feedback loop as the derivative of a sinusoidal signal with noise is noise times the sinusoidal signal.
Most PID controls are tuned manually but the closed loop Ziegler-Nichols method can be implemented if the process cannot be turned off while tuning.
​Open loop tuning can be implemented such as the Cohen-Coon method or Integrated Absolute Error method using a step input and monitoring the response. 
​More tuning discussions will come later.   

​Methods:
​After discussing parent and child function blocks for a PLC controls project. I would like to discuss Methods which are used in function blocks.

A method contains a sequence of statements that may have explicit inputs, outputs, internal variables, or a method return, and this method is assigned to a specific function block or program. Methods may also have implicit access to internal variables of the function block where it is assigned to.
It is important to note, the data of a method is temporary and ONLY VALID when the method is executed or called.
After the method is called, data within the method is defaulted to False if a Boolean variable or 0 for a REAL or UINT variable until the next call of the method. Some other general considerations with Methods are the following, you cannot access VAR_TEMP variables of the function where the method is assigned and access to VAR_IN_OUT variables of function block is possible when using a method.

Methods are a great way of storing specific logic associated with calculating certain values, getting a sensor scaled value, populating an array, setting specific equipment Set-points with limits, and getting certain statuses of equipment.
A Get method for getting a power status with a Boolean return status for a piece of equipment is shown below (code comments not shown):

Using methods allows the PLC controls engineer to make compact logic statements that are called within the function block without cluttering the code of the actual function block. It allows one location where specific logic is defined and controlled by the controls engineer. If child function blocks are called as Pointers by Parent function blocks, then these child Get and Set methods can also be accessed by the parent function blocks allowing feedback flow and control of information from the bottom low-level to upper higher level function blocks. This allows for a standard way of managing and debugging PLC controls code from one project to the next.

Actions:
Actions can also be used which only uses the data defined within the action. In other words, it uses the input/output and local variables of the basic implementation. You can think of actions as pre-defined recipes as designed by the controls engineer. More information on creating programming objects can be found from the Beckhoff website: 
​https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/9007201785048459-2.html&id=

Introduction:
Function Block design is the most fundamental control object design in PLC controls. A FB may be a device driver for sensor IO which scales the IO card/module counts into a real physical signal (i.e. pressure or flow), it may be a FB that is a communication (i.e. Modbus, Profinet) interface between function blocks or control objects where data is correctly mapped between one object and the next, or it may have direct control of a piece of hardware, equipment, or process with an integral or finite event state machine. We will talk about different state machines in a later post and the pros and cons of each state machine. A FB will have some primary purpose and how one arranges FBs to communicate in a parent to child tree structure is critically important as discussed in the previous blog.

Data declaration:
Typical FB data consists of input, output, and process or var in-out data which is bi-directional to communicate data between upper, lower, and lateral function blocks. This data is declared in the FB header. It may also have implicit Pointers or References to other function blocks to receive feedback from and control other function blocks. Pointers or refences (to objects) are used to reduce memory during run-time but pointers also allow you to refer to the same space in memory from multiple locations allowing data to be shared seamlessly without manually passing input and output data between function blocks. This means that you can update memory in one location and the change can be seen from another location in your program or FB. Typically, Input and Output data should be limited to only critical data (i.e. System data such as an E-Stop flag) that needs to be communicated directly between FBs. Also, a FB may contain regular variables contained only within that FB that cannot be seen by other function blocks, these variables are called FB or member variables and should have prefix that differentiates these variables from input and output or bi-directional data.

FB code structure:
Like a book, a function block has a beginning, middle (premise/purpose) and end. In the actual function block code, it is typical to read all the inputs of the function block first, then in the middle do any state machine control such as event triggers and timers that trigger a state transition in your state machine or integral case state machine logic. It may also contain methods to set values in lower function blocks or controller logic such as PID function block calls for pump or valve control or motion control based on certain conditional logic. We will talk about Methods and Actions and the difference between the two in a later blog post and the Pros and Cons between the two when structuring your FB. At the end of the FB code, the outputs of the function block will be set by the logic in your function block.

I hope this gives a general overview of FB design!
​
​See below Beckhoff reference on Function Blocks as well:
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/9007201785020555-1.html&id=

Before any code is written, it is important to have a controls architecture in place. Essentially, architecture allows you to design your building blocks for creating an overall control system and should be based on a requirements document that is designed first with the basic controls components defined then more complicated controls blocks defined later. These basic components could be the mechanical & electrical components which are the most fundamental blocks of the controls design. Examples of mechanical & electrical controls components could be the individual valves on a valve manifold unit, or it could be the pump or VFD portion of a pump unit or the motor on a conveyor unit, or it could be the flow/encoder sensors on a pump. Other examples include the Low Voltage contactors that control the Low Voltage power to a control system. It matters that you define and design these basic blocks first before more complicated control blocks are designed.
 
The next step is to define and design a unit function block. A unit or unit function block consists of the mechanical and electrical components associated with the functionality of a unit. For example, a pump unit consists of the VFD, motor, gear box, and pump with flow or pressure sensors associated with that pump unit. A conveyor unit consists of the motor, gear box, and belt with position or speed sensors associated with that conveyor unit. These units may have functionality to set speed or flow values and decode the inputs signals from the mechanical & electrical components.
 
Finally, a process or motion control block is defined and designed. A process or motion control block may contain many of these function block units that controls the function block units in a way a maestro conducts an orchestra in synchronization. In this way, we design controls code with a parent-child tree structure with PLC Inputs from sensors & PLC Outputs to actuators associated with the children function blocks and the parent function blocks then calling the children function blocks.
​
This makes the code much easier to manage, debug, and expand upon on and mitigates the development of spaghetti code where children call parents.