CODESYS V3.5 Runtime System详解与架构文档

需积分: 36 33 浏览量更新于2024-07-15 1 收藏 1.62MB PDF 举报

《CODESYS Control V3 手册》是一份详细介绍了CodeSys V3.5 Runtime System (RTS) 的移植和架构的文档。CodeSys是一个流行的二次开发平台，它不仅支持传统的梯形图编程，还兼容IEC标准的ST语言，适用于构建复杂的逻辑控制应用。手册主要涵盖了以下几个关键部分： 1. **介绍**：首先，文档概述了运行时系统在整个系统中的角色，解释了它的使命，即在实时系统中提供高效、灵活和稳定的控制功能。 2. **架构**：这部分深入解析了CodeSYS Control V3的体系结构，包括整体的概述、技术基础（如ANSI-C和C++的使用）、单一源代码的优势，以及其紧凑运行时的特性。其中，紧凑下载格式允许高效的资源管理和部署。此外，文档详细讨论了错误代码管理、对象句柄的概念、函数调用和数据导入/导出的约定，以及M4机制，包括接口描述文件和依赖描述文件的作用。 3. **核心组件与主要功能**：手册接着介绍了核心组件的功能，如启动和关闭过程，包括初始化时的设置、系统的运行模式，以及程序的终止阶段。这部分还涵盖了组件接口架构，包括函数调用约定（caller convention）、导出约定（export convention）、导入约定（import convention）以及用于确保代码质量的检查函数。 4. **源代码结构**：手册描述了运行时系统的源代码组织结构，帮助用户理解如何构建和维护系统。同时，文档列出了目标系统上的各种文件，如启动项目、I/O管理器、用户管理系统和可视化工具。通过这份文档，开发者可以全面了解如何在实际项目中利用CodeSYS Control V3进行高效、标准化的PLC编程，确保系统的稳定性和兼容性。无论是初次接触CodeSYS还是深入研究的用户，都可以从中找到所需的信息来优化他们的自动化解决方案。

CODESYS Control V3 Manual

In the starter-package of the runtime system you can find a template for a Compact Runtime with the

corresponding "RTS Configurator" project. This can be used as a template to create own compact

runtime systems.

2.3.1.1 Compact download format

With the version V3.4.1.0 of the runtime system, a new download format is designed especially for

embedded runtime systems to fulfill the following requirements:

 Easy to implement the download service in the runtime system

 Easy to implement storing and loading the boot project

 Ability to run the boot project directly out of flash memory

For this, a new download format is created. It consists of a contiguous binary stream with the following

different content segments:

Segment

Description

CodeHeader:

RTS_UI32 ulHeaderTag;

RTS_UI32 ulHeaderVersion;

RTS_UI32 ulHeaderSize;

RTS_UI32 ulTotalSize;

RTS_UI32 ulDeviceType;

RTS_UI32 ulDeviceId;

RTS_UI32 ulDeviceVersion;

RTS_UI32 ulFlags;

RTS_UI32 ulCompilerVersion;

RTS_UI32 ulCodeAreaSize;

RTS_UI16 usCodeAreaIndex;

RTS_UI16 usCodeAreaFlags;

RTS_UI32 ulOffsetCode;

RTS_UI32 ulSizeCode;

RTS_UI32 ulOffsetApplicationInfo;

RTS_UI32 ulSizeApplicationInfo;

RTS_UI32 ulOffsetAreaTable;

RTS_UI32 ulSizeAreaTable;

RTS_UI32 ulOffsetFunctionTable;

RTS_UI32 ulSizeFunctionTable;

RTS_UI32 ulOffsetExternalFunctionTable;

Header of the stream:

HeaderTag=0x1234ABCD

HeaderVersion=0x00000001

HeaderSize=104

Total size of header including all segments

Device type of the selected device

DeviceID of the selected device

Device version of the selected device

Download Flags

Compiler version of used CODESYS version

Code area size

Code area index

Code area flags

Offset in bytes, where the code segment begins

Size in bytes of the code segment

Offset in bytes, where the application info

segment begins

Size in bytes of the application info segment

Offset in bytes, where the area table segment

begins

Size in bytes of the area table segment

Offset in bytes, where the function table segment

begins, Here the link function are specified:

- CodeInit

- GlobalInit

- GlobalExit

- Reloc

- DownloadCode

- TargetInfo

Size in bytes of the function table segment

Offset in bytes, where the external function table

segment begins to link c functions against iec

code

 3S-Smart Software Solutions GmbH Page 16 of 219

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

CODESYS Control V3 Manual

2.4 Error Codes

All functions in the runtime system return an error code. This error code has the type RTS_RESULT.

All error codes can be found in CmpErrors.h.

Standard error codes that can be used in each component are defined at the beginning of

CmpErrors.h. Each error code has a prefix with ERR_.

Each kernel component can specify its own error codes in CmpErrors.h.

Each OEM components can specify its own error codes in the range f 0x8000..0xFFFF.

2.5 Object Handles

All handles to data structures or objects have the type RTS_HANDLE. An invalid object can be

checked with RTS_INVALID_HANDLE. All functions that return a handle must additionally return an

error code to the caller to specify the reason of an RTS_INVALID_HANDLE.

2.6 Linkage

All components of the runtime system can be linked together in 3 different ways:

• Static Link: All components are linked together to one executable file (e.g. *.exe). This

executable file is closed, so no additional component can be added afterwards to this package.

• Dynamic Link: Each component is linked here separately to a dynamically loadable module

(e.g. *.dll or *.o). The components are loaded dynamically during startup of the runtime system.

So at every start it can be decided, which components are to be loaded and linked to the

runtime system.

• Mixed Link: This is a mixture of both issues above. The basic components are linked statically

together to one executable file, but can get extended by dynamically loaded components.

How the linkage is done can be specified with compiler flags:

• STATIC_LINK: For static linking

• MIXED_LINK: For mixed linking

• DYNAMIC_LINK (or nothing): This is the default, if none of the two defines above is set

The source code of the components is identical in all linkage models. How this is realized is described

in the next chapter.

2.7 Component Interface Architecture

The component interface of the runtime system must match the following requirements:

1. For embedded targets, all runtime system components should be linked static with direct C-

functions calls in order to have a maximum of performance.

2. For more powerful systems with an operating system, the components should be loaded

dynamically in order to have the flexibility to select components that should be used during

startup time. Here, all functions of other components must be called via function pointers that

are investigated during start up of the system.

3. For C++ runtime systems, the C++ calling conventions (name mangling, virtual function calls,

methods) should be used.

To perform all these issues, 3S has developed an own interface technology based on C-macros.

Every function call must be done not directly with a call of the C-function. You always have to use a

special CAL_ prefix for that.

Additionally the export and import of functions must be done by special EXP_ and GET_ macros.

The usage of these macros is explained in the following:

 3S-Smart Software Solutions GmbH Page 18 of 219

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

CODESYS Control V3 Manual

2.7.1 Calling convention

If a component Cmp1 wants to call a function Fct1 of component Cmp2 and Cmp1 does not call the

function directly, it will have to call the function via the specific CAL_ macro:

CAL_Fct1();

The CAL_ macros can now be resolved in different ways:

Static Linking: #define CAL_Fct1 Fct1

Dynamic Linking: #define CAL_Fct1 pfFct1 // Function pointer to Fct1

C++: #define CAL_Fct1 ICmp2::Fct1

As you can see, the CAL_ macro reaches the goal to adapt the calling convention to the linkage

mechanism. On the other hand you can see that the caller does not see any difference, in which linking

environment the component is embedded.

2.7.2 Export convention

To use a function from another component, the function first must be exported by this component. This

is done with a second macro, the export macro. Therefore we created the so called EXP_ macro.

Referring to the example shown above, Cmp2 has to export its Fct1 with the following macro at a

specific moment during start up of the runtime system:

EXP_Fct1;

This macro is expanded in different environments like:

Static Linking: #define EXP_Fct1 ERR_OK

Dynamic Linking: #define EXP_Fct1 CMRegisterAPI( "Fct1", (void*)Fct1, 0, 0)

C++: #define EXP_Fct1 ERR_OK

Only in case of dynamic linking, component Cmp2 has to register its function pointer of the exported

function at the component manager to use it later from other components.

2.7.3 Import convention

If a component needs to call functions from other components, it has a dependency to other

components. This issue is covered by the third macro called GET_ macro.

In the example shown above, Cmp1 has to import Fct1 with the following macro at a specific moment

during start up of the runtime system:

GET_Fct1;

This macro is expanded in different environments like:

Static Linking: #define GET_Fct1 ERR_OK

Dynamic Linking: #define GET_Fct1 CMGetAPI( "Fct1", (void **)&pfFct1, 0)

C++: #define GET_Fct1 ERR_OK

Only in case of dynamic linking, component Cmp1 has to resolve the function pointer of the imported

function from the component manager to use it later.

In the case of dynamic linking you can see that there is a function pointer needed to hold the pointer to

the function. For this a second macro is needed, that declares these function pointers. It is called

USE_ macro.

In the example shown above, Cmp1 has to declare a function pointer for Fct1 with the following macro

at the beginning of its C-file:

USE_Fct1;

This macro is expanded in different environments like:

Static Linking: #define USE_Fct1

 3S-Smart Software Solutions GmbH Page 19 of 219

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

剩余218页未读，继续阅读

plcyshx

粉丝: 1
资源: 10

CODESYS V3.5 Runtime System详解与架构文档

CoDeSys V3软件手册

Setup_CODESYSControlRTE64V3.5P13Build05.exe

codesys运动控制源程序

gnss-sdr_manual.pdf git

tina_9.0_manual.pdf

04_efdc_explorer8.1_chinese_user_manual.pdf

如何在activity_manual_driving.xml获取activity_manual_driving_item.xml的id

mtk_sdk_user_manual.pdf

zint_manual_242.pdf

xl_driver_library_manual_en.pdf

最新资源