Sección 5: Funcionamiento
5.4 Procedimiento de arranque subsiguiente
I want to stop here and talk about folder ordering. First of all, TwinCAT 3 will order the folders and items in a folder alphabetically. Secondly, TwinCAT 3 has a bug where it will only re-order them after you save your project, close the solution and open it again. Initially they show up based on the original folder name, which was NewFolder1(hopefully this is fixed in a later version). Since the folders represent the major components of our machine, we want the ordering to flow logically from the way the machine works. If the machine works by parts being introduced to the machine on the infeed conveyor, and are then processed by the pick & place, then it makes the most sense to have the InfeedConveyor folder come before PickAndPlace folder. It just so happens that “I”
comes before “P” in the alphabet, but this is only a happy coincidence. That’s why I suggest prefixing each folder with a number so you can enforce a logical ordering:
I used two digit numbers because that will allow it to sort correctly from 01 through 99. Don’t worry about needing to insert one later as renumbering even 10 or 20 folders doesn’t take very long.
Now let’s add a Global Variable List for the infeed conveyor. Right click on the01_InfeedConveyor folder and select Add -> Global Variable List+ from the context menu. That will display the Add Global Variable List dialog.
Enter InfeedConveyorin the Name text box and click the Open button:
Now you’ll see an empty global variable list in the editor:
Now we have to imagine some global variables that our imaginary conveyor might have. I think it needs an output to turn on the motor (we’ll call that “Run”), a through-beam sensor across the end of the conveyor to sense when a part reaches the pick position (we’ll call that the “NoPart” input) and maybe this conveyor needs to signal to the pick & place that the conveyor is stopped (we’ll call that the “Stopped” interlock). Here’s what a global variable list with those 3 variables would look like:
Let’s look at the first variable:
NoPart AT %I* : BOOL; (* Through-beam sensor *)
The line starts with the variable name (NoPart). Typical variable naming rules apply, so you can’t start the name with a number, and you can’t have spaces or special characters in the name, except an underscore. Here I’ve used the PascalCase way of writing the variable, by sticking capitalized words together. You don’t have to use PascalCase, but you should pick a consistent way of naming your variables and stick with it.
After the variable name is an optional element that defines the variable as an input or output (AT %I*). The “I” means input and a “Q” means output. Adding this element will force the variable to show up in the PLC project’s I/O map which makes it available for linking to physical I/O. Inputs are set by the input scan before your logic runs, and outputs are set by your
logic, but copied to the physical outputs during the next output scan. (Technically the input an output scans happen at the same time.)
A colon (:) separates the declaration of the variable from the variable type (BOOL). Here are the common types you’ll use, though there are more:
•
BOOL: A boolean value (TRUE or FALSE)•
BYTE: An 8-bit unsigned integer value (0 to 255) aka USINT•
SINT: An 8-bit signed integer value (-128 to 127)•
WORD: A 16-bit unsigned integer value (0 to 65,535) aka UINT•
INT: A 16-bit signed integer value (−32,768 to 32,767)•
DWORD: A 32-bit unsigned integer value (0 to 4,294,967,295) aka UDINT•
DINT: A 32-bit signed integer value (−2,147,483,648 to 2,147,483,647)•
ULINT: A 64-bit unsigned integer value (0 to 18,446,744,073,709,551,615), new in TwinCAT 3•
LINT: A 64-bit signed integer value (-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807), new in TwinCAT 3•
REAL: A 32-bit floating point value•
LREAL: A 64-bit floating point value•
STRING: An ASCII null-terminated string, default 80 characters•
STRING(n): An ASCII null-terminated string, with max length “n” characters•
TIME: A 32-bit time value (typically used in timers)A note on how much memory each one takes: for anything that says “8-bit”, “16-bit”, “32-bit” or “64-bit” then the memory usage is 1 byte, 2 bytes, 4 bytes, or 8 bytes respectively. A BOOL could be represented by a single bit, but takes a full byte (this is for performance reasons). There is also a rarely used data type called BIT which uses a single bit, and can have the values 0 and 1, but this is not equivalent to a BOOL. ASTRING takes 81 bytes (80 for the characters and 1 for the null terminator) and aSTRING(n) takes n+1 bytes.
Beckhoff’s Infosys site has more information about TwinCAT 3 Data Types.
After the data type, there is a terminating semi-colon (;). The compiler stops reading here.
After the semi-colon you can put an optional comment ((* Through-beam sensor *)). There are two ways to insert comments: you can enclose them in bracket-asterisks, as I did, or you can preface them with a double-slash (//). Note that comments will show up as tool-tips when you hover your mouse over any use of this variable in your logic, so they are helpful.
The other thing that shows up in a tool-tip over a variable is the data type (BOOL, INT, etc.). Long before we had helpful features like this in our IDE, programmers invented a system for embedding the type of the variable in the variable name called Hungarian Notation. You will often see TwinCAT code examples, even in the official documentation, that use
Hungarian Notation (such as bIsTRUE : BOOL;). This is now discouraged thanks to smarter and more helpful editors. In general you should avoid Hungarian Notation in your TwinCAT 3 programs.
When you refer to global variables in your logic, you should use the fully qualified name of the variable (including the Global Variable List name) such asInfeedConveyor.Run. Technically it will let you omit the Global Variable List name and just use the variable name (Run). This is a throw-back to TwinCAT 2 where there was only one Global Variable List. You don’t want to run into a situation where it gets confused with another global variable called Run in another Global Variable List (OutfeedConveyor.Run would be an obvious one). If you happen to do this, the compiler will give you an error telling you that you have an ambiguous variable name and it will force you to use the fully qualified name. I suggest using fully qualified names for all global variables.