Consider Implicit Functions

This option is disabled by default.

After enabling this option, implicit generated methods like FB_INIT, FB_EXIT, FB_REINIT, and so on, are considered during code analysis.

In most cases, these methods are not relevant to explore the source code or to list them in metrics and conventions.

Deactivate this option to reduce the amount of analysis data and to improve the performance.

Consider Property Accessor Functions

This option is disabled by default.

After enabling of this option, the generated property accessor functions like GetTextProperty(), GetBooleanProperty(), GetNumberProperty(), GetCompany(), GetTextProperty2(), GetTitle(), GetVersion(), and GetVersionProperty() are considered during code analysis.

In most cases, these functions are not relevant to explore the source code or to list them in metrics and conventions.

Deactivate this option to reduce the amount of analysis data, to increases the performance, and to improve the usability of Dependency View content added via a Select query.

Consider Check Functions

This option is disabled by default.

After enabling this option, the check functions like CheckBounds(), CheckDiv…(), CheckPointer(), and so on, are considered during code analysis.

In most cases, these functions are not relevant to explore the source code or to list them in metrics and conventions.This option reduces the amount of analysis data, increases the performance, and improves the usability of Dependency View.

Consider Analysis of Library Content in Deep

This option is disabled by default.

The more libraries are referenced and used by a project (direct or indirect library references), the more compile output must be analyzed.

In general, functions, programs, function blocks, and so on, which are part of the compilation (called, read, written, ...) are part of the compile output independent of the origin (application, library, POU space, …).

This needs CPU time during code analysis and results in a larger dependency model, and RDF model in RDF Triple Storage.

If you enable this option, a medium size project with a long list of referenced libraries can result in multiple GB of RAM usage (8...12 GB) and an increased CPU time to analyze the read, write, and call dependencies between the libraries.

Also, the query execution times to get the conventions and metrics results can result in execution timeouts.

In most cases, the content of a library (not directly used by the application via a call, read, or write), can be skipped during code analysis run.

Deactivate this option to reduce the amount of required RAM.

Consider Devices

This option is disabled by default.

With this option, all devices are considered during code analysis. The analysis of devices is not relevant to get conventions or metrics. For exploring your own functions, programs, function blocks, and so on, via Dependency View, devices are also not relevant. If it is necessary to explore the connection between these functions, programs, and so on, to the devices and their parameters, it is necessary to consider devices, too.

NOTE: The additional amount of RAM needed depends on the number of devices in the project.

A typical use case where devices are relevant is for drag-and-drop of a device into the Dependency View. For example, to navigate to its corresponding function block instance and see which programs or functions are accessing devices parameters directly.

Automatic (In-Memory or Out-Proc)

The code analysis feature automatically uses a backend type depending on the configured threshold of nodes count in the dependency model.

In most cases, EcoStruxure Machine Expert provides enough memory for the configured threshold level. If you run in out-of-memory exceptions during code analysis, the threshold level is too high.

Triple Storage in Memory (In-Memory)

This option forces code analysis to try to maintain the dependency model and the RDF model in EcoStruxure Machine Expert process/memory.

With larger projects, this results in out-of-memory exceptions during code analysis.

Triple Storage in Separate Process (Out-Proc)

This option is selected by default.

This is the easiest and most performant way to maintain the RDF model and to outsource the RDF query execution to a separate process.

This process provides a communication channel to EcoStruxure Machine Expert to receive commands like a query execution.

The Out-Proc process is configured as a 64-bit process. This helps to ensure that more than 4 GB of RAM can be used to maintain the RDF model and execute the queries.

Start and stop of this process is managed automatically by EcoStruxure Machine Expert.

Triple Storage in Database via http://... access

This option enables you to connect code analysis to a real RDF Triple Storage (database) which has to provide generic http://... access.

For example, Triple Storage can be used and hosted on another PC.

You can configure different values, like Server URL, Dataset Name, Graph Name, and so on.

If you use this option, the capability of the used RDF Triple Storage limits the RDF model size. Therefore, you have to configure the used Triple Storage software in an appropriate way.