3. Software Integration

3.1. EcSimulatorHilDemo

The example application EcMasterDemo will handle the following tasks:

  • Stack initialization

  • Flash process data

  • Out of the box solution for different operating systems:
    • Windows

    • Linux

    • LxWin

  • Example implementation for polled mode operation

  • Thread with periodic tasks and application thread already implemented

  • The output messages of the demo application will be printed on the console as well as in some files (*.log).

3.1.1. File reference

The Demo application consists of the following files:

EcDemoMain.cpp

Entrypoint for the different operating systems

EcDemoApp.cpp

Initialize, start and terminate the EC-Simulator stack

EcDemoApp.h

Application specific settings for EcSimulatorHilDemo

EcDemoParms.cpp

Parsing of command line parameters and generic helper functionns

EcSelectLinkLayer.cpp

Common Functions which abstract the command line parsing into Link Layer parameters

EcLogging.cpp

Message logging functions

EcTimer.cpp

Start and monitor timeouts

3.1.2. Simulator lifecycle

This chapter gives brief information about the starting and stopping of the EC-Simulator.

Basically the operation of the EC-Simulator stack is wrapped between the functions

3.1.3. Logging

The Example programs cpp demonstrates how messages can be processed by the application, see ExamplesEcSimulatorHilDemoLogging.cpp.

The messages handled by Logging.cpp are of different type, e.g. EC-Simulator Log Messages and Application Messages are logged to console and/or to files. The verbosity of the demo given as console parameter “-v” is used to determine the log level of the application, see “set application log level” in EcSimulatorHilDemoMain.cpp. Logging is configured on initialization, see the structure documentation of EC_T_SIMULATOR_INIT_PARMS::LogParms in esInitSimulator(). The EC-Simulator automatically filters log messages according to EC_T_SIMULATOR_INIT_PARMS::LogParms.dwLogLevel . Log messages which are less relevant according their severity (see EC_LOG_LEVEL…) are filtered out.

CAtEmLogging has various parameters beside the log level, like Roll Over setting, log task prio and affinity, log buffer size, etc. See InitLogging in EcLogging.h, EcSimulatorHilDemoMain.cpp for reference.

The application can override CAtEmLogging::PrintConsole / CAtEmLogging::PrintMsg if the default handler in EcLogging.cpp does not fulfill the application’s needs.

Important

The callback is typically called from the Job Task’s context and should return as fast as possible.

Important

logging to files is disabled by default for some OS. Because e.g. a file system must be added explicitely. Setting bLogFileEnb to 1 is needed for some operating systems to enable file logging.

Identical messages are skipped automatically by default.

3.2. Process data update and synchronization

The EtherCAT© Master cyclically sends frames containing the outputs of the Process Data Image to the EtherCAT© network and the Simulator synchronizes the Process Data Image with the frames from the Master and sends the response back to the Master. The Master cyclically receives the inputs of the Process Data Image from the Simulator.

The HiL Application directly accesses the Process Data Image at Simulator:

The SiL Application directly accesses the Process Data Image at Master and Simulator:

3.2.1. Forced Data, Firmware Data, DPRAM

The EC-Simulator stack synchronizes the outputs and inputs from the Process Data Image and the slave DPRAM areas containing process data objects individually.

3.2.2. EC-Simulator stack as process data memory provider

By default the EC-Simulator stack internally allocates the memory needed to store input and output process data values.

In order to update process data, the application’s JobTask has to call:

  • eUsrJob_ProcessAllRxFrames

    Link layer in polling mode: process all received frames

  • eUsrJob_SimulatorTimer

    Trigger lower level state machines

Important

The Link Layer standard mode is polling. In polling mode, the master cycle time must be at least two times higher than the simulator cycle time. E.g. if the simulator runs with 1ms, the master cycle time must be at least 2ms. If the Link Layer is running in interrupt mode (non-standard), processing of received frames is done immediately after the frame is received.

See also

EC_T_SIMULATOR_INIT_PARMS::bDisableProcessDataImage at esInitSimulator() (HiL) or EC_T_LINK_PARMS_SIMULATOR::bDisableProcessDataImage (SiL) for how to disable allocation and usage of the process data image.

3.2.3. Single or multiple cyclic entries in ENI file

For reading new input data values and writing new output data values (process data update) the EtherCAT configuration file contains one or multiple “Cyclic” entries. These entries contain one or multiple frames (so-called cyclic frames) to be sent cyclically by the master. Inside the cyclic frames there are one or multiple EtherCAT datagrams containing logical read/write commands for reading and writing process data values.

3.2.3.1. Configuration variant 1: single cyclic entry

In the simplest case there is only one single cyclic entry with one or multiple cyclic frames.

All process data synchronization modes support this configuration variant.

3.2.3.2. Configuration variant 2: multiple cyclic entries

For more sophisticated scenarios it is possible to configure the system using multiple cyclic entries with one or multiple cyclic frames for each cyclic entry.

The simulator automatically synchronizes the corresponding tasks as driven by the master.

3.3. Accessing process data in the application

The process data, exchanged between the EC-Simulator stack and the slaves in every cycle, are stored in the process data image. There are two separate memory areas, one for the input data and another one for the output data. The base addresses of these areas are provided by calling the functions emGetProcessImageInputPtr() and emGetProcessImageOutputPtr(). The size of the process data input image is defined in the ENI file under “EtherCATConfig/Config/ProcessImage/Inputs/ByteSize” and “EtherCATConfig/Config/ProcessImage/Outputs/ByteSize”.

See also

emGetProcessImageInputPtr() and emGetProcessImageOutputPtr()

3.3.1. Process Data Access Functions selection

Process data variables that are packed as array of bits are bit aligned and not byte aligned in process data. S

See also

EC_COPYBITS for how to copy data areas with bit offsets that are not byte aligned.

Getting and setting bits that are bit aligned and not byte aligned should be done using EC_SETBITS and EC_GETBITS. Accessing complete EC_T_BYTE, EC_T_WORD, EC_T_DWORD, EC_T_QWORD can be accessed more efficiently using the appropriate macros according to the following table.

Note that these function do not initiate any transfer on wire. Typically process data is transferred as little endian on wire and therefor must be swapped on big endian systems like PPC to be correctly interpreted, see hints in table below.

Variable type

Bit size

Macro

Chapter

Hint

EC_T_BYTE

8

N/A

Bytes are b yte-aligend and can be directly addressed at pbyBuffer[B itOffset/8]

EC_T_WORD

16

EC_SE T_FRM_WORD, EC_G ET_FRM_WORD

4.4.2

Contains swap for big endian systems.

EC_T_DWORD

32

EC_SET _FRM_DWORD, EC_GE T_FRM_DWORD

4.4.3

Contains swap for big endian systems.

EC_T_QWORD

64

EC_SET _FRM_QWORD, EC_GE T_FRM_QWORD

4.4.4

Contains swap for big endian systems.

Bit

1

EC_SETBITS / EC_GETBITS

4.4.8

3.3.2. Process variables’ offset and size

The following screenshot shows variables’ offset and size within the Process Data Image:

Accessing the process data of a specific slave always works by adding an offset to the base address.

There are different ways possible to get this offset. All offsets are given as bit offsets! The offset values will not change until a new configuration is provided (s.a. emConfigureNetwork()) therefore it is sufficient to load them once right after emConfigureNetwork(), it is not needed every cycle.

3.3.2.1. Manually hard coded offsets (compiled in application)

The offset value is figured out from the EtherCAT configuration tool. It’s not recommended to use fixed values because the offsets changes in case of adding/removing slaves to/from the configuration.

As listed in the screenshot above “Slave_1004 [EL2004].Channel 3.Output” in the example is at offset 1.2 with size 0.1. The numbering is Byte.Bit so the offset in the example is Byte 1, Bit 2 means bit offset 8*1+2 = 10 and size is 0*8+1 = 1.

Sample code:

EC_T_BYTE byNewValue = 0x01;

/* get variable from process data */

EC_GETBITS(emGetProcessImageOutputPtr(), &byNewValue, 10 /* offset in bits */, 1 /* size in bits */);

3.3.2.2. Generated PD Layout (compiled in application)

The EC-Engineer can export the process variables to a PD Layout File (C-Header) using the menu item “Network > Export Process Variables” as shown in the following screenshots:

This will generate a header file containing the slaves’ variables like this:

    [...]
#include EC_PACKED_INCLUDESTART(1)
#define PDLAYOUT_OUT_OFFSET_SLAVE_2002 22
typedef struct _T_PDLAYOUT_OUT_SLAVE_2002
{
    EC_T_SWORD  swChannel_1_Output; // Slave_2002 [EL4132].Channel 1.Output ...
    EC_T_SWORD  swChannel_2_Output; // Slave_2002 [EL4132].Channel 2.Output ...
} EC_PACKED(1) T_PDLAYOUT_OUT_SLAVE_2002;
#include EC_PACKED_INCLUDESTOP

Example for changing values in e.g. myAppWorkPd:

EC_T_WORD wVal = EC_GET_FRM_WORD(&((T_PDLAYOUT_OUT_SLAVE_2002*)(pbyPDOut +
PDLAYOUT_OUT_OFFSET_SLAVE_2002))->swChannel_1_Output);

3.3.2.3. Slave / variable offset from configuration

3.3.2.3.1. esGetCfgSlaveInfo

Figure out the slave offsets dynamically by calling the function emGetCfgSlaveInfo(): The offsets are stored in EC_T_CFG_SLAVE_INFO.dwPdOffsIn and EC_T_CFG_SLAVE_INFO.dwPdOffsOut. E.g. setting “Slave_1004 [EL2004].Channel 3.Output” according to the screenshot above is like:

EC_T_BYTE byNewValue = 0x01;

EC_T_CFG_SLAVE_INFO SlaveInfo;
dwRes = esGetCfgSlaveInfo(EC_TRUE, 1004, &SlaveInfo);

/* get variable from process data */
EC_GETBITS(emGetProcessImageOutputPtr(), &byNewValue, SlaveInfo.dwPdOffsOut + 2 /* variable relative offset in bits within slave sync unit */, 1 /* variable size in bits */);
3.3.2.3.2. esFindInpVarByName

Figure out the variable offset by calling the function esFindInpVarByName() or esFindOutpVarByName(): The offset is stored in EC_T_PROCESS_VAR_INFO.nBitOffs. Each input or output has a unique variable name. All variables names are stored in the ENI file under “EtherCATConfig/Config/ProcessImage/Inputs/Variable”. E.g. setting “Slave_1004 [EL2004].Channel 3.Output” according to the screenshot above is like:

EC_T_BYTE byNewValue = 0x01;

EC_T_PROCESS_VAR_INFO VarInfo;
dwRes = esFindOutpVarByName("Slave_1004 [EL2004].Channel 3.Output", &VarInfo)

/* get variable from process data */
EC_GETBITS(emGetProcessImageOutputPtr(), &byNewValue, VarInfo.nBitOffs /* variable absolute offset in bits within Process Data Image */, VarInfo.nBitSize /* size in bits */);

3.4. Hot Connect

The EC-Simulator supports networks with Hot Connect. Initial presence of Hot Connect groups can be configured. If bConnectHcGroups is set, all Hot Connect groups will be initially connected, else all are disconnected.

3.4.1. Configured Station Alias

The network configuration contains the initial setting of the Configured Station Alias e.g. used by the Master to identify Hot Connect Group Heads.

In order to change the Configured Station Alias after loading the configuration, the EEPROM must be updated and the slave needs to be power cycled.

The following examples demonstrates this:

3.5. Error detection and diagnosis

The EC-Simulator API generally return EC_E_NOERROR or an error code.

Messages are logged as descrined in esInitSimulator().

Important

Logging is typically from JobTask context so the handler should queue the messages and process in a low priority task. See logging in EcSimulatorHilDemo .

3.6. RAS-Server for EC-Lyser and EC-Engineer

3.6.1. Integration Requirements

To use the diagnosis tool EC-Lyser with a customer application, some modifications have to be done during integration of the EC-Simulator. The task is to integrate and start the Remote API Server system within the custom application, which provides a socket based uplink, which later on is connected by the EC-Lyser.

An example on how to integrate the Remote API Server within the application is given with the example application EcSimulatorHilDemo, which in case is preconfigured to listen for EC-Lyser on TCP Port 6000 when commandline parameter “-sp” is given.

To clarify the steps, which are needed within a custom application, a developer may use the following pseudo-code segment as a point of start. The Remote API Server library “AtesRasSrv” must be linked.

3.6.2. Pseudo Code

#include "AtEmRasSrv.h"

/* custom Remote API Notification handler, example in EcSimulatorHilDemo (emNotification.cpp) */
EC_T_DWORD RasNotifyCallback(
    EC_T_DWORD          dwCode,     /**< [in]   Notification code identifier */
    EC_T_NOTIFYPARMS*   pParms      /**< [in]   Notification data portion */
                    )
{
    /* custom notification handler */
}
    /* initialization  */
    ATEMRAS_T_SRVPARMS  oRemoteApiConfig = {0};
    EC_T_PVOID          pvRemApiHandle;
    oRemoteApiConfig.dwSignature          = ATEMRASSRV_SIGNATURE;
    oRemoteApiConfig.dwSize               = sizeof(ATEMRAS_T_SRVPARMS);
    /* INADDR_ANY */
    oRemoteApiConfig.oAddr.dwAddr         = 0;
    /*< default is port 6000 > */
    oRemoteApiConfig.wPort                = wServerPort;
    /*< default is 2 msec */
    oRemoteApiConfig.dwCycleTime          = ATEMRAS_CYCLE_TIME;
    oRemoteApiConfig.dwCommunicationTimeout = ATEMRAS_MAX_WATCHDOG_TIMEOUT;
    EC_CPUSET_ZERO(oRemoteApiConfig.oAcceptorThreadCpuAffinityMask);
    oRemoteApiConfig.dwAcceptorThreadPrio           = MAIN_THREAD_PRIO;
    oRemoteApiConfig.dwAcceptorThreadStackSize      = JOBS_THREAD_STACKSIZE;
    EC_CPUSET_ZERO(oRemoteApiConfig.oClientWorkerThreadCpuAffinityMask);
    oRemoteApiConfig.dwClientWorkerThreadPrio       = MAIN_THREAD_PRIO;
    oRemoteApiConfig.dwClientWorkerThreadStackSize  = JOBS_THREAD_STACKSIZE;
    /* RAS notification callback function */
    oRemoteApiConfig.pfnRasNotify     = RasNotifyCallback;
    /* RAS notification callback function context */
    oRemoteApiConfig.pvRasNotifyCtxt = pAppContext->pNotificationHandler;
    /* pre-allocation */
    oRemoteApiConfig.dwMaxQueuedNotificationCnt = 100;
    /* pre-allocation */
    oRemoteApiConfig.dwMaxParallelMbxTferCnt       = 50;
    /* span between to consecutive cyclic notifications of same type */
    oRemoteApiConfig.dwCycErrInterval              = 500;

    /* init simulator */
    esInitSimulator(...);

    /* start remote API server */
    esRasSrvStart(&oRemoteApiConfig, &pvRemApiHandle);

    /* stop remote API server */
    esRasSrvStop(pvRemApiHandle, 2000)

    esDeinitSimulator(...);
}

3.6.3. Required API Calls

3.6.3.1. esRasSrvStart

EC_T_DWORD EC_NAMESPACE::esRasSrvStart(ATEMRAS_T_SRVPARMS *pParms, EC_T_PVOID *ppHandle)

Initializes and start remote API Server Instance.

Parameters
  • pParms – [in] Server start-up parameters

  • ppHandle – [out] Handle to opened instance, used for ctrl access

Returns

EC_E_NOERROR or error code

struct ATEMRAS_T_SRVPARMS

Public Members

EC_T_DWORD dwSignature

[in] Set to ATEMRASSRV_SIGNATURE

EC_T_DWORD dwSize

[in] Set to sizeof(ATEMRAS_T_SRVPARMS)

EC_T_LOG_PARMS LogParms

[in] Logging parameters

ATEMRAS_T_IPADDR oAddr

[in] Server Bind IP Address

EC_T_WORD wPort

[in] Server Bind IP Port

EC_T_WORD wMaxClientCnt

[in] Max. clients in parallel (0: unlimited)

EC_T_DWORD dwCycleTime

[in] Cycle Time of RAS Network access (acceptor, worker)

EC_T_DWORD dwCommunicationTimeout

[in] timeout before automatically closing connection

EC_T_CPUSET oAcceptorThreadCpuAffinityMask

[in] Acceptor Thread CPU affinity mask

EC_T_DWORD dwAcceptorThreadPrio

[in] Acceptor Thread Priority

EC_T_DWORD dwAcceptorThreadStackSize

[in] Acceptor Thread Stack Size

EC_T_CPUSET oClientWorkerThreadCpuAffinityMask

[in] Client Worker Thread CPU affinity mask

EC_T_DWORD dwClientWorkerThreadPrio

[in] Client Worker Thread Priority

EC_T_DWORD dwClientWorkerThreadStackSize

[in] Client Worker Thread Stack Size

EC_T_DWORD dwMaxQueuedNotificationCnt

[in] Amount of concurrently queue able Notifications

EC_T_DWORD dwMaxParallelMbxTferCnt

[in] Amount of concurrent active mailbox transfers

EC_PF_NOTIFY pfnRasNotify

[in] Function pointer called to notify error and status information generated by Remote API Layer

EC_T_VOID *pvRasNotifyCtxt

[in] Notification context returned while calling pfNotification

EC_T_DWORD dwCycErrInterval

[in] Interval which allows cyclic Notifications

3.6.3.2. esRasSrvStop

EC_T_DWORD EC_NAMESPACE::esRasSrvStop(EC_T_PVOID pvHandle, EC_T_DWORD dwTimeout)

Stop and de-initialize remote API Server Instance.

Parameters
  • pvHandle – [in] Handle to previously started Server

  • dwTimeout – [in] Timeout [ms] used to shut down all spawned threads, it’s multiplied internally by the amount of threads spawned.

Returns

EC_E_NOERROR or error code

3.6.3.3. RasNotifyCallback - xxx

Callback function called by Remote API Server in case of State changes or error situations.

Data structure filled with detailed information about the according notification.

struct EC_T_NOTIFYPARMS
EC_T_VOID *pCallerData
EC_T_BYTE *pbyInBuf
EC_T_DWORD dwInBufSize
EC_T_BYTE *pbyOutBuf
EC_T_DWORD dwOutBufSize
EC_T_DWORD *pdwNumOutData

3.6.3.4. RasNotifyCallback - ATEMRAS_NOTIFY_CONNECTION

Notification about a change in the Remote API’s state.

emRasNotify - ATEMRAS_NOTIFY_CONNECTION
Parameter
  • pbyInBuf: [in] Pointer to data of type ATEMRAS_T_CONNOTIFYDESC

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

Data structure containing the new Remote API state and the cause of state change.

struct ATEMRAS_T_CONNOTIFYDESC

Public Members

EC_T_DWORD dwCause

[in] Cause of state connection state change

EC_T_DWORD dwCookie

[in] Unique identification cookie of connection instance.

3.6.3.5. RasNotifyCallback - ATEMRAS_NOTIFY_REGISTER

Notification about a connected application registered a client to the stack.

emRasNotify - ATEMRAS_NOTIFY_REGISTER
Parameter
  • pbyInBuf: [in] Pointer to data of type ATEMRAS_T_REGNOTIFYDESC

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

struct ATEMRAS_T_REGNOTIFYDESC

Public Members

EC_T_DWORD dwCookie

[in] Unique identification cookie of connection instance

EC_T_DWORD dwResult

[in] Result of registration request

EC_T_DWORD dwInstanceId

[in] Master Instance client registered to

EC_T_DWORD dwClientId

[in] Client ID of registered client

3.6.3.6. RasNotifyCallback - ATEMRAS_NOTIFY_UNREGISTER

Notification about a connected application un-registered a client from the simulator stack.

emRasNotify - ATEMRAS_NOTIFY_UNREGISTER
Parameter
  • pbyInBuf: [in] Pointer to data of type ATEMRAS_T_REGNOTIFYDESC

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

RasNotifyCallback - ATEMRAS_NOTIFY_REGISTER

3.6.3.7. RasNotifyCallback - ATEMRAS_NOTIFY_MARSHALERROR

Notification about an error during marshalling in Remote API Server connection layer.

emRasNotify - ATEMRAS_NOTIFY_MARSHALERROR
Parameter
  • pbyInBuf: [in] Pointer to data of type ATEMRAS_T_MARSHALERRORDESC

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

struct ATEMRAS_T_MARSHALERRORDESC

Public Members

EC_T_DWORD dwCookie

[in] Unique identification cookie of connection instance

EC_T_DWORD dwCause

[in] Cause of the command marshalling error

EC_T_DWORD dwLenStatCmd

[in] Length faulty command

EC_T_DWORD dwCommandCode

[in] Command code of faulty command

3.6.3.8. RasNotifyCallback - ATEMRAS_NOTIFY_ACKERROR

Notification about an error during creation of ack / nack packet.

emRasNotify - ATEMRAS_NOTIFY_ACKERROR
Parameter
  • pbyInBuf: [in] Pointer to EC_T_DWORD containing error code

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

3.6.3.9. RasNotifyCallback - ATEMRAS_NOTIFY_NONOTIFYMEMORY

Notification given, when no empty buffers for notifications are available in pre-alloced notification store. This points to a configuration error.

emRasNotify - ATEMRAS_NOTIFY_NONOTIFYMEMORY
Parameter
  • pbyInBuf: [in] Pointer to EC_T_DWORD containing unique identification cookie of connection instance

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

3.6.3.10. RasNotifyCallback - ATEMRAS_NOTIFY_STDNOTIFYMEMORYSMALL

Notification given, when buffersize for standard notifications available in pre-alloced notification store are too small to carry a specific notification. This points to a configuration error.

3.6.3.11. RasNotifyCallback - ATEMRAS_NOTIFY_MBXNOTIFYMEMORYSMALL

Notification given, when buffersize for Mailbox notifications available in pre-alloced notification store are too small to carry a specific notification. This points to a configuration error.

emRasNotify - ATEMRAS_NOTIFY_MBXNOTIFYMEMORYSMALL
Parameter
  • pbyInBuf: [in] Pointer to EC_T_DWORD containing unique identification cookie of connection instance

  • dwInBufSize: [in] Size of the input buffer in bytes

  • pbyOutBuf: [out] Should be set to EC_NULL

  • dwOutBufSize: [in] Should be set to 0

  • pdwNumOutData: [out] Should be set to EC_NULL

This is a serious error. If this error is given, Mailbox Transfer objects may have been become out of sync and therefore no more valid usable.

See also

esRasSrvStart() for Mailbox notifications should be dimensioned correctly.

3.7. EC-Simulator stack Source Code

In a source code delivery the stack sources are divided into 4 parts:

  • SDK Header files

  • Link layer files (multiple Link Layers may be shipped)

  • Link OS layer files (only valid for the Link Layers)

  • stack files (configuration, core and interface layer)

  • OS layer files (only valid for the stack)

The stack can be ported to several different operating systems and CPU architectures with different compilers and development environments. Typically no supported build environment files like IDE projects are shipped with the source code.

To build the stack the appropriate build environment for the target operating system has to be used. If an integrated development environment (IDE) exists (Visual Studio, Eclipse, etc.) several projects containing all necessary files are needed to build the artefacts. If no integrated development environment is available makefiles and dependency rules may have to be created which contain the necessary stack source and header files.

For most platforms three separate independent binaries will have to be generated: #. Link Layer Binary (e.g. a DLL in Windows). The Link Layer binary will be dynamically bound to the application at runtime. (currently not for On Time RTOS-32 and T-Kernel these use static libraries) #. Stack Library #. Remote API Server Library

Link Layer Libraries: the following files have to be included into an IDE project or makefile:

  • Link layer files. Only one single Link Layer must be selected even if multiple Link Layers are shipped. For each Link Layer a separate binary has to be created.

  • Link OS layer files

  • Windows: a dynamic link library (.dll) has to be created. The name of the DLL has to be emllXxxx.dll where Xxxx shall be replaced by the Link Layer type (e.g. emllI8255x.dll for the I8255x Link Layer).

  • Linux/QNX: a shared object library (.so) has to be created.

  • RTX a RTX dynamic link library (.rtdll) has to be created. The name of the DLL has to be emllXxxx.dll where Xxxx shall be replaced by the Link Layer type (e.g. emllI8255x.dll for the I8255x Link Layer).

  • INtime: a shared library (.rsl) has to be created. The name of the RSL has to be emllXxxx.rsl where Xxxx shall be replaced by the Link Layer type (e.g. emllI8255x.rsl for the I8255x Link Layer).

Stack Libraries: the following files have to be included into an IDE project or makefile:

  • stack files

  • OS layer files

  • For all platforms a static library has to be created. This library will have to be linked together with the application.

Remote API Server Binaries: the following files have to be included into an IDE project or makefile:

  • Remote API server files.

  • For all platforms a static library has to be created. This library will have to be linked together with the application.

See also

OS Compiler settings for required toolchain settings

3.8. EcSimulatorHilDemoMotion

The EcSimulatorHilDemoMotion is an extension of the EcSimulatorHilDemo that handles the following additional tasks:

  • Simulating CiA402 capabilities of slaves

The EcSimulatorHilDemoMotion is available “out of the box” for different operating systems.

3.8.1. Command line parameters

EcSimulatorHilDemoMotion supports all parameters supported by EcSimulatorHilDemo . The following additional parameters are supported:

  • “-ds402 <FixedAddress1,…,FixedAddressN>”: Simulate CiA402 capability of slaves. Slaves are passed as comma separated list of fixed Slave adresses to simulate.

The Demo uses the following files in addition to the files used by the EcSimulatorHilDemo:

  • Examples\Common\EcSimulatorDs402.h: Simulation of CiA402 capabilities using slave application’s callback functions, see esSetSlaveSscApplication() .