3. Software Integration
3.1. EcSimulatorHilDemo
The example application EcSimulatorHilDemo 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 or interrupt 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 |
Entrypoint for the different operating systems |
EcDemoPlatform.h |
Operating system specific settings (task priorities, timer settings) |
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 |
EcDemoParms.h |
Basic configuration parameters |
EcSelectLinkLayer.cpp |
Common Functions which abstract the command line parsing into Link Layer parameters |
EcNotification.cpp |
Slave monitoring and error detection
(function |
EcSlaveInfo.cpp |
Slave information services |
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 ExamplesCommonEcLogging.cpp.
The messages handled by EcLogging.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 (polling mode only)
Process all received frames from link layer
- eUsrJob_SimulatorTimer
Trigger state machines
Important
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 1 ms, the master cycle time must be at least 2 ms. 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.2.1. Cyclic frames - Link layer 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 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 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 esIoControl - 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 array of bits are bit aligned and not byte aligned in 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. 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 |
Hint |
---|---|---|
EC_T_BYTE (8) |
N/A |
Bytes are byte-aligend 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 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. 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 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(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 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 esGetCfgSlaveInfo()
:
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(dwSimulatorInstanceId, EC_TRUE, 1004, &SlaveInfo);
/* get variable from process data */
EC_GETBITS(esGetProcessImageOutputPtr(dwSimulatorInstanceId), &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(dwSimulatorInstanceId, "Slave_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 slaves will be initially connected.
See also
HiL:
EC_T_SIMULATOR_INIT_PARMS::bConnectHcGroups
atesInitSimulator()
SiL
EC_T_LINK_PARMS_SIMULATOR::bConnectHcGroups
at ecatInitMaster
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:
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. 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 (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 */
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(dwSimulatorInstanceId, &oRemoteApiConfig, &pvRemApiHandle);
/* stop remote API server */
esRasSrvStop(dwSimulatorInstanceId, 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_LOG_PARMS LogParms
[in] Logging parameters
-
EC_PF_NOTIFY pfnRasNotify
[in] Function pointer called to notify error and status information generated by Remote API Layer
-
EC_T_LOG_PARMS LogParms
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
-
EC_T_VOID *pCallerData
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_CONNOTIFYDESCdwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [out] Should be set to EC_NULL
Data structure containing the new Remote API state and the cause of state change.
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_REGNOTIFYDESCdwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [out] Should be set to EC_NULL
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_REGNOTIFYDESCdwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [out] Should be set to EC_NULL
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_MARSHALERRORDESCdwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [out] Should be set to EC_NULL
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 codedwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [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 instancedwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [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 instancedwInBufSize
: [in] Size of the input buffer in bytespbyOutBuf
: [out] Should be set to EC_NULLdwOutBufSize
: [in] Should be set to 0pdwNumOutData
: [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.
See also
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()
.