| This documentation is out of date.
The new version of the documentation is here: https://cannylogic.com/docs |
Difference between revisions of "CFD Language"
| [unchecked revision] | [unchecked revision] |
(→Network) |
(Initial edit) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Canny Function Diagram (CFD) is the programming language used to program the Canny 7 controller within CannyLab IDE. During the development of the language, the goal was to create a tool which best suits the capabilities of the controller, while at the same time maintaining industry standard. Function Block Diagram (FBD) Language was used as the basis for the development of CFD. It’s fair to say that FBD is a contender for the most well-balanced among the five languages approved by the International Electrotechnical Commission for the purposes of creating user programs for PLC within the IEC 61131-3 standard. | |
| − | As a graphical programming language, CFD has a high clarity comparable to wiring diagrams, but is at a higher level of abstraction, which | + | As a graphical programming language, CFD has a high visual clarity comparable to wiring diagrams, but is at a higher level of abstraction, which lets largely irrelevant algorithm implementation details remain hidden. |
| − | === | + | === Function Diagram === |
| − | + | A program in the CFD language is called a function diagram. It’s a draft (scheme) containing the function blocks, the connection lines (networks) linking those function blocks to each other, and miscellaneous supporting elements. | |
| − | The program | + | The algorithm of executing a program in the CFD language can be best described as successive (usually from the left to the right) calculation of each function block’s values, with the result transferring to the next connected function block for further calculations. We will refer to such an algorithm as a thread of execution. |
[[File:3_1_1.png]] | [[File:3_1_1.png]] | ||
| − | + | Presenting the program this way makes it easy to trace the thread of execution, just by looking at the picture and following connection lines from block to block. | |
| − | In CFD language, the relative position of | + | In the CFD language, the relative position of blocks in an acyclic diagram, which in this context means a diagram without a feedback loop, does not affect their execution order. Function block order of execution of such a diagram is automatically determined by the following rule: each function block is executed when all of its inputs are calculated. |
| − | + | When determining the order of execution of a cyclic diagram, which in this context means a diagram with a feedback loop, function blocks involved in the feedback loop are executed in such order, that the rightmost function block is always the last one to be executed. | |
[[File:3_1_2.png]] | [[File:3_1_2.png]] | ||
| − | === | + | === Function Block === |
| − | The function block is a graphical element in the | + | The function block is a graphical element in the function diagram indicating a function, algorithm or mathematical expression. The function block produces calculation of its output data depending on the input data received from the outside. On the function block image, the inputs are positioned on the left and outputs on the right. |
[[File:3_2_1.png|900px]] | [[File:3_2_1.png|900px]] | ||
| − | [[Built-in Function Blocks | | + | [[Built-in Function Blocks | Built-in Function Blocks of CFD-language]] includes both simple blocks that perform basic logic transformation on their input data – such as AND, OR, NOT – along side more complex function: triggers, generators, switches. |
| − | + | A function block, depending on its type, may have several inputs and several outputs, use its own memory as well as access the controller operating system resources for computations. For example, a function block can read data from a timer and use it for calculating the output values. | |
[[File:3_2_2.png]] | [[File:3_2_2.png]] | ||
| − | In CannyLab environment, sources of input data for a function block | + | In the CannyLab environment, valid sources of input data for a function block are: other function blocks whose output output is connected to the block’s input via connection lines (networks); numeric constants entered by the user or selected from the directory; data from controller service memory registers. |
| − | Any | + | Any input or output of a function block can be inverted. In the case of an input inversion, the new value of input data is equivalent to the value that results from performing the operation "Logical NOT" on the real input data. In case of output inversion, the "Logical NOT" operation will be applied to the data before sending the calculation result of the function block to the next function block or supporting element. |
=== Network === | === Network === | ||
| − | The line connecting data source to one or more recipients of | + | The line connecting a data source to one or more recipients of data on the function diagram, is called a network . In the CFD language, the data source is usually the output of a function block, a recipient is an input of another function block. In the CFD language any network can have only one data source. |
| − | In programming | + | In programming language terms, the network is a "variable", a place where specific data is stored. After a function block finishes its calculations, writes its output value into the network as the network value. The function blocks whose inputs are connected to this network read the data stored in the network and use it in their calculations as input values. |
| − | + | ||
| − | + | An unbroken connection line from one function block to another is a network segment. Network segments can have any number of branches(or none at all), the important part is the connection line being unbroken. This means that the networks described above consist of only one segment and can be referred to as anonymous networks. | |
| + | Alongside anonymous networks, CannyLab has named networks, which are created by assigning a display name to an existing network on the diagram. Named networks are logically unified, meaning that it is possible to separate the network into several visually unrelated segments for easier composition. For example, the two segments of "Tyre pressure, kPa" (on the figure below) represent the same network, and have the same value at each point in time, despite not being visually connected. | ||
| + | |||
| + | [[File:3_3_1.png]] | ||
=== Data === | === Data === | ||
| − | In CFD language, all the data used | + | In the CFD language, all the data used is 16-bit non-negative integer numbers in the range of 0 to 65535. The result of an arithmetic operation is always a numeric value from the specified range, and logical operations results are "1" (true) and "0" (false). |
| − | During | + | During function diagram execution, where necessary, data conversion from boolean to numeric data and vice versa is performed automatically using the following rules: |
| − | * When converting a number to a boolean value, zero is converted to a value of "false", any number other than zero | + | * When converting a number to a boolean value, zero is converted to a value of "false", any number other than zero is converted to "true". |
| − | * | + | * In arithmetic operation, the logic values of "false" and "truth" are used as the numbers 0 and 1, respectively. |
| − | * Inversion at the input or output of any block, automatically converts | + | * Inversion at the input or output of any block, automatically converts data to a boolean. |
[[File:3_4_1.png]] | [[File:3_4_1.png]] | ||
| − | The results of arithmetic operations are taken modulo 65535. This means that if the operation result exceeds | + | The results of arithmetic operations are taken modulo 65535. This means that if the operation result exceeds 65535, then 65536 is automatically deducted from the result, creating the final value. And if the result was less than 0, then 65536 is added to the result, creating the final value. |
{| | {| | ||
| Line 80: | Line 82: | ||
=== Controller Resources Management === | === Controller Resources Management === | ||
| − | + | In order for the function diagram to use the controller's physical input data, change the status of the physical outputs, receive and transmit data on the data interfaces or even simply change the status of the built-in LED, the diagram and controller resources have to be linked to each other. In other words, they need to communicate somehow. | |
| − | In CANNY7 controller, access to hardware resources from the user application | + | In the CANNY7 controller, the access to hardware resources from the user application is implemented in the form of data reads and writes from/to specific registers (addresses) reflecting the status of these resources. |
| − | Controller resources require a specific order of access. For example, in the simplest case, to turn on embedded LED is enough send "1" to a particular | + | Controller resources require a specific order of access. For example, in the simplest possible case, to turn on the embedded controller LED it is enough to send "1" to a particular register and "0" to turn it off. But in order to use, say, a universal external channel for relay control, it must first be initialized, by writing its specific operating mode value into the relevant configuration register. Only then it is possible to control the electric potential on the channel by sending a "1" or "0" to the channel’s output value register. |
| − | + | As an example, the diagram below is used to control railway crossing traffic lights. Notice the three controller resource bindings in the top of the diagram. This diagram is perfectly suitable for uploading into the PLC and controlling actual hardware. | |
[[File:3_5_1.png]] | [[File:3_5_1.png]] | ||
| − | The list of | + | The list of registers of all the resources available to the user of the controller is in the CannyLab controller register directory, which is available to the user via the context menu when assigning registers as inputs and outputs in CannyLab. |
| − | + | ||
| − | + | ||
| + | The configuration of certain controller resources requires the use of special named constants that can be found in the CannyLab named constant list, which is available to the user during when assigning a constant as an input. | ||
| + | For more information on the UI and how to access these lists, read [[CANNY Lab Functional Diagram Editor]]. | ||
Detailed description CANNY 7 resources and the access procedure to them, is described in [[CANNY 7| CANNY 7 Reference Manual]]. | Detailed description CANNY 7 resources and the access procedure to them, is described in [[CANNY 7| CANNY 7 Reference Manual]]. | ||
Latest revision as of 15:21, 11 December 2020
Canny Function Diagram (CFD) is the programming language used to program the Canny 7 controller within CannyLab IDE. During the development of the language, the goal was to create a tool which best suits the capabilities of the controller, while at the same time maintaining industry standard. Function Block Diagram (FBD) Language was used as the basis for the development of CFD. It’s fair to say that FBD is a contender for the most well-balanced among the five languages approved by the International Electrotechnical Commission for the purposes of creating user programs for PLC within the IEC 61131-3 standard.
As a graphical programming language, CFD has a high visual clarity comparable to wiring diagrams, but is at a higher level of abstraction, which lets largely irrelevant algorithm implementation details remain hidden.
Function Diagram
A program in the CFD language is called a function diagram. It’s a draft (scheme) containing the function blocks, the connection lines (networks) linking those function blocks to each other, and miscellaneous supporting elements.
The algorithm of executing a program in the CFD language can be best described as successive (usually from the left to the right) calculation of each function block’s values, with the result transferring to the next connected function block for further calculations. We will refer to such an algorithm as a thread of execution.
Presenting the program this way makes it easy to trace the thread of execution, just by looking at the picture and following connection lines from block to block.
In the CFD language, the relative position of blocks in an acyclic diagram, which in this context means a diagram without a feedback loop, does not affect their execution order. Function block order of execution of such a diagram is automatically determined by the following rule: each function block is executed when all of its inputs are calculated.
When determining the order of execution of a cyclic diagram, which in this context means a diagram with a feedback loop, function blocks involved in the feedback loop are executed in such order, that the rightmost function block is always the last one to be executed.
Function Block
The function block is a graphical element in the function diagram indicating a function, algorithm or mathematical expression. The function block produces calculation of its output data depending on the input data received from the outside. On the function block image, the inputs are positioned on the left and outputs on the right.
Built-in Function Blocks of CFD-language includes both simple blocks that perform basic logic transformation on their input data – such as AND, OR, NOT – along side more complex function: triggers, generators, switches.
A function block, depending on its type, may have several inputs and several outputs, use its own memory as well as access the controller operating system resources for computations. For example, a function block can read data from a timer and use it for calculating the output values.
In the CannyLab environment, valid sources of input data for a function block are: other function blocks whose output output is connected to the block’s input via connection lines (networks); numeric constants entered by the user or selected from the directory; data from controller service memory registers.
Any input or output of a function block can be inverted. In the case of an input inversion, the new value of input data is equivalent to the value that results from performing the operation "Logical NOT" on the real input data. In case of output inversion, the "Logical NOT" operation will be applied to the data before sending the calculation result of the function block to the next function block or supporting element.
Network
The line connecting a data source to one or more recipients of data on the function diagram, is called a network . In the CFD language, the data source is usually the output of a function block, a recipient is an input of another function block. In the CFD language any network can have only one data source.
In programming language terms, the network is a "variable", a place where specific data is stored. After a function block finishes its calculations, writes its output value into the network as the network value. The function blocks whose inputs are connected to this network read the data stored in the network and use it in their calculations as input values.
An unbroken connection line from one function block to another is a network segment. Network segments can have any number of branches(or none at all), the important part is the connection line being unbroken. This means that the networks described above consist of only one segment and can be referred to as anonymous networks.
Alongside anonymous networks, CannyLab has named networks, which are created by assigning a display name to an existing network on the diagram. Named networks are logically unified, meaning that it is possible to separate the network into several visually unrelated segments for easier composition. For example, the two segments of "Tyre pressure, kPa" (on the figure below) represent the same network, and have the same value at each point in time, despite not being visually connected.
Data
In the CFD language, all the data used is 16-bit non-negative integer numbers in the range of 0 to 65535. The result of an arithmetic operation is always a numeric value from the specified range, and logical operations results are "1" (true) and "0" (false).
During function diagram execution, where necessary, data conversion from boolean to numeric data and vice versa is performed automatically using the following rules:
- When converting a number to a boolean value, zero is converted to a value of "false", any number other than zero is converted to "true".
- In arithmetic operation, the logic values of "false" and "truth" are used as the numbers 0 and 1, respectively.
- Inversion at the input or output of any block, automatically converts data to a boolean.
The results of arithmetic operations are taken modulo 65535. This means that if the operation result exceeds 65535, then 65536 is automatically deducted from the result, creating the final value. And if the result was less than 0, then 65536 is added to the result, creating the final value.
| For example: | 65535 + 1 = 0 | 1 – 2 = 65535 | |
| 65535 + 2 = 1 | 1 – 3 = 65534 | ||
| 65500 + 122 = 86 | 117 – 259 = 65294 |
Controller Resources Management
In order for the function diagram to use the controller's physical input data, change the status of the physical outputs, receive and transmit data on the data interfaces or even simply change the status of the built-in LED, the diagram and controller resources have to be linked to each other. In other words, they need to communicate somehow.
In the CANNY7 controller, the access to hardware resources from the user application is implemented in the form of data reads and writes from/to specific registers (addresses) reflecting the status of these resources.
Controller resources require a specific order of access. For example, in the simplest possible case, to turn on the embedded controller LED it is enough to send "1" to a particular register and "0" to turn it off. But in order to use, say, a universal external channel for relay control, it must first be initialized, by writing its specific operating mode value into the relevant configuration register. Only then it is possible to control the electric potential on the channel by sending a "1" or "0" to the channel’s output value register.
As an example, the diagram below is used to control railway crossing traffic lights. Notice the three controller resource bindings in the top of the diagram. This diagram is perfectly suitable for uploading into the PLC and controlling actual hardware.
The list of registers of all the resources available to the user of the controller is in the CannyLab controller register directory, which is available to the user via the context menu when assigning registers as inputs and outputs in CannyLab.
The configuration of certain controller resources requires the use of special named constants that can be found in the CannyLab named constant list, which is available to the user during when assigning a constant as an input. For more information on the UI and how to access these lists, read CANNY Lab Functional Diagram Editor. Detailed description CANNY 7 resources and the access procedure to them, is described in CANNY 7 Reference Manual.
