3. Software Integration

3.1. EcSimulatorSilDemo

The example application EcSimulatorSilDemo will handle the following tasks:

  • Stack initialization

  • Flash process data

  • Out of the box solution for different operating systems:

    • Windows

    • Linux

    • …

  • 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 log files (*.log).

3.1.1. File reference

The Demo application consists of the following files:

EcDemoMain.cpp

Entry point for the different operating systems

EcDemoPlatform.h

Operating system specific settings (task priorities, timer settings)

EcDemoApp.cpp

Initialize, start and terminate the MainDevice and EC-Simulator stack

EcDemoApp.h

Application specific settings for EcSimulatorSilDemo

EcDemoParms.cpp

Parsing of command line parameters and generic helper functions

EcDemoParms.h

Basic configuration parameters

EcSelectLinkLayer.cpp

Common functions which abstract the command line parsing into Real-time Ethernet Driver parameter

EcNotification.cpp

SubDevice monitoring and error detection (function NotifyWrapper() )

EcSlaveInfo.cpp

SubDevice information services

EcLogging.cpp

Message logging functions

EcTimer.cpp

Start and monitor timeouts

EcDemoTimingTask.cpp

Operating system independent default timing task implementation (base class)

EcLogging.cpp

Message logging functions

EcSdoServices.cpp

CoE object dictionary example

EcTimer.cpp

Start and monitor timeouts

3.1.2. Logging

The example program demonstrates how messages can be processed by the application, see Examples/Common/EcLogging.cpp.

The messages handled by EcLogging.cpp are of different type, e.g. MainDevice and EC-Simulator stack 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 EcDemoMain.cpp. Logging is configured on MainDevice stack initialization. The MainDevice and EC-Simulator stack automatically filters log messages according to the log level. Log messages which are less relevant according to 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, EcDemoMain.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 explicitly. 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® MainDevice 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 MainDevice and sends the response back to the MainDevice. The MainDevice cyclically receives the inputs of the Process Data Image from the Simulator.

The SiL Application directly accesses the Process Data Image at MainDevice 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 SubDevice 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 (polling mode only)

    Process all received frames from Real-time Ethernet Driver

  • eUsrJob_SimulatorTimer

    Trigger state machines

Important

In polling mode, the MainDevice cycle time must be at least two times higher than the simulator cycle time. E.g. if the simulator runs with 1 ms, the MainDevice cycle time must be at least 2 ms. If the Real-time Ethernet Driver 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.2.1. Cyclic frames - Real-time Ethernet Driver in polling mode

Application has to perform:

/* Job 1: incoming process data is stored to Process data image (polling mode only) */
esExecJob(dwSimulatorInstanceId, eUsrJob_ProcessAllRxFrames, &bPrevCycProcessed);
...
...
/* do process data cycle */
...
...
/* Job 2: trigger state machines, which are necessary to perform any status change or internal administration tasks */
esExecJob(dwSimulatorInstanceId, eUsrJob_SimulatorTimer, EC_NULL);

For closer details find an example project “EcSimulatorHilDemo” in the folder “Examples”.

3.3. Accessing process data in the application

The process data, exchanged between the EC-Simulator stack and the SubDevices 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 esGetProcessImageInputPtr() and esGetProcessImageOutputPtr(). The size of the process data image is defined in the ENI file under “EtherCATConfig/Config/ProcessImage/Inputs/ByteSize” and “EtherCATConfig/Config/ProcessImage/Outputs/ByteSize” and is returned by esIoCtl - EC_IOCTL_GET_PDMEMORYSIZE and esRegisterClient() at EC_T_REGISTERRESULTS::dwPDOutSize and EC_T_REGISTERRESULTS::dwPDInSize.

See also

3.3.1. Process Data Access Functions selection

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

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. 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 functions do not initiate any transfer on wire. Typically process data is transferred as little endian on wire and therefore must be swapped on big endian systems like PPC to be correctly interpreted, see hints in table below.

Variable type (Bit size)

Macro

Hint

EC_T_BYTE (8)

N/A

Bytes are byte-aligned and can be directly addressed at pbyBuffer[ BitOffset/8]

EC_T_WORD (16)

EC_SET_FRM_WORD, EC_GET_FRM_WORD

Contains swap for big endian systems

EC_T_DWORD (32)

EC_SET_FRM_DWORD, EC_GET_FRM_DWORD

Contains swap for big endian systems

EC_T_QWORD (64)

EC_SET_FRM_QWORD, EC_GET_FRM_QWORD

Contains swap for big endian systems

Bit(1)

EC_SETBITS / EC_GETBITS

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 SubDevice 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. esConfigureNetwork()), therefore it is sufficient to load them once right after esConfigureNetwork(), 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 change when adding/removing SubDevices to/from the configuration.

As listed in the screenshot above “SubDevice_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(esGetProcessImageOutputPtr(dwSimulatorInstanceId), &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 SubDevice’s 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. SubDevice / variable offset from configuration

3.3.2.3.1. esGetCfgSlaveInfo

Figure out the SubDevice offsets dynamically by calling the function esGetCfgSlaveInfo(): The offsets are stored in EC_T_CFG_SLAVE_INFO::dwPdOffsIn and EC_T_CFG_SLAVE_INFO::dwPdOffsOut. E.g. setting “SubDevice_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(dwSimulatorInstanceId, EC_TRUE, 1004, &SlaveInfo);

/* get variable from process data */
EC_GETBITS(esGetProcessImageOutputPtr(dwSimulatorInstanceId), &byNewValue, SlaveInfo.dwPdOffsOut + 2 /* variable relative offset in bits within SubDevice 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 variable names are stored in the ENI file under “EtherCATConfig/Config/ProcessImage/Inputs/Variable”. E.g. setting “SubDevice_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(dwSimulatorInstanceId, "SubDevice_1004 [EL2004].Channel 3.Output", &VarInfo)

/* get variable from process data */
EC_GETBITS(esGetProcessImageOutputPtr(dwSimulatorInstanceId), &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 Hot Connect. The initial presence of Hot Connect groups can be configured. If bConnectHcGroups is set, all Hot Connect groups will be initially connected, else only the mandatory SubDevices will be initially connected.

See also

3.4.1. Configured Station Alias

The network configuration contains the initial setting of the Configured Station Alias e.g. used by the MainDevice 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 SubDevice needs to be power cycled.

The following example demonstrates this:

Configured Station Alias Update Example
    EC_T_WORD wSlaveAddress = 1001;
    EC_T_WORD wAlias = 1234;
    EC_T_WORD wEepromVal = EC_GET_FRM_WORD(&wAlias);

    /* write new station alias to EEPROM */
    dwRes = esWriteSlaveEEPRom(dwSimulatorId, EC_TRUE, wSlaveAddress, ESC_SII_REG_ALIASADDRESS, &wEepromVal, 1, EEPROM_TIMEOUT);
    if (dwRes != EC_E_NOERROR)
    {
        goto Exit;
    }

    /* power cycle slave to apply station alias from ESC_SII_REG_ALIASADDRESS (EEPROM) to ECREG_STATION_ADDRESS_ALIAS (ESC register 0x0012) */
    dwRes = esPowerSlave(dwSimulatorId, wSlaveAddress, EC_FALSE);
    if (dwRes != EC_E_NOERROR)
    {
        goto Exit;
    }
    dwRes = esPowerSlave(dwSimulatorId, wSlaveAddress, EC_TRUE);
    if (dwRes != EC_E_NOERROR)
    {
        goto Exit;
    }

3.5. Cable Redundancy

The EC-Simulator supports Cable Redundancy by using two Network Interfaces to provide the Redundancy feature. Frames are sent from and received on both interfaces.

Important

The MainDevice has restrictions in case of cable redundancy, e.g. it is not allowed to use LRW EtherCAT® commands.

The EC-Simulator SiL cannot automatically connect the red adapter to a matching port within the simulated network topology. The connection must be set explicitly at EC_T_LINK_PARMS_SIMULATOR::oDeviceConnection .

3.6. Running EcSimulatorSilDemo with Cable Redundancy

3.6.1. Linux (EcSimulatorSilDemo)

  • Starting EcSimulatorSilDemo with two links configured and red adapter connected to simulator instance 1, SubDevice 1001, Port C:

cd /opt/EC-Simulator/Bin/Linux/x64
LD_LIBRARY_PATH=. ./EcSimulatorSilDemo -f exi.xml -simulator 1 1 exi.xml -simulator 2 1 exi.xml --connect slave 1 1001 2

3.6.2. EcMasterDemoPython (SiL)

  • Script arguments for Examples/EcMasterDemoPython/EcDemoApp.py with two emllSimulator instances configured and red adapter connected to simulator instance 1, SubDevice 1001, Port C:

-mode 1 -file exi.xml -time 20000 -lvl 3 -link "simulator exi.xml 1 1" -linkred "simulator exi.xml 2 1" -simconnect "slave 1 1001 2"

3.7. Error detection and diagnosis

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

Messages are logged as described in esInitSimulator().

Important

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

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

3.8.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 is preconfigured to listen for EC-Lyser on TCP Port 6000 when command line parameter “-sp” is given.

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

3.8.2. Pseudo Code

#include "EcSimulatorRasServer.h"

/* custom Remote API Notification handler, example in EcSimulatorHilDemo (EcNotification.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  */
    EC_T_RAS_SERVER_PARMS  oRemoteApiConfig;
    OsMemset(&oRemoteApiConfig, 0, sizeof(EC_T_RAS_SERVER_PARMS));
    EC_T_PVOID          pvRemApiHandle;
    oRemoteApiConfig.dwSignature            = EC_RAS_SERVER_SIGNATURE;
    oRemoteApiConfig.dwSize                 = sizeof(EC_T_RAS_SERVER_PARMS);
    /* INADDR_ANY */
    oRemoteApiConfig.oAddr.dwAddr           = 0;
    /*< default is port 6000 > */
    oRemoteApiConfig.wPort                  = wServerPort;
    /*< default is 2 ms */
    oRemoteApiConfig.dwCycleTime            = EC_RAS_CYCLE_TIME;
    oRemoteApiConfig.dwCommunicationTimeout = EC_RAS_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(dwSimulatorInstanceId, &oRemoteApiConfig, &pvRemApiHandle);

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

    esDeinitSimulator(...);
}

3.8.3. Required API Calls

3.8.3.1. esRasSrvStart

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

Initializes and starts a 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 EC_T_RAS_SERVER_PARMS

Public Members

EC_T_DWORD dwSignature

[in] Set to EC_RAS_SERVER_SIGNATURE

EC_T_DWORD dwSize

[in] Set to sizeof(EC_T_RAS_SERVER_PARMS)

EC_T_LOG_PARMS LogParms

[in] Logging parameters

EC_T_IPADDR oAddr

[in] Remote Access Server (RAS) listen IP address

EC_T_WORD wPort

[in] Remote Access Server (RAS) listen 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 [ms] 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

EC_T_DWORD dwMaxQueuedNotificationSize

[in] Size of concurrent active mailbox transfers

EC_PF_CHECK_TOKEN pfCheckToken

[in] Function pointer called to check token

EC_T_VOID *pvCheckTokenContext

[in] Check token context

EC_T_BYTE *pbyTlsCert

[in] TLS certificate filename string

EC_T_DWORD dwTlsCertSize

[in] Size of TLS certeficate

EC_T_TLS_CERT_TYPE eTlsCertType

[in] TLS certeficate type

EC_T_BYTE *pbyTlsPrivKey

[in] TLS private key filename string

EC_T_DWORD dwTlsPrivKeySize

[in] Size of TLS private key

EC_T_TLS_PRIVKEY_TYPE eTlsPrivKeyType

[in] TLS certeficate type

union EC_T_IPADDR
#include <EthernetServices.h>

Public Members

EC_T_INNER_IPADDR sAddr

IPv4 address (endianness independent)

EC_T_DWORD dwAddr

Reserved, use EC_T_IPADDR::sAddr.by instead. OS-Layer socket API calls (SOCKADDR_IN::sin_addr).

struct EC_T_INNER_IPADDR

Public Members

EC_T_BYTE by[4]

IPv4 address (endianness independent)

3.8.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.8.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.8.3.4. RasNotifyCallback - EC_RAS_NOTIFY_CONNECTION

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

RasNotifyCallback - EC_RAS_NOTIFY_CONNECTION
Parameter

  • pbyInBuf: [in] Pointer to data of type EC_T_RAS_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 EC_T_RAS_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.8.3.5. RasNotifyCallback - EC_RAS_NOTIFY_REGISTER

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

RasNotifyCallback - EC_RAS_NOTIFY_REGISTER
Parameter

  • pbyInBuf: [in] Pointer to data of type EC_T_RAS_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 EC_T_RAS_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.8.3.6. RasNotifyCallback - EC_RAS_NOTIFY_UNREGISTER

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

RasNotifyCallback - EC_RAS_NOTIFY_UNREGISTER
Parameter

  • pbyInBuf: [in] Pointer to data of type EC_T_RAS_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 - EC_RAS_NOTIFY_REGISTER

3.8.3.7. RasNotifyCallback - EC_RAS_NOTIFY_MARSHALERROR

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

RasNotifyCallback - EC_RAS_NOTIFY_MARSHALERROR
Parameter

  • pbyInBuf: [in] Pointer to data of type EC_T_RAS_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 EC_T_RAS_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 of the faulty command

EC_T_DWORD dwCommandCode

[in] Command code of the faulty command

3.8.3.8. RasNotifyCallback - EC_RAS_NOTIFY_ACKERROR

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

RasNotifyCallback - EC_RAS_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.8.3.9. RasNotifyCallback - EC_RAS_NOTIFY_NONOTIFYMEMORY

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

RasNotifyCallback - EC_RAS_NOTIFY_NONOTIFYMEMORY
Parameter

  • pbyInBuf: [in] Pointer to EC_T_DWORD containing a 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.8.3.10. RasNotifyCallback - EC_RAS_NOTIFY_STDNOTIFYMEMORYSMALL

Notification given when the buffer size for standard notifications available in pre-alloced notification store is too small to carry a specific notification. This points to a configuration error.

3.8.3.11. RasNotifyCallback - EC_RAS_NOTIFY_MBXNOTIFYMEMORYSMALL

Notification given when the buffer size for Mailbox notifications available in pre-alloced notification store is too small to carry a specific notification. This points to a configuration error.

RasNotifyCallback - EC_RAS_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 occurs, Mailbox Transfer objects may have gotten out of sync and are therefore no longer valid.

See also

esRasSrvStart() for Mailbox notifications should be dimensioned correctly.

3.9. Motion

3.9.1. Internal DS402 Simulation

The EC-Simulator SiL includes an internal DS402 state machine simulation with actual position emulation. Axis movement is implemented by mapping Target position (0x607A) directly to Position actual value (0x6064) in CSP mode, and Target velocity (0x60FF) directly to Velocity actual value (0x606C) in CSV mode.

To enable the internal DS402 simulation the application name of the simulated SubDevice must be set to “DS402” in the EXI file exported by EC-Engineer:

_images/DS402Exi.png

3.9.2. EcSimulatorSilDemoMotion

For basic functionality it suffices to use the internal DS402 Simulation as demonstrated with EcSimulatorSilDemo and an EXI file with the application name of the simulated SubDevice set to “DS402”. It is also possible to implement the motion simulation in the application which needs more source code changes. The EcSimulatorSilDemoMotion is an extension of the EcSimulatorSilDemo that shows how to integrate the DS402 simulation into the EC-Simulator application. It handles the following additional tasks:

  • Simulating CiA402 capabilities of SubDevices

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

See also

EcSimulatorSilDemo

There is also support for multiple axes.

3.9.3. Command line parameters

EcSimulatorSilDemoMotion supports all parameters supported by EcSimulatorSilDemo .

The following additional parameters are supported:

  • “-ds402 <FixedAddress1,…,FixedAddressN>”: Simulate CiA402 capability of SubDevices. SubDevices are passed as comma separated list of fixed SubDevice addresses to simulate.

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

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