About compatibility:

If you have used a previous version of logi.CAD 3 and you want to use the current version, see "Are my projects upwards and downwards compatible?" for important information.

On the Log4j security vulnerability:

See "Is the IDE affected by the Log4j security vulnerability (December 2021, CVE-2021-44228, Log4Shell)".

About system libraries:

See "Release notes for system libraries".

On version 3.16.2:

Due to the problem according to the ID "108185" logi.cals recommends using the qualified version 3.23.2 instead of the version 3.16.2.
See "Release history" for more information on the provided releases.

About t he →runtime system :

If you are using logi.CAD 3 version 3.16.2, install and use the version 5 .14.0 of the runtime system.
The installation package for the runtime system is included in the delivery range of logi.CAD 3.

If you are using an older version of the runtime system, it might not be possible to successfully connect to the target system from within logi.CAD 3 (see troubleshooting article "No connection to the target system, but there are error messages)".
See the FAQ article "When to update the version of the runtime system on the PLC?", if you need information on how to check whether the runtime system version appropriate for logi.CAD 3 is used on the PLC.

About →Raspberry Pi :

See the tutorial "Putting Raspberry Pi into operation" which version is recommended by logi.cals for usage.

53067
(51356)

Validating the application

In case of the activated rule "Only identifiers conform to predefined specifications must be used for projects/folders/objects.", an exception is caused when creating a device object.
Fix: The problem according to the following scenario does not occur anymore.
Scenario for problem: When you activate the rule Only identifiers conform to predefined specifications must be used for projects/folders/objects, it is not possible to create a new device object because an exception is caused. In this case, the dialog to create the object does not display an enabled button Finish and the error log displays the messages Unhandled event loop exception.

53388
(51290)

Validating the application

In case of a validation relating to the instance and the activated rule "Illegal elementary data types must not be used", an exception might occur.
Fix: The exception does not occur for the following scenario anymore.
Scenario for problem: When you validate the elements of a resource and these elements contain a type with a recursion, the validation with the activated rule Illegal elementary data types must not be used causes an exception. In this case, the following message is displayed in a dialog and the error log:

53401

Building the application

An exception might occur when building the application for the built-in PLC.
Fix: The exception does not occur for the following scenario anymore.
Scenario for problem: It might be possible that the application cannot be built for the built-in PLC, although the application does not contain any error. In this case, the error log displays the following message (twice): Cannot invoke "com.logicals.lc3api.model.Project.getProgramOrganiationUnit(String)" because the return value of "com.logicals.projectindex.db.DbDataType.getProject()" is null
There are not details on the problem cause.

54980

Validating the application

An exception occurs when validating a resource containing a missing program type.
Fix: The exception does not occur for the following scenario anymore.
Scenario for problem: When you validate the elements of a resource and the specified program type does not exist, the validation causes an exception. In this case, the following message is displayed in a dialog and the error log:

Workaround: Specify an existing program type before validating the resource.

55306

Validating the application

The rule "C-blocks must only be contained in libraries" does not recognize all forbidden usages of a vendor block.
Fix: The rule recognizes the usages of a vendor block according to the following scenario, too.
Scenario for problem: The rule C-blocks must only be contained in libraries checks whether the used C-blocks (such as vendor blocks) are contained in libraries. The validation does indeed report the call of a vendor block that is located in the current project itself. However, if the same vendor block is used e.g. in statements only, this usage is not reported. It is possible that other usages of the vendor block are neither reported (e.g. the call of a vendor block in a value field).

55333

Building the application

A compiler warning might occur when building an application where REAL is converted to another data type.
Fix: The compiler warning does not occur for the following scenario anymore.
Scenario for problem: When an application converts REAL to another data type (e.g. by calling the TO_UDINT block with a connected REAL variable), the following compiler warning might be displayed when building the application:

Additional information:

1. The problem occurs only, if the compiler option -Wdouble-promotion has been activated by the system integrator. The problem does not occur for the built-in PLC.

2. The compiler warning is listed in the Build Log view, under Compiler and Linker Output.

55486

Validating the application

Vendor functions are not listed in the MRC-report when validating the application.
Fix: Vendor functions are listed in the MRC-report as well.
Scenario for problem: The generated MRC-report (a report with the file extension .mrclog) contains information about the executed static code analysis. In particular, the names and the fingerprints of each application element is listed in this MRC-report. However, a vendor function (= a vendor block declared as function) is not listed in the MRC-report.

55895

System blocks

The EXPT block and the operator do not work as expected for large values. This is valid for the negative return values exceeding ≤ -2**32.
Fix: The problem does not occur anymore. The correct values are returned and the ENO output returns TRUE.
Scenario for problem: The EXPT block and the corresponding ST-operator ** do not work as expected in the case that the following values should be returned:

• Wrong values are returned when a return value between -2**32 and -2**63 should be returned. In this case, the ENO output is not reset to FALSE but TRUE is returned. So unfortunately there is no pointer to this type of problem.
  Observe that such a return value can be calculated by different block inputs or operands respectively. Here are some samples how the block might be supplied with input values:

  IN1 (see: NOTE 1)	IN2 (as the exponent)
  -1291	3
  -74	5
  -22	7
  -11	9
  -8	11

  NOTE 1: The specified value for IN2 is the limit. This value and higher values will cause the above-mentioned problem.

• Moreover, the calulation of -2**63 resets the ENO output to FALSE. This indicates that an error has occurred for the block. Actually, the correct result is returned.

54218

"Instances" view

The fingerprint for the resource might change when a project is cleaned.
Fix: The fingerprint for the resource does not change anymore for the following scenario.
Scenario for problem: The Instances view displays a fingerprint for the resource. When a project is cleaned, it is expected that the same fingerprint is displayed after the cleaning has been finished. However, a different fingerprint is displayed after the cleaning of some projects.
Additional information: These projects contain 2 structured data types with the same name in different namespaces.

49494

Application navigator,
ST-objects

When several function blocks have been created in the same ST object, the command "Delete" in the application navigator deletes all function blocks in this ST object without any previous information.
Scenario for problem: It is possible to create several language elements, such as function blocks, in the same ST-object. When in the application navigator, you are selecting the command Delete for one of these language elements, all language elements in the ST-object are deleted because the entire ST-object is deleted. There is no information before the delete action that other elements will be affected by the delete action.
Additional information: The same problem occurs in case of a moving action. This means: If one element is moved, the other elements within the ST-object are moved as well.
Workaround: Before you delete an element, you might want to check whether there are other elements in the same object. If yes, rather delete the element in the ST-object (i.e. in the ST-editor).

49498

Application navigator

The command "Go Into" in the application navigator does not behave as expected.
Scenario for problem: The command Go into should refocus the view to the currently selected folder. However, if the command is selected in the application navigator (for example, for the folder Project blocks), the view does not display the contents of only this folder, but all projects that are currently open will be displayed in that folder as well. This behavior in the application navigator is not as expected.
Workaround: none available

49514

"Values of Variables" view

An external variable cannot be forced in the "Values of Variables" view, if the corresponding global variable is a program-global variable.
Scenario for problem: If you force an external variable for which the corresponding global variable has been declared in the program, this message is displayed in the error log: Access to the variable has been denied. (Error code: 0x10308 (66312)} – The external variable is not forced.
Workaround: Force the program-global variable instead of the external variable. However, observe that the Values of Variables view does not correctly display the force status of the corresponding external variable. The following additional force information for the external variable is missing:

• the force value in the column Prepared value

• the preceding symbol in the column Value

49535

List of declared variables

The command "New Variable..." is not using the correct entry for a data type with named values declared within a namespace.
Scenario for problem: In the list of the declared variables, when you select a variable and then the context menu command New Variable..., the dialog uses the data type of the selected variable in order to quickly create a new variable with a similar name. However, if the selected variable has been declared based on a data type with named values within a namespace, the data type of the named values is not correctly entered. Subsequently, the button OK of the dialog is disabled and the new variable cannot be created.
Example: The dialog suggests the data type Colors instead of the correct data type NS1.Colors. The variable cannot be created because the namespace NS1 is missing for the suggested data type.
Workaround: Delete the last character of the suggested data type (so delete the character s of Colors) in order to get a list with suggestions for the data type. In this list, select the correct data type, e.g. NS1.Colors. Then the button OK of the dialog will be enabled.

49539

List of declared variables

The command "New Variable..." uses a non-saved item for a data type. However, the validation is based on the saved item.
Scenario for problem: In the list of the declared variables, when you select a variable and then the context menu command New Variable..., the dialog uses the data type of the selected variable in order to quickly create a new variable with a similar name. If the name of the data type has been changed in the ST-editor, but the change has not been saved, the previous name of the data type is suggested as the data type in the dialog, but the OK button of the dialog is disabled. If you change the name of the data type in the dialog to the new name of the data type, the OK button of the dialog becomes enabled. If you save the editor with the created variable (based on the new data type name) but the changes in the ST-editor remain unsaved, the created variable will be reported as faulty because the validation is based on the saved entry (= the previous name of the datatype).
Example: The data type myINT has been corrected to myINT2 in the ST-editor but this change has not been saved yet. The dialog for the new variable (e.g. in the FBD editor) still suggests the original data type myINT but OK is disabled. Only when you correct the data type from myINT to myINT2, it is possible to create the variable based on myINT2. However, after saving the editor with the created variable, this variable is reported as faulty because the ST-editor with myINT2 is not saved yet.
Workaround: Save the changes in the ST-editor as well so that there is a consistent state that is used for the validation.

49543

List of declared variables

It might not be possible to correct a missing data type of a variable within the dialog. Or the error icon is not displayed for the variable with a missing data type.
Scenario for problem: When the data type of a variable within a graphical editor is missing, this error is highlighted in the list of the declared variables by an error icon in front of the variable name (this is mentioned within the user documentation). It is possible to fix this problem in the list of the declared variables. e.g. double-clicking the variable opens a dialog to correct the data for this variable.
However, there have been occurrences where

• the field Data type in the dialog has been disabled. In this case, it is not possible to correct the data type in the dialog.

• the variable with the missing data type has not been highlighted with the error icon .

Workaround, if the field Data type in the dialog is disabled: Use the context menu command Edit Type in order to correct the data type.
Workaround, if the error icon is missing: Check the Problems view for error messages that report the missing data type. Double-click this error message to go to the respective variable in the list of the declared variables. Correct the data type.

50847

FBD-editor

Copying/Pasting the contents on several pages does not work when one of the target pages is missing.
Scenario for problem: When you select the entire content in an FBD-editor that consists of several pages, it is possible to copy the selection to the clipboard. But it is not possible to paste the content into a different FBD-editor that consists of fewer pages. In this case, only the preview of the pasted elements is displayed but nothing is inserted. Moreover, no message informs about the possible problem cause.
Workaround: Make sure that all target pages are existing before pasting the content. Or copy and paste only the elements of one page.

50924

FBD-editor

It is not possible to create a line fork when connecting a continuation to an input of a second block.
Scenario for problem: When you point to an existing line, press and hold the primary mouse button, move the mouse pointer onto a free block input and release the primary mouse button, a line fork (incl. a connection point) is created connecting the line with the block input. However, if the existing line has been connected to a continuation and the free input is that of a second block, the line fork will not be created.
Example: Here the line fork from the continuation C1 to the input of the lower OR block cannot be created (do not mind the error icons; they are of no consequence for this problem):

Workaround: Create the line in the other direction. This means:

• Create the connection point on the existing line (by double-clicking onto the line).

• Point to the free block input

• Press and hold the primary mouse button.

• Move the mouse pointer onto the connection point.

• Release the primary mouse button.

50969

FBD-editor

It is not possible to create a new value field with a TIME_OF_DAY or DATE_AND_TIME literal.
Scenario for problem: When you use the context assist to create a new value field with a TIME_OF_DAY or DATE_AND_TIME literal, the specified value is not accepted.
Example for such values: TOD#13:33:17, DT#1999-03-12-01:20:41.500
Workaround: First create a value field with value TRUE. Then edit the value field and insert the desired value.

51230

LD-editor

The statusbar of the LD-editor does not contain information on the POU.
Scenario for problem: According to the user documentation, the statusbar of an LD-editor should contain information on the POU, such as the POU type and the POU name. However, the statusbar is empty.
Workaround: none existing

51266

Validating the application

In case of a validation relating to the instance, the rule "The usage of blocks is restricted either completely or only for defined types" is also applied to objects that are not included in the instance context.
Scenario for problem: When you validate the elements of a resource, the validation should be done for all objects that are used starting from the resource. That means, objects not in the instance context of the resource should not be validated. However, the rule The usage of blocks is restricted either completely or only for defined types is also applied to the objects that are not included in the instance context of the resource.
Additional information: This problem occurs when objects included in the instance context are located in the same ST-object as objects not included in the instance context.
Workaround: Move the objects into to different ST-objects, if this is reasonable for you.

51281

Validating the application

In case of a validation relating to the instance, the rule "Illegal elementary data types must not be used" is also applied to objects that are not included in the instance context.
Scenario for problem: When you validate the elements of a resource, the validation should be done for all objects that are used starting from the resource. That means, objects not in the instance context of the resource should not be validated. However, the rule Illegal elementary data types must not be used is also applied to the objects that are not included in the instance context of the resource.
Additional information: This problem occurs when objects included in the instance context are located in the same ST-object as objects not included in the instance context.
Workaround: Move the objects into to different ST-objects, if this is reasonable for you.

51294

Creating custom library

The link to open the validation report does not work when a project is located outside the workspace.
Scenario for problem: When you generate a library, the library is automatically validated in some variants of logi.CAD 3. In the other variants of logi.CAD 3, it is possible to validate the library yourself. When such a validation is executed, the Validate view informs that this validation report has been created. When you double-click the appropriate message, the validation report is opened in logi.CAD 3. When logi.CAD 3 has been started with a workspace containing a blank, the project mus be located outside of the workspace. In this case, the validation report is not opened. Instead, the error log displays the messages Unable to create part and Cannot determine URI for 'path/library-name.lib.mrclog'.
The last message is also displayed in the component where the report should be displayed .
Workaround: Open the validation report from the project explorer.

51303

FBD-editor

It is possible to create a value field by dragging the variable with an invalid data type from the list of the declared variables.
Scenario for problem: When a variable is declared on an invalid data type, the view Problems contains a message to indicate the problem. However, it is possible to create a value field for this variable by dragging this variable from the list of the declared variables into the drawing field. As a consequence, the value field uses a faulty variable.
Additional information:

1. The data type might be invalid because the data type has been deleted since the variable has been declared.

2. The content assist does not list the variable with the invalid data type.

Workaround: none existing

51364

FBD-editor

The refactoring of a data type has no impact on variables that are declared/used in the FBD-editor.
Scenario for problem: It is possible to refactor a data type by changing its name. Variables that are declared with this data type are correctly changed to the new name of the data type - but only when the variable has been declared in the ST-editor. The refactoring is not done when the variable has been declared in the FBD-editor.
Workaround: Double-click the error message reporting the missing data type. Change the data type of the variable in the FBD-editor yourself.

53941

Namespaces

It is not possible to use language elements with a same name from the global namespace, if a language element with the same name exists in the current namespace.
Scenario for problem: It is possible to insert the call of a block e.g. in the FBD-editor by dragging the block from the project explorer or application navigator. If this block is located in the global namespace and the current block is located in a declared namespace in which there is also a block with the same name as the inserted block, then logi.CAD 3 changes the call of the block from the global namespace to the one from the same namespace.
Example: The block TestMotor1 exists in the global namespace, in the namespace NS1 the blocks Testing and TestMotor1 exist. If you insert TestMotor1 from the global namespace into the Testing block, TestMotor1 from the NS1 namespace will be used instead.
Additional information:

• This change is only noticeable after you have saved, closed and reopened the FBD-editor.

• At present, the user documentation contains a corresponding restriction that it is not possible to use language elements with the same name from the global namespace.

Workaround (recommendation if you are developing safety-related applications/libraries): Do not use namespaces. Or define strict naming conventions/guidelines, if you want to use namespaces.

55031

Building the application,
vendor block

Include is missing from CustomImplementation block if a data type is only used as a return value of a function.
Scenario for problem: If a user data type is only used as the return value of a CustomImplementation function, the generated H-file for the data type is not included in the resulting H-file for the function itself.
Subsequently, the application cannot be built because of this missing include.
Additional information about the resulting C-/H-files: When saving the ST-object with the inputs/outputs for the CustomImplementation block, the required C-/H-files with the implementation stubs are automatically generated. If you have already saved the ST-object before the ST-object was completed, it is likely that the object will not match the generated files. Example: You have declared a CustomImplementation function with a data type as the return value of this function, you saved the ST-object and then you used the data type in the function and you saved this change. In this case, the 1st saving action creates the C-/H-files with the implementation stub, while the 2nd saving action does not update the C-/H-files with the implementation stub. In this case, you must rename the automatically generated files to another unique name (if you have already entered your code in these C-/H-files) or delete these files (if you have not entered any code in these C-/H-files yet). Then, save the ST-object again to make sure that the generated files contain the correct implementation stubs. If you renamed the C-/H-files that were generated: Transfer your code to the newly generated C-/H-files and delete the renamed C-/H-files.
Workaround, if the implementation stubs have not yet been generated yet: Use the data type also in the function itself. Example: Declare a variable based on this data type.

55214

IDE-documentation,
system blocks

The block descriptions for certain numeric and time functions do not contain the information about an existing IEC standard deviation.
Scenario for problem: The block descriptions for certain blocks do not contain the information that the block behavior is not IEC standard compliant in the case of an overflow. The information is missing for the following blocks:

• Numeric functions:

  • ADD block

  • DIV block

  • EXPT block

  • MOD block

  • MUL block

  • SUB block

• Time functions:

  • ADD_TIME block

  • CONCAT_DATE_TOD block

  • MUL_TIME block

  • SUB_DT_DT block

  • SUB_TIME block

Additional information:

• For these blocks, invalid connections are not checked by logi.CAD 3. Therefore, enter code in your application to detect invalid connections (e.g. IF-statements). See the IDE-documentation (under "IEC-blocks for the application" for information what the consequences of an invalid connection might be.

• The information is missing in the block descriptions up to logi.CAD 3 version 3.20.0.

Workaround: none existing

55377

Building the application

It is not possible to build an application when value fields contain specific operations.
Scenario for problem: If you enter an expression with an operator in a value field, it is possible that the application cannot be built. No errors are reported before the application is built. Afterwards, messages similar to this one appear in the Problems view: implicit declaration of function 'lcfu_iec61131_EXPT__INT__INL'; did you mean ''lcfu_iec61131__TO_INT__INT'? [-Werror=implicit-function-declaration]
Additional information: The problematic operators are the operators for which there are equivalent system blocks. But only the following operators are affected:

Thus, the problem occurs, when an expression such as 2**3 is entered in the value field.
Workaround (if sensible): Use other expressions that return the same value.

55464

Building the application,
build report

The HTML-report does not contain any notice, if the application could not be built due to errors in the application.
Scenario for problem: The HTML-report that is generated when the application is built (also called build report) does not contain any indication, when it was not possible to build the application due to errors in the application (e.g. syntax errors). The section with the errors and warnings displays the text None suggesting that the application was built. The messages in the Problems view and in the error log take precedence.
Additional information: In the variant of logi.CAD 3 that is used to develop safety-relevant applications, the Build Log view contains a link to an HTML-report containing information about the built application and its components (e.g. fingerprint of the elements of the application). This HTML-report (also called build report) must be checked when building safety-related applications – as specified in the documentation "Safety instructions on working with the IDE".
Workaround: When building safety-related applications and checking the contents of the build report, also check the contents of the Problems and Error log views. If errors are listed there, fix them and repeat all workflow phases as specified in the documentation "Safety instructions on working with the IDE " and required by the change of the application. In the case that there are only warnings and/or infos in the views, contact the system integrator and clarify the necessary course of events.

55190

IDE-documentation,
system blocks

The block description for the blocks ROL, ROR, SHL and SHL does not contain any information about a deviation from the IEC-standard for negative values of the input N.
Scenario for problem: The IDE documentation does not contain any information about this block behavior:
If a negative value is connected to the N input of the ROL, ROR, SHL and SHL blocks, a opposite rotation or shift is performed. Example: For SHR, no bitwise shift to the right but a bitwise shift to the left is performed.
This behavior is a deviation from the IEC-standard. The "Table 30 - Bit shift functions" of the standard defines that values < 0 for input N are an error. The IDE-documentation also contains no information that the blocks deviate from the IEC-standard in this respect.
Workaround: none existing

55194

IDE-documentation,
system blocks

The block description for the Compare blocks does not contain information that bitstring values are treated like unsigned integer values.
Scenario for problem: The IDE documentation does not contain any information about the behavior that the compare functions treat bitstring values (= ANY_BIT values} like unsigned integer values.
This behavior is consistent with this specification from the IEC standard:

Comparisons of bit string data shall be made bitwise from the leftmost to the rightmost bit, and shorter bit strings shall be considered to be filled on the left with zeros when compared to longer bit strings; that is, comparison of bit string variables shall have the same result as comparison of unsigned integer variables.

The behavior applies to the following blocks:

• EQ

• GE

• GT

• LE

• LT

• NE

Workaround: none existing

55198

IDE-documentation,
system blocks

The block description for some conversion blocks does not contain information about a deviation from the IEC-standard regarding a binary transfer.
Scenario for problem: The IDE documentation does not contain any information about this behavior of conversion blocks:

• The conversion of the value is performed as a semantic interpretation.

• REAL and LREAL values are also interpreted.

This behavior is a deviation from the IEC-standard. The standard defines that the data type conversion is done as a binary transfer. The IDE documentation also contains no information that the blocks deviate from the IEC-standard in this respect.

The following blocks are affected:

• TO_BOOL

• TO_BYTE – with input data type CHAR

• TO_CHAR – with input data type BYTE

• TO_DWORD – with input data type CHAR und LREAL

• TO_LREAL – with input data type LWORD

• TO_LWORD – with input data types CHAR and LREAL

• TO_REAL – with input data type DWORD

• TO_WORD – with input data type CHAR

Workaround: none existing

55202,
part 1

IDE-documentation,
system blocks

The block description for the conversion blocks from Convert does not contain information about the behavior in case of errors that are possible according to the IEC-standard.
Scenario for problem: The IDE documentation does not contain information about the behavior of the conversion blocks when the connected value is not within the range of values overlapping for the data type of the input and for the result value. The IEC-standard defines that the behavior in the case of such an error is implementer specific.
The general behavior of the conversion blocks in logi.CAD 3 (provided in the Convert sub-library) is as follows: The non-overlapping value range is not considered to be an error and the higher bytes (= bytes not within the range of values) are truncated.
Observe that the following is valid for the conversion block DT_TO_DATE: The block discards the time and returns only the date. Therefore, there is no value range error.
Additional information: In contrast to the above-mentioned problem the description of the block TO_TOD (provided in the ConvertEnh sublibrary) already contains the information on the error.
Workaround: none existing

55202,
part 2

IDE-documentation,
system blocks

The block description for the TRUNC blocks does not contain information about the behavior in case of values that are not in the common range of values.
Scenario for problem: The IDE documentation does not contain information about the behavior of the TRUNC blocks when the connected value is not within the range of values overlapping for the data type of the input and for the return value. The IEC-standard defines that the behavior in the case of such an error is implementer specific.
Please observe: The behavior of the TRUNC blocks in case of a range of values not overlapping depends on the compiler and the target system. This means that the TRUNC blocks might return different return values for an input value that is not in the common range of values and in case of different compilers and the target systems. Therefore, enter code in your application to detect a range of values not overlapping (e.g. IF-statements in the ST-code).
Abhilfe: none existing

55218

IDE-documentation,
system blocks

The block description for the block DIV does not contain any information about the truncation behavior for integers.
Scenario for problem: The IDE documentation for the block DIV} does not contain any information that the result of the division of integers is an integer of the same type with truncation toward zero (there is no rounding).
Examples:

• The division 7/3 returns the value{{2}}. The decimal part 0,333... is truncated

• The division (-7)/3 returns the value -2. The decimal part 0,333... is truncated

Workaround: none existing

55456

Validating the application

The description of the model rule configuration does not contain some details for specific changes.
Scenario for problem: It is possible to change the model rule configuration by changing values in files for the model rules. For instance, it is possible to configure a model rule so that its values cannot be changed in the GUI. It is unclear why the model rules in the GUI are not affected by the following changes:

1. The configuration has been changed in the project.rule file.

2. The value overridable is changed from true to false.

Additional information:

• The configuration in the files is not described in the reference documentation of the IDE. Starting pointers are included in the administrator's manual and details on the files are included in the API SDK documentation. The impact of the above-mentioned changes is missing in the manual or API SDK documentation.

• The GUI might even not list any model rules at all. This means that the property page Validation might be empty.

Workaround:

1. Instead of changing the project.rule file: Change the basic configuration of the rules. i.e. the files included in the corresponding sub-folder of plugins of the logi.CAD 3 installation folder.

2. In addition to changing the value overridable to false: Specify only one value under allowedValues.

55620

FBD-editor

The network elements might not be evaluated correctly with regard to their processing order if the network contains only function blocks with feedback loops.
Scenario for problem: If a network contains only function blocks with feedback loops (see the following figure), the processing order is not displayed as expected according to the description in the IDE documentation.
The following illustration shows the expected execution order with the numbers (in the black circle) in contrast to the assigned execution order with the numbers (in the red rectangle):

Additional information: logi.CAD 3 should behave like this (according to the description in the IDE documentation):

• As not one of the statements within the network can be evaluated, there is a feedback loop.

• First logi.CAD 3 tries to reduce the sum of the statements to be evaluated: logi.CAD 3 will ignore all statements which follow the feedback loop and do not contain any other feedback loop. This leaves the 2 left function blocks that are supplied with a value from one and two respectively.

• As there are no assignments in these remaining statements, logi.CAD 3 selects the call of the function block being most top/left. This is the function block that is supplied with a value from one. logi.CAD 3 considers the outputs of this call as evaluated until the call can actually be evaluated.
  Now this function block and the function block right next to it can be evaluated.

• As several calls can be evaluated, logi.CAD 3 determines the graphical position of these calls to each other: The call most top/left is evaluated (top is applied before left). This is the function block which is highlighted with the number 1 in the illustration. Thus, this function block is evaluated as the 1st function block.
  Now only the leftmost function block can be evaluated.

• logi.CAD 3 evaluates the leftmost function block, because it is the only element that can be evaluated. This function block is highlighted with the number 2 in the illustration. Thus, this function block is evaluated as the 2nd function block.
  Now no further element is evaluable. Details:

  • The rightmost function block highlighted with the number 3 (in the red rectangle) in the illustration cannot be evaluated because its input y has not been evaluated yet.

  • The lower left function block that is supplied with a value from two cannot be evaluated because there is a feedback loop.

• logi.CAD 3 tries again to reduce the sum of instructions to be evaluated. For this purpose, the instructions that follow the feedback loop and that do not contain another feedback loop are ignored again. This leaves the lower function block that is supplied with a value from two.

• logi.CAD 3 considers the outputs of this call as evaluated until the call can actually be evaluated.
  Now this function block and the function block right next to it can be evaluated.
  According to the description in the IDE documentation, the function block right next to it should now be evaluated as the 3rd element – as highlighted with the number 3 (in the black circle) in the illustration. However, the rightmost function block is incorrectly evaluated as the 3rd element. This function block is highlighted with the number 3 (in the red rectangle) in the illustration.

Workaround: none existing

55921

System blocks

The result of a DIV_TIME block might not be as expected.
Scenario for problem: The DIV_TIME block divides the TIME value at input IN1 by a numerical value at input IN2 and returns the result of this division in format TIME. If a REAL value is connected to input IN2, it is possible that the return value will not be as expected. The technical reason for this is that a LREAL value is used for the internal calculation (instead of a REAL value). Thus, a higher calculation precision is achieved than is actually required for REAL.
Example: With a REAL value for IN2, the value TIME#3000d is calculated by mistake. This erroneous calculation is executed due to the higher calculation precision. In comparison, if the same value is connected to IN2 but with data type LREAL, the expected value TIME#3000d will be calculated.
In case of an internal calculation with REAL, the value TIME#2999d23h59m51s808ms would be returned. Here this value is as expected for REAL values.
TIME#2999d23h59m51s808ms
Workaround, if you want to calculate precise values: Connect the input IN2 of the DIV_TIME block with a LREAL value.

55951

System blocks

The EXPT block might return an incorrect result.
Scenario for problem: The EXPT block returns the result 1 for the calculation 0**0 . This is a mathematically incorrect result.
Additional information: In this case, the ENO output of EXPT is not reset to FALSE but TRUE is returned. So unfortunately there is no pointer to this type of problem.
Workaround: Avoid the usage of the EXPT block for the calculation 0**0.

55996

ST-editor,
C-code,
building the application

The usage of REAL#-0.0 or LREAL#-0.0 might cause compiler warnings when building the application.
Scenario for problem: When REAL#-0.0 or LREAL#-0.0 is used in ST-code as typed literal, the cast LC_TD_REAL or LC_TD_LREAL is omitted in the automatically generated C-code and the literal in the C-code is always of type double (= LREAL).
This may lead to implicit casts in the C-code which in turn may lead to compiler warnings when building the application.

Additional information: Observe the additional problem with the ID "56121" that the usage of -0.0 might cause 0.0 in the C-code.
Workaround: Call the conversion block TO_REAL. Relating to the above example, this would result in the following ST-code:

56105

Vendor blocks,
building the application

An empty fingerprint is reported for a vendor block containing the statement extraIncludes.
Scenario for problem: When using a vendor block that contains the statement extraIncludes in the application, the build report contains the following message: The extra include "name" with checksum "" could not be verified – The message contains an empty fingerprint for the H-file that has been specified by the statement extraIncludes.
Additional information: This problem is in particular relevant when developing a safety-relevant application because the fingerprint of each application element listed in the build report must be checked. The empty fingerprint makes is impossible to continue with the workflow as specified in the document "Safety instructions on working with the IDE".
Workaround: Use the H-file that has been specified by the statement extraIncludes so that it is linked. Build the application anew so that a new build report is generated.

56121

ST-editor,
C-code

The -0.0 specification might become 0.0 in the C-code.
Scenario for problem: If -0.0 is entered in the ST-code, the - character may be missing in the automatically generated C-code.

Workaround: none existing

56113

Test framework

A program in a namespace cannot be tested.
Scenario for problem: When testing a program declared in a namespace, the following message is displayed in the console: An error occurred while processing Head: 'NoneType' object has no attribute 'has_head_row_occurred' – The test is not executed and the test report does not contain a fingerprint for the program.
Additional Information: This issue is especially relevant when developing a security-sensitive application because the fingerprint of the program is missing from the test report. A missing fingerprint makes it impossible to continue with the workflow, as described in the English document "Safety instructions on working with the IDE."
Workaround (recommendation if you are developing safety-related applications/libraries): Do not use namespaces for programs. Run the test again so that the test report contains the fingerprint of the program.

56417

PLC,
Runtime system

The PLC or runtime system is terminated unexpectedly in case of a certain division.
Scenario for problem: In the case of the following division (see the following ST-code), the PLC or runtime system is unexpectedly terminated during the execution of your application. As a result, no values for the application are displayed in the Values of Variables view and the Instances view displays the state Offline.

Workaround: Stop and restart the PLC or the runtime system, remove the error in the ST-code with the division and load the application anew onto the PLC.
If loading the application onto the PLC is not possible, you probably need to delete the RTSCode or RTSCode.dll file. See the troubleshooting article " PLC cannot be addressed. The runtime system is slow to respond or does not respond at all. " for details on where to find this file.

56573

Vendor blocks

The fingerprint of a vendor block with CustomNameSpace property is not updated correctly.
Scenario for problem: If a library element is changed and the library is created anew, this fingerprint is updated. However, in the following scenario, the fingerprint is not updated correctly:

• You create a vendor block with the CustomNameSpace property.

• You specify this vendor block in the library configuration.

• You create the library based on the library configuration.
  Result: The library generation report contains the fingerprint for the vendor block.

• You change the H or the C file for the vendor block.

• You create the library anew (based on the same library configuration).
  Result: The new library generation report still contains the original fingerprint for the vendor block.

Additional information:

• The same problem is valid for reports that are created when validating, testing and building the application.

• The problem is in particular relevant for system integrators and when developing a safety-relevant application. Reasons:

  • Usually, vendor blocks are created and deployed in libraries by system integrators.

  • The fingerprint of each element listed in the report must be checked and compared with the fingerprints in other reports (e.g. the SiL/PiL test reports). The different or wrong fingerprint makes it impossible to proceed with the workflow as described in the English document "Safety instructions on working with the IDE."

• The specification for CustomNameSpace is used as part for the name of the generated H/C file.

Workaround: Do not use the CustomNameSpace property. Or, clean the project after each change in the H or C file so that the fingerprint is updated correctly in the new library generation report for the vendor block.

56764

Vendor blocks

The fingerprint of a vendor block with implementationName property is not updated correctly.
Scenario for problem incl additional information: As for ID "56573" but for the implementationName property.
implementationName determines a different POU name as part of the file name for the H-file as well as for the C-file (if the definition functionHasCFile is specified as well)
This definition is useful in particular if several identical functions are to be implemented within the same file.
Workaround: As for ID "56573" but for the implementationName property.

59209

Data types,
building the application

A change in the automatically generated C/H file for a data type is not checked.
Scenario for problem: If the content of a C-file is changed and this C-file has automatically been generated for a data type that you have declared in the ST editor, the build report (= the HTML report that contains information about the built application and its components) does not contain an error or any other indication that the C-file has been edited and does not match the declaration in the ST editor. The same problem is valid when the automatically generated H-file is changed.
Additional information:_ This problem is in particular relevant when developing a safety-relevant application because the build report must be checked for such applications.
Workaround: Do not edit C/H files that are automatically generated for data types.

62166

IDE Documentation

The online help, local HTML help, and PDF files might not contain the complete list of blocks with internal error diagnostics.
Fix: The online help was corrected around the middle of October 2023 to provide the full list. The HTML help and PDF files for the current release also contain the full list.
Scenario for Problem: The article "Execution control: EN, ENO" contains a list of blocks with internal error diagnostics. This list might not be complete because blocks after the TO_TOD block might be missing. These missing blocks might be:

• TO_UDINT block

• TO_UINT block

• TO_ULINT block

• TO_USINT block

• TO_WORD block

• UDP_Close block

• UDP_Open block

• UDP_Receive block

• UDP_Send block

Additional information: The problem affects the online help prior to October 10th, 2023 but also local HTML helps and PDF files created for this release and/or previous releases.
Workaround (possible after October 10th, 2023): Go to the online help article https://help.logicals.com/lco3docu/latest/user-documentation/en/referenzdokumentation/anwendung-erstellen/anwendung-im-st-editor-erstellen/ausfuehrungssteuerung-en-eno in the online help and change to the appropriate version. The article contains the complete list.

107650

Safety-related applications, Building the application

The SEL_DWORD block cannot be used in safety-related applications.
Scenario for problem: When a safety-releated application is using the SEL_DWORD block and this application is built, an error messages is reported that the fingerprints do not match for SEL_DWORD.
Additional information: The document "Safety instructions on working with the IDE" does not list the SEL_DWORD block as an unsupported block. So it is expected that this block can be used in in safety-related applications.
Workaround: Do not use the SEL_DWORD block in safety-related applications.

107784

Safety-relevant application, information for users, IDE documentation, document "Safety instructions on working with the IDE"

The document "Safety instructions on working with the IDE" (version 3.0) does not contain a restriction.
Scenario for problem: The document "Safety instructions on working with the IDE" (version 2.0) does not contain the following information:

• The section BINARY_LIBRARIES ... END_BINARY_LIBRARIES (when creating custom libraries with user blocks) is not supported.

Even if the above item is not listed in the section "List of unsupported and restricted elements" of the document in version 2.0, you must not use the specified section when developing safety-relevant applications.
Workaround: none existing

108185

Building the application, safety-relevant applications

Wrong C-code is generated, if you call a function block instance declared as an in-out variable. Subsequently, it is possible that memory on the PLC is overwritten.
Scenario for problem: If you call a function block instance that has been declared as an in-out variable (= VAR_IN_OUT) as illustrated in the following example, the application can be built. However, wrong C-code is generated. This might cause the problem that memory on the PLC is overwritten.

Workaround 1: Do not declare a function block instance as an in-out variable.
Workaround 2: Use the upcoming logi.CAD 3 version 3.23.2 or version 3.24.0 where the problem will be fixed.

108609

IDE documentation, data types

The IDE documentation contains wrong information: The lower and upper limit is not correctly specified for the data type BOOL.
Scenario for problem: The article "Supported data types (in ST) " in the IDE documentation specifies the supported data types, their initial values, lower limits and upper limits. The lower limit and the upper limit for the data type BOOL is not correctly specified in the IDE documentation. Observe that the German and the English language of the IDE documentation contain wrong information.
The following text on the lower limit and upper limit is the correct information for the data type BOOL:

Default initial value (I): 0 or FALSE
Lower limit (L): as default initial value (I)
Upper limit (U): 1 or TRUE

Workaround: none existing

logi.CAD 3 IDE

version 3.16.2

305ff77e4845eb7910f29c42f2f134ea

checksum of configuration\com.logicals\application.md5 (in relation to the i nstallation folder of logi.CAD 3)

system library Standard

version 3.2.8.1

9b96615a7ba362044256a304576886c2

checksum of index.md5, contained in plugins\com.logicals.library.lc3lib_3.16.2\libautoinstall\com.logicals.lc3.library.standard__3.2.8.1.ZIP (in relation to the i nstallation folder of logi.CAD 3)