CODESYS运行时系统详解：入门与架构

需积分: 47 11 浏览量更新于2024-07-18 收藏 1.25MB PDF 举报

"本文档是CoDeSys入门手册的英文版，主要涵盖了CoDeSys的软件架构、RTE（Runtime Environment）的相关设置，适合初学者了解和学习。文档由3S-Smart Software Solutions GmbH制作，包含了从系统整体的Runtime结构到具体组件的功能介绍。" 在CoDeSys编程环境中，Runtime System扮演着核心角色，它是整个系统中的关键组成部分。在整体系统中，Runtime System负责执行编译后的PLC程序，并与硬件进行交互。它的任务包括管理程序的执行流程、处理错误、以及提供与设备通信的接口。在架构部分，手册详细描述了Runtime System的概述。CoDeSys基于ANSI-C和C++技术，实现了单源代码设计，这使得开发更加灵活且高效。Runtime System提供了紧凑型下载格式，以优化存储空间。此外，手册还提到了错误代码系统，它用于在运行时识别和报告问题。对象句柄是Runtime System中用于标识和操作对象的关键机制，而链接机制则处理不同组件之间的相互调用。组件接口架构部分，手册详细介绍了调用约定、导出约定和导入约定，这些都是保证不同组件间通信规则的关键。检查函数用于确保接口的正确性，而M4机制则是一种用于描述接口和依赖性的工具。源代码树和目标系统上的文件布局部分，展示了Runtime System的组织结构，包括启动项目、I/O管理、用户管理和可视化组件。接下来的部分，手册概述了内核组件及其主要功能，这些组件是CoDeSys能够运行应用程序的基础。这些组件在启动、任务调度、中断处理、I/O操作等方面起到关键作用，确保了系统的稳定性和实时性。这份CoDeSys入门手册是学习和理解这个强大PLC编程平台的宝贵资料，通过深入阅读，读者可以掌握CoDeSys的系统架构，了解其内部工作原理，从而更好地利用它来开发和调试工业自动化项目。

CODESYS Control V3 Manual

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

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

RTS_UI32 ulSizeExternalFunctionTable;

RTS_UI32 ulOffsetRegisterIecFunctionTable;

RTS_UI32 ulSizeRegisterIecFunctionTable;

RTS_UI32 ulOffsetSourceCode;

RTS_UI32 ulSizeSourceCode;

RTS_UI32 ulCrc;

Size in bytes of the external function table

segment

Offset in bytes, where the iec function table

segment begins to link iec functions against the

runtime system

Size in bytes of the external function table

segment

Offset in bytes, where the optional sourcecode

segment begins

Size in bytes of the optional sourcecode segment

RC32 of the complete download stream including

the header with ulCRC written to 0!

Code segment

Code POUs

ApplicationInfo segment:

All names are transmitted 4 byte aligned:

Project name (ASCII string)

Author (ASCII string)

Version (ASCII string)

Description (ASCII string)

Profile (ASCII string)

Date of last change (DATE_AND_TIME)

Application info

Area segment:

List of AREA_INFO

Table of all used areas

Function table:

1. pfCodeInit

2. pfGlobalInit

3. pfGlobalExit

4. pfReloc

5. pfDownloadCode

6. pfTargetInfo

Function table to link to runtime

External Function table:

List of EXT_REF_INFO (4 Byte aligned for the

next entry!)

Table of external references

IEC Function table:

List of FUNCTION_INFO with following name of

the IEC function at the end (4 Byte aligned for the

next entry!)

Table of IEC functions that can be called from C

Source code segment:

Actually not used

Optional source code segment for the source

code of the used project

CRC CRC over the complete download stream

The code POUs can be relocated in CODESYS, if the address of the Data Area is fix and is known.

This is the main requirement to execute the plc program in flash.

CODESYS Control V3 Manual

 3S-Smart Software Solutions GmbH Page 17 of 17

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

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:

CODESYS Control V3 Manual

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

CODESYSControlV3_Manual.doc

tech_doc_e.doc / V1.2

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

剩余194页未读，继续阅读

Jeff-Hu

粉丝: 7
资源: 2

CODESYS运行时系统详解：入门与架构

CodeSys指令手册 - ABB.rar

Codesys变成入门手册

Codesys中文指令手册

Codesys快速入门手册

CoDeSys V3 基础编程入门,codesys编程手册,PLC

CoDeSys V3 基础编程入门,codesys编程手册,PLC源码.zip

codesys编程手册

CoDeSys手册CoDeSys手册

CoDeSys V3基础编程入门_手册_CoDeSys_

Codesys 2.1编程入门手册

最新资源