Differences: Predecessor product to current product
When you migrate logi.CAD/32 projects/objects to logi.CAD 3 projects/objects, you will notice that the resulting logi.CAD 3 projects/objects differ from the logi.CAD/32 projects/objects in some aspects. The main reason for the differences is that:
logi.CAD 3 is based on the standard IEC 61131-3, edition 3.0 (= IEC-standard).
logi.CAD/32 is based on the standard IEC 61131-3, edition 2.0 but there have been deviations from it.
logi.cals tries to provide a complete list regarding the differences of the logi.CAD/32 compared to logi.CAD 3. However, be aware that this list does not claim to be comprehensive. Please inform logi.cals when you become aware of additional differences so that this list is modified/enhanced accordingly.
The following tables inform in which aspects logi.CAD 3 differs from its its predecessor logi.CAD/32. The aspects are grouped as logi.cals sees fit.
Explanation for tables
The columns of the tables have the following meaning:
Title specifies the appropriate aspect as known from logi.CAD/32.
Migration points out how the migration handles the aspect. Mind that the aspect is adjusted so that it matches the implementation in logi.CAD 3.
Migration can be done by the migration wizard or a command line interface for migration (identified as "headless tool" in the following description). Some of the migration results can be changed by configuring a file in JSON format (= JSON file) for the migration wizard or by specifying appropriate parameters when invoking the headless tool. See the documentation "Administrator's Manual" for information about the configuration possibilities for the migration wizard and the invocation of the headless tool and its parameters.
The icons used in this column have the following meaning:The aspect will be migrated.
The aspect will be migrated. But logi.cals advises you to check the results in logi.CAD 3. If they are not to your liking, you might have to adjust them in logi.CAD 3.
The aspect will be migrated. But logi.CAD 3 will report some problems after the migration of this aspect. Check the results in logi.CAD 3 and fix the reported problems.
The aspect will not be migrated.
If this aspect is not supported in logi.CAD 3, the results in logi.CAD 3 will not contain this aspect. Otherwise the columns to the right inform what can be done or how the aspect is realized in logi.CAD 3.LC32 informs about details of the aspect how it is realized for logi.CAD/32. Just the different parts are mentioned.
LC3 informs about details of the aspect how it is realized for logi.CAD 3. Just the different parts are mentioned.
Basics
Title |
Migration |
LC32 |
LC3 |
identifiers in the logic
|
If you are interested in a different replacing method, it is possible to specify a replacement list and/or the simpler algorithm (instead of the default one). This is possible for the migration wizard (by changing a JSON file) as well as the headless tool (by specifying the appropriate parameter).
Only in case of inputs (also BYREF inputs) as well as outputs: The original identifier of the logi.CAD/32 input/output is automatically used as alternate name for the logi.CAD 3 input/output as long as no alternate name is displayed for the input/output in logi.CAD/32. |
Non-IEC-conform identifiers are allowed.
At special locations (e.g. at the declaration location), such identifiers might have been embedded in: @"" |
Only IEC-conform identifiers are allowed.
Example: Pulse_On |
reserved keywords |
Identifiers that are reserved keywords are automatically replaced as follows:
|
Such identifiers are allowed. |
Such identifiers might not be allowed – depending on the context See the logi.CAD 3 product user documentation for information on reserved keywords in logi.CAD 3 product – search for "Reserved keywords in ST". |
names of system blocks as names for user-defined blocks in the logic (ST and FBD) |
The names of system blocks are automatically replaced, if they are used as
Example: The user-defined block Move becomes: _8_Move If you are interested in a different replacing method, specify a replacement list and/or the simpler algorithm (instead of the default one). This is possible for the migration wizard (by changing a JSON file) as well as the headless tool (by specifying the appropriate parameter). |
Names of system blocks are allowed as names for user-defined blocks.
|
Names of system blocks are not allowed as names for user-defined blocks.
|
names of system blocks as names for variables or structuring elements in the logic (ST and FBD) |
Names of system blocks are allowed as names for variables or structuring elements. Example: variable Move |
|
|
Case of letters in identifiers
|
Case sensitive identifiers for local variables become unique identifiers. logi.CAD 3 will report errors for other case sensitive identifiers, i.e. for for inputs, outputs, global/external variables or blocks. |
case sensitivity of identifiers
|
case insensitivity of identifiers
|
Objects in Project Management
Errors and omissions when migrating objects
When a logi.CAD/32 object is exported to an XML-file but this object is not supported in logi.CAD 3, the migration using this XML-file will not be successful. Example: A documents-object is exported.
Best practice is to export the parent object of such objects (e.g. the project) to an XML-file. The migration using this XML-file will skip the objects not supported.In logi.CAD/32, it is possible to enter various definitions in the properties of objects (in the tabs). Most of these definitions are not migrated to logi.CAD 3.
Definitions not migrated are: printing forms (entered in tab Print-Forms), information for print-outs (entered in tab Master Data, Var.-List, Print-Order, Contents, GV-XRef, Var.-XRef), specific settings (entered in tab More), basic text for documentation (entered in tab Documentation), information for signal list (entered in tab SIG, Signal List or Signal-XRef)
Those definitions that are migrated are listed in the following table.
Title |
Migration |
LC32 |
LC3 |
project |
Blanks in the project name are deleted.
|
Blanks in the project name are allowed.
|
Only a project name without blanks is allowed.
|
libraries |
|
Libraries are realized ... |
... as folders. |
POU(ST);
|
|
POU(ST) are realized ... |
... as ST-objects. |
program types(ST) |
|
|
ST-objects containing one program |
function block types(ST) |
|
|
ST-objects containing one function block |
functions(ST) |
|
|
ST-objects containing one function |
for default migration when using the migration wizard
It is not possible to change this migration result (by changing a JSON file). |
The function(ST) becomes... |
... a function block(ST). |
|
for default migration when using the headless tool (without parameter -userFunctionsAsFunctionBlocks):
|
The function(ST) becomes... |
... a function (ST). |
|
data types |
|
Data types are realized ... |
... as ST-objects containing one data type. |
POU(FBD);
|
|
POU(FBD) are realized ... |
... as FBD-objects. |
program types(FBD) |
|
|
FBD programs |
function block types(FBD) |
|
|
FBD function blocks |
functions(FBD) |
|
|
FBD functions |
for default migration when using the migration wizard
It is not possible to change this migration result (by changing a JSON file). |
The function(FBD) becomes... |
... a function block(FBD). |
|
for default migration when using the headless tool (without parameter -userFunctionsAsFunctionBlocks):
|
The function(FBD) becomes... |
.... a function(FBD). |
|
POU(LD);
|
|
|
not supported |
program types(LD) |
|
|
not supported |
function block types(LD) |
|
|
not supported |
functions(LD) |
|
|
not supported |
configurations |
|
Configurations are realized ... |
... as items within a PLC-object. |
resources |
|
Resources are realized ... |
... as items within a PLC-object. |
program instances |
|
Program instances are realized ... |
... as items within a PLC-object. |
type instances |
Type instances are migrated to program types and program instances. |
A type instance becomes ... |
|
task |
Tasks are migrated with an exception. |
Tasks are realized ... |
... as items within a PLC-object. |
global variables in configurations |
|
Configuration-global variables are realized ... |
... as global variables in a global-object (located in a folder with the name of the configuration). The configuration in the PLC-object contains a reference to these global variables. |
global variables in resources |
|
Resource-global variables are realized ... |
... as global variables in a global-object (located in a folder with the name of the resource). The resource in the PLC-object contains a reference to these global variables. |
documents-objects |
|
|
not supported |
structuring folders |
|
Structuring folders are realized ... |
... as folders. |
links |
|
|
Create a linked resource in logi.CAD 3. |
non logi.CAD/32 objects
|
|
Such objects must be copied from the logi.CAD/32 project ... |
... into the logi.CAD 3 project. |
vendor libraries with
vendor function blocks and/or
|
Only the interface of vendor function blocks and vendor functions is migrated.
Regarding the sorting of variables:
Use POU-unique names (when possible, project- and POU-unique) for all C-identifiers that are available in a global namespace. Details on the reason for this can be found in the logi.CAD 3 user documentation, under "The dos and don'ts when working, When creating blocks with C-code". |
The required C-code must be integrated ... |
... into the application in logi.CAD 3. |
definitions entered by an OEM in the tab Master Data for vendor function blocks and/or vendor functions |
– if the project/objects are migrated when using the headless tool and the corresponding OEM-parameter -customerMode OEMID This migration result is also possible when using the migration wizard (by changing a JSON file). Contact logi.cals for more information. |
The definitions become ... |
... so-called instance parameter items. |
signal data base |
|
|
not supported |
properties LC3_Namespace and LC3_Using (entered in tab More) for POUs, program instances and data types |
|
The values might be a comma-separated list. These values become ... |
... the according settings for namespaces. |
Contact logi.cals, if you are interested in details on how to specify the mentioned logi.CAD/32 properties. |
Supported elementary data types
Title |
Migration |
LC32 |
LC3 |
BOOL |
|
|
|
SINT |
|
|
|
USINT |
|
|
|
BYTE |
|
|
|
INT |
|
|
|
UINT |
|
|
|
WORD |
|
|
|
DINT |
|
|
|
UDINT |
|
|
|
DWORD |
|
|
|
REAL |
|
|
|
LREAL |
|
|
|
TIME |
|
|
|
DATE |
|
lower limit: D#0001-01-01 |
lower limit: D#1970-01-01 |
TIME_OF_DAY |
|
upper limit: TOD#23:59:59.9999 |
upper limit: TOD#23:59:59.999_000_000 |
DATE_AND_TIME |
|
lower limit: DT#0001-01-01-00:00:00.00 |
lower limit: DT#1970-01-01-00:00:00.000_000_000 |
STRING |
String literals not conform to the IEC-standard are migrated. This affects e.g. string literals with double quotes or with special characters. |
String literals (constants) with double quotes are migrated ...
|
... to string literals with single quotes.
|
for default migration when using the migration wizard: Strings without a size become strings with a length of 250. Strings with a size always keep their length – no matter if the parameter -stringLength is specified or not. |
|
|
|
for default migration when using the headless tool (without parameter -stringLength): Strings without a size become strings with a length of 128. Strings with a size always keep their length – no matter if the parameter -stringLength is specified or not. |
|
|
Variable declarations for ST and FBD
Title |
Migration |
LC32 |
LC3 |
variables in programs |
– as specified in this table |
|
|
variables in function blocks |
– as specified in this table |
|
|
variables in functions |
The storing behavior changes.
Observe that it is possible to migrate LC32 functions so that they become LC3 function blocks. As a consequence, the storing behavior does not change for the included variables (see " Objects in Project Management", items " functions(ST)" and functions(FBD) for details). |
Variables in functions have storing behavior. |
Variables in functions do not have storing behavior. |
variables
|
|
|
|
VAR |
Regarding the sorting of variables:
|
|
|
VAR_INPUT |
|
|
|
VAR_OUTPUT |
|
|
|
VAR_GLOBAL |
Regarding the sorting of variables:
|
|
|
VAR_EXTERNAL |
Initial values for VAR_EXTERNAL are discarded.
Regarding the sorting of variables:
|
Initial values for VAR_EXTERNAL are possible. |
Initial values for VAR_EXTERNAL are not possible. |
variables
|
|
|
|
derived variables |
|
|
|
subrange variables |
The variable is migrated but the subrange is lost. |
The subrange becomes... |
a comment. |
array variables |
|
|
|
enumeration variables |
logi.CAD 3 will report errors for such variables. |
|
not supported |
variables
|
|
|
|
CONST |
A variable with attribute CONST is migrated.
|
CONST becomes... |
CONSTANT.
|
RETAIN |
A variable with attribute RETAIN is migrated. |
The attribute is lost or highlighted as faulty for VAR_EXTERNAL, VAR_TEMP or BYREF ... |
because RETAIN is not supported there. |
BYREF |
A BYREF input is migrated to an in-out variable.
|
The BYREF input becomes... |
an in-out variable (VAR_IN_OUT). |
visualize |
|
|
not supported |
parameter |
|
|
not supported |
the following pieces of information for variables |
|
|
|
long name |
The long name is automatically enclosed by single quotes: '' |
Single quotes '' within the long name are replaced... |
by double quotes "" within the long name. |
comment |
The comment is automatically enclosed by single quotes: '' |
Single quotes '' within the comment are replaced... |
by double quotes "" within the comment. |
technical units |
|
|
not supported |
scaling |
|
|
not supported |
alternate names for in-/outputs |
Alternate names are only migrated in case of the active LC32 setting Alternate I/O-names. There is a special behavior, if no alternate name for an input (also BYREF input) or output is displayed and the identifier is a non-IEC-conform identifier: The original identifier of the logi.CAD/32 input/output is automatically used as alternate name for the logi.CAD 3 input/output (see item "identifiers in the logic (ST and FBD)" for more information). |
|
|
physical address |
Physical addresses for outputs are migrated to hardware addresses for outputs conform to the IEC-standard.
Invalid physical addresses are removed. |
Example: %OB0 is migrated to... |
%QB0. |
additional information e.g. for variables (specified by an OEM) |
|
The definitions become... |
... initial values of the so-called instance parameter. |
Data type declarations
Title |
Migration |
LC32 |
LC3 |
declarations
|
|
|
|
derived data types |
|
|
|
subrange data types |
The data type is migrated but the subrange is lost. |
The subrange becomes... |
a comment. |
array data types |
|
|
|
enumeration data types |
logi.CAD 3 will report errors for such data types. |
|
not supported |
structured data types |
Regarding the sorting of variables:
|
|
Regarding the sorting of variables:
|
the following pieces of information for structure elements |
|
|
|
long name |
The long name is automatically enclosed by single quotes: '' |
Single quotes '' within the long name are replaced... |
by double quotes "" within the long name. |
comment |
The comment is automatically enclosed by single quotes: '' |
Single quotes '' within the comment are replaced... |
by double quotes "" within the comment. |
scaling |
|
|
not supported |
layout for data types: color, line type |
|
|
The default layout is used. |
Elements for function block diagram
If the POU(FBD) in logi.CAD/32 contains faulty FBD-elements, those FBD-elements are still faulty in logi.CAD 3.
Title |
Migration |
LC32 |
LC3 |
empty value fields |
|
|
not supported |
value fields with content and the following pieces of information |
|
|
|
position, size |
|
|
|
text (variable or literal) in value field |
|
String literals (constants) with double quotes are migrated ...
|
... to string literals with single quotes.
|
inverted, connected in-/outputs |
|
Inverted in-/outputs are called ... |
... negated in-/outputs. |
inverted, unconnected in-/outputs |
|
|
not supported |
layout: color, font |
|
|
The default layout is used. |
flipped value fields |
Re-position such value fields in order to correct the line connections. |
Flipped value fields become ... |
... normal values fields but the original line connections are kept. |
call of function block or functions with the following pieces of information |
|
|
|
position, size |
|
|
|
name of function block or function |
|
|
|
in-/outputs: name and position |
|
|
|
EN and ENO: behavior |
The left columns contain only the differences.
|
The different behavior, when EN=FALSE:
|
The different behavior, when EN=FALSE:
See the logi.CAD 3 user documentation for information on the behavior in logi.CAD 3 – search for "Execution control: EN, ENO". |
inverted, connected in-/outputs |
|
Inverted in-/outputs are called ... |
... negated in-/outputs. |
inverted, unconnected in-/outputs |
|
|
supported but such inputs are causing a warning |
layout: color, font |
|
|
The default layout is used. |
displayed instance name |
|
|
|
displayed priority |
|
|
not supported |
flag for inline |
|
|
not supported |
flag for retain |
|
|
not supported |
instance data |
Some lists and/or a format string might become normal text. |
The list %"@ID:*" ... %"" becomes ...
Wildcards for data items within the list are supported in logi.CAD/32.
|
... the appertaining dynamic text for the instance data: {instanceData("...")}
Wildcards for the instance data elements are not supported in logi.CAD 3.
|
comment fields with the following pieces of information |
|
|
|
position, size |
|
|
|
text in comment field |
|
|
|
graphics in comment field |
|
|
not supported |
layout: color, font |
|
|
The default layout is used. |
comment fields attached to empty value fields |
|
|
not supported |
comment fields attached to other elements in FBD |
Some format strings might become normal text. |
Attached comment fields become ...
|
... attached comment fields.
|
connector fields with the following pieces of information |
|
Connector breaks are called ...
|
... connectors.
|
position, size |
|
|
|
text in connector field |
|
The text (name) for the connector is adjusted ... |
... so that the name is unique.
|
layout: color, font |
|
|
The default layout is used. |
flipped connector fields |
Re-position such connector fields in order to correct the line connections. |
Flipped connector fields become ... |
... normal connector fields but the original line connections are kept. |
invisible connector fields (= mini connector fields) |
|
Invisible connector fields become ... |
... normal connector fields. |
lines connected to FBD-elements, connecting an input with an output |
|
|
|
lines connected to FBD-elements, connecting an input with a different input |
Such lines are migrated but they are highlighted as faulty in logi.CAD 3. |
It is possible to create a line and its starting or ending point are different inputs. |
It is not possible to create such lines. |
open lines
|
|
It is possible to create a line and its starting or ending point is not connected to any element. |
It is not possible to create such lines. |
line connections with the following pieces of information |
|
|
|
routes of lines |
|
|
|
fixed nodes for lines |
|
Nodes for lines are called ... |
... connection points. |
layout: color, font |
|
|
The default layout is used. |
OLT-fields in function blocks or programs |
|
|
|
OLT-fields for value fields with content |
|
|
|
OLT-fields for empty value fields |
|
|
not supported |
OLT-fields for function block instances |
|
|
|
OLT-fields for function calls |
|
|
not supported |
OLT-fields for in-/outputs of function block instances |
|
|
|
OLT-fields for inputs of function calls |
|
|
not supported |
OLT-fields for outputs of function calls |
|
|
|
unconnected OLT-fields |
|
|
not supported |
OLT-fields in functions |
|
|
not supported |
OLE-objects |
|
|
not supported |
feedback loops |
Feedback loops are not touched.
|
A feedback loop caused after a function call is allowed. |
A feedback loop caused after a function call is only allowed, if a value field or a function block call follows the function call. Depending on the configuration of logi.CAD 3, feedback loops for functions without a variable in between are highlighted as error or warning. |
execution order of networks, if all network inputs are part of explicit feedback loops within the network |
A different execution order might result. This different execution order of networks might influence the behavior at the end of the task cycle. |
If all inputs of the network are part of explicit feedback loops within the network or an input is used as output by another network, the network cannot be evaluated at first.
|
If all inputs of the network are part of feedback loops within the network, the network can be evaluated.
|
execution order of networks, if a variable is used as array index for statements |
A different execution order might result. |
In the default variant, logi.CAD/32 distinguishes where the array variable is used for the statement:
Note: There is a processing variant for logi.CAD/32 that is identical to the logi.CAD 3 behavior. |
logi.CAD 3 always waits for the evaluation of the variable which is used as array index – no matter where the array variable is used for the statement. |
execution order within networks |
A different execution order might result, if:
|
|
Note:
Different rules are applied, if you have used the start option lc3.fbdStatementSortLC32 to activate the execution order modeled after the predecessor product logi.CAD/32. The behavior modeled on the predecessor product corresponds to the behavior in the predecessor product with the logi.CAD/32 environment variable LC32_SORTORDER_TAR_DEP_CHECK=1. Details about the rules of the execution order for logi.CAD/32 can be found in the online help of logi.CAD/32. the information about LC32_SORTORDER_TAR_DEP_CHECK=1 can be found in the documentation for administrators of the predecessor product (in the article "Defining Processing Variant Concerning Variables Used as Array Index").
|
the following pieces of information for FBD-elements |
|
|
|
hyperlinks |
|
|
not supported |
properties |
|
|
not supported |
shapes |
|
|
not supported |
the following pieces of information for the drawing field |
|
|
|
size |
|
Example: The page size "DIN A3" in logi.CAD/32 becomes... |
page size "DIN A4" in logi.CAD 3. |
layout: value field area |
|
|
|
other layout: connector field area, grid, color, DXF-forms in background |
|
|
The default layout is used. |
the following pieces of information for the sheets |
|
|
|
page number, short name |
|
|
not supported |
long name |
|
The long name becomes... |
the page name. |
information on creation, changes |
|
|
not supported |
information on labeling system: ULS, PPLS, page ID |
|
|
not supported |
Sequential function chart (SFC)
Title |
Migration |
LC32 |
LC3 |
steps and initial steps |
|
|
|
transitions |
Transitions with an inverted input for the transition condition but without a connected value field differ in their behavior. |
Such transitions are never enabled. |
Such transitions are not supported in logi.CAD 3. An error message will report this error. |
action blocks |
|
The comment of an action block...
|
... is not supported in logi.CAD 3.
|
connecting one step to one transition and vice versa |
Check the messages of the logi.CAD/32 tool LCxmlExport whether error messages on SFC connections prevent a migration. |
|
|
other connections for step sequences:
|
|
Lines of these connections are ... |
... displayed with another line style. |
execution order of SFC networks and SFC elements |
The execution order of SFC differs. |
The execution order of SFC differs ... See the logi.CAD/32 online-help for information on the behavior in logi.CAD/32. |
... from the evaluation of SFC elements. See the logi.CAD 3 user documentation for information on the behavior in logi.CAD 3. |
Ladder diagram
Title |
Migration |
LC32 |
LC3 |
LD (ladder diagram) |
If you migrate ladder diagrams anyway, it is likely that the results in logi.CAD 3 will differ from your expectations. |
Ladder diagrams in logi.CAD/32 are differently realized ... |
... than in logi.CAD 3. |
System function blocks or functions
See "Differences: System blocks in predecessor product to current product".
Graphical interfaces for user-defined function blocks or functions
Title |
Migration |
LC32 |
LC3 |
displayed text: name |
|
|
|
displayed text: alternative text |
|
|
|
size |
|
|
|
extendable |
|
|
|
in-/outputs |
|
|
|
position of in-/outputs |
|
|
|
layout: background color |
|
|
|
other layout options, such as font |
|
|
The default options for the layout are used, when a new call is set. |
the following pieces of information |
|
|
|
setting whether a specific in-/output is to be inverted |
|
|
not supported |
setting whether instance name is to be displayed |
|
|
|
setting whether to generate INLINE-code |
|
|
not supported |
setting whether EN and ENO are to be displayed |
|
|
not supported |
setting Alternate I/O-names (= whether alternate names for in-/outputs are to be displayed) |
The behavior is slightly different.
|
The alternate names are used for the visual display, only if the LC32 setting is checked.
|
The alternate names are automatically used for the visual display.
|
setting for priority |
|
|
not supported |
the following elements in the interface |
|
|
|
attribute input fields |
|
|
not supported |
comment fields containing the format string %I for the instance name |
|
Such comment fields become ... |
... the instance name displayed within the interface. |
other comment fields |
|
Format strings in comment fields, such as %t and %q, become ...
|
... normal text (such as the type name). |
layout of comment fields |
|
The layout of comment fields is migrated... |
as far as LC3 supports the respective layout option. |
value fields for an input, if the input is not connected |
|
The value field incl. its content ... |
... is migrated. Reason: The content of the value field (e.g. a literal) is used as value for the input. |
value fields for an input, if the input is connected |
|
Only the value field ... |
... is migrated.
|
graphics |
|
|
not supported |