etherlabmaster: comparison documentation/ethercat

equal deleted inserted replaced

-:ef907b0b5125
+:4d179b06dd3c
 \item Automatic reconfiguration of slaves (for example after power failure)
 during operation.
 \end{itemize}
-\item CANopen-over-EtherCAT (CoE)
+\item CANopen over EtherCAT (CoE)
 \begin{itemize}
-\item Sdo upload, download and information service.
+\item SDO upload, download and information service.
-\item Slave configuration via Sdos.
+\item Slave configuration via SDOs.
-\item Sdo access from userspace and from the application.
+\item SDO access from userspace and from the application.
 \end{itemize}
-\item Ethernet-over-EtherCAT (EoE)
+\item Ethernet over EtherCAT (EoE)
 \begin{itemize}
 \item Transparent use of EoE slaves via virtual network interfaces.
 \item Userspace command-line-tool ``ethercat`` (see sec.~\ref{sec:tool})
 \begin{itemize}
-\item Showing the current bus with slaves, Pdos and Sdos.
+\item Showing the current bus with slaves, PDOs and SDOs.
 \item Showing the bus configuration.
 \item Showing domains and process data.
 \item Setting the master's debug level.
 \item Writing alias addresses.
-\item Sdo uploading/downloading.
+\item SDO uploading/downloading.
 \item Reading/writing a slave's SII.
 \item Setting slave states.
 \item Generate slave description XML.
 \end{itemize}
 \item[Idle phase]\index{Idle phase} takes effect when the master has accepted
 an Ethernet device, but is not requested by any application yet. The master
 runs its state machine (see sec.~\ref{sec:fsm-master}), that automatically
 scans the bus for slaves and executes pending operations from the userspace
-interface (for example Sdo access). The command-line tool can be used to
+interface (for example SDO access). The command-line tool can be used to
 access the bus, but there is no process data exchange because of the missing
 bus configuration.
 \item[Operation phase]\index{Operation phase} The master is requested by an
 application that can provide a bus configuration and exchange process data.
 \paragraph{Process Data Image}
 \index{Process data}
 Slaves offer their inputs and outputs by presenting the master so-called
-``Process Data Objects'' (Pdos\index{Pdo}). The available Pdos can be either
+``Process Data Objects'' (PDOs\index{PDO}). The available PDOs can be either
 determined by reading out the slave's TXPDO and RXPDO SII categories from the
-E$^2$PROM (in case of fixed Pdos) or by reading out the appropriate CoE
+E$^2$PROM (in case of fixed PDOs) or by reading out the appropriate CoE
 objects (see sec.~\ref{sec:coe}), if available.  The application can register
-the Pdos' entries for exchange during cyclic operation. The sum of all
+the PDOs' entries for exchange during cyclic operation. The sum of all
-registered Pdo entries defines the ``process data image'', which is exchanged
+registered PDO entries defines the ``process data image'', which is exchanged
 via datagrams with ``logical'' memory access (like LWR, LRD or LRW) introduced
 in~\cite[sec.~5.4]{dlspec}.
 \paragraph{Process Data Domains}
 \index{Domain}
 The process data image can be easily managed by creating so-called
-``domains'', which allow grouped Pdo exchange. They also take care of managing
+``domains'', which allow grouped PDO exchange. They also take care of managing
-the datagram structures needed to exchange the Pdos. Domains are mandatory for
+the datagram structures needed to exchange the PDOs. Domains are mandatory for
 process data exchange, so there has to be at least one. They were introduced
 for the following reasons:
 \begin{itemize}
 footer: $1500 - 2 - 12 - 2 = 1484$ octets. If the size of the process data
 image exceeds this limit, multiple frames have to be sent, and the image has
 to be partitioned for the use of multiple datagrams. A domain manages this
 automatically.
-\item Not every Pdo has to be exchanged with the same frequency: The values of
+\item Not every PDO has to be exchanged with the same frequency: The values of
-Pdos can vary slowly over time (for example temperature values), so exchanging
+PDOs can vary slowly over time (for example temperature values), so exchanging
 them with a high frequency would just waste bus bandwidth. For this reason,
-multiple domains can be created, to group different Pdos and so allow separate
+multiple domains can be created, to group different PDOs and so allow separate
 exchange.
 \end{itemize}
 There is no upper limit for the number of domains, but each domain occupies
 limited by the slaves.
 \paragraph{FMMU Configuration}
 \index{FMMU!Configuration}
-An application can register Pdo entries for exchange. Every Pdo entry and its
+An application can register PDO entries for exchange. Every PDO entry and its
-parent Pdo is part of a memory area in the slave's physical memory, that is
+parent PDO is part of a memory area in the slave's physical memory, that is
 protected by a sync manager \cite[sec.~6.7]{dlspec} for synchronized access.
 In order to make a sync manager react on a datagram accessing its memory, it
 is necessary to access the last byte covered by the sync manager. Otherwise
 the sync manager will not react on the datagram and no data will be exchanged.
 That is why the whole synchronized memory area has to be included into the
-process data image: For example, if a certain Pdo entry of a slave is
+process data image: For example, if a certain PDO entry of a slave is
 registered for exchange with a certain domain, one FMMU will be configured to
-map the complete sync-manager-protected memory, the Pdo entry resides in. If a
+map the complete sync-manager-protected memory, the PDO entry resides in. If a
-second Pdo entry of the same slave is registered for process data exchange
+second PDO entry of the same slave is registered for process data exchange
 within the same domain, and it resides in the same sync-manager-protected
 memory as the first one, the FMMU configuration is not altered, because the
 desired memory is already part of the domain's process data image. If the
-second Pdo entry would belong to another sync-manager-protected area, this
+second PDO entry would belong to another sync-manager-protected area, this
 complete area would also be included into the domains process data image.
 Figure~\ref{fig:fmmus} gives an overview, how FMMUs are configured to map
 physical memory to logical process data images.
 % TODO
 %
 % Interface version
 % Master Requesting and Releasing
 % Master Locking
-% Configuring Pdo assignment and mapping
+% Configuring PDO assignment and mapping
 % Domains (memory)
-% Pdo entry registration
+% PDO entry registration
-% Sdo configuration
+% SDO configuration
-% Sdo access
+% SDO access
 The application interface provides functions and data structures for
 applications to access an EtherCAT master. The complete documentation of the
 interface is included as Doxygen~\cite{doxygen} comments in the header file
 \textit{include/ecrt.h}. It can either be read directly from the file
 Every application should use the master in two steps:
 \begin{description}
 \item[Configuration] The master is requested and the configuration is applied.
-For example, domains are created, slaves are configured and Pdo entries are
+For example, domains are created, slaves are configured and PDO entries are
 registered (see sec.~\ref{sec:masterconfig}).
 \item[Operation] Cyclic code is run and process data are exchanged (see
 sec.~\ref{sec:cyclic}).
 monitored. If a slave is not in the state it supposed to be, the slave is
 (re-)configured.
 \item[Request handling] Requests (either originating from the application or
 from external sources) are handled. A request is a job that the master shall
-process asynchronously, for example an SII access, Sdo access, or similar.
+process asynchronously, for example an SII access, SDO access, or similar.
 \end{description}
 %------------------------------------------------------------------------------
 \item[SII Data] The SII contents are read into the master's image.
 \item[PREOP] If the slave supports CoE, it is set to PREOP state using the
 State change FSM (see sec.~\ref{sec:fsm-change}) to enable mailbox
-communication and read the Pdo configuration via CoE.
+communication and read the PDO configuration via CoE.
-\item[Pdos] The Pdos are read via CoE (if supported) using the Pdo Reading FSM
+\item[PDOs] The PDOs are read via CoE (if supported) using the PDO Reading FSM
-(see sec.~\ref{sec:fsm-pdo}). If this is successful, the Pdo information from
+(see sec.~\ref{sec:fsm-pdo}). If this is successful, the PDO information from
 the SII (if any) is overwritten.
 \end{description}
 %------------------------------------------------------------------------------
 is skipped.
 \item[PREOP] The state change FSM is used to bring the slave to PREOP state.
 If this is the requested state, the state machine is finished.
-\item[Sdo Configuration] If there is a slave configuration attached (see
+\item[SDO Configuration] If there is a slave configuration attached (see
-sec.~\ref{sec:masterconfig}), and there are any Sdo configurations are
+sec.~\ref{sec:masterconfig}), and there are any SDO configurations are
 provided by the application, these are sent to the slave.
-\item[Pdo Configuration] The Pdo configuration state machine is executed to
+\item[PDO Configuration] The PDO configuration state machine is executed to
-apply all necessary Pdo configurations.
+apply all necessary PDO configurations.
-\item[Pdo Sync Manager Configuration] If any Pdo sync managers exist, they are
+\item[PDO Sync Manager Configuration] If any PDO sync managers exist, they are
 configured.
 \item[FMMU Configuration] If there are FMMUs configurations supplied by the
-application (i.\,e.\ if the application registered Pdo entries), they are
+application (i.\,e.\ if the application registered PDO entries), they are
 applied.
 \item[SAFEOP] The state change FSM is used to bring the slave to SAFEOP state.
 If this is the requested state, the state machine is finished.
 \end{description}
 %------------------------------------------------------------------------------
-\section{The Pdo State Machines}
+\section{The PDO State Machines}
 \label{sec:fsm-pdo}
-\index{FSM!Pdo}
+\index{FSM!PDO}
-The Pdo state machines are a set of state machines that read or write the Pdo
+The PDO state machines are a set of state machines that read or write the PDO
-assignment and the Pdo mapping via the ``CoE Communication Area'' described in
+assignment and the PDO mapping via the ``CoE Communication Area'' described in
-\cite[sec. 5.6.7.4]{alspec}. For the object access, the CANopen-over-EtherCAT
+\cite[sec. 5.6.7.4]{alspec}. For the object access, the CANopen over EtherCAT
 access primitives are used (see sec.~\ref{sec:coe}), so the slave must support
 the CoE mailbox protocol.
-\paragraph{Pdo Reading FSM} This state machine (fig.~\ref{fig:fsm-pdo-read})
+\paragraph{PDO Reading FSM} This state machine (fig.~\ref{fig:fsm-pdo-read})
-has the purpose to read the complete Pdo configuration of a slave. It reads
+has the purpose to read the complete PDO configuration of a slave. It reads
-the Pdo assignment for each Sync Manager and uses the Pdo Entry Reading FSM
+the PDO assignment for each Sync Manager and uses the PDO Entry Reading FSM
-(fig.~\ref{fig:fsm-pdo-entry-read}) to read the mapping for each assigned Pdo.
+(fig.~\ref{fig:fsm-pdo-entry-read}) to read the mapping for each assigned PDO.
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.4\textwidth]{graphs/fsm_pdo_read}
-\caption{Transition Diagram of the Pdo Reading State Machine}
+\caption{Transition Diagram of the PDO Reading State Machine}
 \label{fig:fsm-pdo-read}
 \end{figure}
-Basically it reads the every Sync manager's Pdo assignment Sdo's
+Basically it reads the every Sync manager's PDO assignment SDO's
 (\lstinline+0x1C1x+) number of elements to determine the number of assigned
-Pdos for this sync manager and then reads out the subindices of the Sdo to get
+PDOs for this sync manager and then reads out the subindices of the SDO to get
-the assigned Pdo's indices. When a Pdo index is read, the Pdo Entry Reading
+the assigned PDO's indices. When a PDO index is read, the PDO Entry Reading
-FSM is executed to read the Pdo's mapped Pdo entries.
+FSM is executed to read the PDO's mapped PDO entries.
-\paragraph{Pdo Entry Reading FSM} This state machine
+\paragraph{PDO Entry Reading FSM} This state machine
-(fig.~\ref{fig:fsm-pdo-entry-read}) reads the Pdo mapping (the Pdo entries) of
+(fig.~\ref{fig:fsm-pdo-entry-read}) reads the PDO mapping (the PDO entries) of
-a Pdo. It reads the respective mapping Sdo (\lstinline+0x1600+ --
+a PDO. It reads the respective mapping SDO (\lstinline+0x1600+ --
 \lstinline+0x17ff+, or \lstinline+0x1a00+ -- \lstinline+0x1bff+) for the given
-Pdo by reading first the subindex zero (number of elements) to determine the
+PDO by reading first the subindex zero (number of elements) to determine the
-number of mapped Pdo entries. After that, each subindex is read to get the
+number of mapped PDO entries. After that, each subindex is read to get the
-mapped Pdo entry index, subindex and bit size.
+mapped PDO entry index, subindex and bit size.
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.4\textwidth]{graphs/fsm_pdo_entry_read}
-\caption{Transition Diagram of the Pdo Entry Reading State Machine}
+\caption{Transition Diagram of the PDO Entry Reading State Machine}
 \label{fig:fsm-pdo-entry-read}
 \end{figure}
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.9\textwidth]{graphs/fsm_pdo_conf}
-\caption{Transition Diagram of the Pdo Configuration State Machine}
+\caption{Transition Diagram of the PDO Configuration State Machine}
 \label{fig:fsm-pdo-conf}
 \end{figure}
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.4\textwidth]{graphs/fsm_pdo_entry_conf}
-\caption{Transition Diagram of the Pdo Entry Configuration State Machine}
+\caption{Transition Diagram of the PDO Entry Configuration State Machine}
 \label{fig:fsm-pdo-entry-conf}
 \end{figure}
 %------------------------------------------------------------------------------
 The EtherCAT master implements the EoE and the CoE mailbox
 protocols. See the below section for details.
 %------------------------------------------------------------------------------
-\section{Ethernet-over-EtherCAT (EoE)}
+\section{Ethernet over EtherCAT (EoE)}
 \label{sec:eoe}
 \index{EoE}
 The EtherCAT master implements the
-Ethernet-over-EtherCAT\nomenclature{EoE}{Ethernet-over-EtherCAT, Mailbox
+Ethernet over EtherCAT\nomenclature{EoE}{Ethernet over EtherCAT, Mailbox
 Protocol} mailbox protocol~\cite[sec.~5.7]{alspec} to enable the tunneling of
 Ethernet frames to special slaves, that can either have physical Ethernet
 ports to forward the frames to, or have an own IP stack to receive the frames.
 \paragraph{Virtual Network Interfaces}
 an EoE interface link is set to ``up'', the requested slave's
 application-layer state is automatically set to OP.
 %------------------------------------------------------------------------------
-\section{CANopen-over-EtherCAT (CoE)}
+\section{CANopen over EtherCAT (CoE)}
 \label{sec:coe}
 \index{CoE}
-The CANopen-over-EtherCAT\nomenclature{CoE}{CANopen-over-EtherCAT, Mailbox
+The CANopen over EtherCAT\nomenclature{CoE}{CANopen over EtherCAT, Mailbox
 Protocol} protocol~\cite[sec.~5.6]{alspec} is used to configure slaves and
 exchange data objects on application level.
 % TODO
 %
 % Download / Upload
 % Expedited / Normal
 % Segmenting
-% Sdo Info Services
+% SDO Info Services
 %
 \ldots
-\paragraph{Sdo Download State Machine}
+\paragraph{SDO Download State Machine}
-The best time to apply Sdo configurations is during the slave's PREOP state,
+The best time to apply SDO configurations is during the slave's PREOP state,
 because mailbox communication is already possible and slave's application will
 start with updating input data in the succeeding SAFEOP state. Therefore the
-Sdo configuration has to be part of the slave configuration state machine (see
+SDO configuration has to be part of the slave configuration state machine (see
-sec.~\ref{sec:fsm-conf}): It is implemented via an Sdo download state machine,
+sec.~\ref{sec:fsm-conf}): It is implemented via an SDO download state machine,
 that is executed just before entering the slave's SAFEOP state. In this way,
-it is guaranteed that the Sdo configurations are applied each time, the slave
+it is guaranteed that the SDO configurations are applied each time, the slave
 is reconfigured.
-The transition diagram of the Sdo Download state machine can be seen
+The transition diagram of the SDO Download state machine can be seen
 in figure~\ref{fig:fsm-coedown}.
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.9\textwidth]{images/fsm-coedown} % FIXME
 % FIXME
 \begin{description}
 \item[START] The beginning state of the CoE download state
-machine. The ``Sdo Download Normal Request'' mailbox command is
+machine. The ``SDO Download Normal Request'' mailbox command is
 sent. $\rightarrow$~REQUEST
 \item[REQUEST] It is checked, if the CoE download request has been
 received by the slave. After that, a mailbox check command is issued
 and a timer is started. $\rightarrow$~CHECK
 \item[CHECK] If no mailbox data is available, the timer is checked.
 \begin{itemize}
-\item If it timed out, the Sdo download is aborted.
+\item If it timed out, the SDO download is aborted.
 $\rightarrow$~ERROR
 \item Otherwise, the mailbox is queried again.
 $\rightarrow$~CHECK
 \end{itemize}
 If the mailbox contains new data, the response is fetched.
 $\rightarrow$~RESPONSE
 \item[RESPONSE] If the mailbox response could not be fetched, the data
-is invalid, the wrong protocol was received, or a ``Abort Sdo
+is invalid, the wrong protocol was received, or a ``Abort SDO
-Transfer Request'' was received, the Sdo download is aborted.
+Transfer Request'' was received, the SDO download is aborted.
 $\rightarrow$~ERROR
-If a ``Sdo Download Normal Response'' acknowledgement was received,
+If a ``SDO Download Normal Response'' acknowledgement was received,
-the Sdo download was successful. $\rightarrow$~END
+the SDO download was successful. $\rightarrow$~END
-\item[END] The Sdo download was successful.
+\item[END] The SDO download was successful.
-\item[ERROR] The Sdo download was aborted due to an error.
+\item[ERROR] The SDO download was aborted due to an error.
 \end{description}
 %------------------------------------------------------------------------------
-\section{Vendor-specific-over-EtherCAT (VoE)}
+\section{Vendor specific over EtherCAT (VoE)}
 \label{sec:voe}
 \index{VoE}
 The VoE protocol opens the possibility to implement a vendor-specific mailbox
 communication protocol. VoE mailbox messages are prepended by a VoE header
 \lstinputlisting[basicstyle=\ttfamily\footnotesize]{external/ethercat_master}
 %------------------------------------------------------------------------------
-\subsection{Sync Managers, Pdos and Pdo Entries}
+\subsection{Sync Managers, PDOs and PDO Entries}
 \lstinputlisting[basicstyle=\ttfamily\footnotesize]{external/ethercat_pdos}
 %------------------------------------------------------------------------------
-\subsection{Sdo Dictionary}
+\subsection{SDO Dictionary}
 \lstinputlisting[basicstyle=\ttfamily\footnotesize]{external/ethercat_sdos}
 %------------------------------------------------------------------------------
-\subsection{Sdo Access}
+\subsection{SDO Access}
 \lstinputlisting[basicstyle=\ttfamily\footnotesize]{external/ethercat_download}
 \lstinputlisting[basicstyle=\ttfamily\footnotesize]{external/ethercat_upload}

changeset 1327	4d179b06dd3c
parent 1309	d9f775cbbc1e
child 1364	471cd0e77b55