Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| en:software:qview:qview_6:qview60 [2015/04/28 16:06] – [3.11.2. Indexed Variables] qem207 | en:software:qview:qview_6:qview60 [2022/08/31 09:02] (current) – qem214 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== QVIEW 6.0 ======= | ||
| + | ====== - Introduction ====== | ||
| + | The QVIEW (QMOVE Viewer) development environment, | ||
| + | |||
| + | ===== - QVIEW: QMOVE VIEWer ===== | ||
| + | As with any compiled and structured text language, even QCL and Ladder require an editor to type in lines of code and a compiler that translates machine language syntax checking; QVIEW is the development environment that, in addition to supporting the QCL language and Ladder language allows to transfer the program to the CPU of the system QMOVE to monitor and modify all the variables and parameters of the program and to stop the execution to understand and correct any unwanted operations (DEBUG). | ||
| + | |||
| + | ===== - QCL: QEM Control Language ===== | ||
| + | QCL is a structured language with syntax and commands that will be familiar to programmers involved in planning or that already had the opportunity to experience a high level language. | ||
| + | However, anyone who is approaching Structured Text languages for the first time will find in this manual a valuable support. | ||
| + | |||
| + | ===== - Ladder ===== | ||
| + | //Ladder// is a logic contact language familiar to anyone acquainted with PLC programming. If approaching the Ladder method for the first time, it would be best to take a general course in PLC programming to integrate this manual. | ||
| + | |||
| + | ===== - Devices ===== | ||
| + | //Devices// perform typical functions in industrial automation (e.g. reading an analog input, a signal from a position translator, executing actual axis positioning). | ||
| + | Each device has a specific manual, please consult them for specific details. | ||
| + | |||
| + | ===== - QPaint ===== | ||
| + | An application of products QEM in an industrial automation may need to be of a project developed in Qview (for the control and automation) and is of a design for all that concerns the interface with the operator. QPaint is the environment for the development of the graphical interface for the operator terminals QEM. The two projects are related to each other because they refer to the same data structure (variables, arrays, etc.). | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Introduction to the environment ====== | ||
| + | |||
| + | This section will introduce the development environment (QVIEW) by presenting a simple demo example, that can be used as a practice tool during learning.\\ | ||
| + | The basic steps that will be developed: | ||
| + | |||
| + | * Opening and creating a demo project. | ||
| + | * Compiling the demo project. | ||
| + | * Connecting a PC to QMOVE. | ||
| + | * Downloading the compiled project on the CPU. | ||
| + | * Monitoring its execution. | ||
| + | |||
| + | ===== - Opening and Creating a Demo Project ===== | ||
| + | QVIEW 6.0 is part of the QWorkbench software package. When QVIEW 6.0 is installed and started up, the following opening screen is viewed (Figure 1). | ||
| + | |||
| + | | Figure 1: First startup | ||
| + | | {{: | ||
| + | |||
| + | |||
| + | * There is a menu at the top of the screen with all the operations possible. | ||
| + | * Below there is a tool bar with icons for the most common operations. | ||
| + | * The bottom of the screen has a status bar gives any most important information. | ||
| + | * The grey window is the work area where all the windows are opened for development, | ||
| + | * The white side window lists the units in the project or the ladder elements that can be used. | ||
| + | |||
| + | ==== - Creating a new project ==== | ||
| + | To create a new project select: | ||
| + | |||
| + | * File - New Project | ||
| + | |||
| + | enter a project name, e.g. " | ||
| + | |||
| + | * File - Save | ||
| + | |||
| + | select a directory to save the project. | ||
| + | |||
| + | * File - Add Unit - Configuration Unit | ||
| + | |||
| + | leave //Unit Name// as CONFIG and press OK. A new unit will appear in the white window and an editor window will open in the //Work Area//. This new window lists the code lines in the unit. This unit will now be modified. Only one Configuration Unit can exist in a project (no others of this kind can be added) and it is used to declare the project variables or data structure, to declare the devices being used and the type of hardware for the project. | ||
| + | |||
| + | === - Configuration unit === | ||
| + | The configuration unit is used to declare: | ||
| + | * constants, variables, | ||
| + | * the hardware; | ||
| + | * all //devices// used in the project. | ||
| + | |||
| + | Now introduce some changes to the configuration unit. Search the unit for the //SYSTEM// keyword (search tool hotkeys CTRL+F). This is the existing code: | ||
| + | |||
| + | <code QCL> | ||
| + | ; | ||
| + | ; Definitions of SYSTEM variables | ||
| + | ; | ||
| + | SYSTEM | ||
| + | </ | ||
| + | |||
| + | change to: | ||
| + | |||
| + | <code QCL> | ||
| + | ; | ||
| + | ; Definitions of SYSTEM variables | ||
| + | ; | ||
| + | SYSTEM | ||
| + | | ||
| + | </ | ||
| + | |||
| + | This syntax declares a //count// variable, it is an //L (Long)// type and belongs to the //SYSTEM// group. | ||
| + | * //SYSTEM//: a group of variables that memorise their value when the system is shut-off. The value is maintained when the system starts again. | ||
| + | * //Long//: a variable type that takes up 4 bytes in memory. This type of variable can contain values between -2147483648 and 2147483647; | ||
| + | * //count//: the name assigned to the variable. | ||
| + | |||
| + | ^All code lines starting with ";" | ||
| + | |||
| + | Another action is to indicate the make up of the QMOVE system. First of all, search for the keyword //BUS//. | ||
| + | |||
| + | <code QCL> | ||
| + | ; | ||
| + | ; BUS configuration | ||
| + | ; | ||
| + | BUS | ||
| + | </ | ||
| + | |||
| + | Change this to: | ||
| + | |||
| + | <code QCL> | ||
| + | ; | ||
| + | ; BUS configuration | ||
| + | ; | ||
| + | BUS | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | </ | ||
| + | |||
| + | These code lines depend on the type of hardware used in the project. In the documentation for installing the qmove control in use, you can get information about the configuration of the BUS section. | ||
| + | |||
| + | === - QCL unit === | ||
| + | Add a new unit to the project. Select: | ||
| + | |||
| + | * File - Add Unit - QCL Unit | ||
| + | |||
| + | leave Unit Name as UNIT1 and press OK. A second unit is created with the following default code lines: | ||
| + | |||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | change this to: | ||
| + | |||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | count = count + 1 | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | A project can have several of this type of task unit. The code lines between the //MAIN// label and //JUMP MAIN// instruction is repeated continuously in an infinite cycle. The code line //count = count + 1// increases the //count// variable at each cycle. | ||
| + | |||
| + | ==== - Compiling the Demo Project ==== | ||
| + | Before downloading the project onto the CPU it has to be compiled. Compilation can be started from the menu: | ||
| + | |||
| + | * Project - Compile | ||
| + | |||
| + | At the end of compilation messages give the outcome. The demo project does not have errors and so the message should be //Project compiling OK!//. | ||
| + | |||
| + | ===== - Connecting a PC to QMOVE ===== | ||
| + | Before opening the connection, the QRM (Qem Resource Manager) has to be running. Its icon {{: | ||
| + | |||
| + | The connection can be made by serial port using the IQ009 USB-Serial converter [[http:// | ||
| + | |||
| + | To download the compiled project onto the CPU connect the PC to the QMOVE system. Select: | ||
| + | |||
| + | * Options - Open connection | ||
| + | |||
| + | Double click on the correct resource from list. | ||
| + | |||
| + | ===== - Downloading the compiled project to the CPU ===== | ||
| + | At this stage the compiled project is ready to be downloaded onto the CPU. Select: | ||
| + | |||
| + | * Project - Download | ||
| + | |||
| + | and the project will be downloaded. A progress bar shows the download status. | ||
| + | |||
| + | ===== - Monitoring execution ===== | ||
| + | The system is now ready to execute the application. Select: | ||
| + | |||
| + | * Monitor - CPU | ||
| + | |||
| + | Open the window \\ | ||
| + | {{: | ||
| + | that will give the message | ||
| + | |||
| + | Select the command | ||
| + | |||
| + | * Debug - Run, | ||
| + | |||
| + | the application is executed; the CPU status becomes RUN. | ||
| + | Now click {{: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | When the CPU is in RUN the variable value will increase. | ||
| + | |||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Introduction to programming ====== | ||
| + | |||
| + | ===== - Declarations ===== | ||
| + | The following declarations are possible in a QMOVE project: | ||
| + | |||
| + | * symbol declarations; | ||
| + | * device declarations; | ||
| + | * hardware declarations. | ||
| + | |||
| + | These declarations can be made | ||
| + | |||
| + | * in the configuration unit, or | ||
| + | * in other task units of the project that also contain the code lines. | ||
| + | |||
| + | //Symbols// are names assigned to variables, arrays, datagroups, constants, inputs or outputs. | ||
| + | The various declarations are distinguished by the keywords placed before each group of declarations. The keywords:\\ | ||
| + | * CONST\\ | ||
| + | * SYSTEM\\ | ||
| + | * GLOBAL\\ | ||
| + | * ARRSYS\\ | ||
| + | * ARRGBL\\ | ||
| + | * TIMER\\ | ||
| + | * INPUT\\ | ||
| + | * OUTPUT\\ | ||
| + | * INTDEVICE\\ | ||
| + | * DATAGROUP (only in configuration unit)\\ | ||
| + | * BUS (only in configuration unit)\\ | ||
| + | * REFERENCES (only in configuration unit) | ||
| + | ==== - Configuration Unit ==== | ||
| + | The configuration unit is a component of a QMOVE project. Only one configuration unit can exist in a project.\\ | ||
| + | The configuration unit has to contain the declarations of variables and constants used in the application and it also defines the hardware in the QMOVE system, specifying the CPU card type and card models.\\ | ||
| + | The variables, arrays, datagroups, devices and constants declared in the configuration unit are available throughout the project. Their scope is the whole project and therefore they are readable and writeable by all the other units. | ||
| + | |||
| + | ==== - Task Units ==== | ||
| + | |||
| + | A QMOVE project can have several other task units, containing the code lines that determine the project' | ||
| + | The variables, arrays, datagroups declared in the task units can be given additional accessibility properties. Normally, when a variable is declared in a task unit it can only be used in that unit, however it can also be assigned an additional property in the declaration: | ||
| + | |||
| + | |||
| + | * IN, the symbol is accessible in write/read by other task units, while it is only accessible in read by the unit declaring the symbol | ||
| + | * OUT, the symbol is accessible in write/read by the declaring unit, while the other task units can only use it in read | ||
| + | * INOUT, the symbol is accessible in write/read both by the declaring unit and all other task units. | ||
| + | |||
| + | ===== - Variable types ===== | ||
| + | All the information necessary to declare variables is provided below. | ||
| + | ^ In the syntax descriptions the parts in <...> are mandatory. The parts in [...] are optional, while the parts separated by "/" | ||
| + | ^ All code lines starting with ";" | ||
| + | |||
| + | QCL has five main data types: | ||
| + | |||
| + | ==== - Flag ==== | ||
| + | FLAG type data is used to define boolean variables with a whole values range between 0 and 1. Its memory space depends on their quantity.\\ | ||
| + | The syntax for the definition of a FLAG type variable:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | ==== - Byte ==== | ||
| + | BYTE type data is used to define variables with a whole number range between -128 and +127. It takes up one byte of memory.\\ | ||
| + | The syntax for the definition of a BYTE variable:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | ==== - Word ==== | ||
| + | WORD type data is used to define variables with a whole number range between -32768 and +32767. It takes up two bytes of memory.\\ | ||
| + | The syntax for the definition of a WORD variable:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | ==== - Long ==== | ||
| + | LONG type data is used to define variables with a range of whole values -2147483648 and +2147483647. It takes up four bytes of memory. LONG variable definition syntax:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | ==== - Single ==== | ||
| + | SINGLE type data is a floating point value as defined by the //IEEE 754 single precision// | ||
| + | The syntax for the definition of a SINGLE variable:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | ==== - Double ==== | ||
| + | DOUBLE type data is a floating point value as defined by the //IEEE 754 double precision// | ||
| + | The syntax for the definition of a DOUBLE variable:\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | ==== - Overview of Variable types ==== | ||
| + | ^Assigning an out of range value to a variable creates an overflow condition.^ | ||
| + | |||
| + | | Data type | Code | Memory space (Bit) | Range | | ||
| + | | FLAG | F | 1 | 0 - 1 | | ||
| + | | BYTE | B | 8 | -128 - 127 | | ||
| + | | WORD | W | 16 | -32768 - 32767 | | ||
| + | | LONG | L | 32 | -2147483648 - 2147483647 | ||
| + | | SINGLE | ||
| + | | DOUBLE | ||
| + | |||
| + | |||
| + | ===== - Identifiers ===== | ||
| + | Identifiers are names used to refer to objects or labels. An identifiers is made up of one or more alphanumeric characters, always starting with a letter. The characters that can be used:\\ | ||
| + | - " | ||
| + | - " | ||
| + | - " | ||
| + | - " | ||
| + | |||
| + | ==== - Names ==== | ||
| + | Names are used to help identification of an object within the QMOVE system. | ||
| + | Object is intended as any part that can be managed by the language and having its specific the physical characteristics: | ||
| + | |||
| + | ===== - Constants ===== | ||
| + | Constants are a character or character string used as a value in a project. The constants are declared after the keyword //CONST//. The syntax for defining constants: | ||
| + | <code QCL> | ||
| + | CONST | ||
| + | <nome costante> | ||
| + | </ | ||
| + | dove: | ||
| + | |CONST|Keyword for defining constants| | ||
| + | |< | ||
| + | |< | ||
| + | |[OUT]|A declaration in the task unit used to make the constant accessible in read also in other task units| | ||
| + | |[; | ||
| + | |||
| + | A typical declaration of constants: | ||
| + | <code QCL> | ||
| + | CONST | ||
| + | TM_SECOND | ||
| + | DIM_ARRAY | ||
| + | DIM_PROG | ||
| + | DIM_STEP | ||
| + | </ | ||
| + | |||
| + | ===== - The SYSTEM variables ===== | ||
| + | ^SYSTEM variables are retentive, i.e. they maintain their value even after the system is shut off.^ | ||
| + | SYSTEM groups all retentive variables, they can be FLAG, BYTE, WORD, LONG or SINGLE type. They have to be placed after the keyword //SYSTEM//. The syntax for defining SYSTEM variables. | ||
| + | |||
| + | <code QCL> | ||
| + | SYSTEM | ||
| + | < | ||
| + | </ | ||
| + | where: | ||
| + | |SYSTEM|Keyword indicating the definition of //SYSTEM// variables| | ||
| + | |< | ||
| + | |< | ||
| + | |[OUT/ | ||
| + | |[; | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | SYSTEM | ||
| + | count L ;This is used as a counter. | ||
| + | sbSeconds | ||
| + | sbMinutes | ||
| + | swHours | ||
| + | </ | ||
| + | |||
| + | ===== - GLOBAL variables ===== | ||
| + | ^//GLOBAL// variables are non-retentive, | ||
| + | GLOBAL groups all non-retentive variables, they can be FLAG, BYTE, WORD, LONG and SINGLE type. They are declared after the keyword //GLOBAL//. The syntax for defining GLOBAL variables. | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | <nome variabile> | ||
| + | </ | ||
| + | dove: | ||
| + | |GLOBAL|Keyword indicated for defining GLOBAL variables.| | ||
| + | |<nome variabile> | ||
| + | |< | ||
| + | |[OUT/ | ||
| + | |[; | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | gfMyFlag | ||
| + | gbYourByte | ||
| + | gwHisWord | ||
| + | glYourLong | ||
| + | gsTheirSingle | ||
| + | </ | ||
| + | |||
| + | ===== - ARRAY SYSTEM variables ===== | ||
| + | An Array System variable is a group of the same type of retentive variables. They have the same size and can be accessed by a common name and refer to a specific element by an index. FLAG type variable arrays cannot be used.\\ | ||
| + | As with SYSTEM variables, they are retentive variables and have to be declared after the keyword // | ||
| + | The syntax for defining ARRAY SYSTEM variables: | ||
| + | <code QCL> | ||
| + | ARRSYS | ||
| + | <nome variabile> | ||
| + | </ | ||
| + | dove: | ||
| + | |GLOBAL|Keyword for the definition of ARRAY SYSTEM variables.| | ||
| + | |<nome variabile> | ||
| + | |< | ||
| + | |< | ||
| + | |[OUT/ | ||
| + | |[; | ||
| + | |||
| + | An array can have a maximum number of elements of 65535. Negative or fractional | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | ARRSYS | ||
| + | asbMyArray | ||
| + | aslYourArray | ||
| + | </ | ||
| + | It can be seen that the second array uses a constant for the dimension declaration. | ||
| + | |||
| + | ===== - ARRAY GLOBAL variables ===== | ||
| + | An Array Global variable is a group of the same type of non retentive variables. They have the same size and can be accessed by a common name, referring to a specific element by an index. FLAG type variables cannot be used.\\ | ||
| + | As with GLOBAL, they are non retentive variables and have to be declared after the keyword “ARRGBL”.\\ | ||
| + | The syntax for defining ARRAY GLOBAL variables: | ||
| + | <code QCL> | ||
| + | ARRGBL | ||
| + | <nome variabile> | ||
| + | </ | ||
| + | dove: | ||
| + | |ARRGBL|Keyword for defining ARRAY GLOBAL variables.| | ||
| + | |<nome variabile> | ||
| + | |< | ||
| + | |< | ||
| + | |[OUT/ | ||
| + | |[; | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | ARRGBL | ||
| + | arwMyArray | ||
| + | </ | ||
| + | |||
| + | ===== - TIMER variables ===== | ||
| + | TIMER variables are used to create timers that can be assigned a whole number value (expressed in ms) that represents the time that has to pass (from the assignment time); the “Timing ended” (1) or “Timing in course” (0) statuses are provided in read.\\ | ||
| + | Timer variables are declared after the keyword | ||
| + | The syntax for defining TIMER variables: | ||
| + | <code QCL> | ||
| + | TIMER | ||
| + | <timer name> [OUT/ | ||
| + | </ | ||
| + | dove: | ||
| + | |TIMER|Keyword for defining TIMER variables| | ||
| + | |<timer name> | ||
| + | |[OUT/ | ||
| + | |[; | ||
| + | |||
| + | Example:\\ | ||
| + | <code QCL> | ||
| + | TIMER | ||
| + | tTimer1 | ||
| + | tTimer2 | ||
| + | tSeconds | ||
| + | tDelay | ||
| + | </ | ||
| + | |||
| + | When a timer variable is placed on the left of the assignment operator a value is set in the timer (in milliseconds): | ||
| + | <code QCL> | ||
| + | tMyTimer = 1000 ;Set timer tMyTimer to 1 second. | ||
| + | </ | ||
| + | |||
| + | When a timer variable is placed on the right of the assignment operator or in an expression only the status is read (0 = Timing in course, 1 = Timing ended): | ||
| + | <code QCL> | ||
| + | gfIsTimerEnd = tMyTimer ;Assign to gfIsTimerEnd variable the timer state. | ||
| + | </ | ||
| + | or | ||
| + | <code QCL> | ||
| + | IF(tMyTimer) | ||
| + | ;Put here the code | ||
| + | ..... | ||
| + | ENDIF | ||
| + | </ | ||
| + | |||
| + | It is also possible to read the remaining time value before the timer ends (the read value is expressed in milliseconds): | ||
| + | <code QCL> | ||
| + | < Timer Name >.remain | ||
| + | </ | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | glRemainTime = tMyTimer.remain | ||
| + | </ | ||
| + | ===== - INPUT and OUTPUT variables ===== | ||
| + | All variables referring to digital inputs and outputs. Their declaration must come after the keyword //INPUT// for inputs or //OUTPUT// for outputs.\\ | ||
| + | ^The digital inputs and outputs can only be declared in the configuration unit.^ | ||
| + | The syntax for defining INPUT and OUTPUT variables: | ||
| + | <code QCL> | ||
| + | INPUT | ||
| + | < | ||
| + | OUTPUT | ||
| + | < | ||
| + | </ | ||
| + | ^The I/O addresses are given in the hardware technical data of the card.^ | ||
| + | |||
| + | where: | ||
| + | |INPUT|Keyword for defining INPUT variables| | ||
| + | |OUTPUT|Keyword for defining OUTPUT variables| | ||
| + | |< | ||
| + | |< | ||
| + | |<io address> | ||
| + | |||
| + | An interesting application of the digital inputs and outputs is to group them in under a single identifier. This identifier is similar to an eight or sixteen bit variable where each input or output represents a bit.\\ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | INPUT | ||
| + | ibInput | ||
| + | </ | ||
| + | |||
| + | <code QCL> | ||
| + | OUTPUT | ||
| + | obOutput | ||
| + | </ | ||
| + | |||
| + | If the card has more than eight digital inputs or outputs | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | INPUT | ||
| + | ibInput1 | ||
| + | ibInput2 | ||
| + | iwInput | ||
| + | </ | ||
| + | |||
| + | <code QCL> | ||
| + | OUTPUT | ||
| + | obOutput1 | ||
| + | obOutput2 | ||
| + | owOutput | ||
| + | </ | ||
| + | |||
| + | ===== - DATAGROUP variables ===== | ||
| + | Datagroup variables are a special data structures, that are stored in retentive memory. They are declared in the configuration unit and are suitable to represent a recipe database. \\ Datagroup variables contains two kinds of variable: | ||
| + | |||
| + | ==== - Static Variables ==== | ||
| + | <code QCL> | ||
| + | DATAGROUP | ||
| + | < | ||
| + | DATAPROGRAM | ||
| + | <number of recipes> | ||
| + | ;Static variables declaration | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | Static variables reside in DATAGROUP subsector named DATAPROGRAM. The first value of this sector is a number or an integer constant, and represents the number of recipes in archive. Static variables are to be considered as containers of a certain value for each recipe, and are accessed as an array, where the index is the number of desired recipe. Example: | ||
| + | |||
| + | <code QCL> | ||
| + | DATAGROUP | ||
| + | Name | ||
| + | DATAPROGRAM | ||
| + | 100 | ||
| + | ;Static variables declaration | ||
| + | Variable1 | ||
| + | Variable2 | ||
| + | Variable3 | ||
| + | </ | ||
| + | To refer to variable // | ||
| + | <code QCL> | ||
| + | Variable3[5] | ||
| + | </ | ||
| + | |||
| + | We can imagine the memory structure of a variable DATAGROUP, in our example with static variables, as the following table: | ||
| + | ^ ^ Variable1 | ||
| + | ^Recipe 1| | | | | ||
| + | ^Recipe 2| | | | | ||
| + | ^Recipe 3| | | | | ||
| + | ^...| | | | | ||
| + | ^Recipe 100| | | | | ||
| + | |||
| + | ==== - Indexed Variables ==== | ||
| + | <code QCL> | ||
| + | DATAGROUP | ||
| + | < | ||
| + | DATAPROGRAM | ||
| + | <number of recipes> | ||
| + | STEP | ||
| + | <number of steps> | ||
| + | ;Indexed variables declaration | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | Indexed variables reside in DATAGROUP subsector named STEP. Their function is to introduce for each recipe, the concept of step. The first value of this sector is a number or an integer constant, and represents the number of steps for each recipe in archive. Indexed variables are to be considered as containers of a list of values for each recipe, and are accessed as a 2-dimensional array, where the first value is the number of the recipe, the second the number of desired step. Example: | ||
| + | <code QCL> | ||
| + | DATAGROUP | ||
| + | Name | ||
| + | DATAPROGRAM | ||
| + | 100 | ||
| + | ;Static variables declaration | ||
| + | Variable1 | ||
| + | Variable2 | ||
| + | Variable3 | ||
| + | STEP | ||
| + | 10 | ||
| + | ;Indexed variables declaration | ||
| + | Variable4 | ||
| + | Variable5 | ||
| + | </ | ||
| + | To refer to variable // | ||
| + | <code QCL> | ||
| + | Variable4[5, | ||
| + | </ | ||
| + | |||
| + | We can imagine the memory structure of a variable DATAGROUP, in our example with static and indexed variables, as the following table: | ||
| + | |||
| + | ^ ^ Variable1 | ||
| + | ^Recipe 1| | | | | | | | | | | | | | | ||
| + | ^::: | ||
| + | ^Recipe 2| | | | | | | | | | | | | | | ||
| + | ^::: | ||
| + | ^Recipe 3| | | | | | | | | | | | | | | ||
| + | ^::: | ||
| + | ^...| | | | | | | | | | | | | | | ||
| + | ^::: | ||
| + | ^Recipe 100| | | | | | | | | | | | | | | ||
| + | ^::: | ||
| + | |||
| + | Other informations: | ||
| + | * In a DATAGROUP all variables, both static and indexed, are retentive (maintain the value at power off). | ||
| + | * The Datagroup variables may be more than one, in this case it is necessary to insert more DATAGROUP keywords. | ||
| + | * The subsection DATAPROGRAM is mandatory, while the STEP is optional. | ||
| + | * The maximum number of recipes can be set is 65534. | ||
| + | * The maximum number of steps can be set is 65534. | ||
| + | * Compared to a common array, static variables can also support a Flag size data (F). | ||
| + | |||
| + | ===== - BUS Section ===== | ||
| + | The BUS section in the configuration unit is essential to declare the QMOVE hardware model being used.\\ | ||
| + | In accordance with the declared hardware model it is also possible to obtain its hardware resources, e.g. the number of digital inputs and outputs, analog inputs and outputs, or count inputs . The QMOVE may also have other resources like serial interfaces or removable mass storage slots.\\ | ||
| + | The declaration made in the //BUS// section is divided in //slots//. | ||
| + | //Slot 1// indicates which CPU is being used, while the other //slots// declare the electronic cards installed in the model. Each card is identified by a keyword that identifies the type of hardware. The keywords are provided in the hardware installation and maintenance manuals. | ||
| + | |||
| + | The syntax: | ||
| + | |||
| + | <code QCL> | ||
| + | BUS | ||
| + | | ||
| + | [2 < | ||
| + | [3 < | ||
| + | [4 < | ||
| + | </ | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | BUS | ||
| + | 1 1P51F 30 ; | ||
| + | 2 . | ||
| + | 3 1MG8F | ||
| + | </ | ||
| + | |||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Variable scopes ====== | ||
| + | The scope of symbols declared in a project is very important, so it is worth dedicating a specific chapter to this topic.\\ | ||
| + | As explained, the following groups can be declared\\ | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | SYSTEM | ||
| + | GLOBAL | ||
| + | ARRSYS | ||
| + | ARRGBL | ||
| + | TIMER | ||
| + | INPUT | ||
| + | OUTPUT | ||
| + | INTDEVICE | ||
| + | </ | ||
| + | |||
| + | both in the configuration unit and in task units included in the project. The other declaration groups\\ | ||
| + | |||
| + | <code QCL> | ||
| + | BUS | ||
| + | REFERENCES | ||
| + | </ | ||
| + | |||
| + | can only be included in the configuration unit. | ||
| + | ^The addition of the // | ||
| + | |||
| + | The figure below shows a chart of the various declaration groups in a project. | ||
| + | |||
| + | {{: | ||
| + | ===== - Configuration variables ===== | ||
| + | |||
| + | Symbols declared in the configuration unit have their scope extended to all the task units. This example declares a variable in the SYSTEM group: | ||
| + | |||
| + | <code QCL> | ||
| + | SYSTEM | ||
| + | ConfigurationVariable | ||
| + | </ | ||
| + | |||
| + | This variable can be used in any task unit of the project both to assign it a value (i.e. write) and for use as a value in an expression (i.e. read). | ||
| + | |||
| + | <code QCL> | ||
| + | ConfigurationVariable = 5 ;Assign the value 5 to the variable | ||
| + | Unit1Variable = ConfigurationVariable * 2 ;Assign twice variable value to another variable | ||
| + | </ | ||
| + | |||
| + | In practice, the following complete note refers to the // | ||
| + | |||
| + | <code QCL> | ||
| + | APPLICATION.ConfigurationVariable | ||
| + | </ | ||
| + | |||
| + | The // | ||
| + | |||
| + | ===== - Local variables ===== | ||
| + | |||
| + | Symbols declared in task units containing the code lines, before the //BEGIN// keyword, have different scopes. For example: | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | local_variable | ||
| + | BEGIN | ||
| + | ... ;Here are the lines code | ||
| + | </ | ||
| + | |||
| + | the scope of this variable is limited to within the task unit where it is declared. No other task unit can access this variable in read or write. It is considered a //local// variable, since it is declared for a scope that is satisfied within that unit. It is possible for another unit to contain the declaration of a variable with the same name. In fact there is no chance of confusion because when the // | ||
| + | |||
| + | ===== - IN/ | ||
| + | |||
| + | If certain attributes are added to the declaration of a variable an interface can be created towards the outside of the task unit containing the declaration. The attributes: | ||
| + | |||
| + | * IN | ||
| + | * OUT | ||
| + | * INOUT | ||
| + | |||
| + | To illustrate this possibility, | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | InputVariable | ||
| + | OutputVariable | ||
| + | InOutVariable | ||
| + | | ||
| + | local_variable | ||
| + | BEGIN | ||
| + | ... ;Here are the lines code | ||
| + | </ | ||
| + | |||
| + | thereby obtaining a unit interface towards the other task units. \\ | ||
| + | ==== - IN ==== | ||
| + | The unit sees the // | ||
| + | |||
| + | {{: | ||
| + | |||
| + | As shown in the figure, the other task units (Unit2) can access it if they specify which unit the variable belongs to: | ||
| + | |||
| + | <code QCL> | ||
| + | Unit1.InputVariable = 1 | ||
| + | </ | ||
| + | |||
| + | In this way several task units can have the same variables with IN properties. Confusion cannot exist because each variable belongs to units with different names. | ||
| + | |||
| + | ==== - OUT ==== | ||
| + | The // | ||
| + | |||
| + | {{: | ||
| + | |||
| + | As shown in the figure, the other task units (Unit2) can only use the value of the // | ||
| + | |||
| + | <code QCL> | ||
| + | IF Unit1.OutputVariable | ||
| + | ... | ||
| + | ENDIF | ||
| + | </ | ||
| + | ==== - INOUT ==== | ||
| + | The // | ||
| + | |||
| + | {{: | ||
| + | |||
| + | Even in this case the other task units (Unit2) can use the Unit1 variable by specifying its name before the unit name it belongs to : | ||
| + | |||
| + | <code QCL> | ||
| + | IF Unit1.OutputVariable EQ 0 | ||
| + | Unit1.OutputVariable = 1 | ||
| + | ... | ||
| + | ENDIF | ||
| + | </ | ||
| + | ===== - APPLICATION ===== | ||
| + | As said, this is the full name to identify variables declared in the configuration unit: | ||
| + | |||
| + | <code QCL> | ||
| + | APPLICATION.< | ||
| + | </ | ||
| + | |||
| + | Use the // | ||
| + | This is why the name | ||
| + | |||
| + | <code QCL> | ||
| + | APPLICATION.HomePosition | ||
| + | </ | ||
| + | |||
| + | and | ||
| + | |||
| + | <code QCL> | ||
| + | Unit1.HomePosition | ||
| + | </ | ||
| + | |||
| + | depend on which it refers to. | ||
| + | |||
| + | ====== - REFERENCE ====== | ||
| + | A different attribute that can be assigned to a symbol in the declaration is REFERENCE. In this case the symbol declared as REFERENCE is simply a reference to a variable declared in another point (typically in the configuration unit). There are two stages in the declaration of these special symbols: | ||
| + | |||
| + | - declaration in the task unit where it is used | ||
| + | - declaration in the configuration unit (in the REFERENCES section) defining the reference variable. | ||
| + | |||
| + | Example: | ||
| + | |||
| + | In Unit1 | ||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | MachineState | ||
| + | </ | ||
| + | |||
| + | In the Configuration unit | ||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | GeneralState | ||
| + | ... | ||
| + | REFERENCES | ||
| + | Unit1.MachineState | ||
| + | </ | ||
| + | |||
| + | The // | ||
| + | |||
| + | ^The declaration of INTDEVICE, INPUT, OUTPUT can only be made as REFERENCE.^ | ||
| + | |||
| + | ====== - COSTANTS ====== | ||
| + | Constants can also be declared in the task unit containing the code. | ||
| + | Example of this kind of declaration in Unit1: | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | MAX_PROGRAM_NUMBER | ||
| + | ... | ||
| + | BEGIN | ||
| + | ... | ||
| + | </ | ||
| + | |||
| + | the // | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | MAX_PROGRAM_NUMBER | ||
| + | ... | ||
| + | BEGIN | ||
| + | ... | ||
| + | </ | ||
| + | |||
| + | the scope of the // | ||
| + | |||
| + | <code QCL> | ||
| + | Unit1.MAX_PROGRAM_NUMBER | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - QCL Instructions ====== | ||
| + | |||
| + | QCL (QEM Control Language) has been conceived specifically for programming the QMOVE system. The QCL salient features are simplicity (i.e. few powerful instructions), | ||
| + | |||
| + | ===== - QCL operators ===== | ||
| + | The QCL language offers all elementary data processing operators. | ||
| + | |||
| + | ==== - Assignment ==== | ||
| + | The assignment operator can be used in any expression and can act on all variables, both elementary and belonging to DataGroups or Device | ||
| + | parameters. The typical form of an assignment instruction :\\ | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | If the size of the //variable name// variable is less than the result of the expression, the value is rounded down according to the type conversion rules (see appendix). | ||
| + | |||
| + | ==== - Arithmetic operators ==== | ||
| + | |||
| + | The arithmetic operators: | ||
| + | |||
| + | * add (+), | ||
| + | * subtract (-), | ||
| + | * multiply (*), | ||
| + | * divide (/), | ||
| + | * division remainder (%). | ||
| + | |||
| + | These operators act on all data types and their combinations (including bit).\\ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | sbVar01 = slVar02 + swVar03 | ||
| + | slVarxy = glVarA * glVarB | ||
| + | sl01 = ss02 % ss03 | ||
| + | </ | ||
| + | |||
| + | ==== - Logic operators ==== | ||
| + | The logic operators (i.e. AND, OR and NOT) can act on all variables except single precision type. Their function is summarised in the table below. | ||
| + | ^Value 1 simply indicates that the variable is different to 0.^ | ||
| + | |||
| + | |a b|a AND b|a OR b|NOT a| | ||
| + | |0 0| 0 | 0 | 1 | | ||
| + | |0 1| 0 | 1 | 1 | | ||
| + | |1 0| 0 | 1 | 0 | | ||
| + | |1 1| 1 | 1 | 0 | | ||
| + | |||
| + | Examples | ||
| + | <code QCL> | ||
| + | glBit01 = glBit02 AND gfBit03 | ||
| + | glBitA = NOT glBitB | ||
| + | </ | ||
| + | |||
| + | ==== - Binary operators ==== | ||
| + | The binary operators | ||
| + | |||
| + | * ANDB, | ||
| + | * ORB, | ||
| + | * NOTB, | ||
| + | * XORB | ||
| + | |||
| + | act on all variables including SINGLE ( after automatic conversion to whole numbers). These operators create the same t/f table that governs the equivalent logic operations, except they act on the single bits. | ||
| + | |||
| + | |(a)< | ||
| + | | 3 | 2 | 011 | 010 | 010 | 011 | 100 | 001 | | ||
| + | | 7 | 5 | 111 | 101 | 101 | 111 | 000 | 010 | | ||
| + | |||
| + | Example | ||
| + | <code QCL> | ||
| + | swVar01 = gwVar02 ANDB gwVar03 | ||
| + | </ | ||
| + | |||
| + | ==== - Relational operators ==== | ||
| + | Relational operators ascertain relations between values: | ||
| + | |EQ|equal to| | ||
| + | |NEQ|not equal to| | ||
| + | |LT|lower than| | ||
| + | |LE|lower or equal)| | ||
| + | |GT|greater than| | ||
| + | |GE|greater or equal| | ||
| + | |||
| + | Example | ||
| + | <code QCL> | ||
| + | gfBit01 = glCont GE glAsse01 | ||
| + | </ | ||
| + | |||
| + | ==== - Operator Priority | ||
| + | Round brackets " | ||
| + | Example | ||
| + | AA = [(A + B)/C] - (D x E) | ||
| + | <code QCL> | ||
| + | gwVarAA = ((gwVarA + gwVarB) / glVarC) - (swVarD * glVarE) | ||
| + | </ | ||
| + | |||
| + | ==== - QCL Operator Priority Levels | ||
| + | The priority of QCL operators is the same as all programming languages: | ||
| + | |||
| + | ^ Top priority | ||
| + | | ( ) | | ||
| + | | Math functions and \\ Trigonometric functions | | ||
| + | | NEG NOT NOTB | | ||
| + | | * / % | | ||
| + | | + - | | ||
| + | | LT GT LE GE | | ||
| + | | EQ | | ||
| + | | AND ANDB | | ||
| + | | OR ORB XORB | | ||
| + | | = | | ||
| + | ^ Bottom priority | ||
| + | |||
| + | ===== - Instructions and flow control structures ===== | ||
| + | All the instructions that modify the execution flow. | ||
| + | |||
| + | ==== - IF / ELSE / ENDIF ==== | ||
| + | A typical conditional, | ||
| + | The syntax: | ||
| + | <code QCL> | ||
| + | IF < | ||
| + | < | ||
| + | [ELSE | ||
| + | < | ||
| + | ENDIF | ||
| + | </ | ||
| + | |||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | IF tTime ;If timer has expired | ||
| + | tTime = TM_SECOND | ||
| + | count = count + 1 ; | ||
| + | ENDIF | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | Example of nested IF loop.\\ | ||
| + | Change the example above as follows: | ||
| + | |||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | IF tSecond | ||
| + | tSecond = TM_SECOND | ||
| + | IF sbSeconds LT 59 ;If the sbSeconds variable is less than 59 | ||
| + | sbSeconds = sbSeconds + 1 ; | ||
| + | ELSE ;else (if the seconds are greater than 59) | ||
| + | sbSeconds = 0 ; | ||
| + | IF sbMinutes LT 59 ;If the sbMinutes variable is less than 59 | ||
| + | sbMinutes = sbMinutes + 1 ;increase the minutes counter | ||
| + | ELSE ;else (if the minutes are greater than 59) | ||
| + | sbMinutes = 0 ;reset the minutes | ||
| + | IF swHours LT 167 ;If the swHours variable is less than 167 | ||
| + | swHours = swHours + 1 ; | ||
| + | ELSE ;else (if the hours is greater than 167) | ||
| + | swHours = 0 ; | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | This creates a system clock with three system variables: one for seconds, one for minutes and one for hours. A byte type variable is used for the seconds and minutes since they never leave the range [-128, 127], while the swHours variable uses a Word type variable since it can | ||
| + | reach 167, remaining within the range [-32768, 32767], being the hours in a week. | ||
| + | |||
| + | ==== - FOR-NEXT ==== | ||
| + | An iterative loop normally used to perform an instruction block or single instruction, | ||
| + | |||
| + | <code QCL> | ||
| + | FOR (< | ||
| + | < code lines > | ||
| + | NEXT | ||
| + | </ | ||
| + | |||
| + | where: | ||
| + | |< | ||
| + | |< | ||
| + | |< | ||
| + | |||
| + | Example: | ||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | FOR(gbYourByte = 1, gbYourByte LE 10, 1) ;For gbYourByte from 1 to 10 | ||
| + | arwMyArray[gbYourByte] = POW(3, gbYourByte) ;the element arwMyArray[gbYourByte] gets the value 3^gbYourByte, | ||
| + | dswStat2[gbYourByte] = 1 ;assign the value 1 to the static variable, | ||
| + | ddbDin1[gbYourByte, | ||
| + | NEXT | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | The FOR-NEXT loop fills the array global // | ||
| + | |||
| + | ==== - WHILE-ENDWHILE ==== | ||
| + | An iterative loop used to perform an instruction or instruction block until a given condition is found.\\ | ||
| + | Exit the WHILE-ENDWHILE loop before it becomes false by using the BREAK instruction, | ||
| + | |||
| + | <code QCL> | ||
| + | WHILE (< | ||
| + | < code lines > | ||
| + | ENDWHILE | ||
| + | </ | ||
| + | |||
| + | where: | ||
| + | |< | ||
| + | |||
| + | Example: | ||
| + | ^These two loops are made to set the value of the sbMinutes and swHours variables keeping two different inputs activated, the ifSetUpMin and ifSetUpHours inputs. It can be seen that tdelay, a delay time has been inserted in each WHILE instruction to slow down the increase in the variable and provide a way to disable the input when the variable reaches the required value. Of course the value assigned to minutes or hours is limited so an IF is added in the WHILE loop to control this limit. The //WAIT 1// instruction is explained below.^ | ||
| + | |||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | |||
| + | WHILE (ifSetUpHours) | ||
| + | IF tDelay | ||
| + | tDelay = 500 ; | ||
| + | swHours = swHours + 1 ;increase the hours counter. | ||
| + | IF swHours GE 168 ;If the hours are greater than 167 (greater or equal to 168) | ||
| + | swHours = 0 ;reset the hours counter. | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | WAIT 1 | ||
| + | ENDWHILE | ||
| + | |||
| + | WHILE (ifSetUpMinutes) | ||
| + | IF tDelay | ||
| + | tDelay = 500 ; | ||
| + | sbMinutes = sbMinutes + 1 ;increase the minutes counter. | ||
| + | IF sbMinutes GE 60 ;If the minutes are greater than 59 (greater or equal to 60) | ||
| + | sbMinutes = 0 ;reset the minutes counter. | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | WAIT 1 | ||
| + | ENDWHILE | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | ==== - SWITCH-ENDSWITCH ==== | ||
| + | QView 6 has the SWITCH instruction, | ||
| + | |||
| + | <code QCL> | ||
| + | SWITCH(< | ||
| + | CASE <value 1> | ||
| + | < lines code for value 1> | ||
| + | CASE <value 2> | ||
| + | < lines code for values between value 2 and value 3> [;comments] | ||
| + | CASE <value 4>, <value 5> | ||
| + | < lines code for value 4 and for values between value 2 and value 3> [; | ||
| + | [DEFAULT | ||
| + | < lines code for default> | ||
| + | | ||
| + | ENDSWITCH | ||
| + | </ | ||
| + | |||
| + | A typical example of a temperature control measured by a sensor that writes its value in the // | ||
| + | |||
| + | <code QCL> | ||
| + | SWITCH(Temperature) | ||
| + | CASE 0 | ||
| + | CloseDoor = 1 | ||
| + | WarmUp = 100 | ||
| + | IceAlarm = 1 | ||
| + | OutOfRange = 0 | ||
| + | CASE 1..10 | ||
| + | CloseDoor = 1 | ||
| + | WarmUp = 50 | ||
| + | IceAlarm = 0 | ||
| + | OutOfRange = 0 | ||
| + | CASE 11..15 | ||
| + | CloseDoor = 1 | ||
| + | WarmUp = 15 | ||
| + | IceAlarm = 0 | ||
| + | OutOfRange = 0 | ||
| + | CASE 16..25 | ||
| + | CloseDoor = 0 | ||
| + | WarmUp = 0 | ||
| + | IceAlarm = 0 | ||
| + | OutOfRange = 0 | ||
| + | DEFAULT | ||
| + | OutOfRange = 1 | ||
| + | ENDSWITCH | ||
| + | </ | ||
| + | |||
| + | ==== - WAIT ==== | ||
| + | Wait for a condition or an event. The WAIT instruction is very important when it is executed and the < | ||
| + | <code QCL> | ||
| + | WAIT < | ||
| + | </ | ||
| + | |||
| + | ==== - JUMP ==== | ||
| + | An unconditional jump to the instruction at the specified label. The syntax: | ||
| + | <code QCL> | ||
| + | JUMP < | ||
| + | </ | ||
| + | Example\\ | ||
| + | The classic example of a JUMP instruction is where it is repeated in each task to jump from the end to start of the code, i.e. from the MAIN label. | ||
| + | |||
| + | This flow control instruction can be also used in other points of the task unit. JUMP is an unconditional jump that can be made conditional with | ||
| + | |||
| + | an IF to deviate the code flow under specific conditions. | ||
| + | |||
| + | ==== - LABELS ==== | ||
| + | Labels locate given points in the sequence of instructions in an application. They are used to change the execution flow of instructions (the QCL JUMP command). When a label is inserted in the instructions it must be followed by a colon ":", | ||
| + | Example of an unconditional jump | ||
| + | <code QCL> | ||
| + | Label1: | ||
| + | < code line > | ||
| + | < code line > | ||
| + | ; | ||
| + | JUMP Label1 | ||
| + | </ | ||
| + | |||
| + | Example of conditional jump | ||
| + | <code QCL> | ||
| + | Label1: | ||
| + | < code line > | ||
| + | IF < | ||
| + | JUMP Label1 | ||
| + | ENDIF | ||
| + | </ | ||
| + | ==== - SUBROUTINE ==== | ||
| + | When a part of the code is repeated several times in the same unit, it is useful to define a subroutine. The subroutine code is executed every time a subroutine call instruction is found (CALL). The subroutine is identified by a name after the SUB keyword and must end with the ENDSUB keyword. See also the CALL instruction.\\ To stop a subroutine before the end use the keyword RETURN. | ||
| + | |||
| + | ==== - CALL ==== | ||
| + | Call to Subroutine: an unconditional jump to the first instruction in the named subroutine. At the end of the subroutine (identified by ENDSUB) the program flow continues from the instruction following the CALL. | ||
| + | <code QCL> | ||
| + | CALL < | ||
| + | </ | ||
| + | |||
| + | |||
| + | ^These code lines are placed after the END keyword, i.e. after the end of the application unit.^ | ||
| + | A subroutine is introduced to calculate the length of a diagonal of a square, given the length of a side. | ||
| + | |||
| + | Example of subroutine call: | ||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | |||
| + | glOurLong = 4 ;This is the square edge | ||
| + | CALL CALC_DIAG | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | |||
| + | ; | ||
| + | SUB CALC_DIAG | ||
| + | gsYourSing = SQRT(2 * POW(glOurlong, | ||
| + | ENDSUB | ||
| + | </ | ||
| + | |||
| + | ==== - NOP ==== | ||
| + | No operation: this instruction has no effect on the program and is used to introduce delays. | ||
| + | |||
| + | ===== - Instructions for digital outputs ===== | ||
| + | Instructions for activating or deactivating a digital output. The activation and deactivation can also be executed by the assignment operator | ||
| + | |||
| + | (<output name>= 1), however dedicated instructions are faster. | ||
| + | |||
| + | ==== - SETOUT ==== | ||
| + | Activate a digital output. The syntax: | ||
| + | <code QCL> | ||
| + | SETOUT <output name> | ||
| + | </ | ||
| + | |||
| + | ==== - RESOUT ==== | ||
| + | Deactivate a digital output. The syntax: | ||
| + | <code QCL> | ||
| + | RESOUT <output name> | ||
| + | </ | ||
| + | |||
| + | |||
| + | ^The ofOutput1 output is activated by the SETOUT command when the sbSeconds variable value is 20 only if the ifEnableO1 input is | ||
| + | activated. This output is then reset when the sbSeconds value is 40.^ | ||
| + | An example can be introduced where an output status changes status according to the value of a variable: | ||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | IF (sbSeconds EQ 20) AND ifEnableO1 | ||
| + | SETOUT ofOutput1 | ||
| + | ENDIF | ||
| + | IF sbSeconds EQ 40 ;When the sbSeconds is equal to 40 | ||
| + | RESOUT ofOutput1 | ||
| + | ENDIF | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | ===== - System Instructions ===== | ||
| + | Instructions that allow to control unit execution | ||
| + | |||
| + | after consulting Multitasking. | ||
| + | |||
| + | ==== - SUSPEND ==== | ||
| + | A suspension in the execution of the specified task unit .\\ | ||
| + | This instruction can be used by a unit to block the execution of another unit or to block the execution of itself. In this case, since the unit in question is suspended, it can no longer be reactivated but this must be done by one of the other units in execution. The Syntax: | ||
| + | <code QCL> | ||
| + | <unit name> | ||
| + | </ | ||
| + | |||
| + | ==== - RESUME ==== | ||
| + | Restore the execution of an instruction in a suspended unit. | ||
| + | This instruction restores execution of a suspended unit from the next instruction following the one executed at the moment of suspension. The syntax:\\ | ||
| + | <code QCL> | ||
| + | <unit name> | ||
| + | </ | ||
| + | RESUME is only effective if the unit <unit name> was suspended. | ||
| + | |||
| + | ==== - RESTART ==== | ||
| + | " | ||
| + | This instruction does not alter the suspended status of the unit in question, which means that if a suspended unit is given a RESTART, it | ||
| + | prepares for the execution of the first instruction but remains suspended until it is activated by the RESUME instruction. The syntax: | ||
| + | <code QCL> | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | To best understand the meaning of these system instructions see “Multitasking”. | ||
| + | ===== - System Variables ===== | ||
| + | The QMOVE system provides variables related to the internal operating system and these variables have pre-set names, i.e. they cannot be | ||
| + | changed by the user. | ||
| + | |||
| + | ==== - is_suspended ==== | ||
| + | Gives the status of a unit: | ||
| + | |||
| + | * 0 = unit in execution | ||
| + | * 1 = unit suspended | ||
| + | |||
| + | The syntax: | ||
| + | <code QCL> | ||
| + | <unit name> | ||
| + | </ | ||
| + | |||
| + | ==== - w_dog_task ==== | ||
| + | //Watchdog task// indicates the execution time of that unit is over 200 ms. The same information appears in the //Monitor - CPU// panel under //Watchdog Task//. | ||
| + | The syntax: | ||
| + | <code QCL> | ||
| + | <unit name> | ||
| + | </ | ||
| + | |||
| + | ==== - time_task_lost ==== | ||
| + | Indicates that the time unit has missed an event. The same information is given in the //Monitor - CPU// panel under //Time task Lost//. A time unit must be executed at preset times. These times may not be respected because of the load of executing the code in the unit. If this happens it is known as a //Time task lost// for a given unit.\\ | ||
| + | The syntax:\\ | ||
| + | <code QCL> | ||
| + | <unit name> | ||
| + | </ | ||
| + | |||
| + | ==== - battery_low ==== | ||
| + | The battery charge is low and the BATT led blinks. This only refers to QMOVE models mounting a backup battery for the RAM memory.\\ | ||
| + | The syntax: | ||
| + | <code QCL> | ||
| + | QMOVE.battery_low | ||
| + | </ | ||
| + | |||
| + | ==== - battery_down ==== | ||
| + | The battery is flat and the BATT led is on. This only refers to QMOVE models mounting a backup battery for the RAM memory.\\ | ||
| + | The syntax: | ||
| + | <code QCL> | ||
| + | QMOVE.battery_down | ||
| + | </ | ||
| + | |||
| + | Other variables depend on the CPU firmware. To access these variables use the syntax:\\ | ||
| + | <code QCL> | ||
| + | QMOVE.sys001 | ||
| + | QMOVE.sys002 | ||
| + | ;... | ||
| + | QMOVE.sys016 | ||
| + | </ | ||
| + | For details on these variables consult the hardware documentation. | ||
| + | |||
| + | |||
| + | |||
| + | ===== - Math Functions ===== | ||
| + | |||
| + | ==== - Exponentiation ==== | ||
| + | Exponentiation of the base. The syntax:\\ | ||
| + | <code QCL> | ||
| + | POW(< | ||
| + | </ | ||
| + | Example: gsMaxVal = 2< | ||
| + | <code QCL> | ||
| + | gsMaxVal = POW(2, | ||
| + | </ | ||
| + | |||
| + | ==== - Square root ==== | ||
| + | Calculation of the square root of the argument. The syntax:\\ | ||
| + | <code QCL> | ||
| + | SQRT(< | ||
| + | </ | ||
| + | Example: gsIpot = v(gsL1< | ||
| + | <code QCL> | ||
| + | gsIpot = SQRT(POW(gsL1, | ||
| + | </ | ||
| + | |||
| + | ==== - Natural Logarithm ==== | ||
| + | Calculation of the natural logarithm of the argument. The syntax:\\ | ||
| + | <code QCL> | ||
| + | LN(< | ||
| + | </ | ||
| + | Example: gsValue = ln gsMaximum | ||
| + | <code QCL> | ||
| + | gsValue = LN(gsMaximun) | ||
| + | </ | ||
| + | |||
| + | ==== - Exponential ==== | ||
| + | The exponentiation of the Nepero number. The syntax: | ||
| + | <code QCL> | ||
| + | EXP(< | ||
| + | </ | ||
| + | Example: gsA = e< | ||
| + | <code QCL> | ||
| + | gsA =EXP(2) | ||
| + | </ | ||
| + | |||
| + | ==== - Absolute value ==== | ||
| + | The absolute value of the argument. The syntax:\\ | ||
| + | <code QCL> | ||
| + | ABS(< | ||
| + | </ | ||
| + | Example: glModule = I glValue I | ||
| + | <code QCL> | ||
| + | glModule = ABS(glValue) | ||
| + | </ | ||
| + | |||
| + | ==== - Shift logical left ==== | ||
| + | Logic shifts the contents of var value to the left by //n// bits. \\ {{: | ||
| + | <code QCL> | ||
| + | SHLL(< | ||
| + | </ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | glValue = SHLL(glValue, | ||
| + | </ | ||
| + | |||
| + | ==== - Right logical left ==== | ||
| + | Logic shifts the contents of var value to the right by //n// bits. \\ {{: | ||
| + | <code QCL> | ||
| + | SHLR(< | ||
| + | </ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | glValue = SHLR(glValue, | ||
| + | </ | ||
| + | ==== - Multiplication and division ==== | ||
| + | Perform a 32 bit integer values multiplication with 64 bit result and a successive division by 32 bit integer value. Result is a 32 bit value.\\ **N.B.** If a division by zero occur, CPU state will set to " | ||
| + | <code QCL> | ||
| + | MULDIV(< | ||
| + | </ | ||
| + | Example: glValue = a * b / c | ||
| + | <code QCL> | ||
| + | glValue = MULDIV(a, b, c) | ||
| + | </ | ||
| + | |||
| + | ==== - Remainder of multiplication and division ==== | ||
| + | Perform a 32 bit integer values multiplication with 64 bit result and a successive division by 32 bit integer value. Result is the division remainder.\\ **N.B.** If a division by zero occur, CPU state will set to " | ||
| + | <code QCL> | ||
| + | RMULDIV(< | ||
| + | </ | ||
| + | Example: glValue = a * b % c | ||
| + | <code QCL> | ||
| + | glValue = RMULDIV(a, b, c) | ||
| + | </ | ||
| + | |||
| + | ==== - Nearest integer rounding ==== | ||
| + | |ROUND|Rounds to nearest integer, rounding away from zero in halfway cases.| | ||
| + | |TRUNC|Rounds to nearest integer not greater in magnitude than the given value.| | ||
| + | |FLOOR|Computes largest integer not greater than the given value.| | ||
| + | |CEIL|Computes smallest integer not less than the given value.| | ||
| + | The syntax:\\ | ||
| + | <code QCL> | ||
| + | ROUND(< | ||
| + | TRUNC(< | ||
| + | FLOOR(< | ||
| + | CEIL(< | ||
| + | </ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | gsValue = ROUND(2.7) | ||
| + | gsValue = ROUND(-2.7) | ||
| + | gsValue = TRUNC(2.7) | ||
| + | gsValue = TRUNC(-2.7) | ||
| + | gsValue = FLOOR(2.7) | ||
| + | gsValue = FLOOR(-2.7) | ||
| + | gsValue = CEIL(2.7) | ||
| + | gsValue = CEIL(-2.7) | ||
| + | </ | ||
| + | |||
| + | ==== - Classification operators ==== | ||
| + | |ISFINITE|Checks if the given number has finite value.| | ||
| + | |ISINF|Checks if the given number is infinite.| | ||
| + | |ISNAN|Checks if the given number is NaN.| | ||
| + | |ISNORMAL|Checks if the given number is normal.| | ||
| + | Syntax:\\ | ||
| + | <code QCL> | ||
| + | ISFINITE(< | ||
| + | ISINF(< | ||
| + | ISNAN(< | ||
| + | ISNORMAL(< | ||
| + | </ | ||
| + | Example: | ||
| + | <code QCL> | ||
| + | gfValue = ISFINITE(gsValue) | ||
| + | gfValue = ISINF(gsValue) | ||
| + | gfValue = ISNAN(gsValue) | ||
| + | gfValue = ISNORMAL(gsValue) | ||
| + | </ | ||
| + | ===== - Trigonometry Functions ===== | ||
| + | |||
| + | ==== - Sine ==== | ||
| + | Calculation of the sine of an angle expressed in radians. The syntax:\\ | ||
| + | <code QCL> | ||
| + | SIN(< | ||
| + | </ | ||
| + | Example: gsYPos = ssRadius x SIN gsalpha | ||
| + | <code QCL> | ||
| + | gsYPos = ssRadius * SIN(gsalpha) | ||
| + | </ | ||
| + | |||
| + | ==== - Cosine ==== | ||
| + | Calculation of the cosine of an angle expressed in radians. The syntax:\\ | ||
| + | <code QCL> | ||
| + | COS(< | ||
| + | </ | ||
| + | Example: gsXPos = ssRadius x COS gsalpha | ||
| + | <code QCL> | ||
| + | gsXPos = ssRadius * COS(gsalpha) | ||
| + | </ | ||
| + | |||
| + | ==== - Tangent ==== | ||
| + | Calculation of the tangent of an angle expressed in radians. The syntax:\\ | ||
| + | <code QCL> | ||
| + | TAN(< | ||
| + | </ | ||
| + | Example: gsMyVal = TAN gsalpha | ||
| + | <code QCL> | ||
| + | gsMyVal = TAN(gsalpha) | ||
| + | </ | ||
| + | |||
| + | ==== - Cotangent ==== | ||
| + | Calculation of the cotangent of an angle expressed in radians. The syntax: | ||
| + | <code QCL> | ||
| + | COT(< | ||
| + | </ | ||
| + | Example: gsMyVal = COT gsalpha | ||
| + | <code QCL> | ||
| + | gsMyVal = COTG(gsalpha) | ||
| + | </ | ||
| + | |||
| + | ==== - Arcsine ==== | ||
| + | Calculation of an angle, expressed in radians, where the sine is equal to the argument. The syntax: | ||
| + | <code QCL> | ||
| + | ASIN(< | ||
| + | </ | ||
| + | Example: gsAngle = ASIN Arc | ||
| + | <code QCL> | ||
| + | | ||
| + | </ | ||
| + | |||
| + | ==== - Arcosine ==== | ||
| + | Calculation of an angle, expressed in radians, where the cosine is equal to the argument. The syntax: | ||
| + | <code QCL> | ||
| + | ACOS(< | ||
| + | </ | ||
| + | Example: gsAngle = ACOS Arc | ||
| + | <code QCL> | ||
| + | gsAngle = ACOS(Arc) | ||
| + | </ | ||
| + | |||
| + | ==== - Arctangent ==== | ||
| + | Calculation of an angle, expressed in radians, where the tangent is equal to the argument. The syntax: | ||
| + | <code QCL> | ||
| + | ATAN(arc) | ||
| + | </ | ||
| + | Example: gsMyVal = ATAN Arc | ||
| + | <code QCL> | ||
| + | gsMyVal = ATAN(Arc) | ||
| + | </ | ||
| + | |||
| + | ==== - Caution ==== | ||
| + | In trigonometry functions the angles are normally expressed in radians. Since p is an irrational number (not finite) and since it is represented with a precision of 7 decimal points, this introduces an approximation in trigonometric calculations.\\ | ||
| + | Another limit is with trigonometric calculations that give the result as an infinite number, which cannot be represented by a single precision floating point number (7 digit). For example the result of the tangent of p/2 is an enormous number in negative, which is not infinite and so incorrect. | ||
| + | |||
| + | Example: | ||
| + | tang p/2 = tang 1.570796371 = -22877332 ;\\ | ||
| + | arctg -22877332 = -1.570796371 = - p/2 (!!) | ||
| + | |||
| + | The tangent of p/2 cannot be calculated by the equation:\\ | ||
| + | tang p/2 = (sin p/2) / (cos p/2)\\ | ||
| + | since it has a division by zero. | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Demo Application ====== | ||
| + | The development of this application implements the information illustrated in this manual. \\ | ||
| + | The project includes: | ||
| + | * a unit for the machine state management | ||
| + | * a unit to create a sequencer | ||
| + | * a unit to detect digital inputs and activate digital outputs. | ||
| + | |||
| + | ===== - New Project ===== | ||
| + | Create a new project with | ||
| + | |||
| + | * File - New Project | ||
| + | |||
| + | enter the //Project Name// as // | ||
| + | |||
| + | ===== - Add the configuration unit ===== | ||
| + | Select | ||
| + | |||
| + | * File - Add Unit - Configuration Unit | ||
| + | |||
| + | and name it CONFIG. The unit will be precompiled with all the keywords that distinguish the various variable groups. At this stage it is essential | ||
| + | |||
| + | to declare the hardware that is going to be used in the configuration unit.\\ | ||
| + | The demo uses | ||
| + | <code QCL> | ||
| + | ... | ||
| + | BUS | ||
| + | 1 1P51F 30 | ||
| + | 2 . . | ||
| + | 3 1MG8F . | ||
| + | </ | ||
| + | |||
| + | Nothing else is declared in the configuration unit. | ||
| + | |||
| + | ===== - Add the QCL task units ===== | ||
| + | ==== - MANAGER Unit ==== | ||
| + | Select | ||
| + | |||
| + | * File - Add Unit - Qcl Unit | ||
| + | |||
| + | and name it // | ||
| + | |||
| + | <code QCL> | ||
| + | MAIN: | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | The //MANAGER// unit manages the machine states shown in the diagram below: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | The //MANAGER// unit code lines will manage the state transitions and supply information (e.g. the current state).\\ | ||
| + | Declare the following variables in the //MANAGER// unit: | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | ALARM_STATE | ||
| + | MANUAL_STATE | ||
| + | AUTOMATIC_STATE | ||
| + | | ||
| + | GLOBAL | ||
| + | NewState | ||
| + | State | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | Now add the following code: | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | ALARM_STATE | ||
| + | MANUAL_STATE | ||
| + | AUTOMATIC_STATE | ||
| + | | ||
| + | GLOBAL | ||
| + | NewState | ||
| + | State | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | SWITCH State | ||
| + | CASE ALARM_STATE | ||
| + | ;Put the code to do when the state is ALARM | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code to do when the state is MANUAL | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code to do when the state is AUTOMATIC | ||
| + | ENDSWITCH | ||
| + | | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | The //State// variable is considered an OUT for this unit. If another unit wants to change machine state it cannot act directly on //State// because | ||
| + | |||
| + | only the //MANAGER// unit can change it. So a variabile // | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | ALARM_STATE | ||
| + | MANUAL_STATE | ||
| + | AUTOMATIC_STATE | ||
| + | | ||
| + | GLOBAL | ||
| + | NewState | ||
| + | State | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | SWITCH State | ||
| + | CASE ALARM_STATE | ||
| + | ;Put here the code to do when the state is ALARM | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code to do when the state is MANUAL | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code to do when the state is AUTOMATIC | ||
| + | ENDSWITCH | ||
| + | | ||
| + | ;Check if there is a state transition request | ||
| + | IF State NEQ NewState | ||
| + | SWITCH NewState | ||
| + | CASE ALARM_STATE | ||
| + | | ||
| + | SWITCH State | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code for MANUAL to ALARM trasition | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code for AUTO to ALARM transition | ||
| + | ENDSWITCH | ||
| + | | ||
| + | CASE MANUAL_STATE | ||
| + | |||
| + | SWITCH State | ||
| + | CASE ALARM_STATE | ||
| + | ;Put here the code for ALARM to MANUAL transition | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code for AUTO to MANUAL transition | ||
| + | ENDSWITCH | ||
| + | |||
| + | CASE AUTOMATIC_STATE | ||
| + | |||
| + | SWITCH State | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code for MANUAL to AUTO transition | ||
| + | ENDSWITCH | ||
| + | | ||
| + | ENDSWITCH | ||
| + | | ||
| + | State = NewState | ||
| + | | ||
| + | ENDIF | ||
| + | | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | It can be seen that, when // | ||
| + | |||
| + | the end of the transition, the machine state is conclusively set to the new status.\\ | ||
| + | So any unit that wants to use the MANAGER unit must use this kind of code: | ||
| + | |||
| + | <code QCL> | ||
| + | MANAGER.NewState = MANAGER.AUTOMATIC_STATE | ||
| + | WAIT MANAGER.State EQ MANAGER.NewState | ||
| + | </ | ||
| + | |||
| + | To command the state transition. | ||
| + | |||
| + | ==== - SEQUENC Unit ==== | ||
| + | Add another unit with the same properties as //MANAGER// and name it // | ||
| + | To obtain a sequence write the following code: | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | Start | ||
| + | Sequence | ||
| + | | ||
| + | start_rise_up | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | IF Start | ||
| + | IF start_rise_up | ||
| + | start_rise_up = 0 | ||
| + | Sequence = 10 ;Start the sequence | ||
| + | ENDIF | ||
| + | ELSE | ||
| + | start_rise_up = 1 | ||
| + | Sequence = 0 ; | ||
| + | ENDIF | ||
| + | | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | | ||
| + | </ | ||
| + | |||
| + | It can be seen that, when the //Start// IN variable is 0 (FALSE), the // | ||
| + | Now add the code lines to use the // | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | OFF 0 | ||
| + | ON 1 | ||
| + | | ||
| + | GLOBAL | ||
| + | Start | ||
| + | Force | ||
| + | Sequence | ||
| + | Signal | ||
| + | | ||
| + | start_rise_up | ||
| + | |||
| + | TIMER | ||
| + | time_on | ||
| + | time_off | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | IF Start | ||
| + | IF start_rise_up | ||
| + | start_rise_up = 0 | ||
| + | Sequence = 10 ;Start the sequence | ||
| + | ENDIF | ||
| + | ELSE | ||
| + | start_rise_up = 1 | ||
| + | Sequence = 0 ; | ||
| + | Signal = Force ; | ||
| + | ENDIF | ||
| + | | ||
| + | ;This is the sequence management | ||
| + | IF Sequence EQ 10 ;First step | ||
| + | Signal = OFF ; | ||
| + | time_off = 1000 ;1000 ms = 1 s | ||
| + | Sequence = 20 | ||
| + | ENDIF | ||
| + | IF Sequence EQ 20 ;Second step | ||
| + | IF time_off | ||
| + | Sequence = 30 | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | IF Sequence EQ 30 ;3rd step | ||
| + | Signal = ON ;Set signal | ||
| + | time_on = 500 ;500 ms = 0.5 s | ||
| + | Sequence = 40 | ||
| + | ENDIF | ||
| + | IF Sequence EQ 40 ;4th step | ||
| + | IF time_on | ||
| + | Sequence = 50 | ||
| + | ENDIF | ||
| + | ENDIF | ||
| + | IF Sequence EQ 50 ;5th step | ||
| + | Sequence = 10 | ||
| + | ENDIF | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | | ||
| + | </ | ||
| + | |||
| + | When the // | ||
| + | |||
| + | <code QCL> | ||
| + | IF Sequence EQ 10 | ||
| + | ... | ||
| + | </ | ||
| + | |||
| + | that changes it to 20 and so forth executing the sequence step by step. The sequence sets the //Signal// variable to OFF for 1s and then to ON for | ||
| + | |||
| + | 0.5s and the sequence is repeated infinitely, so long as //Start// is TRUE). | ||
| + | |||
| + | ==== - COMMAND Unit ==== | ||
| + | Add the COMMAND unit and enter the following code: | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | ForceOutput | ||
| + | | ||
| + | INPUT | ||
| + | Selector | ||
| + | Enable | ||
| + | ManualButton | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | Three // | ||
| + | |||
| + | added to the configuration unit. Now add the following code: | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | ForceOutput | ||
| + | | ||
| + | INPUT | ||
| + | Selector | ||
| + | Enable | ||
| + | ManualButton | ||
| + | |||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | IF Enable | ||
| + | IF Selector | ||
| + | ;Go to automatic state | ||
| + | MANAGER.NewState = MANAGER.AUTOMATIC_STATE | ||
| + | WAIT MANAGER.State EQ MANAGER.AUTOMATIC_STATE | ||
| + | ELSE | ||
| + | ;Go to manual state | ||
| + | MANAGER.NewState = MANAGER.MANUAL_STATE | ||
| + | WAIT MANAGER.State EQ MANAGER.MANUAL_STATE | ||
| + | ENDIF | ||
| + | ELSE | ||
| + | ;Go to alarm state | ||
| + | MANAGER.NewState = MANAGER.ALARM_STATE | ||
| + | WAIT MANAGER.State EQ MANAGER.ALARM_STATE | ||
| + | ENDIF | ||
| + | |||
| + | ForceOutput = ManualButton | ||
| + | |||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | |||
| + | </ | ||
| + | |||
| + | This code is used to decide when to execution the state transitions. Now the code written in //MANAGER// has to be completed as follows: | ||
| + | |||
| + | <code QCL> | ||
| + | CONST | ||
| + | ALARM_STATE | ||
| + | MANUAL_STATE | ||
| + | AUTOMATIC_STATE | ||
| + | | ||
| + | GLOBAL | ||
| + | NewState | ||
| + | State | ||
| + | | ||
| + | BEGIN | ||
| + | MAIN: | ||
| + | |||
| + | SWITCH State | ||
| + | CASE ALARM_STATE | ||
| + | ;Put here the code to do when the state is ALARM | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code to do when the state is MANUAL | ||
| + | SEQUENC.Force = COMMAND.ForceOutput | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code to do when the state is AUTOMATIC | ||
| + | SEQUENC.Start = SEQUENC.ON | ||
| + | ENDSWITCH | ||
| + | | ||
| + | ;Check if there is a state transition request | ||
| + | IF State NEQ NewState | ||
| + | SWITCH NewState | ||
| + | CASE ALARM_STATE | ||
| + | | ||
| + | SWITCH State | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code for MANUAL to ALARM trasition | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code for AUTO to ALARM trasition | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | ENDSWITCH | ||
| + | | ||
| + | CASE MANUAL_STATE | ||
| + | |||
| + | SWITCH State | ||
| + | CASE ALARM_STATE | ||
| + | ;Put here the code for ALARM to MANUAL trasition | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | CASE AUTOMATIC_STATE | ||
| + | ;Put here the code for AUTO to MANUAL trasition | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | ENDSWITCH | ||
| + | |||
| + | CASE AUTOMATIC_STATE | ||
| + | |||
| + | SWITCH State | ||
| + | CASE MANUAL_STATE | ||
| + | ;Put here the code for MANUAL to AUTO trasition | ||
| + | SEQUENC.Start = SEQUENC.OFF | ||
| + | SEQUENC.Force = SEQUENC.OFF | ||
| + | ENDSWITCH | ||
| + | | ||
| + | ENDSWITCH | ||
| + | | ||
| + | State = NewState | ||
| + | | ||
| + | ENDIF | ||
| + | | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | This simple examle shows how all the operations are executed during the state transitions are the same and block any operation on the // | ||
| + | |||
| + | variable. It can be noted that when in the manual state, activation of //Signal// is assigned to // | ||
| + | |||
| + | value as a digital input. In the automatic state the sequence managed in the //SEQUENC// unit is activated.\\ | ||
| + | The last addition to the //CONFIG// configuration unit is made as follows: | ||
| + | |||
| + | <code QCL> | ||
| + | INPUT | ||
| + | ManAuto | ||
| + | PowerOn | ||
| + | Push F 3.INP03 | ||
| + | |||
| + | REFERENCES | ||
| + | COMMAND.Selector | ||
| + | COMMAND.Enable | ||
| + | COMMAND.ManualButton = Push | ||
| + | | ||
| + | </ | ||
| + | |||
| + | In this way the symbols of the //COMMAND// unit: // | ||
| + | |||
| + | // | ||
| + | |||
| + | of the // | ||
| + | |||
| + | written for the //COMMAND// unit. A new unit could be added, named //COMMAN2// that contains exactly the same code as //COMMAND// but with | ||
| + | |||
| + | REFERENCE' | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - The QCL function library ====== | ||
| + | |||
| + | A QCL function is part of a code that allows to solve particular situations, perform data processing or provide a QMOVE project with specific functionalities. To use a QCL function in a unit code it just has to be called and its arguments completed, as described below.\\ | ||
| + | This programming method offers several advantages: | ||
| + | * They are parts of code ready written and tested, which offer optimised solutions to the most common situations faced when drawing up a project. | ||
| + | * They offer the possibility of using the same function several times without having to write it every time. | ||
| + | * The library can be updated any time new functions are added, maintaining full compatibility with existing applications. | ||
| + | The list of QCL functions and their use is available in the //**Help > Functions info**// menu, which can be opened anywhere in the development environment. | ||
| + | |||
| + | To recall any library function indicated by // | ||
| + | |||
| + | <code QCL> | ||
| + | FuncQcl01(< | ||
| + | </ | ||
| + | |||
| + | Since functions cannot return values, they cannot be used to the right of an assignment or as part of an expression in an IF, FOR or WHILE instruction. | ||
| + | |||
| + | <code QCL> | ||
| + | slType01 = FuncQCL01(...) | ||
| + | |||
| + | IF (FuncQCl01(...) AND ...) | ||
| + | |||
| + | FOR (sInt01 = 1, sInt01 LT FuncQCL01(...), | ||
| + | |||
| + | WHILE (FuncQCL01(...) LT 24) !COMPILING ERROR! | ||
| + | </ | ||
| + | |||
| + | Even if a QCL function does not return a value, a QCL function can set values to past parameters as an argument and so in practice it has the effect of returning several results. | ||
| + | |||
| + | Some simple examples: | ||
| + | <code QCL> | ||
| + | AC10AvergArr (MyArray, average_value, | ||
| + | </ | ||
| + | |||
| + | The function calculates the average value of an array supplied as argument. In this case //MyArray// is an input parameter and the function calculates its average value.\\ | ||
| + | // | ||
| + | |||
| + | In what part of the unit a function must be called is indicated. In fact there are functions, because of the actions they have to perform, that have to be called in a cyclic part of the project, while others can also be called in a non-cyclic part of the project. | ||
| + | Cyclic is intended as part of the QCL code that is executed at every program execution. | ||
| + | |||
| + | Non-cyclic is intended as part of the code that is not executed at every program execution because they lack certain conditions | ||
| + | Indications on “where” to recall a function are provided in the description of each function (//**Help > Functions info**// | ||
| + | Another characteristic to remember for other functions is that, when actions require long execution times, the function executes a WAIT instruction every 180 milliseconds. This prevents unit executions being “blocked” by particularly heavy actions. This kind of function normally has a flag type argument that can be monitored to verify when the function has completed its action.\\ | ||
| + | The function help clearly indicates the types of argument that the function expects. If the programmer does not respect these types an error is generated during the project compilation. | ||
| + | |||
| + | |||
| + | |||
| + | ==== - Practical example of QCL functions ==== | ||
| + | The use of the arithmetic average calculation function on the values in an array (AC10AvergArr): | ||
| + | |||
| + | <code QCL> | ||
| + | GLOBAL | ||
| + | glAverage L ; This is used as the result variable | ||
| + | gfDone F ; This flag is used to result variable | ||
| + | ARRSYS | ||
| + | aslMyArray 10 L ; Array System | ||
| + | |||
| + | BEGIN | ||
| + | |||
| + | MAIN: | ||
| + | IF NOT gfDone | ||
| + | AC10AvergArr(aslMyArray, | ||
| + | ENDIF | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Editor Ladder ====== | ||
| + | |||
| + | Ladder (contact logic) is a language conceived for PLC programming, | ||
| + | good performance in managing inputs, outputs and short sequences.\\ | ||
| + | It is presumed that the user knows the IEC1131 Ladder language and if this is not the case | ||
| + | it is advisable to integrate this manual with a general course in PLC. | ||
| + | |||
| + | ===== - Execution of the rung ===== | ||
| + | In LADDER it must be remembered that the various elements inside a rung are analysed starting from the top left-hand corner and moving up to down and left to right (Figure 1). | ||
| + | |Figure 1: execution of the rung.| | ||
| + | |{{ software: | ||
| + | |||
| + | If an element that takes up several cells (e.g. a counter) is inserted, the top left-hand cell is referred to when executing the rung.\\ | ||
| + | The name of the variables for the Ladder program are declared in the configuration unit and the same as the QCL section. The same variables can be used in Ladder and QCL, even simultaneously.\\ | ||
| + | An element is inserted in the LADDER grid using the menu functions is described below. | ||
| + | |||
| + | ===== - How to insert an element ===== | ||
| + | First of all a new LADDER unit has to be inserted by selecting //**File > Add unit > Ladder unit**//. The window in Figure 2 will open. | ||
| + | |||
| + | |Figure 2: inserting a new LADDER unit.| | ||
| + | |{{ software: | ||
| + | |||
| + | Confirm with //Ok// and a new unit is added in the **UNIT MANAGER** window. | ||
| + | Double click on the new LADDER unit to open the LADDER editor. Now the first element of this LADDER grid can be inserted using the “LADDER library” as shown in figure 3. | ||
| + | |||
| + | |Figure 3: LADDER Library| | ||
| + | |{{ software: | ||
| + | |||
| + | At this stage the various elements available can be selected and placed on the editor grid. The element can be placed by dragging it to its position, or by double clicking on the element, which positions the element in the highlighted editor box.\\ | ||
| + | The ladder element can also be selected from the list of “latest elements inserted”.\\ | ||
| + | The ladder element must be inserted in an existing grid. If the grid does not exist, it has to be created by inserting a new rung. To insert a new “rung” select menu //**Edit > New Rung**//.\\ | ||
| + | For instance, to insert a normally open contact, select the Normally Open Contact and the symbol of the contact will appear on the editor (Figure 4). | ||
| + | |||
| + | |Figure 4: normally open contact in a LADDER grid.| | ||
| + | |{{ software: | ||
| + | |||
| + | The LADDER library has a series of categories dividing the elements used in a LADDER grid, which will be viewed briefly below. | ||
| + | The element inserted in figure 4 is not associated to a variable. To associate a variable highlight the element and select the menu //**Edit > Element Properties**// | ||
| + | |||
| + | |Figure 5: block properties.| | ||
| + | |{{ software: | ||
| + | |||
| + | The “Note” field is used to associate useful comments about the element for the programmer. When the window has been filled in as in figure 5, the LADDER grid will appear as in figure 6. | ||
| + | |||
| + | |Figure 6: block properties.| | ||
| + | |{{ software: | ||
| + | |||
| + | The element properties window is used to enter all the variables required by the element. However some variables are optional. For example. | ||
| + | figure 7 shows that some parameters of the **TON (On Delay)** element are not mandatory and this is indicated by the lack of “???” (i.e. 3 question marks). | ||
| + | |||
| + | |Figure 7: TON: mandatory and optional parameters.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Element Categories ===== | ||
| + | The LADDER element categories for the LADDER grid: | ||
| + | |Contact Elements| | ||
| + | |Coil Elements| | ||
| + | |Comparison Function| | ||
| + | |Device Functions| | ||
| + | |Counter Functions| | ||
| + | |Timer Functions| | ||
| + | |Table functions| | ||
| + | |Bitwise Functions| | ||
| + | |Boolean Functions - Bitwise| | ||
| + | |Boolean Functions - Logical| | ||
| + | |Math Functions| | ||
| + | |Trigonometric Functions| | ||
| + | |Edge Functions| | ||
| + | |Bistable Functions| | ||
| + | |Selection Functions| | ||
| + | |||
| + | ===== - Comments ===== | ||
| + | The LADDER grid can accept a row of comment boxes. | ||
| + | To enter a comment select the menu //**Edit > New Element > Comment**// | ||
| + | Each comment can have a title and a text. | ||
| + | |||
| + | ===== - Jump and Label ===== | ||
| + | The Ladder structure provides the possibility to jump to a label so the program can skip heavy parts of the program when there is no need to execute them. To insert a jump element select the menu //**Edit > New Element > Jump**// | ||
| + | To enter the target label select the menu // | ||
| + | |||
| + | |Figure 8: (JUMP) to (LABEL) ETIC.| | ||
| + | |{{ software: | ||
| + | |||
| + | “Jump end” element can be inserted to simple jump directly to the end of the unit without a label (Figure 9). | ||
| + | |||
| + | |Figure 9: JUMP END.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Moving LADDER rows ===== | ||
| + | The Ladder structure can be changed by move parts of a program up or down to add new program lines. To move a row select a rung and select the menu //**Edit > Move Rows Up**// or // | ||
| + | When the ladder unit has ended, the program lines can be compacted to remove any empty spaces by the command // | ||
| + | |||
| + | ===== - Drag & Drop ===== | ||
| + | One or more ladder elements can be selected and then dragged by mouse and then dropped in another position. When the elements are selected keep the left mouse button pressed on the selection, which changes colour and the cursor changes shape, so that it can be moved. | ||
| + | When dragging the selection the bottom status bar shows the message:: " | ||
| + | |||
| + | - Drag & Drop in an empty area with no other ladder elements:\\ | ||
| + | Release the mouse button to place it in the box, the coloured box disappears and the selected elements are inserted in the editor. | ||
| + | |||
| + | - Drag & Drop over or in an area with other ladder elements:\\ | ||
| + | as above, when the box is placed and the mouse button release, the coloured box disappears and a message box asks to confirm or cancel the operation. Confirm the operation to insert the elements in the box below, automatically creating all the connections needed for a correct compilation of the end result. | ||
| + | |||
| + | ===== - Obsolete LADDER elements ===== | ||
| + | **Obsolete elements**, are old ladder elements that Qem has then made obsolete during Ladder library updates and maintenance. | ||
| + | A ladder element is usually marked obsolete if it has been substituted by an updated version, which normally increases efficiency of the internal code. | ||
| + | The obsolete element can always be replaced by an equivalent element in the ladder library in use. A project using obsolete ladder elements highlights them by giving them a coloured background (yellow by default). The obsolete elements in a program are easily found by // | ||
| + | |||
| + | |Figure 10: Obsolete Elements folder| | ||
| + | |{{ software: | ||
| + | |||
| + | In // | ||
| + | |||
| + | ===== - Substitution of obsolete elements ===== | ||
| + | The obsolete element substitution function (**Substitute Obsolete element**) has been provided to replace | ||
| + | Go to Menu > // | ||
| + | When the obsolete elements are substituted they change background colour to the standard background for valid elements.\\ | ||
| + | Use Menu > // | ||
| + | |||
| + | **Searches for obsolete elements in progress...** | ||
| + | |||
| + | This message is followed by: | ||
| + | |||
| + | **No obsolete elements to substitute** | ||
| + | |||
| + | if there are no obsolete elements, or | ||
| + | |||
| + | **There are obsolete ladder elements...** | ||
| + | |||
| + | At this stage either select to start substitute all or quit the procedure. | ||
| + | The complete substitution is signalled by the message: | ||
| + | |||
| + | **All obsolete elements are substituted!** | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Multitasking ====== | ||
| + | |||
| + | Multitasking is the capacity of a system to manage simultaneous execution of several tasks.\\ | ||
| + | A QCL and Ladder project is made up of a series of task units. The multitasking implemented in the QMOVE system is a so-called // | ||
| + | |||
| + | <code QCL> | ||
| + | WAIT < condition >. | ||
| + | </ | ||
| + | |||
| + | This is true for task units written in QCL, while tasks developped in ladder pass onto the next task after the last instruction. | ||
| + | The CPU stops executing the code of a task unit when the task is put in standby by the WAIT instruction.\\ | ||
| + | A flow chart of the so-called //task cycle// is shown in figure 1. So each task of a project has to be able to // | ||
| + | On startup the execution order of the units is the same as the order declared in the UNIT MANAGER window in QVIEW, except that the first task executed is the second in the list and then contining down the last and the first in list is the last task. | ||
| + | |||
| + | |Figure 1: task execution (initial condition).| | ||
| + | |{{ software: | ||
| + | |||
| + | |Figure 2: task execution (flow chart).| | ||
| + | |{{ software: | ||
| + | |||
| + | In addition to executing the code lines, the CPU also simultaneously executes the devices. Devices are explained in their specific chapter, however they can be generally described as tools that provide functionalities called by QCL or Ladder code lines, to achieve the most common applications met in industrial automation. | ||
| + | |||
| + | ===== - The Standard structure of a QCL task ===== | ||
| + | All tasks start their execution from the first code line. Control then passes onto the next task when a WAIT instruction is met (Figure 3). | ||
| + | |||
| + | |Figure 3: program flow (initial condition).| | ||
| + | |{{ software: | ||
| + | |||
| + | When control returns to the task in question, it restores execution of the code from the point where it was interrupted only if the condition to the right of the WAIT keyword is true, otherwise it executes a new task change, as represented in figure | ||
| + | |||
| + | |Figure 4: program flow (change task condition).| | ||
| + | |{{ software: | ||
| + | |||
| + | So if a task is in WAIT and its condition is never met, the code line following the WAIT is never executed.\\ | ||
| + | The QCL code is executed through to the end in every unit. To ensure that the code is repeated continuously, | ||
| + | or start has to be inserted. Normally every task has the following minimum QCL code: | ||
| + | |||
| + | <code QCL> | ||
| + | [< declaration code > | ||
| + | BEGIN] | ||
| + | [< initialization code >] | ||
| + | MAIN: | ||
| + | < operative code > | ||
| + | WAIT 1 | ||
| + | JUMP MAIN | ||
| + | END | ||
| + | </ | ||
| + | |||
| + | The initialisation code before the MAIN is only executed once during startup, while everything between MAIN and JUMP MAIN is executed | ||
| + | cyclically . If a given task does not have the JUMP MAIN instruction, | ||
| + | The WAIT 1 instruction is needed to ensure the task change. | ||
| + | |||
| + | ==== - Example of SUSPEND ==== | ||
| + | If this instruction is inserted in the task3 unit | ||
| + | |||
| + | <code QCL> | ||
| + | Task2.SUSPEND | ||
| + | </ | ||
| + | |||
| + | task2 is suspended and will no longer be executed. | ||
| + | |||
| + | {{: | ||
| + | ==== - Example of RESUME ==== | ||
| + | If the CPU executes this instruction in task4 | ||
| + | |||
| + | <code QCL> | ||
| + | task2.RESUME | ||
| + | </ | ||
| + | |||
| + | task2 unit enters the multitasking cycle and the code it contains is executed again. | ||
| + | |||
| + | {{: | ||
| + | ==== - Example of RESTART ==== | ||
| + | The RESTART instruction applied to a task unit restarts the execution of a code from the first instruction in the unit. For example the order of execution of instructions contained in a task are represented in the figure below: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | If, in the same or another | ||
| + | |||
| + | <code QCL> | ||
| + | task1.RESTART | ||
| + | </ | ||
| + | |||
| + | The next execution of a code in task1 restarts as if it were the first execution. | ||
| + | ===== - Time task units ===== | ||
| + | When writing a program it may be necessary to manage events at fixed, repeatable times. Since the cooperative multitasking system does not | ||
| + | have a repeatable cycle time, time units have been introduced, which can be activated by selecting the specific box in the unit properties | ||
| + | and declaring the time base to use. | ||
| + | |||
| + | |Figure 1: declaration of a time unit| | ||
| + | |{{ software: | ||
| + | |||
| + | Time units have priority over normal task units. Make sure that the code lines in a time unit (both QCL and | ||
| + | |||
| + | LADDER) do not require more time for execution than the set repeat time.\\ | ||
| + | If this happens some code repetitions are skipped or lost and the CPU signals this event with a “Time task lost” status. This can be seen in the CPU Monitor window. | ||
| + | Moreover, type of task unit cannot accept WAIT instructions, | ||
| + | **A maximum of 7 time units can exist in a project.** | ||
| + | |||
| + | ===== - Interrupt task units ===== | ||
| + | When writing a program it may be necessary to manage events created by an interrupt input (e.g. photocells or proximities). | ||
| + | |||
| + | |Figure 2: declaration of an interrupt based task| | ||
| + | |{{ software: | ||
| + | |||
| + | The interrupt units are priority over normal task units and time units. Moreover, type of unit cannot accept WAIT instructions, | ||
| + | The interrupt units can be written in both QCL and Ladder.\\ | ||
| + | A maximum of 2 interrupt units are allowed for a project. | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Devices ====== | ||
| + | |||
| + | Devices are a category of software tools that perform more or less complex support or control operations that simplify operations and procedures in industrial automation.\\ | ||
| + | For instance, a typical device can manage a CNC type positioner with +/-10V analog output, offering all the functions, commands and parameters needed to manage the positioning correctly (e.g. homing, manual positioning, | ||
| + | Devices have their own functions, variables, commands and parameters. They can be configured and inserted in a project so that one or more devices become an integral part of the application program.\\ | ||
| + | |||
| + | The parameters are variables used to configure the device execution (e.g. positioning speed, count , etc.): | ||
| + | <code QCL> | ||
| + | <device name> | ||
| + | </ | ||
| + | |||
| + | The commands make the device perform specific functions (e.g. START, STOP, etc.): | ||
| + | <code QCL> | ||
| + | <device name> | ||
| + | </ | ||
| + | |||
| + | The devices available for any given QMOVE model are listed in the hardware installation and maintenance manuals. | ||
| + | |||
| + | ===== - Declaring a Device ===== | ||
| + | ^The syntax for declaring a device is given in the specific device documentation.^ | ||
| + | The use of a device must be declared in the configuration unit or in the declaration section of each unit. The declaration syntax changes according to the device. | ||
| + | |||
| + | ==== - Device Declaration ==== | ||
| + | The device declaration in the configuration unit must include the INTDEVICE keyword.\\ | ||
| + | For more details see the specific documentation on each Device. | ||
| + | |||
| + | ===== - Using devices ===== | ||
| + | This chapter will give a preliminary introduction for the correct use of devices. The information below must be completed with the specific documentation on each device. | ||
| + | |||
| + | ==== - Sampling time ==== | ||
| + | As explained in Multitasking, | ||
| + | The general criteria in choosing sampling times is that a short time normally executes the device at a high rate so it therefore reacts rapidly to external actions | ||
| + | |||
| + | |Figure 1: device update delay.| | ||
| + | |{{ software: | ||
| + | |||
| + | The choice of device sampling times used in a project must account for certain considerations. A natural question is, “Why not select the minimum sampling time for each device?”. In effect this would give maximum performance, | ||
| + | The CPU allocates a part of its processing resources to managing the devices in a project. Each sampling of each device occupies a part of these resources. To determine and estimate the use of resources, consider that the CPU provides a resource of 100% every millisecond. The firmware documentation gives the percentage resource that each device uses in a sampling. In the same sampling the CPU can manage several devices and the overall resource allocation is the sum of the percentages for each device. When choosing the times, | ||
| + | The diagram in figure 2 gives an example of this concept using the following devices: | ||
| + | * an OOPOS3 device with tc=6msec., | ||
| + | * an OOPOS3 device with tc=30msec., | ||
| + | * an EANPOS device con tc=2msec. | ||
| + | * a COUNTER3 device with tc=3msec | ||
| + | * a CAMMING3 device with tc=1msec. | ||
| + | |||
| + | |Figure 2: CPU resource requirement for device management.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Consecutive commands and priorities ==== | ||
| + | A command addressing a device is not processed immediately by the CPU, but at the next sampling time, without interrupting the QCL instructions. | ||
| + | This is why the device may have to process several commands in the same sampling instant, and management of the device does not account for the sequence these commands are given but processes them according to an internal priority. This priority is specified in the documentation of each device.\\ | ||
| + | To ensure the sequence of commands given in the QCL code, introduce WAIT instructions conditioned by a device status. In this way the WAIT instruction waits for the execution of the command before executing the next instruction. | ||
| + | |||
| + | ==== - Complementary commands ==== | ||
| + | Some commands are complementary with others, i.e. they each produce the opposite effect of the other. If a device has to execute complementary commands in a given sampling time, only the last in the sequence has effect. To ensure execution of the two commands see “Consecutive commands and priorities” above. | ||
| + | |||
| + | ===== - Device groups ===== | ||
| + | A group of devices and be defined in the INTDEVICE section by the // | ||
| + | Example: | ||
| + | |||
| + | <code QCL> | ||
| + | DEVGROUP Axes | ||
| + | X ANPOS2 4 3.CNT01 1 3.INP19 X.X 3.AN01 | ||
| + | Y ANPOS2 4 3.CNT02 2 3.INP18 X.X 3.AN02 | ||
| + | ENDDEVGROUP | ||
| + | </ | ||
| + | |||
| + | The devices in a group have two restrictions: | ||
| + | |||
| + | - they must have the same sampling time | ||
| + | - the sum of their execution times must not be more than the maximum execution time of a sampling. | ||
| + | |||
| + | Definition of a group ensures execution of all its devices at the same sampling time. This function is dedicated to particular motion control applications. | ||
| + | |||
| + | |||
| + | < | ||
| + | |||
| + | ====== - The Qview environment ====== | ||
| + | This chapter describes the menus and commands in QVIEW. For details on some Windows functions (e.g. Open, Save, etc.) consult the operating system instructions. | ||
| + | |||
| + | ===== - Tool Bar ===== | ||
| + | The Tool Bar has the icons of the most common command functions.\\ | ||
| + | {{software: | ||
| + | |||
| + | ===== - Status Bar ===== | ||
| + | The Status Bar has four separate sections.\\ | ||
| + | 1 left - shows the value of the selected variable. Click the right mouse button Click on a variable or device parameter to see its value in this section (the serial connection must be active). | ||
| + | 2 - shows the cursor position (row and column) and the write mode (INS = insert text and OVR = overwrite text) (Figure 1).\\ | ||
| + | 3 - shows the serial port communication status between PC and CPU: port status (//No connection// | ||
| + | 4 - shows the “Match OK” or “No Match” messages when the serial communication is active and the projects on PC and CPU are the same or different. | ||
| + | |||
| + | |Figure 1: section 2 from left: cursor position.| | ||
| + | |{{ software: | ||
| + | |||
| + | |Figure 2: section 3 from left: serial port communication parameters and status .| | ||
| + | |{{ software: | ||
| + | |||
| + | |||
| + | ===== - Menu > File ===== | ||
| + | The commands for managing the project and related files. | ||
| + | |||
| + | ==== - New Project ==== | ||
| + | Create a new project. A name must be given to the project (Figure 1).\\ | ||
| + | The Project Information window opens (Figure 2) to enter the project data. This form is for information about the project and is optional so it can be completed later. | ||
| + | |Figure 1: entering the project name.| | ||
| + | |{{ software: | ||
| + | |||
| + | |Figure 2: project information window.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Open Project ==== | ||
| + | Open an existing project (Figure 3). | ||
| + | |Figure 3: opening a project.| | ||
| + | |{{ software: | ||
| + | A project created with a previous version of Qview can be opened by selecting the different extensions in "File Type". | ||
| + | |||
| + | ==== - Save Project ==== | ||
| + | Save any changes made to the project. | ||
| + | |||
| + | ==== - Save Project As ==== | ||
| + | Save a copy of the project under a different name, including any changes | ||
| + | (Figure 4). | ||
| + | |Figure 4: saving a project under a different name.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Close Project ===== - | ||
| + | Close the project. | ||
| + | |||
| + | ==== - Add Unit ==== | ||
| + | Add a new unit to the project.\\ | ||
| + | New unit options:\\ | ||
| + | * Configuration Unit: enter the configuration unit. This is not enabled if a configuration unit already exists in the project.\\ | ||
| + | * QCL Unit: add a new task unit in QCL language\\ | ||
| + | * Ladder Unit: add a new task unit in Ladder language\\ | ||
| + | * Document Unit: add a new document unit (text document to group comments, spec' | ||
| + | The new unit is added to the bottom of the list of existing units. | ||
| + | |||
| + | ==== - Insert Unit ==== | ||
| + | Insert a new unit in the project. | ||
| + | |||
| + | See //Add Unit// above for the new unit options. | ||
| + | |||
| + | The new unit is inserted above the selected unit in the list. | ||
| + | |||
| + | ==== - Create a configuration unit ==== | ||
| + | When a new configuration unit is created with the “Add unit” or “Insert | ||
| + | unit” commands, the “Unit property” window opens (Figure 5). | ||
| + | |Figure 5: Configuration unit title.| | ||
| + | |{{ software: | ||
| + | This window assigns a unit name and brief description of the unit. Confirm with // | ||
| + | Only one configuration unit can exist in a project. | ||
| + | |||
| + | ==== - Create a QCL or LADDER unit ==== | ||
| + | Whenever a new QCL or LADDER unit is created by the “Add unit” or “Insert unit” commands, a “Unit property” window opens (Figures 6, 7). | ||
| + | |Figure 6: QCL unit title.| | ||
| + | |{{ software: | ||
| + | |||
| + | |Figure 7: LADDER unit title.| | ||
| + | |{{ software: | ||
| + | Give a name to the unit and a brief description.\\ | ||
| + | Press // | ||
| + | The “Unit property”window | ||
| + | * **normal** | ||
| + | * **interrupt**: | ||
| + | |||
| + | (**Interrupt Line**); | ||
| + | * **time**: specify the repeat time for the unit code (**Time Exec.**). | ||
| + | |||
| + | ==== - Create document unit ==== | ||
| + | Document units are used text only units to write comments, notes and operating details. | ||
| + | |||
| + | ==== - Remove Unit ==== | ||
| + | Remove the selected unit. | ||
| + | |Figure 8: selecting a unit for removal.| | ||
| + | |{{ software: | ||
| + | Before deleting the unit Qview asks if the unit has to be exporting before removal, otherwise the unit is lost. | ||
| + | |Figure 9: export unit request.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Import Unit ==== | ||
| + | Import a unit previously exported from another project (Figure 10). | ||
| + | |Figure 10: Importing a unit.| | ||
| + | |{{ software: | ||
| + | The two alternatives are “Add unit...” to import a unit at the end of the list or “Insert unit...” to import a unit above the selected unit. | ||
| + | |||
| + | ==== - Export Unit ==== | ||
| + | Export a copy of the selected unit for transfer to another project. The original remains in the project and the unit is exported to the same directory as the project. The unit is exported with a *.unt file extension. | ||
| + | |Figure 11: Confirm export.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Export Unit As ==== | ||
| + | Export a copy of the selected unit for transfer to another project with another unit name. The original remains in the project. | ||
| + | |Figure 12: exporting a unit with another name.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Unit Property ==== | ||
| + | Modify the unit properties and especially the unit Runtime settings, i.e. the unit execution mode when it is downloaded onto the Qmove CPU. The units can be given the following settings: | ||
| + | |||
| + | **Normal** | ||
| + | Maximum 65535 units in a project.\\ | ||
| + | The unit is given a Runtime loop (see Multitasking chapter). | ||
| + | |||
| + | **Interrupt** | ||
| + | Maximum three units in a project.\\ | ||
| + | The unit is given a Runtime behaviour determined by external events (i.e. interrupt hardware lines). Unit execution can be determined to activate on the rising or drop front of the incoming signal and the associated hardware line number, with settings from 1 to 8. | ||
| + | |||
| + | **Time** | ||
| + | Maximum seven units in a project.\\ | ||
| + | The unit is given a Runtime behaviour at a pre-set time rate in the hardware.\\ | ||
| + | The rate can be adjusted from 1 to 999 milliseconds. A new time unit is given a default time of 100ms. | ||
| + | |Figure 13: changing unit properties.| | ||
| + | |{{ software: | ||
| + | The “Unit property” window (Figure 13) can be used to give a new Unit Name to an existing unit. | ||
| + | |||
| + | ==== - Import Module As Unit ==== | ||
| + | The old versions of Qview used the term module instead of unit. Import a module created in an old version of Qview (*.mod). The unit can be added at the end of the list (Add Module as unit) or inserted above a selected unit (Insert Module as Unit). | ||
| + | |||
| + | ==== - Export Unit as Module ==== | ||
| + | Export units in a compatible format for old versions of Qview (i.e. Qview 2.x & Qview 3.x Modules). The window in Figure 14 opens, where units can be selected for export | ||
| + | |Figure 14: exporting units as modules.| | ||
| + | |{{ software: | ||
| + | Double click a unit to select. | ||
| + | |||
| + | ==== - Export Symbols File ==== | ||
| + | Export symbols from a project to realign the symbols in the terminal. | ||
| + | |Figure 15: exporting symbols.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Export Symbols File As ... ==== | ||
| + | Export and rename a symbol file from the project to realign the symbols in the terminal. | ||
| + | |Figure 16: exporting and renaming symbols files.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Export Binary File & Export Binary File As ... ==== | ||
| + | Function only available if the project compilation is successful. | ||
| + | Export the binary file (i.e. compilation result) to download the application on the CPU without using the serial communication (e.g. | ||
| + | transferring it to the CPU by Multi Media Card). Binary files can be exported with the same project name (**Export Binary File**) or | ||
| + | changing the name (**Export Binary File As...**). | ||
| + | |||
| + | ==== - Project Information ... ==== | ||
| + | Open the Project Information window (Figure 20) to enter specific information about the project. | ||
| + | |Figure 17: project information window.| | ||
| + | |{{ software: | ||
| + | This window is made up of folders that divide the project information by topic. Mandatory information is marked by an asterisk. If any mandatory information is not entered, messages will periodically appear to signal the missing information (to disable the messages see //**Menu > Options > Program Setup**//). The window has a “Checksums” button that automatically inserts the project checksum codes. | ||
| + | |||
| + | ==== - Print ==== | ||
| + | ^Command only available after selecting an editor window.^ | ||
| + | Open the “Print Manager” window to print part or all the project with various print options. Figure 18 shows the window where the bottom box gives the list of units in the project, which can be selected for printing. The top left-hand box has the usual font size and n. copies settings.\\ | ||
| + | The top right-hand box configures the LADDER task printout, specifying: | ||
| + | * print the list of inputs and outputs in the LADDER task | ||
| + | * print the variables in the LADDER task | ||
| + | * print the comments in the LADDER task | ||
| + | * print compacting the LADDER rows deleting all empty spaces | ||
| + | * print the number of rungs; | ||
| + | * print a number of cells per row. | ||
| + | In the top left of the window select to print only the selected part of the task unit. | ||
| + | |Figure 18: selecting the print mode.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Recent projects ==== | ||
| + | The last 4 files opened can be directly recalled (Figure 19). | ||
| + | |Figure 19: opening recent projects.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Exit ==== | ||
| + | Close QVIEW and confirm to save any changes made to the project. | ||
| + | |||
| + | ===== - Menu > Edit ===== | ||
| + | ^Commands only available when a unit is open in the editor.^ | ||
| + | |||
| + | ==== - New Element ==== | ||
| + | Insert a new element in the Ladder grid (a LADDER unit must be open). | ||
| + | |||
| + | ==== - New Rung ==== | ||
| + | Insert a new rung in the Ladder grid (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Delete Rung ==== | ||
| + | Delete the selected rung in the Ladder grid (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Toggle Link ==== | ||
| + | Connect two Ladder elements vertically. The link is always made downwards | ||
| + | and to the left of the selected cell (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Substitute Obsolete Element & Substitute All Obsolete Elements...=== | ||
| + | Substitute obsolete elements. For more details see “LADDER editor - Obsolete LADDER elements” (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Element Properties... ==== | ||
| + | Change the variables in a LADDER element (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Undo ==== | ||
| + | Cancel the last change. | ||
| + | |||
| + | ==== - Redo ==== | ||
| + | Cancel the Undo command and restore the last change. | ||
| + | |||
| + | ==== - Cut - Copy - Paste - Delete ==== | ||
| + | Cut, copy, paste and delete texts or elements. | ||
| + | |||
| + | ==== - Select All ==== | ||
| + | Select all the text or elements in an editor window. | ||
| + | |||
| + | ==== - Compact Rows ==== | ||
| + | Compact the Ladder code, eliminating any empty rows (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Move Rows Up ==== | ||
| + | Move a Ladder code line up (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Move Rows Down ==== | ||
| + | Move a Ladder code line down (a LADDER unit must be open). | ||
| + | |||
| + | ==== - Find ==== | ||
| + | Find for a word by selected search criteria (Figure 20).\\ | ||
| + | Search criteria\\ | ||
| + | * Search in Current Unit: search only selected unit. | ||
| + | * Search in All Units: search all project units. | ||
| + | * Find Whole Word Only: find only whole words | ||
| + | * Match Case: search words as entered, with upper and lower case. | ||
| + | |||
| + | |Figure 20: search criteria window.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Find Next ==== | ||
| + | When a term is found by Find, the search for the same term can continue in the rest of the project with the same search criteria. | ||
| + | |||
| + | ==== - Replace ==== | ||
| + | Find a term (Find What) with the set search criteria and replace it with a new term (Replace With)(Figure 21).\\ | ||
| + | |||
| + | **Search criteria**\\ | ||
| + | * Search in Current Unit: search only the selected unit\\ | ||
| + | * Search in All Units: search all project units\\ | ||
| + | * Find Whole Word Only: find only whole words\\ | ||
| + | * Match Case: find words as entered, with upper and lower case.\\ | ||
| + | |||
| + | **Replace criteria**\\ | ||
| + | * Find Next: no replacement, | ||
| + | * Replace: the search finds the word ( Find What) and replaces it with a new word (Replace With);\\ | ||
| + | * Replace All: all of the words are found ( Find What ) and automatically replaced in all the project. | ||
| + | |||
| + | |Figure 21: search and replace criteria window.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Go to ... ==== | ||
| + | The cursor goes to the set line number | ||
| + | |Figure 22: going to a set line number.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Go to PC ==== | ||
| + | When execution of the project is interrupted (e.g. by a breakpoint), | ||
| + | In Figure 23 the Go to PC command shows an interruption by a breakpoint. | ||
| + | |Figure 23: program execution interrupted by a breakpoint.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Next Unit / Previous Unit ==== | ||
| + | Go to the next or previous unit in the project. | ||
| + | |||
| + | ==== - Next Selected Unit / Previous Selected Unit ==== | ||
| + | Go to the next or previous selected units, skipping the others. Select the units one by one and press the space bar. A red spot beside | ||
| + | |||
| + | the unit marks the selection (Figure 24).\\ | ||
| + | The Next and Previous Selected Unit commands can scroll forward and back only between the selected units.\\ | ||
| + | To remove the marking, select the unit, press the space bar again and the red spot will disappear. | ||
| + | |||
| + | |Figure 24: selecting units for an analysis.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Menu > Project ===== | ||
| + | The project and CPU data management commands. | ||
| + | |||
| + | ==== - Compile ==== | ||
| + | Conversion of the project into a format for interpretation by the CPU. The project can only be downloaded onto the CPU if it has been compiled without errors (Figure 25). | ||
| + | |||
| + | |Figure 25: project compilation window.| | ||
| + | |{{ software: | ||
| + | |||
| + | If the project compilation gives errors, double click the message in the compilation window for the editor to show the code line containing the error. | ||
| + | |||
| + | ==== - Force Compile ==== | ||
| + | Compilation of the whole project is forced regardless of its compiled condition. | ||
| + | |||
| + | ==== - Ladder Network checking ==== | ||
| + | A check on the Ladder net. A window opens to give the compilation result (Figure 26). | ||
| + | |Figure 26: Ladder net compilation window.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - View compilation result ==== | ||
| + | View or hide the result window for the last compilation (Figure 24. | ||
| + | |||
| + | ==== - Download ==== | ||
| + | ^Command only available with the PC - QMOVE serial communication activated.^ | ||
| + | The compiled project can be downloaded onto the CPU. The stages in the download are shown in a window (Figure 27). | ||
| + | |Figure 27: download outcome.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Backup data ==== | ||
| + | ^Command only available after an application download.^ | ||
| + | The application downloaded onto CPU contains code and data information. | ||
| + | |||
| + | **Unchangeable Application** | ||
| + | Application information that is not changed, e.g. QCL instructions, | ||
| + | |||
| + | **Changeable Data** | ||
| + | Data indicating the application operating conditions, e.g. device data areas, variable values, array systems, datagroup contents and data that modifies during operation (all the application data). | ||
| + | |||
| + | Backup creates a safety copy of all data, recording it on the internal non-volatile mass storage. This facility is useful because it offers the possibility to restore all existing parameter settings at a given point. The values are copied on non-volatile mass to give maximum security (Figure 28).\\ | ||
| + | Execution conditions of the backup command:\\ | ||
| + | * CPU in READY status. | ||
| + | * The application does not use more RAM space than the backup limit. | ||
| + | * The total space taken up by retentive and non-retentive data must not be more than the non-volatile memory space available. | ||
| + | If the backup is executed from the terminal and takes longer than the terminal timeout, a timeout error will trip in the serial communication between CPU and terminal. | ||
| + | |||
| + | |Figure 28: confirm request for backup.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Restore data ==== | ||
| + | ^Command only available after downloading the application.^ | ||
| + | The application recalled from the CPU contains application and data information. | ||
| + | |||
| + | **Unchangeable Application** | ||
| + | The application that is not modified, e.g. QCL instructions, | ||
| + | |||
| + | **Changeable data** | ||
| + | Data indicating the operating conditions, e.g. device data areas, variable values, array systems, datagroup contents and any data that changes value during operation ( all application data).\\ | ||
| + | |||
| + | The restore command recovers all the data with the backup data (Figure 29).\\ | ||
| + | The backup contents are deleted during the download procedure, since there is no reason to copy the values of an application' | ||
| + | Execution conditions of the restore command: | ||
| + | * A previous backup must have been made | ||
| + | * CPU is in READY or ERROR status. | ||
| + | |||
| + | |Figure 29: confirm restore procedure.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Save Data... ==== | ||
| + | ^Command only available after downloading the application.^ | ||
| + | The CPU data (i.e. retentive variable values) are saved in a .DAT file, defining also the destination directory (Figure 30). | ||
| + | |Figure 30: saving CPU data on file.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Recall Data... ==== | ||
| + | ^Command only available after downloading the application.^ | ||
| + | Replace the retentive variable values on the CPU with the values of the same variables stored in a .DAT file(Figure 31). | ||
| + | |||
| + | The replacement is only made to variables that are common to the application and the .DAT file, so, for example, if variables are added on the CPU after the last data backup, they are not replaced. | ||
| + | |Figure 31: replacing CPU data by .DAT file| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Convert Data... ==== | ||
| + | ^Command always available.^ | ||
| + | Convert the .DAT file into a .TXT text file containing the variable names and values. The text file is generated in the containing the .DAT | ||
| + | file and is given the same name as the .DAT file (Figure 32). | ||
| + | |Figure 32: data file conversion.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Checksum View ==== | ||
| + | ^Command available after opening a project.^ | ||
| + | Compare project checksums with the application downloaded on the CPU (Figure 33), if they are the same the CPU and PC have the same project. | ||
| + | Any differences are signalled with the checksum values in red. The following data types are compared: | ||
| + | |||
| + | * Configuration: | ||
| + | * Code: QCL code generated by the compilation. | ||
| + | * Symbol: symbols of the variables, which depends on the list of variables and their types. | ||
| + | * Source: unit contents | ||
| + | |||
| + | CAUTION! Compilation of the same project by two different Qview versions or builds guarantees the same functions, but does not guarantee that the checksum codes are kept the same. | ||
| + | |Figure 33: checksum summary and comparison.| | ||
| + | |{{ software: | ||
| + | The CPU column gives the values in the CPU and its project signature.\\ | ||
| + | The Project column is updated when the project is opened (if compiled) and after each compilation. | ||
| + | |||
| + | ==== - View Project ID ==== | ||
| + | ^Command available only with the PC - QMOVE serial communication open.^ | ||
| + | View the project name. The name was defined in the Project Information window. When downloading, | ||
| + | |Figure 34: Viewing the project name string.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Menu > Debug ===== | ||
| + | Commands for executing the application downloaded onto the CPU. | ||
| + | |||
| + | ==== - Run ==== | ||
| + | ^Command available after a download.^ | ||
| + | Execution of the application downloaded onto the CPU.. | ||
| + | |||
| + | ==== - Stop ==== | ||
| + | ^Command available after a run.^ | ||
| + | Stop execution of the CPU application (the devices still continue to operate). | ||
| + | |||
| + | ==== - Restart ==== | ||
| + | ^Command available after a start or stop.^ | ||
| + | Execution of the application is stopped and at the next RUN the project starts from the beginning. | ||
| + | |||
| + | ==== - Reset ==== | ||
| + | ^Command available only with the PC - QMOVE serial communication open.^ | ||
| + | Delete the application in the CPU. The data is deleted definitively so a safety confirmation is requested during the reset procedure (see Figure 35). | ||
| + | |Figure 35: confirm reset project procedure.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Step ==== | ||
| + | ^Command available only after a download and selecting the editor window.^ | ||
| + | Execute the project step by step and at each step the program execution flow advances by a step. When a WAIT instruction is found, the editor window editor shows the next unit so that the program can execute all the units at one step at a time.\\ | ||
| + | A green arrow to the left of the editor window indicates the code line that has not been executed (Figure 36). LADDER units execute a rung in each step. | ||
| + | |Figure 36: Program execution in Step mode.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Step Over ==== | ||
| + | ^Command only available after a download and selecting the text editor window.^ | ||
| + | Execute the project one instruction at a time and at each step the project execution advances by an instruction. When a WAIT instruction is found the code execution continues normally through the other units until it returns to the WAIT instruction returning to step by step execution.\\ | ||
| + | A green arrow to the left of the editor window indicates the code line that will be executed (Figure 37). LADDER | ||
| + | |||
| + | ==== - Toggle Breakpoint ==== | ||
| + | ^Command only available after a download and selecting the editor window.^ | ||
| + | |||
| + | ^Up to 5 breakpoints can be inserted, which are reset when the CPU is shut off and when the project is downloaded.^ | ||
| + | Insert a breakpoint or in other words mark a code line where the program execution stops. Several breakpoints can be defined by | ||
| + | |||
| + | selecting a a code line for each breakpoint, the //Toggle breakpoint// | ||
| + | The breakpoints are indicated on the left of the editor window by a red mark with //ST// (Figure 37). Breakpoints can be inserted at rungs | ||
| + | in LADDER units. | ||
| + | |Figure 37: inserting a breakpoint.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Clear All ==== | ||
| + | ^Command only available after a download.^ | ||
| + | Cancel all breakpoints in all the task units. | ||
| + | |||
| + | ==== - Watchpoint ==== | ||
| + | ^Command only available after a download.^ | ||
| + | |||
| + | ^Up to 5 watchpoints can be inserted, which are reset when the CPU is shut off and when the project is downloaded.^ | ||
| + | Interrupt the project execution when a specific condition is satisfied, like a conditional breakpoint. The watchpoint command opens the window in Figure 38 to show the set stop conditions. | ||
| + | * Add: add a stop condition (Figure 39). | ||
| + | * Delete: delete the selected stop condition. | ||
| + | * Reset: delete all set stop conditions. | ||
| + | |||
| + | |Figure 38: watchpoint list.| | ||
| + | |{{ software: | ||
| + | |||
| + | |Figure 39: watchpoint parameter settings.| | ||
| + | |{{ software: | ||
| + | |||
| + | Click on ADD (Figure 38) to open the window in Figure 39 and set the program stop condition.\\ | ||
| + | * Watch Type: select by variable type (i.e. Variables, I/O, Arrays, Data Groups, Devices). | ||
| + | * Name: select a variable belonging to the group defined in the Watch Type drop list. | ||
| + | * Value: enter a variable value that stops the project. | ||
| + | |||
| + | ===== - Menu > Monitor ===== | ||
| + | The diagnostic commands for the QMOVE system and the project execution. | ||
| + | |||
| + | |||
| + | ==== - Devices Panels ==== | ||
| + | In addition to the command parameter status list, Qview provides a user-friendly panel with the device name and type (Figure 51). | ||
| + | |Figure 51: the device panels .| | ||
| + | |{{ software: | ||
| + | | ||
| + | |Figure 52: a typical device panel.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - CPU MONITOR ==== | ||
| + | The //CPU MONITOR// window gives information about the CPU status and the project execution times. | ||
| + | The CPU Monitor Panel has three sections: | ||
| + | * GENERAL: general info on the CPU status and execution times of the whole project. | ||
| + | * TASK INFO: information on each unit. | ||
| + | * CPU’s oscilloscope: | ||
| + | |||
| + | ==== - General ==== | ||
| + | CPU status info | ||
| + | |||
| + | * Mode: the CPU mode(RUN, STOP, ... Err). If Err it also shows the type of error. | ||
| + | * System Time: the application real run time from the CPU startup or restart. | ||
| + | * Used CODE Memory: the percentage memory space occupied by the code. | ||
| + | * Used DATA Memory: the percentage memory space occupied by the data. | ||
| + | * Battery low: low backup battery signal. | ||
| + | * Watchdog Task: signal when a task unit execution requires over 200ms. The signal persists until the CPU is shut-off. The project | ||
| + | continues to run normally, even though the signal indicates an error in the QCL programming. | ||
| + | * Backup OFF: signals the backup cannot be run (e.g. a high percentage of Data Memory space is occupied). | ||
| + | * Time Task Lost: signals when executing the program execution, a time task has not been executed one or more times. | ||
| + | * Running time in ms: task execution time. | ||
| + | * Active Task: task in use. | ||
| + | * Time Task Lost: signals that a time task unit has not been executed during the program execution. | ||
| + | * Wait State: signals a wait instruction is found in the task in use. | ||
| + | * Breakpoint: signals the task flow has found a breakpoint and has been interrupted. | ||
| + | * Watchdog Active: signals the active task has caused a Watchdog signal. | ||
| + | |||
| + | Moreover, MINIMUM TIME and MAXIMUM TIME show the times to execute the project.\\ | ||
| + | There is also a //Reset Timing// button that zero-sets the two times and the //Running time//, enabling the processing time counter. | ||
| + | |||
| + | |Figure 56: CPU general panel.| | ||
| + | |{{ software: | ||
| + | |||
| + | === - Task info === | ||
| + | This menu can control all the units processed by the project and various types of information can be obtained. All the units can give information of the minimum, maximum and actual execution time. | ||
| + | |||
| + | Task units also give information about the // | ||
| + | |||
| + | All other task units can have additional information: | ||
| + | * **TASK LOST:** Indication that the time task unit has lost an event. | ||
| + | * **DEVICE ACCESS:** Indication that the task unit has executed an access to a device that is not updated. | ||
| + | * **INTERRUPT: | ||
| + | |||
| + | |Figure 57: CPU general panel.| | ||
| + | |{{ software: | ||
| + | |||
| + | All the information in Figure 57 can only be shown if the CPU and PC check-sums match, otherwise the Task Info only shows the program units without any other information (Figure 58). | ||
| + | |||
| + | |Figure 58: CPU Task info.| | ||
| + | |{{ software: | ||
| + | |||
| + | Errors are marked by changing the boxes to red, instead of the normal white. | ||
| + | |||
| + | === - CPU Oscilloscope === | ||
| + | The oscilloscope shows the CPU status changes over time (Figure 59). | ||
| + | |||
| + | |Figure 59: CPU Oscilloscope.| | ||
| + | |{{ software: | ||
| + | |||
| + | The acquisition speed is dependent on two factors :\\ | ||
| + | - The serial speed. | ||
| + | - How much data is controlled. | ||
| + | |||
| + | For an acquisition, | ||
| + | When running an acquisition all the rest of Qview is blocked to give all resources to this function.\\ | ||
| + | The acquisition can be associated to any variable, except a datagroup, and the acquisition time can also be enabled with the machine running without influencing its operation since the control does not burden the process.\\ | ||
| + | Acquisition can be stopped at any time by pressing the Backspace key. | ||
| + | |||
| + | Save settings: | ||
| + | |||
| + | CAPTURE TASK: the measurement parameter settings:\\ | ||
| + | - All task units, if set as CPU CYCLE TIMINGS to the cycle time of the whole program (Min. Max. Run). | ||
| + | - On a single task unit, if a time or interrupt task, to see the cycle time of the selected task (Min. Max. Run). Naturally, the scan time for a normal task is for the whole program, however this particular case is also highlighted by a message (Figure 60). | ||
| + | |Figure 60: CPU Oscilloscope Capture Task.| | ||
| + | |{{ software: | ||
| + | CHART: This window sets the graphic options to show characteristics and references related to the measurements (Figure 61). | ||
| + | |Figure 61: CPU Oscilloscope Chart.| | ||
| + | |{{ software: | ||
| + | To know the meaning of a button, pass the cursor over the it and a description is given.\\ | ||
| + | In addition to task unit times, the time of a reference variable can be monitored by specifying it in the “Reference variable” of the Capture section.\\ | ||
| + | If the variable does not exist a signal message is shown, the recoding is made but without the variable. | ||
| + | |||
| + | ==== - BUS ==== | ||
| + | ^Command available after opening an existing project and the PC - QMOVE serial communication port.^ | ||
| + | The BUS Information window (Figure 63) shows the hardware construction and firmware versions/ | ||
| + | |||
| + | * N° SLOT: the slot position. | ||
| + | * ID: identification of the card type. | ||
| + | * VERSION: the firmware version installed on the card. | ||
| + | * RELEASE: the firmware release installed on the card. | ||
| + | * WDOGBUS: any card faults. | ||
| + | |||
| + | |Figure 63: bus composition.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Menu > Tools ===== | ||
| + | |||
| + | ==== - Upgrade QCL Card Library ==== | ||
| + | ^This command is always available.^ | ||
| + | The Upgrade QCL Card Library command updates the QCL language libraries (Figure 64). The libraries contain the following information: | ||
| + | |||
| + | * QMOVE models. | ||
| + | * QMOVE cards. | ||
| + | * QMOVE devices. | ||
| + | |||
| + | |Figure 64: library update.| | ||
| + | |{{ software: | ||
| + | |||
| + | ==== - Upgrade QCL Functions Library ==== | ||
| + | ^This command is always available.^ | ||
| + | The Upgrade Functions Library command will update the QCL function libraries (Figure 65). | ||
| + | |Figure 65: updating the QCL function libraries.| | ||
| + | |{{ software: | ||
| + | |||
| + | |||
| + | |||
| + | ==== - Upgrade Ladder Elements Library ==== | ||
| + | ^This command is always available.^ | ||
| + | The Upgrade Ladder Elements command updates the ladder element libraries (Figure 67). | ||
| + | |Figure 67: Updating the Ladder Library.| | ||
| + | |{{ software: | ||
| + | |||
| + | ===== - Menu > Options ===== | ||
| + | Commands to personalise Qview functions. | ||
| + | |||
| + | ==== - Open COM / Close COM ==== | ||
| + | Open and close the PC - QMOVE serial communication port. | ||
| + | |||
| + | ==== - Program Setup ... ==== | ||
| + | ^This command is always available.^ | ||
| + | A window is opened containing six folders. | ||
| + | |||
| + | === - QCL Editor Folder === | ||
| + | ^This command is always available.^ | ||
| + | Custom QVIEW graphics settings to create personal options, assigning different sizes and colours to the QCL text(Figure 68). | ||
| + | |Figure 68: custom QCL editor settings.| | ||
| + | |{{ software: | ||
| + | - Font Size.\\ | ||
| + | - Tab Stop.\\ | ||
| + | - Text Color.\\ | ||
| + | - Element Color.\\ | ||
| + | - Element Name. \\ | ||
| + | - Text.\\ | ||
| + | - Background.\\ | ||
| + | - Comments.\\ | ||
| + | - Keywords.\\ | ||
| + | - Operators.\\ | ||
| + | - Constants.\\ | ||
| + | - Breakpoint.\\ | ||
| + | - Program Counter.\\ | ||
| + | - Border Background. | ||
| + | |||
| + | === - Ladder Editor Folder === | ||
| + | Personalise the QVIEW interface by selecting the size and colour of the LADDER editor elements (Figure 69). | ||
| + | |Figure 69: custom Ladder editor settings.| | ||
| + | |{{ software: | ||
| + | - Cell Width.\\ | ||
| + | - Cell Height.\\ | ||
| + | - Undo Levels: select max number of UNDO' | ||
| + | - Cursor type: select type of cursor.\\ | ||
| + | - End Rung Mode: select type of end rung.\\ | ||
| + | - Grid Drawing Style.\\ | ||
| + | - Element Placing Style.\\ | ||
| + | - Element Contour Style.\\ | ||
| + | - Grid Visible.\\ | ||
| + | - Note image Visible.\\ | ||
| + | - Row Number visible.\\ | ||
| + | - Rung Number visible.\\ | ||
| + | - Obsolete State Visible: select to indicate the obsolete LADDER elements by a different background color.\\ | ||
| + | - Automatic New Rung Generation: select to automatically generate rungs when inserting a new LADDER element.\\ | ||
| + | - Automatic Element Property Editor: select to automatically open the LADDER element property window it is when inserted.\\ | ||
| + | - Color: the background colour of the editor window.\\ | ||
| + | - Element Color: select the colour of the selected element.\\ | ||
| + | - Element Name: select the editor elements to change colour from the list in the window.\\ | ||
| + | |||
| + | “Program Setup” also offers the possibility to associate a series of HotKeys for the most common LADDER elements. Figure 70 shows how 10 LADDER elements are associated to key combinations of CTRL + ALT + 0...9 and another 10 to CTRL + SHIFT + 0...9. Default associations are already provided, but these can be changed. | ||
| + | |Figure 70: hotkey associations.| | ||
| + | |{{ software: | ||
| + | |||
| + | === - Communication Folder ==== - | ||
| + | ^To use the COM3 and COM4 ports different IRQ's have to be use than those for other hardware (e.g. mouse, COM1, COM2, ...).^ | ||
| + | Configuration of the serial communication port (Figure 71). | ||
| + | |Figure 71: setting the serial communication port parameter.| | ||
| + | |{{ software: | ||
| + | - COM Port: select the serial communication port | ||
| + | - Communication Speed: define the transmission speed of the serial communication, | ||
| + | by selecting the autodetect option, Qview automatically detects the transmission speed. | ||
| + | |||
| + | The serial communication times have two setting groups | ||
| + | (Timeouts Group A and Timeouts Group B). | ||
| + | |||
| + | === - General === | ||
| + | Development environment custom settings (Figure 72). | ||
| + | |Figure 72: general settings.| | ||
| + | |{{ software: | ||
| + | - View Toolbar: show the project toolbar.\\ | ||
| + | - View Status Bar: show the status bar.\\ | ||
| + | - View Ladder Toolbar: show the ladder toolbar.\\ | ||
| + | - View Logo At Startup: show the Qview logo at startup.\\ | ||
| + | - View Ladder Warnings: show warning messages in the compilation result window.\\ | ||
| + | - Automatic Project Backup: execute a backup copy of the project each time it is saved.\\ | ||
| + | - Open the last project at startup: open the last project saved when opening Qview.\\ | ||
| + | - Export unit before remove it: request the unit export before deleting.\\ | ||
| + | - View Compilation Warning report: show warning messages during compilation.\\ | ||
| + | - Export Binary file After Compilation: | ||
| + | - Export symbol file after compiling: the symbols file is automatically exported after a complication. The symbols file is exported to the same directory and with the same name as the project file. A directory request window opens for new projects that have not been | ||
| + | |||
| + | saved.\\ | ||
| + | - Automatic Project Information update: show a message asking if the project details in “Project information” have been updated.\\ | ||
| + | This message is shown if the application has not been saved for at least an hour.\\ | ||
| + | - Project Information update before project saving: every time the project is saved a message warning that mandatory data in “Project information” is missing. | ||
| + | |||
| + | This window can save file settings and specify the author details. | ||
| + | |||
| + | === - Net Configurations === | ||
| + | Data settings to send emails directly from Qview without using an external client mail (Figure 73). | ||
| + | |See Figure 73: general setup.| | ||
| + | |{{ software: | ||
| + | - Mail From...: set the sender address. | ||
| + | This can be an existing personal email address.\\ | ||
| + | - Mail To…: the destination address. Usually support@qem.it, | ||
| + | - User ID: User ID for connection to the internet service provider(ISP).\\ | ||
| + | - SMTP Host: the electronic mail server address .\\ | ||
| + | - Port: the IP communication port. In general 25 is correct in most cases. | ||
| + | |||
| + | ===== - Menu Help ===== | ||
| + | ^This command is always available.^ | ||
| + | The help menu lists the Qview help guides. | ||
| + | |||
| + | ==== - Contents ==== | ||
| + | In-line help guide on the programming language. | ||
| + | |||
| + | |||
| + | ==== - QCL Language guide ==== | ||
| + | In-line QCL programming help guide. | ||
| + | |||
| + | ==== - Ladder Functions info ==== | ||
| + | In-line LADDER element help guide. | ||
| + | |||
| + | ==== - Functions info ==== | ||
| + | In-line help guide on the QCL functions. | ||
| + | ==== - User Functions info ==== | ||
| + | In-line help guide on the user QCL functions. | ||
| + | |||
| + | ==== - Technical Info ==== | ||
| + | To access the Technical Info data select: | ||
| + | TECHNICAL INFO to open the window in Figure 74 that summarises all the information about the PC used for Qview, complete with settings and advanced setup. Moreover the DLL files are recorded to obtain the most information possible.\\ | ||
| + | When all this information has been obtained it can be automatically transferred to a Word document, ready for sending by email (Figure 76), or this information can be sent automatically by email directly from Qview (Data Operations). | ||
| + | |Figure 74: information about the installed hardware and software.| | ||
| + | |{{ software: | ||
| + | The information is divided in three categories.\\ | ||
| + | - PC System Info: a summary of all information about the Computer Hardware and Software.\\ | ||
| + | - Qview System Info: a summary of all information about the Qview program.\\ | ||
| + | - Project Information Info: a summary of all information about the Qview project. | ||
| + | |||
| + | ==== - About Qview ==== | ||
| + | The QVIEW version and QEM srl contact details. | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Debug ====== | ||
| + | |||
| + | As mentioned at the beginning of this manual, QVIEW is an essential support for programming in QCL and LADDER, for writing and compiling the codes, and for debugging the final project.\\ | ||
| + | What is debugging? The time needed to develop a project can normally be divided evenly between the programming and the time for correcting errors. Debugging is the series of all activities that allow to detect any errors that cause unwanted behaviour. The following debugging tools are provided by QCL and LADDER : | ||
| + | * Execution step-by-step of the project (Step). | ||
| + | * Execution step-by-step of an individual module (Step over). | ||
| + | * Breakpoints. | ||
| + | * Watchpoint. | ||
| + | |||
| + | ==== - Step by step Execution ==== | ||
| + | After the project has been compiled and downloaded, the application can be executed by selecting the // | ||
| + | // | ||
| + | At each // | ||
| + | The // | ||
| + | |||
| + | ==== - Step Execution of a single unit ==== | ||
| + | The // | ||
| + | This command is useful to scan the code contained in a single unit of the project. | ||
| + | |||
| + | ==== - Breakpoints ==== | ||
| + | A breakpoint is a precise point in the program where execution of the project is interrupted. To set a breakpoint, place the cursor at the | ||
| + | point in editor where the program has to be stopped and select the // | ||
| + | The RUN command executes the program until it reaches the instruction marked by a breakpoint and it is stopped before the instruction. | ||
| + | The CPU will go into STOP status. The Breakpoint LED lights up in the CPU window to signal a breakpoint has been found. The editor marks the line targeted by the breakpoint with the symbol {{software: | ||
| + | |||
| + | ==== - Watchpoint ==== | ||
| + | Watchpoint is a breakpoint conditioned by the value of a variable, digital input or output, an array, Data Group or the parameter of a device.\\ | ||
| + | The watchpoint asks at what point in the program a parameter or variable acquires the set value.\\ | ||
| + | Select | ||
| + | |Figure 1: | ||
| + | |{{ software: | ||
| + | Use the //**Add**// button to select the name and parameter type for watchpoint.\\ | ||
| + | Then enter the value that triggers watchpoint and stops execution of the program. | ||
| + | |||
| + | |||
| + | < | ||
| + | |||
| + | ====== - The QCL Libraries ====== | ||
| + | |||
| + | The QCL libraries are an essential part of the QCL compiler. During compilation they provide a series of information concerning the devices and hardware. This information is necessary to know which parameters a device uses, their characteristics and memory location, which commands are available for any given device and its configuration syntax. | ||
| + | |||
| + | So when creating a new project check that the Qview version installed contains the libraries needed to manage the devices and hardware being used (refer to the hardware technical data sheets). Select //Technical Info// in the //Help// menu to open the window in figure 1. | ||
| + | |Figure 1: installed software components| | ||
| + | |{{ software: | ||
| + | The LIBRARY row specifies the library identifier in use (e.g. 1LIB3004).\\ | ||
| + | If there are not the required libraries, upgrade them by selecting //Upgrade Library...// | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix A: QCL Restrictions ====== | ||
| + | |||
| + | ==== - Maximum Number of labels ==== | ||
| + | When compiling certain QCL instructions the compiler generates internal labels that are used for later processes. A maximum of 999 labels can be generated for each task unit, over this the source file cannot be compiled. To know the number of internal labels generated it must be known that IF, ELSE, CALL, SUB, instructions or labels (e.g. MAIN) generate a label, while FOR and WHILE instructions generate two. The only solution is to eliminate some of these instructions from the source file to fall under this limit. | ||
| + | |||
| + | ==== - Maximum number of sets of terms ==== | ||
| + | When compiling expressions, | ||
| + | For example, this kind of instruction is allowed:\\ | ||
| + | Variable = 1+(1+(1+(1+(1+1))))\\ | ||
| + | while this causes an error:\\ | ||
| + | Variable = 1+(1+(1+(1+(1+(1+1)))))\\ | ||
| + | |||
| + | ==== - Maximum number of elements ==== | ||
| + | A Datagroup can have a maximum of 65534 elements and steps. Over this the compiler gives an error. | ||
| + | |||
| + | ==== - Maximum dimension of an Array ==== | ||
| + | An Array (both ARRSYS and ARRGBL) can have a maximum of 65535 elements. Over this the compiler gives an error. | ||
| + | |||
| + | ==== - FOR cyle ==== | ||
| + | A FOR cycle must have a numerical increase step, not variables or expressions that cannot be used. | ||
| + | |||
| + | ==== - Datagroup ==== | ||
| + | A Datagroup declaration must have a DATAPROGRAM subsection. | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix B: Type conversion and promotion ====== | ||
| + | |||
| + | ===== - Type conversions ===== | ||
| + | ^It is important to remember that the conversion from a whole type (i.e. Flag, Byte Word or Long) to Single type does not increase precision, it merely changes the format of the value.^ | ||
| + | An Expression is a series of operators, constants and variables whose result defines a number value. QCL provides the assignment | ||
| + | |||
| + | operator “=” in its general form: | ||
| + | |||
| + | variable = expression\\ | ||
| + | Multiple assignments type //variable = variable = expression// | ||
| + | In the assignment instruction, | ||
| + | |||
| + | For example:\\ | ||
| + | Consider the following variables: | ||
| + | <code QCL> | ||
| + | SYSTEM | ||
| + | sfFlag | ||
| + | sbByte | ||
| + | swWord | ||
| + | slLong | ||
| + | ssSingle S | ||
| + | </ | ||
| + | |||
| + | sbByte = swWord\\ | ||
| + | The first byte of the swWord variable is eliminated assigning only the significant byte to sbByte . If the value of swWord is between 127 and -128, the two values are seen as equal and no rounding down is made. If the value of swWord is out of this range, the value of sbByte only reflects the value of the less significant byte of swWord. | ||
| + | |||
| + | ssSingle = slLong\\ | ||
| + | The slLong value is converted to the real format with single precision. | ||
| + | |||
| + | sfFlag = ssSingle\\ | ||
| + | The sfFlag variable is assigned a value of 1 if ssSingle represents a value other than zero. | ||
| + | |||
| + | ===== - Type promotion ===== | ||
| + | When an expression uses different types of data, the QCL compiler converts them all into the same type and, in particular, in the type with the dimension that takes up the most memory, according to the common definition in langauges as //type promotion// | ||
| + | applied these conversion rules each pair of terms have the same dimension, which is also the dimension of the result. | ||
| + | |||
| + | For example: | ||
| + | <code QCL> | ||
| + | Variabile = (sbByte*sfFlag) + (swWord / sbByte) - (ssSingle+sfFlag) | ||
| + | </ | ||
| + | |||
| + | First the compiler converts sfFlag in BYTE and calculates the multiplication value, then second sbByte in WORD and calculates the division value, then sfFlag in SINGLE and calculates the value of the sum. The result of sbByte*sfFlag is converted in Word and its value is calculated. Then this result is promoted to SINGLE to carry out the subtraction from the result of ssSingle+sfFlag. | ||
| + | |||
| + | Constants in expressions are always converted in a whole type | ||
| + | (i.e. FLAG, BYTE, WORD or LONG) of the most suitable dimension to contain the value (if there are no decimal point in the constant). If the constant has a decimal point, it is converted to SINGLE type. | ||
| + | |||
| + | For example: | ||
| + | <code QCL> | ||
| + | Variabile = swWord / sbByte | ||
| + | </ | ||
| + | with swWord = 5 and sbByte = 2\\ | ||
| + | Variable is WORD type with value 2, thereby losing its decimals. | ||
| + | |||
| + | The expression is rewritten as follows: | ||
| + | <code QCL> | ||
| + | Variabile = (swWord * 1.0) / sbByte | ||
| + | </ | ||
| + | with swWord = 5 and sbByte = 2\\ | ||
| + | Variable is SINGLE type with a value of 2.5. This is because the product of the swWord variable with a constant with decimals causes the conversion of the result to SINGLE. | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix C: Code writing rules ====== | ||
| + | Qem highly recommends that programmers to follow the following simple rules when writing a code. These rules are not essential for funzionamento, | ||
| + | |||
| + | * code comprehension by a programmer who did not write the code | ||
| + | * to reduce the chance of errors in programming. | ||
| + | |||
| + | The rules are: | ||
| + | |||
| + | - write symbols in English | ||
| + | - upper case for names of constants and subroutines. Separate words with an underscore ' | ||
| + | - lower case for names of all local variables (i.e. scope limited to inside that unit). Separate words with an underscore ' | ||
| + | - upper case for local variables that have external scopes (i.e. IN, OUT or INOUT) . Do not use underscore' | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix D: Keywords ====== | ||
| + | |||
| + | |||
| + | A summary of the QCL keywords. | ||
| + | ^ ABS | absolute value | | ||
| + | ^ ACOS | arc cosine | ||
| + | ^ AND | logic AND | | ||
| + | ^ ANDB | bitwise logic And | | ||
| + | ^ APPLICATION | ||
| + | ^ ARRGBL | ||
| + | ^ ARRSYS | ||
| + | ^ ASIN | arc sine | | ||
| + | ^ ATAN | arc tangent | ||
| + | ^ B | byte | | ||
| + | ^ BEGIN | task unit code section | ||
| + | ^ BREAK | break | | ||
| + | ^ BUS | configuration file section | ||
| + | ^ CALL | call to subroutine | ||
| + | ^ CASE | SWITCH-CASE instruction | ||
| + | ^ CEIL | Nearest integer rounding not less than the given value | | ||
| + | ^ CONST | configuration file section | ||
| + | ^ COS | cosine | ||
| + | ^ COT | cotangent | ||
| + | ^ D | double precision | ||
| + | ^ DATAGROUP | ||
| + | ^ DATAPROGRAM | ||
| + | ^ DEVGROUP | ||
| + | ^ ELSE | Else in IF instruction | ||
| + | ^ END | task end | | ||
| + | ^ ENDDEVGROUP | ||
| + | ^ ENDIF | end of IF instruction | ||
| + | ^ ENDSUB | ||
| + | ^ ENDSWITCH | ||
| + | ^ ENDWHILE | ||
| + | ^ EQ | uguale | ||
| + | ^ EXP | exponential | ||
| + | ^ EXTDEVICE | ||
| + | ^ F | flag | | ||
| + | ^ FLOOR | Nearest integer rounding not greater than the value | | ||
| + | ^ FOR | FOR instruction | ||
| + | ^ GE | greater or equal to | | ||
| + | ^ GLOBAL | ||
| + | ^ GT | greater | ||
| + | ^ IF | IF instruction | ||
| + | ^ INPUT | configuration file section | ||
| + | ^ INTDEVICE | ||
| + | ^ ISFINITE | ||
| + | ^ ISINF | checks if the given number is infinite | ||
| + | ^ ISNAN | checks if the given number is NaN (Not a Number) | ||
| + | ^ ISNORMAL | ||
| + | ^ JUMP | JUMP instruction | ||
| + | ^ L | long | | ||
| + | ^ LE | less or equal to | | ||
| + | ^ LN | natural logarhythm | ||
| + | ^ LT | less than | | ||
| + | ^ MULDIV | ||
| + | ^ NEG | negative sign (inversion of sign or two's complement) | ||
| + | ^ NEQ | operatore | ||
| + | ^ NEXT | NEXT instruction | ||
| + | ^ NOP | NOP instruction | ||
| + | ^ NOT | not | | ||
| + | ^ NOTB | bitwise negation (one's complement) | ||
| + | ^ OR | logic OR | | ||
| + | ^ ORB | bitwise OR | | ||
| + | ^ OUTPUT | ||
| + | ^ POW | power of | | ||
| + | ^ REFERENCE | ||
| + | ^ REFERENCES | ||
| + | ^ RESOUT | ||
| + | ^ RESTART | ||
| + | ^ RESUME | ||
| + | ^ RETURN | ||
| + | ^ RMULDIV | ||
| + | ^ ROUND | Nearest integer rounding | ||
| + | ^ S | single precision | ||
| + | ^ SETOUT | ||
| + | ^ SHLL | shift logical left | | ||
| + | ^ SHLR | shift logical right | | ||
| + | ^ SIN | sine | | ||
| + | ^ SQRT | square root | | ||
| + | ^ STEP | configuration file section | ||
| + | ^ SUB | subroutine | ||
| + | ^ SUSPEND | ||
| + | ^ SWITCH | ||
| + | ^ SYSTEM | ||
| + | ^ TAN | tangent | ||
| + | ^ TIMER | configuration file section | ||
| + | ^ TRUNC | Nearest integer rounding not greater in magnitude | ||
| + | ^ W | word | | ||
| + | ^ WAIT | wait instruction | ||
| + | ^ WHILE | while instruction | ||
| + | ^ XORB | bitwise exclusive OR | | ||
| + | |||
| + | |||
| + | |||
| + | In addition these are the precompiler directives | ||
| + | ^#DEFINE| | ||
| + | ^#UNDEF| | ||
| + | ^#IFDEF| | ||
| + | ^#IFNDEF| | ||
| + | ^#ELSE| | ||
| + | ^#ENDIF| | ||
| + | ^#ERROR| | ||
| + | |||
| + | < | ||
| + | ====== - Appendix E: Hotkeys ====== | ||
| + | |||
| + | ^F1|Contents| | ||
| + | ^F2|-| | ||
| + | ^F3|Find Next| | ||
| + | ^F4|Next Unit| | ||
| + | ^F5|Run| | ||
| + | ^F6|Stop| | ||
| + | ^F7|Restart| | ||
| + | ^F8|Step| | ||
| + | ^F9|Toggle breakpoint| | ||
| + | ^F11|Go to PC| | ||
| + | ^F12|Next selected unit| | ||
| + | ^SHIFT + F2|Functions Info| | ||
| + | ^SHIFT + F4|Previous Unit| | ||
| + | ^SHIFT + F5|Move Rows Up (Editor LADDER)| | ||
| + | ^SHIFT + F6|Move Rows Down (Editor LADDER)| | ||
| + | ^SHIFT + F8|Step Over| | ||
| + | ^SHIFT + F9|Clear All| | ||
| + | ^SHIFT + F12|Previous selected unit| | ||
| + | ^CTRL + A|Redo| | ||
| + | ^CTRL + C|Copy| | ||
| + | ^CTRL + E|LADDER Element Properties...| | ||
| + | ^CTRL + F|Find| | ||
| + | ^CTRL + G|Go to| | ||
| + | ^CTRL + K|Compile| | ||
| + | ^CTRL + L|Download| | ||
| + | ^CTRL + N|Save project as ...| | ||
| + | ^CTRL + P|Print| | ||
| + | ^CTRL + R|Replace| | ||
| + | ^CTRL + S|Save project| | ||
| + | ^CTRL + T|Ladder Network Checking| | ||
| + | ^CTRL + V|Paste| | ||
| + | ^CTRL + X|Cut| | ||
| + | ^CTRL + Z|Undo| | ||
| + | ^CTRL + F1|Ladder Function Info| | ||
| + | ^CTRL + F2|Function Info| | ||
| + | ^CTRL + F3|View compilation results| | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix F: File generation ====== | ||
| + | |||
| + | ===== - File *.qm6: project file ===== | ||
| + | |||
| + | This file is created by QVIEW after executing the //New Project// command. It is an individual file for each application. | ||
| + | |||
| + | ===== - File created by compilation ===== | ||
| + | |||
| + | ==== - File *.sym ==== | ||
| + | A symbol file used for the operator interface management (i.e. HMI). It is needed for the HMI application and contains all the information needed to access the variables declared in the project. | ||
| + | |||
| + | ==== - File *.bin ==== | ||
| + | A file of the compilation that can be used for downloading into the CPU without using the serial communication (e.g. by Multi Media Card). | ||
| + | |||
| + | < | ||
| + | |||
| + | ====== - Appendix G: Compatibility with previous versions ====== | ||
| + | |||
| + | The development environment is full compatible with previous versions and releases.\\ | ||
| + | A project created in Qview3, Qview 4 and Qview 5 can be opened in Qview 6. | ||
| + | |||
| + | When opening a project created with a previous Qview, Qview6 applies automatically transforms some parts of the code to adapt them to the new syntax. These transformations are: | ||
| + | |||
| + | ^ Access type ^ previous Versions | ||
| + | |Comandi ai device|< | ||
| + | |Device parameters|< | ||
| + | |system variables|QMOVE:< | ||
| + | |Unit scheduling controlls|T_RESTART <unit name> | ||
| + | |::: | ||
| + | |::: | ||
| + | |Unit suspended status|QMOVE: | ||
| + | |Arrary dimension|< | ||
| + | |Remaining time for timer|< | ||
| + | |||
| + | When compiling a project created with a previous Qview, Qview6 may notify the following errors that were not detected by the previous | ||
| + | |||
| + | Qview: | ||
| + | |||
| + | * The same name cannot be used for a //label// and a // | ||
| + | * It is not possible to write the // | ||