Implicit Instance of the Master

Object: EtherCAT Master

An instance of the type IoDrvEtherCAT is created for each EtherCAT master that is inserted into the device tree. The name of the instance corresponds to the name of the master in the device tree. The availability of the instance is displayed in the IEC Objects tab of the device editor.

See also

EtherCAT Configurator

Inputs
Name	Data type	Description
`xRestart`	`BOOL`	Rising edge: Master is restarted, all configuration parameters are reloaded.
`xStopBus`	`BOOL`	`TRUE`: Communication is stopped. No further EtherCAT telegrams are dispatched. After that a restart is necessary on most devices since they were switched to the error state.

Outputs
Name	Data type	Description
`xConfigFinished`	`BOOL`	`TRUE`: Transfer of all configuration parameters was completed without error. Communication is running on the bus.
`xDistributedClockInSync`	`BOOL`	If Distributed Clocks are used, the PLC is synchronized with the first EtherCAT slave for which the DC option is activated. The output becomes `TRUE` as soon as the synchronization has been successfully completed. This signal can then be used, for example, in order to activate SoftMotion function blocks only when the PLC is in synchronized mode, since otherwise position jumps could occur. When starting the PLC the output is `FALSE` and changes after a few seconds to `TRUE`. The output is reset to `FALSE` if the synchronization is lost due to some error.
`xError`	`BOOL`	Output becomes `TRUE` if An error occurs during the start of the EtherCAT stack. The communication with the slaves is interrupted, because no further messages can be received (for example because of a cable breakage).
`xSyncInWindow`	`BOOL`	Output becomes `TRUE`, if the Sync Window Monitoring option is activated and the synchronization of all slaves is within `Sync Window`.

Examples

Initiate a restart of the master via the xRestart variable:

EtherCAT_Master.xRestart := xRestart;
Initiate stopping of the communication on the bus via the xStop variable:

EtherCAT_Master.xStopBus := xStop;
Call the master in order to get information about the success of the download of the configuration parameters:

EtherCAT_Master();

xFinish := EtherCAT_Master.xConfigFinished;

Properties of the master:
`AutoSetOperational`	TRUE: In the event of a communication breakdown the master immediately attempts to restart the slaves Default: FALSE
`ConfigRead`	TRUE: Reading of the configuration is complete and the user can edit the settings, for example in order to add self-defined SDOs.
`DCInSyncWindow`	Time window for XDistributedClockInSync. Jitter must be within the window, so that the XDistributedClockInSync output signal remains permanently TRUE. Default: 50 microseconds (200 microseconds when using CODESYS SoftMotion)
`DCClockReferenceTime`	Returns the current time of day of the first slave with 'Distributed Clock'. This time is the reference time for all other slaves and the PLC itself.
`DCIntegralDivider`	Integral factor for the Distributed Clock control loop Default: 20
`DCPropFactor`	Proportional factor for the Distributed Clock control loop Default: 25
`DCSyncToMaster`	Distributed Clock synchronization on the master. If set to `TRUE`, then all slaves are synchronized to the master instead of synchronization of the first slave to the PLC. Default: `FALSE`
`DCSyncToMasterWithSysTime`	Distributed Clock synchronization on the master. `TRUE`: All slaves are synchronized to the system time of the master. The time that is read from `SysTimeRtcHighResGet` is used to distribute the system time of the PLC to all EtherCAT slaves. Default: `FALSE`
`EnableTaskOutputMessage`	EtherCAT signals are normally dispatched by the bus cycle task and additionally from each task that uses slave outputs. In the bus cycle task all outputs are written and all inputs are read. In other tasks the outputs are transferred one more time in order to get them written to the corresponding slaves immediately. In this way an attempt is made to keep the dead time until writing as short as possible. Together with the distributed clocks this can cause problems in some devices, for example if servo controllers are not synchronized with the Sync interrupt, but use the time of writing for internal synchronization. In this case multiple write accesses can occur during a cycle. If `EnableTaskOutputMessage` is set to `FALSE`, exclusively the bus cycle task is used. Further tasks will cause no further messages. Default: `TRUE`
`FirstSlave`	Pointer to the first slave underneath the master
`FrameAtTaskStart`	`TRUE`: The frame for the slave is transferred at the beginning of the task (before the IEC task), which ensures minimum jitter. This command is used to achieve jerk-free movements of servo drives. If this flag is set to `TRUE`, the frame of the output buffer is written in the next cycle (see diagram below). Default: `FALSE` (`TRUE` when using CODESYS SoftMotion)
`LastInstance`	Pointer to linked master list -> previous master
`LastMessage`	This property returns a string with the last message of the EtherCAT stack. `All slaves done` is returned if the start proceeded successfully. The same string is used as for the diagnostic message that is displayed in the EtherCAT master device editor window in online mode.
`NextInstance`	Pointer to linked master list -> next master
`NumberActiveSlaves`	This property returns the number of actually connected slaves. `StartConfigWithLessDevice := TRUE`: the number of physical devices can be detected.
`OpenTimeout`	Timeout for the opening of the network adapter. Default value is 4 seconds.
`SplitFrame`	Used for splitting the frame into two parts. The first part contains the process data, and the second part contains the asynchronous mailbox communication and status flags. Due to the splitting, the process data is received earlier and therefore the jitter of the PLC has less effect on the slaves.
`StartConfigWithLessDevice`	Used for influencing the starting behavior of the stack. The EtherCAT stack normally stops if, for example, five servo controllers are configured in the project, but only three are connected. However, if `StartConfigWithLessDevice := TRUE` in the first cycle, then the stack will nevertheless try to start. In this way it is possible, for example, to perform the universal configuration of 10 servo controllers, but to keep the number actually connected variable. Note that the vendor ID and product ID of each slave is checked in any case. The stack is stopped if a discrepancy is found.