Basic instructions.
Know your instruction set.

Making a control starts with the proper perspective on the process. Important is knowing what Toby Hoare (his initials C.A.R. are referring to one of the five basic instructions of one of the first computer languages: LISP) tells you:

Even the slowest computer can perform nothing at infinite speed.

Omitting instructions is the best you can do. It brings the highest performance, but more important: you understand your process to be controlled to its limit if you dare to reduce instructions.
To do so confidently, you must know your available instruction set by heart. To master them is a real challenge. But in this topic we will inspect the basics.
The search for the details of a process is not very important. Its highlights are more important. It all narrows down to how to represent the process.
The process representation is the main topic for a control. Your instructions must keep the representation as close to the process as possible at all times. Because this representation is the basis for all decisions, not the process itself. Compare your own brain: your senses are informing you of the surroundings. You look around and give labels or meaning to what you see. Based on your understanding of what you see, hear, smell, taste or feel, you make a model of reality and act upon that. Your brain is keeping track continuously and your body is moving around in this virtual reality.
It is important to be aware that your senses are not perfect. The temperature you feel is not even a real physical phenomena. Temperature and pressure are so called emerged physical states. The average speed of atoms and molecules is known as temperature. The average force applied by these atoms when colliding to a surface is known as pressure. This shows that knowing all details makes no sense. It would consume more computer power than mankind has, and it brings nothing.
Be a child again. Your brain is equipped with extreme powerfull pattern recognition hardware. You started to look around in the world and recognized patterns. Befor labelling them, you could understand the world around you. Looking at a tennis ball, you can predict its trajectory without a conscience calculation. Just look at it very often, like Federer did, and by "deep learning" you create the most efficient representation of all aspects of the game of tennis and use it to play.
The above is what I try to convey: any representation of a process can be sufficient without knowing all details, but it must have predictive powers. It must be founded in reality.
Now you understand why the T for Timing is important in the PTD: without awareness of time past, you can not predict the future. Making control decisions is forcing the future into the results we want. Like Federer we want to win the game and have fun doing it.

Implementation rule 1: Represent your process efficiently.

Every cell in your body is obeying the above rule. Not just your brain. Evolution equipped us with the powerful pattern recognition capabilities. Just a result of survival of the fittest. Now the next step in making a control: the proper sequence of instructions.
For me it is not amazing that the DNA molecule is such a nice long sequence of only four amino acids (ACTG). It is a computer language formed by three such molecules as a representation of an instruction. It shows that a cell has stored its "programme" in a nice lineair sequence, able to dictate the manufacturing of complex molecules like proteins.
Is it a coincidance that the first, abstact, computer designed by Alan Turing, existed of an infinite long string of paper with squares on it containg a "1", a "X" or a space. (Three symbols. The digit "3" was represented as "X111X") And by only moving the ribbon a single square at the time and reading its content or erasing and rewriting it, any program could be executed.
Of course the DNA programme looks like the spaghetti programming of a bad programmer. Evolution is a matter of blind trial and error. But it is very important to be aware of:

Implementation rule 2: The secret lies in the sequence of instructions.

To paraphrase a real estate agent: three things matter: sequence, sequence, sequence.
Of course we need some more context to give meaning to the sequence of instructions. We call the equivalent of our senses the measurements and the equivalent of our muscles the equipment energized, or just equipment. We assume a computer executing the full sequence of instructions repeatedly. In detail: Input (=read measurements), execute sequence, Output (=energize equipment).
I will refer to the above as the "cycle". Just a single execution of the full sequence of instructions.
Of course a computer could use interrupts or events. This may seem to give quicker response to the process, much like our reflexes processed by the spine to withdraw your hand approaching the hot stofe, but the total reliability and robustness could be in danger. I refer to the quote of Toby Hoare if you want the highest performance.

Implementation rule 3: Use the bare minimum of rules.

Goverments and big firms tend to create a lot of laws and think to be in control due to that. They are not. Often management can be compared with cancer, a tumor consuming a lot of resources and growing at the expense of a healthy body. Always keep in mind what the purpose of the control is about: represent a process and act with the highest performance. The purpose is not: collect the most power to control.
Nothing wrong with creating good laws and a good structure, but look at your brain: it adapts itself by deleting old connections and creating new ones. Adaptive goverments should remove as many laws as invent new ones.
So, seeking the minimum number of rules is showing the maximum of your abilities.

Invertor.

The above HCADwin graphic of an invertor, the NOT symbol, is based on the IEC 61131 norm: PLC language number three, the function block representation. Note also that HCADwin is using the normal black, thin lines, to convey a Boolean. But in animation mode the line becomes blue if not connected or associated with the RTDB, gray for False and red for True. The input side of a symbol is normally on the left. Here "A" is representing the sole input and its value is expressed as 0 or 1, not as False or True. HCADwin is using implicit type conversions when needed, so 0 and 1 are more suitable.
The Pascal code for this most simple instruction would be:

R:=NOT A;

The above example is showing why I stated befor that sequence of instructions matter. The Pascal code for this most simple instruction would be:

R:=NOT R;

R_t:=NOT R_t-1;

Invertor in line.

The above example shows how an in line invertor is positioned using a I command on the Hlyn on the top left. Because the output of the T->0 timer is used here, the orange triangle appears too.
Note that the timer can show its Real value also: the purple line underneath.
This example is showing how the timer restarts itself after reaching the 0.5 seconds. For the sake of these demonstrations HCSimul is using -2 faster than Real Time. So the simulated cycle is 0.4 seconds to be sure that even a single cycle True can be witnessed in the animated GIF.
The in line invertor, the Inv symbol, can be toggled by the I command on a Hlyn or Vlyn. Position the cursor on the proper half of the line. Its function is to invert the Boolean signal when connected to another symbol. Use the NOT if you want to see a seperate symbol. The Inv is more elegant. By using the toggle command, the position of the in line invertor is just in the middle of the line and the line is shortened by a grid distance, 8 pixels.
Note that HCADwin often is conveying the not inverted signal through the lines. The number of in line inverters and the occasional built in inverter are counted. If an odd number is counted, the signal is shown as NOT signal.

Type conversion.

The above example shows how a Boolean is converted to an Integer using the Type symbol.
The Calc symbol is now expected to hold a Pascal Integer expression. Demonstrated by adding the 0 or 1 to his previous output. The "and 15" is added to calculate modulo 16.
Maybe you are now thinking "how is this example a Basic Instruction?". Well, it is about the three data types HCADwin is using. Boolean, Integer and Real. The small black line conveys a Boolean, the thick green line an Integer and the thick purple line a Real.
And you can explicitely change the type. Normally HCADwin is using its implicit type conversion, but it is done by the same symbol.
The six functions to do so are:

function b2i(b:boolean):integer;    //Type conversion routines
function b2r(b:boolean):Real;
function i2b(i:integer):boolean;
function i2r(i:integer):Real;
function r2b(r:Real):boolean;
function r2i(r:Real):Integer;

Type conversion part 2.

Using the Btest symbol, you can select a bit from an Integer. The above example is showing how I created four Boolean signals all nicely oscillating to be used for different flashing lights.
Awareness of your data types and how you can apply them, is essential when listening to Toby Hoare. You can do almost nothing to achieve your goal, but you need to know your data types and the instructions to handle them. Especially when representing your process, try to avoid Booleans and use Integers instead. An Integer can express much more. If you have coded your process representation in multiple Boolean memories, you always have to add logic to keep them synchronized.
The example project PTD_PAPER.HCE will contain the logic examples if you feel the need to play with them. Have fun!

Watch dog oscillator.

Maybe you are a religuous person with a strong belief in fairy tales. Your DCS manifacturer is providing you with an excellent I/O card. Your measurement comes with all kinds of additional information. Like range, a collection of trip and alarm settings and a Boolean variable indicating that the measurement is "healthy". Do not believe this.
Suppose we have two PLC's, A and B, using hardwired connections for the sake of safety. Now your signal may hop through many devices, maybe using the internet and satelites to travel around the world. The I/O card is telling you that only the last physical connection was healthy or not.
Let us solve that problem while being independant of the physical connection(s).
Assume two PLC's, A and B. Input I_A and Output O_A are used in PLC_A and within the sequence of instructions we position the instruction:

O_A:=I_A; //just copy an Input to an Output

O_B:=NOT I_B; //Copy the inverted Input to an Output

O_A:=I_A; {PLC_A}    I_B:=O_A; {cable_AB}    O_B:=NOT I_B; {PLC_B}    I_A:=O_B; {cable_BA}

AverageTime:=AverageTime*0.9+MeasuredTime*0.1;

If False to True transition Then AverageTime:=min(AverageTime*0.9+MeasuredTime*0.1,MaximumTime);

Logic operators.

The three logic operators combining two or more Boolean variables are: AND, OR and XOR.
The above animation is showing how the combinatorial logic is performed using four inputs. A special case of inputs is used: the Gray code. These Boolean variables are showing all 16 variations, but only a single variable is changed at the time. So you can follow what happens a little better.
For the phylosophers amongst you: The AND is equivalent to the democratic principle that a unanimous vote is needed. Only True if all inputs are True. The OR is almost the same, but now only False if all inputs are False. The XOR is more realistic. With two inputs it indicates that the voters disagree. With multiple voters it is a test that an odd number of voters voted True. For that reason the XOR is showing a nice oscillator in the rithm of every change of pattern. (this was the main reason I chose the Gray code for pattern change).