200 \item It runs well even without realtime extensions. |
198 \item It runs well even without realtime extensions. |
201 |
199 |
202 \end{itemize} |
200 \end{itemize} |
203 |
201 |
204 \item Common ``Application Interface'' for applications, that want to use |
202 \item Common ``Application Interface'' for applications, that want to use |
205 EtherCAT functionality (see chap.~\ref{sec:ecrt}). |
203 EtherCAT functionality (see chap.~\ref{chap:api}). |
206 |
204 |
207 \item \textit{Domains} are introduced, to allow grouping of process |
205 \item \textit{Domains} are introduced, to allow grouping of process |
208 data transfers with different slave groups and task periods. |
206 data transfers with different slave groups and task periods. |
209 |
207 |
210 \begin{itemize} |
208 \begin{itemize} |
294 Public License (GPL \cite{gpl})\index{GPL}, version 2. Other developers, that |
291 Public License (GPL \cite{gpl})\index{GPL}, version 2. Other developers, that |
295 want to use EtherCAT with Linux systems, are invited to use the master code or |
292 want to use EtherCAT with Linux systems, are invited to use the master code or |
296 even participate on development. |
293 even participate on development. |
297 |
294 |
298 To allow static linking of userspace application against the master's |
295 To allow static linking of userspace application against the master's |
299 application interface (see chap.~\ref{sec:ecrt}), the userspace library (see |
296 application interface (see chap.~\ref{chap:api}), the userspace library (see |
300 sec.~\ref{sec:userlib}) is licensed under the terms and conditions of the GNU |
297 sec.~\ref{sec:userlib}) is licensed under the terms and conditions of the GNU |
301 Lesser General Public License (LGPL \cite{lgpl})\index{LGPL}, version 2.1. |
298 Lesser General Public License (LGPL \cite{lgpl})\index{LGPL}, version 2.1. |
302 |
299 |
303 %------------------------------------------------------------------------------ |
300 %------------------------------------------------------------------------------ |
304 |
301 |
336 |
333 |
337 \paragraph{Master Module} |
334 \paragraph{Master Module} |
338 \index{Master module} |
335 \index{Master module} |
339 |
336 |
340 Kernel module containing one or more EtherCAT master instances (see |
337 Kernel module containing one or more EtherCAT master instances (see |
341 section~\ref{sec:mastermod}), the ``Device Interface'' (see |
338 sec.~\ref{sec:mastermod}), the ``Device Interface'' (see sec.~\ref{sec:ecdev}) |
342 section~\ref{sec:ecdev}) and the ``Application Interface'' (see |
339 and the ``Application Interface'' (see chap.~\ref{chap:api}). |
343 chap.~\ref{sec:ecrt}). |
|
344 |
340 |
345 \paragraph{Device Modules} |
341 \paragraph{Device Modules} |
346 \index{Device modules} |
342 \index{Device modules} |
347 |
343 |
348 EtherCAT-capable Ethernet device driver modules\index{Device modules}, that |
344 EtherCAT-capable Ethernet device driver modules\index{Device modules}, that |
349 offer their devices to the EtherCAT master via the device interface (see |
345 offer their devices to the EtherCAT master via the device interface (see |
350 section~\ref{sec:ecdev}). These modified network drivers can handle network |
346 sec.~\ref{sec:ecdev}). These modified network drivers can handle network |
351 devices used for EtherCAT operation and ``normal'' Ethernet devices in |
347 devices used for EtherCAT operation and ``normal'' Ethernet devices in |
352 parallel. A master can accept a certain device and then is able to send and |
348 parallel. A master can accept a certain device and then is able to send and |
353 receive EtherCAT frames. Ethernet devices declined by the master module are |
349 receive EtherCAT frames. Ethernet devices declined by the master module are |
354 connected to the kernel's network stack as usual. |
350 connected to the kernel's network stack as usual. |
355 |
351 |
359 Kernel modules, that use the EtherCAT master (usually for cyclic exchange of |
355 Kernel modules, that use the EtherCAT master (usually for cyclic exchange of |
360 process data with EtherCAT slaves). These modules are not part of the EtherCAT |
356 process data with EtherCAT slaves). These modules are not part of the EtherCAT |
361 master code\footnote{Although there are some examples provided in the |
357 master code\footnote{Although there are some examples provided in the |
362 \textit{examples/} directory.}, but have to be generated or written by the |
358 \textit{examples/} directory.}, but have to be generated or written by the |
363 user. An application module can ``request'' a master through the application |
359 user. An application module can ``request'' a master through the application |
364 interface (see chap.~\ref{sec:ecrt}). If this succeeds, the module has the |
360 interface (see chap.~\ref{chap:api}). If this succeeds, the module has the |
365 control over the master: It can provide a bus configuration and exchange |
361 control over the master: It can provide a bus configuration and exchange |
366 process data. |
362 process data. |
367 |
363 |
368 %------------------------------------------------------------------------------ |
364 %------------------------------------------------------------------------------ |
369 |
365 |
384 master still waits for its Ethernet device to connect. No bus communication is |
380 master still waits for its Ethernet device to connect. No bus communication is |
385 possible until then. |
381 possible until then. |
386 |
382 |
387 \item[Idle phase]\index{Idle phase} takes effect when the master has accepted |
383 \item[Idle phase]\index{Idle phase} takes effect when the master has accepted |
388 an Ethernet device, but is not requested by any application yet. The master |
384 an Ethernet device, but is not requested by any application yet. The master |
389 runs its state machine (see section~\ref{sec:fsm-master}), that automatically |
385 runs its state machine (see sec.~\ref{sec:fsm-master}), that automatically |
390 scans the bus for slaves and executes pending operations from the userspace |
386 scans the bus for slaves and executes pending operations from the userspace |
391 interface (for example Sdo access). The command-line tool can be used to |
387 interface (for example Sdo access). The command-line tool can be used to |
392 access the bus, but there is no process data exchange because of the missing |
388 access the bus, but there is no process data exchange because of the missing |
393 bus configuration. |
389 bus configuration. |
394 |
390 |
434 \end{lstlisting} |
430 \end{lstlisting} |
435 |
431 |
436 The two masters can be addressed by their indices 0 and 1 respectively (see |
432 The two masters can be addressed by their indices 0 and 1 respectively (see |
437 figure~\ref{fig:masters}). The master index is needed for the |
433 figure~\ref{fig:masters}). The master index is needed for the |
438 \lstinline+ecrt_master_request()+ function of the application interface (see |
434 \lstinline+ecrt_master_request()+ function of the application interface (see |
439 chap.~\ref{sec:ecrt}) and the \lstinline+--master+ option of the |
435 chap.~\ref{chap:api}) and the \lstinline+--master+ option of the |
440 \textit{ethercat} command-line tool (see section~\ref{sec:ethercat}), which |
436 \textit{ethercat} command-line tool (see sec.~\ref{sec:tool}), which defaults |
441 defaults to $0$. |
437 to $0$. |
442 |
438 |
443 \begin{figure}[htbp] |
439 \begin{figure}[htbp] |
444 \centering |
440 \centering |
445 \includegraphics[width=.5\textwidth]{images/masters} |
441 \includegraphics[width=.5\textwidth]{images/masters} |
446 \caption{Multiple masters in one module} |
442 \caption{Multiple masters in one module} |
449 |
445 |
450 \paragraph{Init script} |
446 \paragraph{Init script} |
451 \index{Init script} |
447 \index{Init script} |
452 |
448 |
453 Most probably you won't want to load the master module and the Ethernet driver |
449 Most probably you won't want to load the master module and the Ethernet driver |
454 modules manually, but start the master as a service. See |
450 modules manually, but start the master as a service. See sec.~\ref{sec:system} |
455 section~\ref{sec:system} on how to do this. |
451 on how to do this. |
456 |
452 |
457 \paragraph{Syslog} |
453 \paragraph{Syslog} |
458 |
454 |
459 The master module outputs information about it's state and events to the |
455 The master module outputs information about it's state and events to the |
460 kernel ring buffer. These also end up in the system logs. The above module |
456 kernel ring buffer. These also end up in the system logs. The above module |
484 \paragraph{Process Data Image} |
480 \paragraph{Process Data Image} |
485 \index{Process data} |
481 \index{Process data} |
486 |
482 |
487 The slaves offer their inputs and outputs by presenting the master so-called |
483 The slaves offer their inputs and outputs by presenting the master so-called |
488 ``Process Data Objects'' (Pdos\index{Pdo}). The available Pdos can be |
484 ``Process Data Objects'' (Pdos\index{Pdo}). The available Pdos can be |
489 determined by reading out the slave's TXPDO and RXPDO E$^2$PROM categories. The |
485 determined by reading out the slave's TXPDO and RXPDO E$^2$PROM categories. |
490 application can register the Pdos for data exchange during cyclic operation. |
486 The application can register the Pdos for data exchange during cyclic |
491 The sum of all registered Pdos defines the ``process data image'', which is |
487 operation. The sum of all registered Pdos defines the ``process data image'', |
492 exchanged via the ``Logical ReadWrite'' datagrams introduced |
488 which is exchanged via the ``Logical ReadWrite'' datagrams introduced |
493 in~\cite[section~5.4.2.4]{dlspec}. |
489 in~\cite[sec.~5.4.2.4]{dlspec}. |
494 |
490 |
495 \paragraph{Process Data Domains} |
491 \paragraph{Process Data Domains} |
496 \index{Domain} |
492 \index{Domain} |
497 |
493 |
498 The process data image can be easily managed by creating so-called |
494 The process data image can be easily managed by creating so-called |
522 domains is also limited by the slaves' capabilities. |
518 domains is also limited by the slaves' capabilities. |
523 |
519 |
524 \paragraph{FMMU Configuration} |
520 \paragraph{FMMU Configuration} |
525 \index{FMMU!Configuration} |
521 \index{FMMU!Configuration} |
526 |
522 |
527 An application can register Pdos for process data exchange. Every |
523 An application can register Pdos for process data exchange. Every Pdo is part |
528 Pdo is part of a memory area in the slave's physical memory, that is |
524 of a memory area in the slave's physical memory, that is protected by a sync |
529 protected by a sync manager \cite[section~6.7]{dlspec} for |
525 manager \cite[sec.~6.7]{dlspec} for synchronized access. In order to make a |
530 synchronized access. In order to make a sync manager react on a |
526 sync manager react on a datagram accessing its memory, it is necessary to |
531 datagram accessing its memory, it is necessary to access the last byte |
527 access the last byte covered by the sync manager. Otherwise the sync manager |
532 covered by the sync manager. Otherwise the sync manager will not react |
528 will not react on the datagram and no data will be exchanged. That is why the |
533 on the datagram and no data will be exchanged. That is why the whole |
529 whole synchronized memory area has to be included into the process data image: |
534 synchronized memory area has to be included into the process data |
530 For example, if a certain Pdo of a slave is registered for exchange with a |
535 image: For example, if a certain Pdo of a slave is registered for |
531 certain domain, one FMMU will be configured to map the complete |
536 exchange with a certain domain, one FMMU will be configured to map the |
532 sync-manager-protected memory, the Pdo resides in. If a second Pdo of the same |
537 complete sync-manager-protected memory, the Pdo resides in. If a |
533 slave is registered for process data exchange within the same domain, and this |
538 second Pdo of the same slave is registered for process data exchange |
534 Pdo resides in the same sync-manager-protected memory as the first Pdo, the |
539 within the same domain, and this Pdo resides in the same |
535 FMMU configuration is not touched, because the appropriate memory is already |
540 sync-manager-protected memory as the first Pdo, the FMMU configuration |
536 part of the domain's process data image. If the second Pdo belongs to another |
541 is not touched, because the appropriate memory is already part of the |
537 sync-manager-protected area, this complete area is also included into the |
542 domain's process data image. If the second Pdo belongs to another |
538 domains process data image. See figure~\ref{fig:fmmus} for an overview, how |
543 sync-manager-protected area, this complete area is also included into |
539 FMMU's are configured to map physical memory to logical process data images. |
544 the domains process data image. See figure~\ref{fig:fmmus} for an |
|
545 overview, how FMMU's are configured to map physical memory to logical |
|
546 process data images. |
|
547 |
540 |
548 \begin{figure}[htbp] |
541 \begin{figure}[htbp] |
549 \centering |
542 \centering |
550 \includegraphics[width=\textwidth]{images/fmmus} |
543 \includegraphics[width=\textwidth]{images/fmmus} |
551 \caption{FMMU configuration for several domains} |
544 \caption{FMMU configuration for several domains} |
581 |
574 |
582 The application interface provides functions and data structures for |
575 The application interface provides functions and data structures for |
583 applications to access and use an EtherCAT master. The complete documentation |
576 applications to access and use an EtherCAT master. The complete documentation |
584 of the interface is included as Doxygen~\cite{doxygen} comments in the header |
577 of the interface is included as Doxygen~\cite{doxygen} comments in the header |
585 file \textit{include/ecrt.h}. You can either directly view the file comments |
578 file \textit{include/ecrt.h}. You can either directly view the file comments |
586 or generate an HTML documentation as described in section~\ref{sec:gendoc}. |
579 or generate an HTML documentation as described in sec.~\ref{sec:gendoc}. |
587 |
580 |
588 The following sections cover a general description of the application |
581 The following sections cover a general description of the application |
589 interface. |
582 interface. |
590 |
583 |
591 Every application should use the master in two steps: |
584 Every application should use the master in two steps: |
592 |
585 |
593 \begin{description} |
586 \begin{description} |
594 |
587 |
595 \item[Configuration] The master is requested and the configuration is applied. |
588 \item[Configuration] The master is requested and the configuration is applied. |
596 Domains are created Slaves are configured and Pdo entries are registered (see |
589 Domains are created Slaves are configured and Pdo entries are registered (see |
597 section~\ref{sec:masterconfig}). |
590 sec.~\ref{sec:masterconfig}). |
598 |
591 |
599 \item[Operation] Cyclic code is run, process data is exchanged (see |
592 \item[Operation] Cyclic code is run, process data is exchanged (see |
600 section~\ref{sec:cyclic}). |
593 sec.~\ref{sec:cyclic}). |
601 |
594 |
602 \end{description} |
595 \end{description} |
603 |
596 |
604 \paragraph{Example Applications} \index{Example Applications} There are a few |
597 \paragraph{Example Applications} \index{Example Applications} There are a few |
605 example applications in the \textit{examples/} subdirectory of the master |
598 example applications in the \textit{examples/} subdirectory of the master |
634 \section{Concurrent Master Access} % FIXME |
627 \section{Concurrent Master Access} % FIXME |
635 \label{sec:concurr} |
628 \label{sec:concurr} |
636 \index{Concurrency} |
629 \index{Concurrency} |
637 |
630 |
638 In some cases, one master is used by several instances, for example when an |
631 In some cases, one master is used by several instances, for example when an |
639 application does cyclic process data exchange, and there are EoE-capable slaves |
632 application does cyclic process data exchange, and there are EoE-capable |
640 that require to exchange Ethernet data with the kernel (see |
633 slaves that require to exchange Ethernet data with the kernel (see |
641 section~\ref{sec:eoe}). For this reason, the master is a shared resource, |
634 sec.~\ref{sec:eoe}). For this reason, the master is a shared resource, and |
642 and access to it has to be sequentialized. This is usually done by locking with |
635 access to it has to be sequentialized. This is usually done by locking with |
643 semaphores, or other methods to protect critical sections. |
636 semaphores, or other methods to protect critical sections. |
644 |
637 |
645 The master itself can not provide locking mechanisms, because it has no chance |
638 The master itself can not provide locking mechanisms, because it has no chance |
646 to know the appropriate kind of lock. For example if the application uses RTAI |
639 to know the appropriate kind of lock. For example if the application uses RTAI |
647 functionality, ordinary kernel semaphores would not be sufficient. For that, an |
640 functionality, ordinary kernel semaphores would not be sufficient. For that, an |
662 Figure~\ref{fig:locks} exemplary shows, how two processes share one master: |
655 Figure~\ref{fig:locks} exemplary shows, how two processes share one master: |
663 The application's cyclic task uses the master for process data exchange, while |
656 The application's cyclic task uses the master for process data exchange, while |
664 the master-internal EoE process uses it to communicate with EoE-capable |
657 the master-internal EoE process uses it to communicate with EoE-capable |
665 slaves. Both have to acquire the master lock before access: The application |
658 slaves. Both have to acquire the master lock before access: The application |
666 task can access the lock natively, while the EoE process has to use the |
659 task can access the lock natively, while the EoE process has to use the |
667 callbacks. See the application interface documentation (chap.~\ref{sec:ecrt} |
660 callbacks. See the application interface documentation (chap.~\ref{chap:api} |
668 of how to use the locking callbacks. |
661 of how to use the locking callbacks. |
669 |
662 |
670 %------------------------------------------------------------------------------ |
663 %------------------------------------------------------------------------------ |
671 |
664 |
672 \chapter{Ethernet Devices} |
665 \chapter{Ethernet Devices} |
812 network driver. |
805 network driver. |
813 |
806 |
814 %------------------------------------------------------------------------------ |
807 %------------------------------------------------------------------------------ |
815 |
808 |
816 \section{EtherCAT Device Drivers} |
809 \section{EtherCAT Device Drivers} |
817 \label{sec:ethercatdrivers} |
810 \label{sec:drivers} |
818 |
811 |
819 There are a few requirements for Ethernet network devices to function as |
812 There are a few requirements for Ethernet network devices to function as |
820 EtherCAT devices, when connected to an EtherCAT bus. |
813 EtherCAT devices, when connected to an EtherCAT bus. |
821 |
814 |
822 \paragraph{Dedicated Interfaces} |
815 \paragraph{Dedicated Interfaces} |
906 \section{Device Selection} |
899 \section{Device Selection} |
907 \label{sec:deviceselection} |
900 \label{sec:deviceselection} |
908 |
901 |
909 After loading the master module, at least one EtherCAT-capable network driver |
902 After loading the master module, at least one EtherCAT-capable network driver |
910 module has to be loaded, that offers its devices to the master (see |
903 module has to be loaded, that offers its devices to the master (see |
911 section~\ref{sec:ecdev}. The master module knows the devices to choose from the |
904 sec.~\ref{sec:ecdev}. The master module knows the devices to choose from the |
912 module parameters (see section~\ref{sec:mastermod}). If the init script is used |
905 module parameters (see sec.~\ref{sec:mastermod}). If the init script is used |
913 to start the master, the drivers and devices to use can be specified in the |
906 to start the master, the drivers and devices to use can be specified in the |
914 sysconfig file (see section~\ref{sec:sysconfig}). |
907 sysconfig file (see sec.~\ref{sec:sysconfig}). |
915 |
908 |
916 %------------------------------------------------------------------------------ |
909 %------------------------------------------------------------------------------ |
917 |
910 |
918 \section{EtherCAT Device Interface} |
911 \section{EtherCAT Device Interface} |
919 \label{sec:ecdev} |
912 \label{sec:ecdev} |
920 \index{Device interface} |
913 \index{Device interface} |
921 |
914 |
922 An anticipation to the section about the master module |
915 An anticipation to the section about the master module |
923 (section~\ref{sec:mastermod}) has to be made in order to understand |
916 (sec.~\ref{sec:mastermod}) has to be made in order to understand the way, a |
924 the way, a network device driver module can connect a device to a |
917 network device driver module can connect a device to a specific EtherCAT |
925 specific EtherCAT master. |
918 master. |
926 |
919 |
927 The master module provides a ``device interface'' for network device drivers. |
920 The master module provides a ``device interface'' for network device drivers. |
928 To use this interface, a network device driver module must include the header |
921 To use this interface, a network device driver module must include the header |
929 \textit{devices/ecdev.h}\nomenclature{ecdev}{EtherCAT Device}, coming with the |
922 \textit{devices/ecdev.h}\nomenclature{ecdev}{EtherCAT Device}, coming with the |
930 EtherCAT master code. This header offers a function interface for EtherCAT |
923 EtherCAT master code. This header offers a function interface for EtherCAT |
931 devices. All functions of the device interface are named with the prefix |
924 devices. All functions of the device interface are named with the prefix |
932 \lstinline+ecdev+. |
925 \lstinline+ecdev+. |
933 |
926 |
934 The documentation of the device interface can be found in the header file or in |
927 The documentation of the device interface can be found in the header file or |
935 the appropriate module of the interface documentation (see |
928 in the appropriate module of the interface documentation (see |
936 section~\ref{sec:gendoc} for generation instructions). |
929 sec.~\ref{sec:gendoc} for generation instructions). |
937 |
930 |
938 \ldots % FIXME general description of the device interface |
931 \ldots % FIXME general description of the device interface |
939 |
932 |
940 %------------------------------------------------------------------------------ |
933 %------------------------------------------------------------------------------ |
941 |
934 |
971 a \lstinline+net_device+ structure with a \lstinline+priv_data+ field to |
964 a \lstinline+net_device+ structure with a \lstinline+priv_data+ field to |
972 attach driver-dependent data to the structure. To distinguish between normal |
965 attach driver-dependent data to the structure. To distinguish between normal |
973 Ethernet devices and the ones used by EtherCAT masters, the private data |
966 Ethernet devices and the ones used by EtherCAT masters, the private data |
974 structure used by the driver could be extended by a pointer, that points to an |
967 structure used by the driver could be extended by a pointer, that points to an |
975 \lstinline+ec_device_t+ object returned by \lstinline+ecdev_offer()+ (see |
968 \lstinline+ec_device_t+ object returned by \lstinline+ecdev_offer()+ (see |
976 section~\ref{sec:ecdev}) if the device is used by a master and otherwise is |
969 sec.~\ref{sec:ecdev}) if the device is used by a master and otherwise is zero. |
977 zero. |
|
978 |
970 |
979 The RealTek RTL-8139 Fast Ethernet driver is a ``simple'' Ethernet driver and |
971 The RealTek RTL-8139 Fast Ethernet driver is a ``simple'' Ethernet driver and |
980 can be taken as an example to patch new drivers. The interesting sections can |
972 can be taken as an example to patch new drivers. The interesting sections can |
981 be found by searching the string ``ecdev" in the file |
973 be found by searching the string ``ecdev" in the file |
982 \textit{devices/8139too-2.6.24-ethercat.c}. |
974 \textit{devices/8139too-2.6.24-ethercat.c}. |
1008 the function is deprecated and stopped existing. Nevertheless it is adequate |
1000 the function is deprecated and stopped existing. Nevertheless it is adequate |
1009 for showing it's own restrictions.}. Internally, it queues the specified |
1001 for showing it's own restrictions.}. Internally, it queues the specified |
1010 datagram, invokes the \textit{ec\_master\_send\_datagrams()} function to send |
1002 datagram, invokes the \textit{ec\_master\_send\_datagrams()} function to send |
1011 a frame with the queued datagram and then waits actively for its reception. |
1003 a frame with the queued datagram and then waits actively for its reception. |
1012 |
1004 |
1013 This sequential approach is very simple, reflecting in only three |
1005 This sequential approach is very simple, reflecting in only three lines of |
1014 lines of code. The disadvantage is, that the master is blocked for the |
1006 code. The disadvantage is, that the master is blocked for the time it waits |
1015 time it waits for datagram reception. There is no difficulty when only |
1007 for datagram reception. There is no difficulty when only one instance is using |
1016 one instance is using the master, but if more instances want to |
1008 the master, but if more instances want to (synchronously\footnote{At this |
1017 (synchronously\footnote{At this time, synchronous master access will |
1009 time, synchronous master access will be adequate to show the advantages of an |
1018 be adequate to show the advantages of an FSM. The asynchronous |
1010 FSM. The asynchronous approach will be discussed in sec.~\ref{sec:eoe}}) use |
1019 approach will be discussed in section~\ref{sec:eoe}}) use the |
1011 the master, it is inevitable to think about an alternative to the sequential |
1020 master, it is inevitable to think about an alternative to the |
1012 model. |
1021 sequential model. |
|
1022 |
1013 |
1023 Master access has to be sequentialized for more than one instance |
1014 Master access has to be sequentialized for more than one instance |
1024 wanting to send and receive datagrams synchronously. With the present |
1015 wanting to send and receive datagrams synchronously. With the present |
1025 approach, this would result in having one phase of active waiting for |
1016 approach, this would result in having one phase of active waiting for |
1026 each instance, which would be non-acceptable especially in realtime |
1017 each instance, which would be non-acceptable especially in realtime |
1061 } |
1052 } |
1062 slave_states = EC_READ_U8(datagram->data); // process datagram |
1053 slave_states = EC_READ_U8(datagram->data); // process datagram |
1063 // state processing finished. |
1054 // state processing finished. |
1064 \end{lstlisting} |
1055 \end{lstlisting} |
1065 |
1056 |
1066 See section~\ref{sec:statemodel} for an introduction to the |
1057 See sec.~\ref{sec:statemodel} for an introduction to the state machine |
1067 state machine programming concept used in the master code. |
1058 programming concept used in the master code. |
1068 |
1059 |
1069 %------------------------------------------------------------------------------ |
1060 %------------------------------------------------------------------------------ |
1070 |
1061 |
1071 \section{State Machine Theory} |
1062 \section{State Machine Theory} |
1072 \label{sec:fsmtheory} |
1063 \label{sec:fsmtheory} |
1240 \paragraph{Mealy and Moore} |
1231 \paragraph{Mealy and Moore} |
1241 |
1232 |
1242 If a closer look is taken to the above listing, it can be seen that the |
1233 If a closer look is taken to the above listing, it can be seen that the |
1243 actions executed (the ``outputs'' of the state machine) only depend on the |
1234 actions executed (the ``outputs'' of the state machine) only depend on the |
1244 current state. This accords to the ``Moore'' model introduced in |
1235 current state. This accords to the ``Moore'' model introduced in |
1245 section~\ref{sec:fsmtheory}. As mentioned, the ``Mealy'' model offers a higher |
1236 sec.~\ref{sec:fsmtheory}. As mentioned, the ``Mealy'' model offers a higher |
1246 flexibility, which can be seen in the listing below: |
1237 flexibility, which can be seen in the listing below: |
1247 |
1238 |
1248 \begin{lstlisting}[gobble=2,language=C,numbers=left] |
1239 \begin{lstlisting}[gobble=2,language=C,numbers=left] |
1249 void state7(void *priv_data) { |
1240 void state7(void *priv_data) { |
1250 if (some_condition) { |
1241 if (some_condition) { |
1289 \paragraph{Using Sub State Machines} |
1280 \paragraph{Using Sub State Machines} |
1290 |
1281 |
1291 To avoid having too much states, certain functions of the EtherCAT master |
1282 To avoid having too much states, certain functions of the EtherCAT master |
1292 state machine have been sourced out into sub state machines. This helps to |
1283 state machine have been sourced out into sub state machines. This helps to |
1293 encapsulate the related workflows and moreover avoids the ``state explosion'' |
1284 encapsulate the related workflows and moreover avoids the ``state explosion'' |
1294 phenomenon described in section~\ref{sec:fsmtheory}. If the master would |
1285 phenomenon described in sec.~\ref{sec:fsmtheory}. If the master would instead |
1295 instead use one big state machine, the number of states would be a multiple of |
1286 use one big state machine, the number of states would be a multiple of the |
1296 the actual number. This would increase the level of complexity to a |
1287 actual number. This would increase the level of complexity to a non-manageable |
1297 non-manageable grade. |
1288 grade. |
1298 |
1289 |
1299 \paragraph{Executing Sub State Machines} |
1290 \paragraph{Executing Sub State Machines} |
1300 |
1291 |
1301 If a state machine starts to execute a sub state machine, it usually |
1292 If a state machine starts to execute a sub state machine, it usually |
1302 remains in one state until the sub state machine terminates. This is |
1293 remains in one state until the sub state machine terminates. This is |
1410 image memory. |
1401 image memory. |
1411 |
1402 |
1412 \item[SII Data] The SII contents are read into the master's image. |
1403 \item[SII Data] The SII contents are read into the master's image. |
1413 |
1404 |
1414 \item[PREOP] If the slave supports CoE, it is set to PREOP state using the |
1405 \item[PREOP] If the slave supports CoE, it is set to PREOP state using the |
1415 State change FSM (see section~\ref{sec:fsm-change}) to enable mailbox |
1406 State change FSM (see sec.~\ref{sec:fsm-change}) to enable mailbox |
1416 communication and read the Pdo configuration via CoE. |
1407 communication and read the Pdo configuration via CoE. |
1417 |
1408 |
1418 \item[Pdos] The Pdos are read via CoE (if supported) using the Pdo Reading FSM |
1409 \item[Pdos] The Pdos are read via CoE (if supported) using the Pdo Reading FSM |
1419 (see section~\ref{sec:fsm-pdo}). If this is successful, the Pdo information |
1410 (see sec.~\ref{sec:fsm-pdo}). If this is successful, the Pdo information from |
1420 from the SII (if any) is overwritten. |
1411 the SII (if any) is overwritten. |
1421 |
1412 |
1422 \end{description} |
1413 \end{description} |
1423 |
1414 |
1424 %------------------------------------------------------------------------------ |
1415 %------------------------------------------------------------------------------ |
1425 |
1416 |
1454 |
1445 |
1455 \item[PREOP] The state change FSM is used to bring the slave to PREOP state. |
1446 \item[PREOP] The state change FSM is used to bring the slave to PREOP state. |
1456 If this is the requested state, the state machine is finished. |
1447 If this is the requested state, the state machine is finished. |
1457 |
1448 |
1458 \item[Sdo Configuration] If there is a slave configuration attached (see |
1449 \item[Sdo Configuration] If there is a slave configuration attached (see |
1459 section~\ref{sec:masterconfig}), and there are any Sdo configurations are |
1450 sec.~\ref{sec:masterconfig}), and there are any Sdo configurations are |
1460 provided by the application, these are sent to the slave. |
1451 provided by the application, these are sent to the slave. |
1461 |
1452 |
1462 \item[Pdo Configuration] The Pdo configuration state machine is executed to |
1453 \item[Pdo Configuration] The Pdo configuration state machine is executed to |
1463 apply all necessary Pdo configurations. |
1454 apply all necessary Pdo configurations. |
1464 |
1455 |
1484 \index{FSM!State Change} |
1475 \index{FSM!State Change} |
1485 |
1476 |
1486 The state change state machine, which can be seen in |
1477 The state change state machine, which can be seen in |
1487 figure~\ref{fig:fsm-change}, leads through the process of changing a slave's |
1478 figure~\ref{fig:fsm-change}, leads through the process of changing a slave's |
1488 application-layer state. This implements the states and transitions described |
1479 application-layer state. This implements the states and transitions described |
1489 in \cite[section~6.4.1]{alspec}. |
1480 in \cite[sec.~6.4.1]{alspec}. |
1490 |
1481 |
1491 \begin{figure}[htbp] |
1482 \begin{figure}[htbp] |
1492 \centering |
1483 \centering |
1493 \includegraphics[width=.6\textwidth]{graphs/fsm_change} |
1484 \includegraphics[width=.6\textwidth]{graphs/fsm_change} |
1494 \caption{Transition Diagram of the State Change State Machine} |
1485 \caption{Transition Diagram of the State Change State Machine} |
1496 \end{figure} |
1487 \end{figure} |
1497 |
1488 |
1498 \begin{description} |
1489 \begin{description} |
1499 |
1490 |
1500 \item[Start] The new application-layer state is requested via the ``AL Control |
1491 \item[Start] The new application-layer state is requested via the ``AL Control |
1501 Request'' register (see ~\cite[section 5.3.1]{alspec}). |
1492 Request'' register (see ~\cite[sec. 5.3.1]{alspec}). |
1502 |
1493 |
1503 \item[Check for Response] Some slave need some time to respond to an AL state |
1494 \item[Check for Response] Some slave need some time to respond to an AL state |
1504 change command, and do not respond for some time. For this case, the command |
1495 change command, and do not respond for some time. For this case, the command |
1505 is issued again, until it is acknowledged. |
1496 is issued again, until it is acknowledged. |
1506 |
1497 |
1507 \item[Check AL Status] If the AL State change datagram was acknowledged, the |
1498 \item[Check AL Status] If the AL State change datagram was acknowledged, the |
1508 ``AL Control Response'' register (see~\cite[section 5.3.2]{alspec}) must be |
1499 ``AL Control Response'' register (see~\cite[sec. 5.3.2]{alspec}) must be read |
1509 read out until the slave changes the AL state. |
1500 out until the slave changes the AL state. |
1510 |
1501 |
1511 \item[AL Status Code] If the slave refused the state change command, the |
1502 \item[AL Status Code] If the slave refused the state change command, the |
1512 reason can be read from the ``AL Status Code'' field in the ``AL State |
1503 reason can be read from the ``AL Status Code'' field in the ``AL State |
1513 Changed'' registers (see~\cite[section 5.3.3]{alspec}). |
1504 Changed'' registers (see~\cite[sec. 5.3.3]{alspec}). |
1514 |
1505 |
1515 \item[Acknowledge State] If the state change was not successful, the master |
1506 \item[Acknowledge State] If the state change was not successful, the master |
1516 has to acknowledge the old state by writing to the ``AL Control request'' |
1507 has to acknowledge the old state by writing to the ``AL Control request'' |
1517 register again. |
1508 register again. |
1518 |
1509 |
1530 \section{The SII State Machine} |
1521 \section{The SII State Machine} |
1531 \label{sec:fsm-sii} |
1522 \label{sec:fsm-sii} |
1532 \index{FSM!SII} |
1523 \index{FSM!SII} |
1533 |
1524 |
1534 The SII\index{SII} state machine (shown in figure~\ref{fig:fsm-sii}) |
1525 The SII\index{SII} state machine (shown in figure~\ref{fig:fsm-sii}) |
1535 implements the process of reading or writing SII data via the |
1526 implements the process of reading or writing SII data via the Slave |
1536 Slave Information Interface described in \cite[section~6.4]{dlspec}. |
1527 Information Interface described in \cite[sec.~6.4]{dlspec}. |
1537 |
1528 |
1538 \begin{figure}[htbp] |
1529 \begin{figure}[htbp] |
1539 \centering |
1530 \centering |
1540 \includegraphics[width=.5\textwidth]{graphs/fsm_sii} |
1531 \includegraphics[width=.5\textwidth]{graphs/fsm_sii} |
1541 \caption{Transition Diagram of the SII State Machine} |
1532 \caption{Transition Diagram of the SII State Machine} |
1582 \label{sec:fsm-pdo} |
1573 \label{sec:fsm-pdo} |
1583 \index{FSM!Pdo} |
1574 \index{FSM!Pdo} |
1584 |
1575 |
1585 The Pdo state machines are a set of state machines that read or write the Pdo |
1576 The Pdo state machines are a set of state machines that read or write the Pdo |
1586 assignment and the Pdo mapping via the ``CoE Communication Area'' described in |
1577 assignment and the Pdo mapping via the ``CoE Communication Area'' described in |
1587 \cite[section 5.6.7.4]{alspec}. For the object access, the |
1578 \cite[sec. 5.6.7.4]{alspec}. For the object access, the CANopen-over-EtherCAT |
1588 CANopen-over-EtherCAT access primitives are used (see |
1579 access primitives are used (see sec.~\ref{sec:coe}), so the slave must support |
1589 section~\ref{sec:coe}), so the slave must support the CoE mailbox protocol. |
1580 the CoE mailbox protocol. |
1590 |
1581 |
1591 \paragraph{Pdo Reading FSM} This state machine (fig.~\ref{fig:fsm-pdo-read}) |
1582 \paragraph{Pdo Reading FSM} This state machine (fig.~\ref{fig:fsm-pdo-read}) |
1592 has the purpose to read the complete Pdo configuration of a slave. It reads |
1583 has the purpose to read the complete Pdo configuration of a slave. It reads |
1593 the Pdo assignment for each Sync Manager and uses the Pdo Entry Reading FSM |
1584 the Pdo assignment for each Sync Manager and uses the Pdo Entry Reading FSM |
1594 (fig.~\ref{fig:fsm-pdo-entry-read}) to read the mapping for each assigned Pdo. |
1585 (fig.~\ref{fig:fsm-pdo-entry-read}) to read the mapping for each assigned Pdo. |
1659 The master creates a virtual EoE network interface for every EoE-capable |
1650 The master creates a virtual EoE network interface for every EoE-capable |
1660 slave. These interfaces are called either |
1651 slave. These interfaces are called either |
1661 |
1652 |
1662 \begin{description} |
1653 \begin{description} |
1663 |
1654 |
1664 \item[eoeXsY] for a slave without an alias address (see |
1655 \item[eoeXsY] for a slave without an alias address (see sec.~\ref{sec:alias}), |
1665 section~\ref{sec:alias}), where X is the master index and Y is the slave's |
1656 where X is the master index and Y is the slave's ring position, or |
1666 ring position, or |
|
1667 |
1657 |
1668 \item[eoeXaY] for a slave with a non-zero alias address, where X is the master |
1658 \item[eoeXaY] for a slave with a non-zero alias address, where X is the master |
1669 index and Y is the decimal alias address. |
1659 index and Y is the decimal alias address. |
1670 |
1660 |
1671 \end{description} |
1661 \end{description} |
1707 up, the passing of new socket buffers is suspended with a call to |
1697 up, the passing of new socket buffers is suspended with a call to |
1708 \lstinline+netif_stop_queue()+. |
1698 \lstinline+netif_stop_queue()+. |
1709 |
1699 |
1710 \paragraph{Creation of EoE Handlers} |
1700 \paragraph{Creation of EoE Handlers} |
1711 |
1701 |
1712 During bus scanning (see section~\ref{sec:fsm-scan}), the master determines |
1702 During bus scanning (see sec.~\ref{sec:fsm-scan}), the master determines the |
1713 the supported mailbox protocols foe each slave. This is done by examining the |
1703 supported mailbox protocols foe each slave. This is done by examining the |
1714 ``Supported Mailbox Protocols'' mask field at word address 0x001C of the |
1704 ``Supported Mailbox Protocols'' mask field at word address 0x001C of the |
1715 SII\index{SII}. If bit 1 is set, the slave supports the EoE protocol. In this |
1705 SII\index{SII}. If bit 1 is set, the slave supports the EoE protocol. In this |
1716 case, an EoE handler is created for that slave. |
1706 case, an EoE handler is created for that slave. |
1717 |
1707 |
1718 \paragraph{EoE State Machine} |
1708 \paragraph{EoE State Machine} |
1780 \paragraph{EoE Processing} |
1770 \paragraph{EoE Processing} |
1781 |
1771 |
1782 To execute the EoE state machine of every active EoE handler, there must be a |
1772 To execute the EoE state machine of every active EoE handler, there must be a |
1783 cyclic process. The easiest solution would be to execute the EoE state |
1773 cyclic process. The easiest solution would be to execute the EoE state |
1784 machines synchronously with the master state machine (see |
1774 machines synchronously with the master state machine (see |
1785 section~\ref{sec:fsm-master}). This approach has the following disadvantage: |
1775 sec.~\ref{sec:fsm-master}). This approach has the following disadvantage: |
1786 |
1776 |
1787 Only one EoE fragment could be sent or received every few cycles. This |
1777 Only one EoE fragment could be sent or received every few cycles. This |
1788 causes the data rate to be very low, because the EoE state machines are not |
1778 causes the data rate to be very low, because the EoE state machines are not |
1789 executed in the time between the application cycles. Moreover, the data rate |
1779 executed in the time between the application cycles. Moreover, the data rate |
1790 would be dependent on the period of the application task. |
1780 would be dependent on the period of the application task. |
1791 |
1781 |
1792 To overcome this problem, an own cyclic process is needed to asynchronously |
1782 To overcome this problem, an own cyclic process is needed to asynchronously |
1793 execute the EoE state machines. For that, the master owns a kernel timer, that |
1783 execute the EoE state machines. For that, the master owns a kernel timer, that |
1794 is executed each timer interrupt. This guarantees a constant bandwidth, but |
1784 is executed each timer interrupt. This guarantees a constant bandwidth, but |
1795 poses the new problem of concurrent access to the master. The locking |
1785 poses the new problem of concurrent access to the master. The locking |
1796 mechanisms needed for this are introduced in section~\ref{sec:concurr}. |
1786 mechanisms needed for this are introduced in sec.~\ref{sec:concurr}. |
1797 |
1787 |
1798 \paragraph{Automatic Configuration} |
1788 \paragraph{Automatic Configuration} |
1799 |
1789 |
1800 By default, slaves are left in PREOP state, if no configuration is applied. If |
1790 By default, slaves are left in PREOP state, if no configuration is applied. If |
1801 an EoE interface link is set to ``up'', the requested slave's |
1791 an EoE interface link is set to ``up'', the requested slave's |
1820 |
1810 |
1821 \ldots |
1811 \ldots |
1822 |
1812 |
1823 \paragraph{Sdo Download State Machine} |
1813 \paragraph{Sdo Download State Machine} |
1824 |
1814 |
1825 The best time to apply Sdo configurations is during the slave's PREOP |
1815 The best time to apply Sdo configurations is during the slave's PREOP state, |
1826 state, because mailbox communication is already possible and slave's |
1816 because mailbox communication is already possible and slave's application will |
1827 application will start with updating input data in the succeeding |
1817 start with updating input data in the succeeding SAFEOP state. Therefore the |
1828 SAFEOP state. Therefore the Sdo configuration has to be part of the |
1818 Sdo configuration has to be part of the slave configuration state machine (see |
1829 slave configuration state machine (see section~\ref{sec:fsm-conf}): It |
1819 sec.~\ref{sec:fsm-conf}): It is implemented via an Sdo download state machine, |
1830 is implemented via an Sdo download state machine, that is executed |
1820 that is executed just before entering the slave's SAFEOP state. In this way, |
1831 just before entering the slave's SAFEOP state. In this way, it is |
1821 it is guaranteed that the Sdo configurations are applied each time, the slave |
1832 guaranteed that the Sdo configurations are applied each time, the |
1822 is reconfigured. |
1833 slave is reconfigured. |
|
1834 |
1823 |
1835 The transition diagram of the Sdo Download state machine can be seen |
1824 The transition diagram of the Sdo Download state machine can be seen |
1836 in figure~\ref{fig:fsm-coedown}. |
1825 in figure~\ref{fig:fsm-coedown}. |
1837 |
1826 |
1838 \begin{figure}[htbp] |
1827 \begin{figure}[htbp] |
1888 communication protocol. VoE mailbox messages are prepended by a VoE header |
1877 communication protocol. VoE mailbox messages are prepended by a VoE header |
1889 containing a 32-bit vendor ID and a 16-bit vendor-type. There are no more |
1878 containing a 32-bit vendor ID and a 16-bit vendor-type. There are no more |
1890 constraints regarding this protocol. |
1879 constraints regarding this protocol. |
1891 |
1880 |
1892 The EtherCAT master allows to create multiple VoE handlers per slave |
1881 The EtherCAT master allows to create multiple VoE handlers per slave |
1893 configuration via the application interface (see chap.~\ref{sec:ecrt}). These |
1882 configuration via the application interface (see chap.~\ref{chap:api}). These |
1894 handlers contain the state machine necessary for the communication via VoE. |
1883 handlers contain the state machine necessary for the communication via VoE. |
1895 One read or write operation may be issued at a time. After the operation is |
1884 One read or write operation may be issued at a time. After the operation is |
1896 initiated, the handler must be executed cyclically until it is finished. After |
1885 initiated, the handler must be executed cyclically until it is finished. After |
1897 that, the results of the operation can be retrieved. |
1886 that, the results of the operation can be retrieved. |
1898 |
1887 |
1899 A VoE handler has an own datagram structure, that is marked for exchange after |
1888 A VoE handler has an own datagram structure, that is marked for exchange after |
1900 each execution step. So the application can decide, how many handlers to |
1889 each execution step. So the application can decide, how many handlers to |
1901 execute before sending the corresponding EtherCAT frame(s). |
1890 execute before sending the corresponding EtherCAT frame(s). |
1902 |
1891 |
1903 For more information about using VoE handlers, see the application interface |
1892 For more information about using VoE handlers, see the application interface |
1904 documentation (chap.~\ref{sec:ecrt}) or the example applications provided in |
1893 documentation (chap.~\ref{chap:api}) or the example applications provided in |
1905 the \textit{examples/} subdirectory. |
1894 the \textit{examples/} subdirectory. |
1906 |
1895 |
1907 %------------------------------------------------------------------------------ |
1896 %------------------------------------------------------------------------------ |
1908 |
1897 |
1909 \chapter{Userspace Interfaces} |
1898 \chapter{Userspace Interfaces} |
1917 the master from userspace and allow a finer influence. It should be possible |
1906 the master from userspace and allow a finer influence. It should be possible |
1918 to view and to change special parameters at runtime. |
1907 to view and to change special parameters at runtime. |
1919 |
1908 |
1920 Bus visualization is another point: For development and debugging purposes it |
1909 Bus visualization is another point: For development and debugging purposes it |
1921 is necessary to show the connected slaves with a single command, for instance |
1910 is necessary to show the connected slaves with a single command, for instance |
1922 (see sec.~\ref{sec:ethercat}). |
1911 (see sec.~\ref{sec:tool}). |
1923 |
1912 |
1924 The application interface has to be available in userspace, to allow userspace |
1913 The application interface has to be available in userspace, to allow userspace |
1925 programs to use EtherCAT master functionality. This was implemented via a |
1914 programs to use EtherCAT master functionality. This was implemented via a |
1926 character device and a userspace library (see sec.~\ref{sec:userlib}). |
1915 character device and a userspace library (see sec.~\ref{sec:userlib}). |
1927 |
1916 |
1950 Each master instance will get a character device as a userspace interface. |
1939 Each master instance will get a character device as a userspace interface. |
1951 The devices are named \textit{/dev/EtherCATx}, where $x \in \{0 \ldots n\}$ is |
1940 The devices are named \textit{/dev/EtherCATx}, where $x \in \{0 \ldots n\}$ is |
1952 the index of the master. |
1941 the index of the master. |
1953 |
1942 |
1954 \paragraph{Device Node Creation} The character device nodes are automatically |
1943 \paragraph{Device Node Creation} The character device nodes are automatically |
1955 created, if the \lstinline+udev+ Package is installed. See section |
1944 created, if the \lstinline+udev+ Package is installed. See |
1956 \ref{sec:autonode} for how to install and configure it. |
1945 sec.~\ref{sec:autonode} for how to install and configure it. |
1957 |
1946 |
1958 %------------------------------------------------------------------------------ |
1947 %------------------------------------------------------------------------------ |
1959 |
1948 |
1960 \subsection{Setting Alias Addresses} |
1949 \subsection{Setting Alias Addresses} |
1961 \label{sec:alias} % FIXME |
1950 \label{sec:alias} % FIXME |
2099 %------------------------------------------------------------------------------ |
2088 %------------------------------------------------------------------------------ |
2100 |
2089 |
2101 \section{Userspace Library} |
2090 \section{Userspace Library} |
2102 \label{sec:userlib} |
2091 \label{sec:userlib} |
2103 |
2092 |
2104 The native application interface (see chap.~\ref{sec:ecrt}) resides in |
2093 The native application interface (see chap.~\ref{chap:api}) resides in |
2105 kernelspace and hence is only accessible from inside the kernel. To make the |
2094 kernelspace and hence is only accessible from inside the kernel. To make the |
2106 application interface available from userspace programs, a userspace library |
2095 application interface available from userspace programs, a userspace library |
2107 has been created, that can be linked to programs under the terms and |
2096 has been created, that can be linked to programs under the terms and |
2108 conditions of the LGPL, version 2 \cite{lgpl}. |
2097 conditions of the LGPL, version 2 \cite{lgpl}. |
2109 |
2098 |
2165 call. The kernel part of the interface calls the according API functions |
2154 call. The kernel part of the interface calls the according API functions |
2166 directly, what results in a minimum additional delay (see |
2155 directly, what results in a minimum additional delay (see |
2167 sec.~\ref{sec:usertiming}). |
2156 sec.~\ref{sec:usertiming}). |
2168 |
2157 |
2169 Also for performance reasons, the actual domain process data (see |
2158 Also for performance reasons, the actual domain process data (see |
2170 chap.~\ref{sec:ecrt}) are not copied between kernel and user memory on every |
2159 chap.~\ref{chap:api}) are not copied between kernel and user memory on every |
2171 access: Instead, the data are memory-mapped to the userspace application. Once |
2160 access: Instead, the data are memory-mapped to the userspace application. Once |
2172 the master is configured and activated, the master module creates one big |
2161 the master is configured and activated, the master module creates one big |
2173 process data memory area for all domains and maps it to userspace, so that the |
2162 process data memory area for all domains and maps it to userspace, so that the |
2174 application can directly access the process data. For that, there is no |
2163 application can directly access the process data. For that, there is no |
2175 additional delay when accessing the process data from userspace. |
2164 additional delay when accessing the process data from userspace. |
2252 |
2241 |
2253 The EtherCAT master init script conforms to the requirements of the ``Linux |
2242 The EtherCAT master init script conforms to the requirements of the ``Linux |
2254 Standard Base'' (LSB\index{LSB}, \cite{lsb}). The script is installed to |
2243 Standard Base'' (LSB\index{LSB}, \cite{lsb}). The script is installed to |
2255 \textit{etc/init.d/ethercat} below the installation prefix and has to be |
2244 \textit{etc/init.d/ethercat} below the installation prefix and has to be |
2256 copied (or better: linked) to the appropriate location (see |
2245 copied (or better: linked) to the appropriate location (see |
2257 section~\ref{sec:installation}), before the master can be inserted as a |
2246 sec.~\ref{sec:installation}), before the master can be inserted as a service. |
2258 service. Please note, that the init script depends on the sysconfig file |
2247 Please note, that the init script depends on the sysconfig file described |
2259 described below. |
2248 below. |
2260 |
2249 |
2261 To provide service dependencies (i.~e. which services have to be started before |
2250 To provide service dependencies (i.~e. which services have to be started before |
2262 others) inside the init script code, LSB defines a special comment block. |
2251 others) inside the init script code, LSB defines a special comment block. |
2263 System tools can extract this information to insert the EtherCAT init script at |
2252 System tools can extract this information to insert the EtherCAT init script at |
2264 the correct place in the startup sequence: |
2253 the correct place in the startup sequence: |
2587 This command will install the compiled kernel modules to |
2576 This command will install the compiled kernel modules to |
2588 \textit{/vol/nfs/root/lib/modules}, prepended by the kernel release. |
2577 \textit{/vol/nfs/root/lib/modules}, prepended by the kernel release. |
2589 |
2578 |
2590 If the EtherCAT master shall be run as a service\footnote{Even if the EtherCAT |
2579 If the EtherCAT master shall be run as a service\footnote{Even if the EtherCAT |
2591 master shall not be loaded on system startup, the use of the init script is |
2580 master shall not be loaded on system startup, the use of the init script is |
2592 recommended for manual (un-)loading.} (see section~\ref{sec:system}), the init |
2581 recommended for manual (un-)loading.} (see sec.~\ref{sec:system}), the init |
2593 script and the sysconfig file have to be copied (or linked) to the appropriate |
2582 script and the sysconfig file have to be copied (or linked) to the appropriate |
2594 locations. The below example is suitable for SUSE Linux. It may vary for other |
2583 locations. The below example is suitable for SUSE Linux. It may vary for other |
2595 distributions. |
2584 distributions. |
2596 |
2585 |
2597 % FIXME relative ln -s? |
2586 % FIXME relative ln -s? |
2601 # `\textbf{ln -s etc/init.d/ethercat /etc/init.d/}` |
2590 # `\textbf{ln -s etc/init.d/ethercat /etc/init.d/}` |
2602 # `\textbf{insserv ethercat}` |
2591 # `\textbf{insserv ethercat}` |
2603 \end{lstlisting} |
2592 \end{lstlisting} |
2604 |
2593 |
2605 Now the sysconfig file \texttt{/etc/sysconfig/ethercat} (see |
2594 Now the sysconfig file \texttt{/etc/sysconfig/ethercat} (see |
2606 section~\ref{sec:sysconfig}) has to be customized. The minimal customization |
2595 sec.~\ref{sec:sysconfig}) has to be customized. The minimal customization is |
2607 is to set the \lstinline+MASTER0_DEVICE+ variable to the MAC address of the |
2596 to set the \lstinline+MASTER0_DEVICE+ variable to the MAC address of the |
2608 Ethernet device to use (or \lstinline+ff:ff:ff:ff:ff:ff+ to use the first |
2597 Ethernet device to use (or \lstinline+ff:ff:ff:ff:ff:ff+ to use the first |
2609 device offered) and selecting the driver(s) to load via the |
2598 device offered) and selecting the driver(s) to load via the |
2610 \lstinline+DEVICE_MODULES+ variable. |
2599 \lstinline+DEVICE_MODULES+ variable. |
2611 |
2600 |
2612 After the basic configuration is done, the master can be started with |
2601 After the basic configuration is done, the master can be started with |
2657 \end{description} |
2646 \end{description} |
2658 |
2647 |
2659 \section{Automatic Device Node Creation} |
2648 \section{Automatic Device Node Creation} |
2660 \label{sec:autonode} |
2649 \label{sec:autonode} |
2661 |
2650 |
2662 The \lstinline+ethercat+ command-line tool (see section~\ref{sec:ethercat}) |
2651 The \lstinline+ethercat+ command-line tool (see sec.~\ref{sec:tool}) |
2663 communicates with the master via a character device. The corresponding device |
2652 communicates with the master via a character device. The corresponding device |
2664 nodes are created automatically, if the udev daemon is running. |
2653 nodes are created automatically, if the udev daemon is running. Note, that on |
2665 Note, that on some distributions, the \lstinline+udev+ package is not |
2654 some distributions, the \lstinline+udev+ package is not installed by default. |
2666 installed by default. |
|
2667 |
2655 |
2668 The device nodes will be created with mode \lstinline+0660+ and group |
2656 The device nodes will be created with mode \lstinline+0660+ and group |
2669 \lstinline+root+ by default. If you want to give normal users reading access, |
2657 \lstinline+root+ by default. If you want to give normal users reading access, |
2670 create a udev rule file (for example |
2658 create a udev rule file (for example |
2671 \textit{/etc/udev/rules.d/99-EtherCAT.rules} with the following content: |
2659 \textit{/etc/udev/rules.d/99-EtherCAT.rules} with the following content: |
2681 \begin{lstlisting} |
2669 \begin{lstlisting} |
2682 # `\textbf{ls -l /dev/EtherCAT0}` |
2670 # `\textbf{ls -l /dev/EtherCAT0}` |
2683 crw-rw-r-- 1 root root 252, 0 2008-09-03 16:19 /dev/EtherCAT0 |
2671 crw-rw-r-- 1 root root 252, 0 2008-09-03 16:19 /dev/EtherCAT0 |
2684 \end{lstlisting} |
2672 \end{lstlisting} |
2685 |
2673 |
2686 Now, the \lstinline+ethercat+ tool can be used (see |
2674 Now, the \lstinline+ethercat+ tool can be used (see sec.~\ref{sec:tool}) even |
2687 section~\ref{sec:ethercat}) even as a non-root user. |
2675 as a non-root user. |
2688 |
2676 |
2689 %------------------------------------------------------------------------------ |
2677 %------------------------------------------------------------------------------ |
2690 |
2678 |
2691 \begin{thebibliography}{99} |
2679 \begin{thebibliography}{99} |
2692 |
2680 |