--- a/documentation/ethercat_doc.tex Tue Sep 26 16:38:38 2006 +0000
+++ b/documentation/ethercat_doc.tex Wed Sep 27 15:25:04 2006 +0000
@@ -114,14 +114,14 @@
If shell commands have to be entered, this is marked by a prompt:
\begin{lstlisting}[gobble=2]
- host>
+ `\$`
\end{lstlisting}
Further, if a shell command has to be entered as the superuser, the
prompt ends with a mesh:
\begin{lstlisting}[gobble=2]
- host#
+ #
\end{lstlisting}
%------------------------------------------------------------------------------
@@ -734,7 +734,7 @@
and connecting it to the first master:
\begin{lstlisting}
- host# `\textbf{modprobe ec\_8139too ec\_device\_index=1}`
+ # `\textbf{modprobe ec\_8139too ec\_device\_index=1}`
\end{lstlisting}
Usually, this command does not have to be entered manually, but is
@@ -1272,7 +1272,7 @@
For example, if the master module has been loaded with the command
\begin{lstlisting}
- host# `\textbf{modprobe ec\_master ec\_master\_count=2}`
+ # `\textbf{modprobe ec\_master ec\_master\_count=2}`
\end{lstlisting}
the two masters can be addressed by their indices 0 and 1 respectively
@@ -2137,13 +2137,13 @@
By calling the \textit{ecrt\_master\_activate()} method, all slaves
are configured according to the prior method calls and are brought
-into \textit{OP} state. In this case, the method has a return value of
-0. Otherwise (wrong configuration or bus failure) the method returns
+into OP state. In this case, the method has a return value of 0.
+Otherwise (wrong configuration or bus failure) the method returns
non-zero.
The \textit{ecrt\_master\_deactivate()} method is the counterpart to
-the activate call: It brings all slaves back into \textit{INIT} state
-again. This method should be called prior to
+the activate call: It brings all slaves back into INIT state again.
+This method should be called prior to
\textit{ecrt\_\-master\_\-release()}.
\paragraph{Locking Callbacks}
@@ -2887,7 +2887,7 @@
machine. There is a datagram issued, that queries the ``AL Control
Response'' attribute \cite[section~5.3.2]{alspec} of all slaves via
broadcast. In this way, all slave states and the number of slaves
- responding can be determined. $\rightarrow$~\textit{BROADCAST}
+ responding can be determined. $\rightarrow$~BROADCAST
\item[BROADCAST] The broadcast datagram is evaluated. A change in the
number of responding slaves is treates as a topology change. If the
@@ -2899,64 +2899,63 @@
normal state and it has to be checked, if all slaves are valid. Now,
the state of every single slave has to be determined. For that, a
(unicast) datagram is issued, that queries the first slave's ``AL
- Control Response'' attribute. $\rightarrow$~\textit{READ STATES}
+ Control Response'' attribute. $\rightarrow$~READ STATES
\item[READ STATES] If the current slave did not respond to its
configured station address, it is marked as offline, and the next
- slave is queried. $\rightarrow$~\textit{READ STATES}
+ slave is queried. $\rightarrow$~READ STATES
If the slave responded, it is marked as online and its current state
- is stored. The next slave is queried. $\rightarrow$~\textit{READ
- STATES}
+ is stored. The next slave is queried. $\rightarrow$~READ STATES
If all slaves have been queried, and the bus is marked for
validation, the validation is started by checking the first slaves
- vendor ID. $\rightarrow$~\textit{VALIDATE VENDOR}
+ vendor ID. $\rightarrow$~VALIDATE VENDOR
If no validation has to be done, it is checked, if all slaves are in
the state they are supposed to be. If not, the first of slave with
the wrong state is reconfigured and brought in the required state.
- $\rightarrow$~\textit{CONFIGURE SLAVES}
+ $\rightarrow$~CONFIGURE SLAVES
If all slaves are in the correct state, the state machine is
- restarted. $\rightarrow$~\textit{START}
+ restarted. $\rightarrow$~START
\item[CONFIGURE SLAVES] The slave configuration state machine is
- executed until termination. $\rightarrow$~\textit{CONFIGURE SLAVES}
+ executed until termination. $\rightarrow$~CONFIGURE SLAVES
If there are still slaves in the wrong state after another check,
the first of these slaves is configured and brought into the correct
- state again. $\rightarrow$~\textit{CONFIGURE SLAVES}
+ state again. $\rightarrow$~CONFIGURE SLAVES
If all slaves are in the correct state, the state machine is
- restarted. $\rightarrow$~\textit{START}
+ restarted. $\rightarrow$~START
\item[VALIDATE VENDOR] The SII state machine is executed until
termination. If the slave has the wrong vendor ID, the state machine
- is restarted. $\rightarrow$~\textit{START}
+ is restarted. $\rightarrow$~START
If the slave has the correct vendor ID, its product ID is queried.
- $\rightarrow$~\textit{VALIDATE PRODUCT}
+ $\rightarrow$~VALIDATE PRODUCT
\item[VALIDATE PRODUCT] The SII state machine is executed until
termination. If the slave has the wrong product ID, the state
- machine is restarted. $\rightarrow$~\textit{START}
+ machine is restarted. $\rightarrow$~START
If the slave has the correct product ID, the next slave's vendor ID
- is queried. $\rightarrow$~\textit{VALIDATE VENDOR}
+ is queried. $\rightarrow$~VALIDATE VENDOR
If all slaves have the correct vendor IDs and product codes, the
configured station addresses can be safely rewritten. This is done
for the first slave marked as offline.
- $\rightarrow$~\textit{REWRITE ADDRESSES}
+ $\rightarrow$~REWRITE ADDRESSES
\item[REWRITE ADDRESSES] If the station address was successfully
written, it is sear\-ched for the next slave marked as offline. If
there is one, its address is reconfigured, too.
- $\rightarrow$~\textit{REWRITE ADDRESSES}
+ $\rightarrow$~REWRITE ADDRESSES
If there are no more slaves marked as offline, the state machine is
- restarted. $\rightarrow$~\textit{START}
+ restarted. $\rightarrow$~START
\end{description}
%------------------------------------------------------------------------------
@@ -2982,72 +2981,72 @@
\item[START] The beginning state of the idle state machine. Similar to
the operation state machine, a broadcast datagram is issued, to
query all slave states and the number of slaves.
- $\rightarrow$~\textit{BROADCAST}
+ $\rightarrow$~BROADCAST
\item[BROADCAST] The number of responding slaves is evaluated. If it
has changed since the last time, this is treated as a topology
change and the internal list of slaves is cleared and rebuild
completely. The slave scan state machine is started for the first
- slave. $\rightarrow$~\textit{SCAN FOR SLAVES}
+ slave. $\rightarrow$~SCAN FOR SLAVES
If no topology change happened, every single slave state is fetched.
- $\rightarrow$~\textit{READ STATES}
+ $\rightarrow$~READ STATES
\item[SCAN FOR SLAVES] The slave scan state machine is executed until
- termination. $\rightarrow$~\textit{SCAN FOR SLAVES}
+ termination. $\rightarrow$~SCAN FOR SLAVES
If there is another slave to scan, the slave scan state machine is
- started again. $\rightarrow$~\textit{SCAN FOR SLAVES}
+ started again. $\rightarrow$~SCAN FOR SLAVES
If all slave information has been fetched, slave addresses are
calculated and EoE processing is started. Then, the state machine is
- restarted. $\rightarrow$~\textit{START}
+ restarted. $\rightarrow$~START
\item[READ STATES] If the slave did not respond to the query, it is
marked as offline. The next slave is queried.
- $\rightarrow$~\textit{READ STATES}
+ $\rightarrow$~READ STATES
If the slave responded, it is marked as online. And the next slave
- is queried. $\rightarrow$~\textit{READ STATES}
+ is queried. $\rightarrow$~READ STATES
If all slave states have been determined, it is checked, if any
slaves are not in the state they supposed to be. If this is true,
the slave configuration state machine is started for the first of
- them. $\rightarrow$~\textit{CONFIGURE SLAVES}
+ them. $\rightarrow$~CONFIGURE SLAVES
If all slaves are in the correct state, it is checked, if any
E$^2$PROM write operations are pending. If this is true, the first
pending operation is executed by starting the SII state machine for
- writing access. $\rightarrow$~\textit{WRITE EEPROM}
+ writing access. $\rightarrow$~WRITE EEPROM
If all these conditions are false, there is nothing to do and the
- state machine is restarted. $\rightarrow$~\textit{START}
+ state machine is restarted. $\rightarrow$~START
\item[CONFIGURE SLAVES] The slave configuration state machine is
- executed until termination. $\rightarrow$~\textit{CONFIGURE SLAVES}
+ executed until termination. $\rightarrow$~CONFIGURE SLAVES
After this, it is checked, if another slave needs a state change. If
this is true, the slave state change state machine is started for
- this slave. $\rightarrow$~\textit{CONFIGURE SLAVES}
+ this slave. $\rightarrow$~CONFIGURE SLAVES
If all slaves are in the correct state, it is determined, if any
E$^2$PROM write operations are pending. If this is true, the first
pending operation is executed by starting the SII state machine for
- writing access. $\rightarrow$~\textit{WRITE EEPROM}
+ writing access. $\rightarrow$~WRITE EEPROM
If all prior conditions are false, the state machine is restarted.
- $\rightarrow$~\textit{START}
+ $\rightarrow$~START
\item[WRITE EEPROM] The SII state machine is executed until
- termination. $\rightarrow$~\textit{WRITE EEPROM}
+ termination. $\rightarrow$~WRITE EEPROM
If the current word has been written successfully, and there are
still word to write, the SII state machine is started for the next
- word. $\rightarrow$~\textit{WRITE EEPROM}
+ word. $\rightarrow$~WRITE EEPROM
If all words have been written successfully, the new E$^2$PROM
contents are evaluated and the state machine is restarted.
- $\rightarrow$~\textit{START}
+ $\rightarrow$~START
\end{description}
@@ -3073,22 +3072,22 @@
the station address is written to the slave, which is always the
ring position~+~$1$. In this way, the address 0x0000 (default
address) is not used, which makes it easy to detect unconfigured
- slaves. $\rightarrow$~\textit{ADDRESS}
+ slaves. $\rightarrow$~ADDRESS
\item[ADDRESS] The writing of the station address is verified. After
that, the slave's ``AL Control Response'' attribute is queried.
- $\rightarrow$~\textit{STATE}
+ $\rightarrow$~STATE
\item[STATE] The AL state is evaluated. A warning is output, if the
slave has still the \textit{Change} bit set. After that, the slave's
``DL Information'' attribute is queried.
- $\rightarrow$~\textit{BASE}
+ $\rightarrow$~BASE
\item[BASE] The queried base data are evaluated: Slave type, revision
and build number, and even more important, the number of supported
sync managers and FMMUs are stored. After that, the slave's data
link layer information is read from the ``DL Status'' attribute at
- address 0x0110. $\rightarrow$~\textit{DATALINK}
+ address 0x0110. $\rightarrow$~DATALINK
\item[DATALINK] In this state, the DL information is evaluated: This
information about the communication ports contains, if the link is
@@ -3100,33 +3099,33 @@
category header, until the last category is reached (type 0xFFFF).
This procedure is started by querying the first category header at
word address 0x0040 via the SII state machine.
- $\rightarrow$~\textit{EEPROM SIZE}
+ $\rightarrow$~EEPROM SIZE
\item[EEPROM SIZE] The SII state machine is executed until
- termination. $\rightarrow$~\textit{EEPROM SIZE}
+ termination. $\rightarrow$~EEPROM SIZE
If the category type does not mark the end of the categories, the
position of the next category header is determined via the length of
the current category, and the SII state machine is started again.
- $\rightarrow$~\textit{EEPROM SIZE}
+ $\rightarrow$~EEPROM SIZE
If the size of the E$^2$PROM contents has been determined, memory is
allocated, to read all the contents. The SII state machine is
- started to read the first word. $\rightarrow$~\textit{EEPROM DATA}
+ started to read the first word. $\rightarrow$~EEPROM DATA
\item[EEPROM DATA] The SII state machine is executed until
- termination. $\rightarrow$~\textit{EEPROM DATA}
+ termination. $\rightarrow$~EEPROM DATA
Two words have been read. If more than one word is needed, the two
words are written in the allocated memory. Otherwise only one word
(the last word) is copied. If more words are to read, the SII state
machine is started again to read the next two words.
- $\rightarrow$~\textit{EEPROM DATA}
+ $\rightarrow$~EEPROM DATA
The complete E$^2$PROM contents have been read. The slave's identity
object and mailbox information are evaluated. Moreover the category
types STRINGS, GENERAL, SYNC and PDO are evaluated. The slave
- scanning has been completed. $\rightarrow$~\textit{END}
+ scanning has been completed. $\rightarrow$~END
\item[END] Slave scanning has been finished.
@@ -3152,89 +3151,88 @@
\begin{description}
\item[INIT] The state change state machine has been initialized to
- bring the slave into the \textit{INIT} state. Now, the slave state
- change state machine is executed until termination.
- $\rightarrow$~\textit{INIT}
+ bring the slave into the INIT state. Now, the slave state change
+ state machine is executed until termination. $\rightarrow$~INIT
If the slave state change failed, the configuration has to be
- aborted. $\rightarrow$~\textit{END}
-
- The slave state change succeeded and the slave is now in
- \textit{INIT} state. If this is the target state, the configuration
- is finished. $\rightarrow$~\textit{END}
+ aborted. $\rightarrow$~END
+
+ The slave state change succeeded and the slave is now in INIT state.
+ If this is the target state, the configuration is finished.
+ $\rightarrow$~END
If the slave does not support any sync managers, the sync manager
configuration can be skipped. The state change state machine is
- started to bring the slave into \textit{PREOP} state.
- $\rightarrow$~\textit{PREOP}
+ started to bring the slave into PREOP state.
+ $\rightarrow$~PREOP
Sync managers are configured conforming to the sync manager category
information provided in the slave's E$^2$PROM. The corresponding
- datagram is issued. $\rightarrow$~\textit{SYNC}
+ datagram is issued. $\rightarrow$~SYNC
\item[SYNC] If the sync manager configuration datagram is accepted,
the sync manager configuration was successful. The slave may now
- enter the \textit{PREOP} state, and the state change state machine
- is started. $\rightarrow$~\textit{PREOP}
+ enter the PREOP state, and the state change state machine is
+ started. $\rightarrow$~PREOP
\item[PREOP] The state change state machine is executed until
- termination. $\rightarrow$~\textit{PREOP}
+ termination. $\rightarrow$~PREOP
If the state change failed, the configuration has to be aborted.
- $\rightarrow$~\textit{END}
-
- If the \textit{PREOP} state was the target state, the configuration
- is finished. $\rightarrow$~\textit{END}
+ $\rightarrow$~END
+
+ If the PREOP state was the target state, the configuration is
+ finished. $\rightarrow$~END
If the slave supports no FMMUs, the FMMU configuration can be
skipped. If the slave has SDOs to configure, it is begun with
- sending the first SDO. $\rightarrow$~\textit{SDO\_CONF}
+ sending the first SDO. $\rightarrow$~SDO\_CONF
If no SDO configurations are provided, the slave can now directly be
- brought into the \textit{SAVEOP} state and the state change state
- machine is started again. $\rightarrow$~\textit{SAVEOP}
+ brought into the SAVEOP state and the state change state machine is
+ started again. $\rightarrow$~SAVEOP
Otherwise, all supported FMMUs are configured according to the PDOs
requested via the master's realtime interface. The appropriate
- datagram is issued. $\rightarrow$~\textit{FMMU}
+ datagram is issued. $\rightarrow$~FMMU
\item[FMMU] The FMMU configuration datagram was accepted. If the slave
has SDOs to configure, it is begun with sending the first SDO.
- $\rightarrow$~\textit{SDO\_CONF}
-
- Otherwise, the slave can now be brought into the \textit{SAVEOP}
- state. The state change state machine is started.
- $\rightarrow$~\textit{SAVEOP}
+ $\rightarrow$~SDO\_CONF
+
+ Otherwise, the slave can now be brought into the SAVEOP state. The
+ state change state machine is started.
+ $\rightarrow$~SAVEOP
\item[SDO\_CONF] The CoE state machine is executed until termination.
- $\rightarrow$~\textit{SDO\_CONF}
+ $\rightarrow$~SDO\_CONF
If another SDO has to be configured, a new SDO download sequence is
- begun. $\rightarrow$~\textit{SDO\_CONF}
-
- Otherwise, the slave can now be brought into the \textit{SAVEOP}
- state. The state change state machine is started.
- $\rightarrow$~\textit{SAVEOP}
+ begun. $\rightarrow$~SDO\_CONF
+
+ Otherwise, the slave can now be brought into the SAVEOP state. The
+ state change state machine is started.
+ $\rightarrow$~SAVEOP
\item[SAVEOP] The state change state machine is executed until
- termination. $\rightarrow$~\textit{SAVEOP}
+ termination. $\rightarrow$~SAVEOP
If the state change failed, the configuration has to be aborted.
- $\rightarrow$~\textit{END}
-
- If the \textit{SAVEOP} state was the target state, the configuration
- is finished. $\rightarrow$~\textit{END}
-
- The slave can now directly be brought into the \textit{OP} state and
- the state change state machine is started a last time.
- $\rightarrow$~\textit{OP}
+ $\rightarrow$~END
+
+ If the SAVEOP state was the target state, the configuration is
+ finished. $\rightarrow$~END
+
+ The slave can now directly be brought into the OP state and the
+ state change state machine is started a last time.
+ $\rightarrow$~OP
\item[OP] The state change state machine is executed until
- termination. $\rightarrow$~\textit{OP}
+ termination. $\rightarrow$~OP
If the state change state machine terminates, the slave
configuration is finished, regardless of its success.
- $\rightarrow$~\textit{END}
+ $\rightarrow$~END
\item[END] The termination state.
@@ -3261,26 +3259,26 @@
\begin{description}
\item[START] The beginning state, where a datagram with the state
change command is written to the slave's ``AL Control Request''
- attribute. Nothing can fail. $\rightarrow$~\textit{CHECK}
+ attribute. Nothing can fail. $\rightarrow$~CHECK
\item[CHECK] After the state change datagram has been sent, the ``AL
Control Response'' attribute is queried with a second datagram.
- $\rightarrow$~\textit{STATUS}
+ $\rightarrow$~STATUS
\item[STATUS] The read memory contents are evaluated: While the
parameter \textit{State} still contains the old slave state, the
slave is busy with reacting on the state change command. In this
case, the attribute has to be queried again.
- $\rightarrow$~\textit{STATUS}
+ $\rightarrow$~STATUS
In case of success, the \textit{State} parameter contains the new
state and the \textit{Change} bit is cleared. The slave is in the
- requested state. $\rightarrow$~\textit{END}
+ requested state. $\rightarrow$~END
If the slave can not process the state change, the \textit{Change}
bit is set: Now the master tries to get the reason for this by
querying the \textit{AL Status Code} parameter.
- $\rightarrow$~\textit{CODE}
+ $\rightarrow$~CODE
\item[END] If the state machine ends in this state, the slaves's state
change has been successful.
@@ -3290,23 +3288,23 @@
this parameter. Anyway, the master has to acknowledge the state
change error by writing the current slave state to the ``AL Control
Request'' attribute with the \textit{Acknowledge} bit set.
- $\rightarrow$~\textit{ACK}
+ $\rightarrow$~ACK
\item[ACK] After that, the ``AL Control Response'' attribute is
queried for the state of the acknowledgement.
- $\rightarrow$~\textit{CHECK ACK}
+ $\rightarrow$~CHECK ACK
\item[CHECK ACK] If the acknowledgement has been accepted by the
slave, the old state is kept. Still, the state change was
- unsuccessful. $\rightarrow$~\textit{ERROR}
+ unsuccessful. $\rightarrow$~ERROR
If the acknowledgement is ignored by the slave, a timeout happens.
In any case, the overall state change was unsuccessful.
- $\rightarrow$~\textit{ERROR}
+ $\rightarrow$~ERROR
If there is still now response from the slave, but the timer did not
run out yet, the slave's ``AL Control Response'' attribute is
- queried again. $\rightarrow$~\textit{CHECK ACK}
+ queried again. $\rightarrow$~CHECK ACK
\item[ERROR] If the state machine ends in this state, the slave's
state change was unsuccessful.
@@ -3334,24 +3332,24 @@
\item[READ\_START] The beginning state for reading access, where the
read request and the requested address are written to the SII
attribute. Nothing can fail up to now.
- $\rightarrow$~\textit{READ\_CHECK}
+ $\rightarrow$~READ\_CHECK
\item[READ\_CHECK] When the SII read request has been sent
successfully, a timer is started. A check/fetch datagram is issued,
that reads out the SII attribute for state and data.
- $\rightarrow$~\textit{READ\_FETCH}
+ $\rightarrow$~READ\_FETCH
\item[READ\_FETCH] Upon reception of the check/fetch datagram, the
\textit{Read Operation} and \textit{Busy} parameters are checked:
\begin{itemize}
\item If the slave is still busy with fetching E$^2$PROM data into
the interface, the timer is checked. If it timed out, the reading
- is aborted ($\rightarrow$~\textit{ERROR}), if not, the check/fetch
- datagram is issued again. $\rightarrow$~\textit{READ\_FETCH}
+ is aborted ($\rightarrow$~ERROR), if not, the check/fetch datagram
+ is issued again. $\rightarrow$~READ\_FETCH
\item If the slave is ready with reading data, these are copied from
the datagram and the read cycle is completed.
- $\rightarrow$~\textit{END}
+ $\rightarrow$~END
\end{itemize}
\end{description}
@@ -3361,22 +3359,22 @@
\item[WRITE\_START] The beginning state for writing access,
respectively. A write request, the target address and the data word
are written to the SII attribute. Nothing can fail.
- $\rightarrow$~\textit{WRITE\_CHECK}
+ $\rightarrow$~WRITE\_CHECK
\item[WRITE\_CHECK] When the SII write request has been sent
successfully, the timer is started. A check datagram is issued, that
reads out the SII attribute for the state of the write operation.
- $\rightarrow$~\textit{WRITE\_CHECK2}
+ $\rightarrow$~WRITE\_CHECK2
\item[WRITE\_CHECK2] Upon reception of the check datagram, the
\textit{Write Operation} and \textit{Busy} parameters are checked:
\begin{itemize}
\item If the slave is still busy with writing E$^2$PROM data, the
timer is checked. If it timed out, the operation is aborted
- ($\rightarrow$~\textit{ERROR}), if not, the check datagram is
- issued again. $\rightarrow$~\textit{WRITE\_CHECK2}
+ ($\rightarrow$~ERROR), if not, the check datagram is issued again.
+ $\rightarrow$~WRITE\_CHECK2
\item If the slave is ready with writing data, the write cycle is
- completed. $\rightarrow$~\textit{END}
+ completed. $\rightarrow$~END
\end{itemize}
\end{description}
@@ -3466,12 +3464,12 @@
the number of EoE interfaces (and handlers) per master to create. This
parameter can either be specified when manually loading the master
module, or (when using the init script) by setting the
-\textit{EOE\_INTERFACES} variable in the sysconfig file (see
+\$EOE\_INTERFACES variable in the sysconfig file (see
section~\ref{sec:sysconfig}). Upon loading of the master module, the
virtual interfaces become available:
\begin{lstlisting}
- host# `\textbf{ifconfig -a}`
+ # `\textbf{ifconfig -a}`
eoe0 Link encap:Ethernet HWaddr 00:11:22:33:44:06
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
@@ -3518,19 +3516,19 @@
\begin{description}
\item[RX\_START] The beginning state of the EoE state machine. A
mailbox check datagram is sent, to query the slave's mailbox for new
- frames. $\rightarrow$~\textit{RX\_CHECK}
+ frames. $\rightarrow$~RX\_CHECK
\item[RX\_CHECK] The mailbox check datagram is received. If the
slave's mailbox did not contain data, a transmit cycle is started.
- $\rightarrow$~\textit{TX\_START}
+ $\rightarrow$~TX\_START
If there are new data in the mailbox, a datagram is sent to fetch
- the new data. $\rightarrow$~\textit{RX\_FETCH}
+ the new data. $\rightarrow$~RX\_FETCH
\item[RX\_FETCH] The fetch datagram is received. If the mailbox data
do not contain a ``EoE Fragment request'' command, the data are
dropped and a transmit sequence is started.
- $\rightarrow$~\textit{TX\_START}
+ $\rightarrow$~TX\_START
If the received Ethernet frame fragment is the first fragment, a new
socket buffer is allocated. In either case, the data are copied into
@@ -3538,26 +3536,26 @@
If the fragment is the last fragment, the socket buffer is forwarded
to the network stack and a transmit sequence is started.
- $\rightarrow$~\textit{TX\_START}
+ $\rightarrow$~TX\_START
Otherwise, a new receive sequence is started to fetch the next
- fragment. $\rightarrow$~\textit{RX\_\-START}
+ fragment. $\rightarrow$~RX\_\-START
\item[TX\_START] The beginning state of a transmit sequence. It is
checked, if the transmittion queue contains a frame to send. If not,
- a receive sequence is started. $\rightarrow$~\textit{RX\_START}
+ a receive sequence is started. $\rightarrow$~RX\_START
If there is a frame to send, it is dequeued. If the queue was
inactive before (because it was full), the queue is woken up with a
call to \textit{netif\_wake\_queue()}. The first fragment of the
- frame is sent. $\rightarrow$~\textit{TX\_SENT}
+ frame is sent. $\rightarrow$~TX\_SENT
\item[TX\_SENT] It is checked, if the first fragment was sent
successfully. If the current frame consists of further fragments,
- the next one is sent. $\rightarrow$~\textit{TX\_SENT}
+ the next one is sent. $\rightarrow$~TX\_SENT
If the last fragment was sent, a new receive sequence is started.
- $\rightarrow$~\textit{RX\_START}
+ $\rightarrow$~RX\_START
\end{description}
\paragraph{EoE Processing}
@@ -3602,12 +3600,11 @@
\paragraph{Automatic Configuration}
-By default, slaves are left in \textit{INIT} state during idle mode.
-If an EoE interface is set to running state (i.~e. with the
-\textit{ifconfig up} command), the requested slave state of the
-related slave is automatically set to \textit{OP}, whereupon the idle
-state machine will attempt to configure the slave and put it into
-operation.
+By default, slaves are left in INIT state during idle mode. If an EoE
+interface is set to running state (i.~e. with the \textit{ifconfig up}
+command), the requested slave state of the related slave is
+automatically set to OP, whereupon the idle state machine will attempt
+to configure the slave and put it into operation.
%------------------------------------------------------------------------------
@@ -3629,15 +3626,15 @@
\paragraph{SDO Download State Machine}
-The best time to apply SDO configurations is during the slave's
-\textit{PREOP} state, because mailbox communication is already
-possible and slave's application will start with updating input data
-in the succeeding \textit{SAVEOP} state. Therefore the SDO
-configuration has to be part of the slave configuration state machine
-(see section~\ref{sec:fsm-conf}): It is implemented via an SDO
-download state machine, that is executed just before entering the
-slave's \textit{SAVEOP} state. In this way, it is guaranteed that the
-SDO configurations are applied each time, the slave is reconfigured.
+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
+SAVEOP state. Therefore the SDO configuration has to be part of the
+slave configuration state machine (see section~\ref{sec:fsm-conf}): It
+is implemented via an SDO download state machine, that is executed
+just before entering the slave's SAVEOP state. In this way, 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
in figure~\ref{fig:fsm-coedown}.
@@ -3652,30 +3649,30 @@
\begin{description}
\item[START] The beginning state of the CoE download state
machine. The ``SDO Download Normal Request'' mailbox command is
- sent. $\rightarrow$~\textit{REQUEST}
+ 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$~\textit{CHECK}
+ 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.
- $\rightarrow$~\textit{ERROR}
+ $\rightarrow$~ERROR
\item Otherwise, the mailbox is queried again.
- $\rightarrow$~\textit{CHECK}
+ $\rightarrow$~CHECK
\end{itemize}
If the mailbox contains new data, the response is fetched.
- $\rightarrow$~\textit{RESPONSE}
+ $\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
Transfer Request'' was received, the SDO download is aborted.
- $\rightarrow$~\textit{ERROR}
+ $\rightarrow$~ERROR
If a ``SDO Download Normal Response'' acknowledgement was received,
- the SDO download was successful. $\rightarrow$~\textit{END}
+ the SDO download was successful. $\rightarrow$~END
\item[END] The SDO download was successful.
@@ -3757,7 +3754,7 @@
file system representation of the master's kobject):
\begin{lstlisting}
- host> `\textbf{ls /sys/ethercat0}`
+ `\$` `\textbf{ls /sys/ethercat0}`
debug_level slave000 slave003 slave006
eeprom_write_enable slave001 slave004 slave007
info slave002 slave005 slave008
@@ -3773,7 +3770,7 @@
defined. Writing is done with command like
\begin{lstlisting}[gobble=4]
- host# `\textbf{echo 1 > /sys/ethercat0/debug\_level}`
+ # `\textbf{echo 1 > /sys/ethercat0/debug\_level}`
\end{lstlisting}
and is receipted with a syslog message by the master:
@@ -3789,7 +3786,7 @@
master. Example contents are below:
\begin{lstlisting}[gobble=4]
- host> `\textbf{cat /sys/ethercat0/info}`
+ `\$` `\textbf{cat /sys/ethercat0/info}`
Mode: IDLE
Slaves: 9
@@ -3815,7 +3812,7 @@
the domain directory contents:
\begin{lstlisting}
- host> `\textbf{ls /sys/ethercat0/domain0}`
+ `\$` `\textbf{ls /sys/ethercat0/domain0}`
image_size
\end{lstlisting}
@@ -3831,7 +3828,7 @@
the EtherCAT bus. Below is a listing of a slave directory:
\begin{lstlisting}
- host> `\textbf{ls /sys/ethercat0/slave003}`
+ `\$` `\textbf{ls /sys/ethercat0/slave003}`
eeprom info state
\end{lstlisting}
@@ -3843,7 +3840,7 @@
about the slave. Below is an example output:
\begin{lstlisting}[gobble=4]
- host> `\textbf{cat /sys/ethercat0/slave003/info}`
+ `\$` `\textbf{cat /sys/ethercat0/slave003/info}`
Name: EL4132 2K. Ana. Ausgang +/-10V
Vendor ID: 0x00000002
@@ -3889,9 +3886,9 @@
It can be read or written:
\begin{lstlisting}[gobble=4]
- host# `\textbf{cat /sys/ethercat0/slave003/state}`
+ # `\textbf{cat /sys/ethercat0/slave003/state}`
OP
- host# `\textbf{echo SAVEOP > /sys/ethercat0/slave003/state}`
+ # `\textbf{echo SAVEOP > /sys/ethercat0/slave003/state}`
\end{lstlisting}
This command should also be receipted with a syslog message:
@@ -3934,7 +3931,7 @@
easier with a tool like \textit{hexdump}:
\begin{lstlisting}
- host> `\textbf{cat /sys/ethercat0/slave003/eeprom | hexdump}`
+ `\$` `\textbf{cat /sys/ethercat0/slave003/eeprom | hexdump}`
0000000 0103 0000 0000 0000 0000 0000 0000 008c
0000010 0002 0000 3052 07f0 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
@@ -3944,7 +3941,7 @@
Backing up E$^2$PROM contents gets as easy as copying a file:
\begin{lstlisting}
- host> `\textbf{cp /sys/ethercat0/slave003/eeprom slave003.eep}`
+ `\$` `\textbf{cp /sys/ethercat0/slave003/eeprom slave003.eep}`
\end{lstlisting}
Writing access is only possible as \textit{root}. Moreover writing has
@@ -3956,7 +3953,7 @@
E$^2$PROM writing is enabled with the command below:
\begin{lstlisting}
- host# `\textbf{echo 1 > /sys/ethercat0/eeprom\_write\_enable}`
+ # `\textbf{echo 1 > /sys/ethercat0/eeprom\_write\_enable}`
\end{lstlisting}
The success can be seen in the syslog messages again:
@@ -3971,7 +3968,7 @@
This validation checks the complete size and the category headers.
\begin{lstlisting}
- host# `\textbf{cat slave003.eep > /sys/ethercat0/slave003/eeprom}`
+ # `\textbf{cat slave003.eep > /sys/ethercat0/slave003/eeprom}`
\end{lstlisting}
The write operation can take a few seconds.
@@ -3992,7 +3989,7 @@
in an output like this:
\begin{lstlisting}
- host> `\textbf{lsec}`
+ `\$` `\textbf{lsec}`
EtherCAT bus listing for master 0:
0 1:0 OP EK1100 Ethernet Kopplerklemme (2A E-Bus)
1 1:1 INIT EL4132 2K. Ana. Ausgang +/-10V
@@ -4017,7 +4014,7 @@
default, but the master index can be specified via command line:
\begin{lstlisting}
- host> `\textbf{lsec -h}`
+ `\$` `\textbf{lsec -h}`
Usage: ec_list [OPTIONS]
-m <IDX> Query master <IDX>.
-h Show this help.
@@ -4074,10 +4071,10 @@
The init script can also be used for manually starting and stopping
the EtherCAT master. It has to be executed with one of the parameters
-\textit{start}, \textit{stop}, \textit{restart} or \textit{status}.
+\texttt{start}, \texttt{stop}, \texttt{restart} or \texttt{status}.
\begin{lstlisting}
- host# `\textbf{/etc/init.d/ethercat restart}`
+ # `\textbf{/etc/init.d/ethercat restart}`
Shutting down EtherCAT master done
Starting EtherCAT master done
\end{lstlisting}
@@ -4102,23 +4099,23 @@
added to a network bridge according to IEEE 802.1D after master
startup. The variable must contain the name of the bridge. To use
this functionality, the kernel must be configured with the
- \textit{CONFIG\_BRIDGE} option and the \textit{bridge-utils} package
- must be installed (i.~e. the \textit{brctl} command is needed).
+ CONFIG\_BRIDGE option and the \textit{bridge-utils} package must be
+ installed (i.~e. the \textit{brctl} command is needed).
\item[EOE\_IP\_ADDRESS] The IP address of the EoE bridge. Setting this
- together with \textit{EOE\_IP\_NETMASK} will let the local host
- communicate with devices on the EoE bridge.
+ together with \$EOE\_IP\_NETMASK will let the local host communicate
+ with devices on the EoE bridge.
\item[EOE\_IP\_NETMASK] IP netmask of the EoE bridge.
\item[EOE\_EXTRA\_INTERFACES] The list of extra interfaces to include
in the EoE brid\-ge. Set this to interconnect the EoE bridge with
- other local interfaces. If \textit{EOE\_\-BRIDGE} is empty or
- undefined, setting this variable has no effect. Important: The IP
- address of the listed interfaces will be cleared. Setting
- \textit{EOE\_\-IP\_\-ADDRESS} and \textit{EOE\_IP\_NETMASK} will
- re-enable them for IP traffic.
+ other local interfaces. If \$EOE\_\-BRIDGE is empty or undefined,
+ setting this variable has no effect. Important: The IP address of
+ the listed interfaces will be cleared. Setting
+ \$EOE\_\-IP\_\-ADDRESS and \$EOE\_IP\_NETMASK will re-enable them
+ for IP traffic.
\item[EOE\_GATEWAY] The IP address of the default gateway. If this
variable is set, the gateway will be renewed after bridge
installation. This is necessary, if the default gateway's interface
- is one of the \textit{EOE\_EXTRA\_INTERFACES}.
+ is one of the \$EOE\_EXTRA\_INTERFACES.
\end{description}
%------------------------------------------------------------------------------
@@ -4306,16 +4303,16 @@
(or similar):
\begin{lstlisting}
- host> `\textbf{tar xjf ethercat-1.1-rXXX.tar.bz2}`
- host> `\textbf{cd ethercat-1.1-rXXX/}`
+ `\$` `\textbf{tar xjf ethercat-1.1-rXXX.tar.bz2}`
+ `\$` `\textbf{cd ethercat-1.1-rXXX/}`
\end{lstlisting}
The tarball was created with GNU Autotools, so the build process
follows the usual commands:
\begin{lstlisting}
- host> `\textbf{./configure}`
- host> `\textbf{make}`
+ `\$` `\textbf{./configure}`
+ `\$` `\textbf{make}`
\end{lstlisting}
The default installation prefix is \textit{/opt/etherlab}. It can be
@@ -4329,8 +4326,8 @@
argument. Example:
\begin{lstlisting}
- host> `\textbf{./configure --with-linux="2.6.17-ipipe"}`
- host> `\textbf{make}`
+ `\$` `\textbf{./configure --with-linux="2.6.17-ipipe"}`
+ `\$` `\textbf{make}`
\end{lstlisting}
The following commands have to be entered as \textit{root}: To install
@@ -4338,7 +4335,7 @@
the user space tools, the below command has to be executed:
\begin{lstlisting}
- host# `\textbf{make install}`
+ # `\textbf{make install}`
\end{lstlisting}
If the EtherCAT master shall be run as a service
@@ -4349,21 +4346,21 @@
suitable for SUSE Linux. It may vary for other distributions.
\begin{lstlisting}
- host# `\textbf{cd /opt/etherlab}`
- host# `\textbf{cp etc/sysconfig/ethercat /etc/sysconfig/}`
- host# `\textbf{cp etc/init.d/ethercat /etc/init.d/}`
- host# `\textbf{insserv ethercat}`
+ # `\textbf{cd /opt/etherlab}`
+ # `\textbf{cp etc/sysconfig/ethercat /etc/sysconfig/}`
+ # `\textbf{cp etc/init.d/ethercat /etc/init.d/}`
+ # `\textbf{insserv ethercat}`
\end{lstlisting}
Now the sysconfig file \texttt{/etc/sysconfig/ethercat} (see
section~\ref{sec:sysconfig}) has to be customized: This is mainly done
-by uncommenting and adjusting the \textit{DEVICE\_INDEX} variable. It
-has to be set to the index of the compatible network device to use
-with EtherCAT, where the order of devices is dependent on their
-position in the PCI bus:
+by uncommenting and adjusting the \$DEVICE\_INDEX variable. It has to
+be set to the index of the compatible network device to use with
+EtherCAT, where the order of devices is dependent on their position in
+the PCI bus:
\begin{lstlisting}[numbers=left,basicstyle=\ttfamily\scriptsize]
- host# `\textbf{lspci}`
+ # `\textbf{lspci}`
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
@@ -4380,14 +4377,14 @@
In the above output of the \textit{lspci} command, two compatible
network devices can be found in lines~\textcircled{\tiny 9} and
-\textcircled{\tiny 11}. The \textit{DEVICE\_INDEX} variable should be
-set to $0$ or $1$, respectively.
+\textcircled{\tiny 11}. The \$DEVICE\_INDEX variable should be set to
+$0$ or $1$, respectively.
After the basic configuration is done, the master can be started with
the below command:
\begin{lstlisting}
- host# `\textbf{/etc/init.d/ethercat start}`
+ # `\textbf{/etc/init.d/ethercat start}`
\end{lstlisting}
The operation of the master can be observed by looking at the
@@ -4550,7 +4547,7 @@
\item[\normalfont\textcircled{\tiny 16}] After the configuration of
process data mapping, the master can be activated for cyclic
operation. This will configure all slaves and bring them into
- \textit{OP} state.
+ OP state.
\item[\normalfont\textcircled{\tiny 20}] This call is needed to avoid
a case differentiation in cyclic operation: The first operation in
cyclic mode is a receive call. Due to the fact, that there is
@@ -4585,8 +4582,8 @@
object. It is assured, that no cyclic work will be done after this
call returns.
\item[\normalfont\textcircled{\tiny 4}] This call deactivates the
- master, which results in all slaves being brought to their
- \textit{INIT} state again.
+ master, which results in all slaves being brought to their INIT
+ state again.
\item[\normalfont\textcircled{\tiny 5}] This call releases the master,
removes any existing configuration and silently starts the idle
mode. The value of the master pointer is invalid after this call and