機能パック-EtherCATマスターオプション

EtherCATユーザーは、相互運用性と、EtherCATマスターが提供する必要のある明確に定義された一連の機能を期待しています。

もちろん、すべてのアプリケーションに同じ要件があるわけではないため、すべてのマスターがEtherCATテクノロジーのすべての機能をサポートする必要はありません。
EtherCATマスターの最も一般的な要件は、EC-MasterのクラスAおよびクラスBエディションでカバーされており、それぞれのETG1500EtherCATマスターディレクティブに完全に準拠しています。
コントローラ、プラント、およびマシンでのEtherCATテクノロジーの幅広い使用に必要となる可能性のある追加機能も利用できます。
これらの機能はオプションと見なすことができ、ETG1500ディレクティブの機能パックで説明されています。機能パックには、冗長性など、特定の機能に必須のすべてのマスター機能が記述されています。EC-Masterは、そのような定義済みの機能パックをすべてカバーし、公式に定義されたものを超える機能も提供します。このページでは、利用可能な機能パックとそれぞれの使用例の概要を説明します。

概要

Feature Pack - Split-Frame Processing

The Split-Frame Processing Feature Pack enables the processing of multiple EtherCAT cyclic tasks in separate application threads. From the application perspective, this makes it possible to structure EtherCAT process data across multiple threads. Therefore, process data that requires different cycle times can be handled accordingly.
Additionally, the processing of acyclic communication can also be outsourced to a separate thread.

For example, a typical application for the Split-Frame Processing Feature Pack would have one tasks for servo drives that requires very fast cycle times, and another task for I / O data that does not need very fast processing or special cycle time requirements.

EC-Engineer makes it easy to create configurations with several EtherCAT cyclic tasks:

The timing of an application utilizing Split-Frame Processing application would look like the following:

  • Thread 0 runs with a 250 microsecond cycle time and handles the processing of EtherCAT task 0. This thread also sends out the process data for all other tasks.
  • Thread 1 runs with a 500 microsecond cycle time and handles only the processing of EtherCAT task 1.
  • Thread Acyc runs with a 1 millisecond cycle time and processes only the acyclic communication and also the Master management tasks.

Feature Pack - External Synchronization

The synchronization of system components or production lines with several EtherCAT Segments can be done with different solutions:

  • Synchronization with an external grandmaster clock using IEEE 1588 protocol
  • Synchronization by a bridge device.

Depending on the application the accuracy of the synchronization has different requirements. For the synchronization of two production lines often the accuracy in the range of milliseconds is enough.
However if two or more motion control networks should be synchronized it may be necessary to have the Sync-signals exact at the same time in all devices (e.g. for a network wide commutation information) - that means an accuracy better than a microsecond may be needed.
Within one EtherCAT Segment the Distributed Clocks (DC) mechanism can be used, to synchronize the network devices. DC offers accuracy much better than a microsecond.
The first device that should be synchronized is used as the reference clock for that segment.
The synchronization of several EtherCAT Segments with a high accuracy means that the DC reference clocks in the segments must be adjusted.
The leading clock is called Grandmaster clock. It can be an external Time information, e.g. GPS or DCF77 receiver (see Figure 27), but it can also be one of the DC reference clocks.

EC-Engineer EtherCAT configuration tool

The synchronization of two or more EtherCAT segments can be done by a Bridge device as shown in this figure.

The Bridge has two EtherCAT connections (internal two EtherCAT Slave Controllers are used). The primary port is connected to the first segment; the secondary port is connected to the second segment. One of the two ports can be configured to be the leading time reference. The Bridge can calculate the time difference and offers the TimeControlValue to the Master. The Master can then adjust the Reference Clock. During startup the two segments can be powered-on at different times. That means that there will be an absolute time difference between the two segments.

To synchronize the Secondary Segment two software algorithms are involved:

  • DCX: Synchronize the reference clock to bridge device
  • DCM: Synchronize the Master timer to reference clock

機能パック - ホットコネクト

「ホットコネクト」の採用は、システムに最大限の柔軟性をもたらします。

「ホットコネクト」の元来のコンセプトは、スレーブが稼働(ホット)中に、スレーブの接続/取り外しを行う点にあります。
しかし、それは考えられるいくつかのシナリオの 1 つに過ぎません。
より起こりうる事態として考えられるのは、EtherCAT のバスコンフィギュレーション(ENI)と、実際に接続されているスレーブや回線が、完全に一致していない状態でシステムを稼働させなければならない場合です。

このため、下記のユースケースが想定され、対応されています(ENI コンフィギュレーションファイルの変更は不要になります)。

- 必要なコンポーネントなどがまだ用意されていなかったり、電源オフにされたり、取り外されたりしている状態で、複雑なシステムをセットアップする。
- 必須なデバイスとオプションデバイスが混在しているシステムの稼働中(試験・計測を実行中の環境)。
- 回線に柔軟性を持たせる場合。例えばアナログ→CAN で、スレーブの接続ポートが変わる場合など。

「ホットコネクト」機能を使用するために、スレーブ側に特別な EtherCAT 機能を持たせる必要はありません。実際、どのような EtherCAT スレーブでも、ホットコネクト グループ(HC グループ)の一員として使用できます。
各HC グループに必要なのは、個別に識別可能であることです。多くの場合、この部分は DIP スイッチで実現できます。個別に持たせたスレーブアドレスは、ステーションエイリアスレジスター内か、スレーブメモリー内のアドレスロケーションのどこかに表示されます。
EtherCAT マスターはどちらの場合にも対応しています。
さらに、アプリケーションはマスターを通じてステーションエイリアスアドレスをプログラムすることもできます(初回システム初期化時用など)。

「ホットコネクト」機能パックを使用するには、EC-Master マスタースタックのバージョン 2.0 以上が必要です。
HC 機能のサポートに必要なすべての EtherCAT アクティビティは、バックグラウンドのスタックによって自動的にハンドリングされます。アプリケーション側の操作は必要ありません。
また、スレーブが接続されたり取り外されたりした場合、コールバック機能(通知)によって、すぐにアプリケーションに情報が渡されます。
どのタイミングでも、アプリケーションは適切なマスタースタック API 関数を使用して、実際に接続されているスレーブデバイスを判定することができます。

HC 機能パック内には、スレーブを間違ったポートに接続するケースへのセキュリティを高めるための、「Border Close(ボーダークローズ)」機能が用意されています。
この機能がオンになっている場合、コンフィギュレーションで許可されたポート以外のすべての EtherCAT ポートがクローズされている状態になります。

「ホットコネクト」機能についてのご質問がある場合は、お気軽にお問い合わせください。

機能パック - ケーブル冗長性

ケーブル冗長性機能は、EtherCAT システム内の通信ケーブル部分で障害が発生した場合の補償を目的として設計されています。このため、通常両側からの操作がされるリングトポロジーが使用されます。リングトポロジーでは、そのどこかが破断している場合でも、どちらのブランチにも到達できるからです。

解説

2 つめのネットワーク ポートは、EtherCAT マスターコントロールシステム側で、リングのクローズに使用されます。サイクリック/非サイクリックフレームのどちらとも、両方のポートから同時に送信され、システム内を転送されます。

リング上に欠けた部分が何もなければ、すべての EtherCAT スレーブが1つめのネットワークポートから順方向(プロセシング方向と呼ばれます)に沿って到達されます。EtherCAT スレーブコントローラー(ESC)は、順方向処理でのみ通過可能なため、この場合はスレーブが処理されることになります。
障害が特になければ、EtherCAT スレーブは 2 つめのポートから逆方向順でも到達されることになります。この場合、データ「冗長性」フレームは、変更されません。

どちらの場合にも、EtherCAT フレームは他のポートに到着します(変更されている可能性もあります)。そして、EtherCAT マスターにチェックされます。ケーブルが破断している場合は、どちらのフレームも、障害があるそれぞれの側で処理されます。つまり、両方のフレームに、入力データの一部が含まれることになります。マスターは両フレームのデータを結合して、すべての入力データが揃った 1 フレームを取得します。両フレームのワーキングカウンターは、加算され、妥当性を検証されます。この時、EtherCAT スレーブがプライマリ ポートと冗長性ポートのどちらから到達されたのかは重要ではありません。EtherCAT マスターが注目する必要があるのは、片側のフレームはロストし、他のフレームは戻ってきた場合です。適合するフレームを見つけるには、フレームに識別子を追加したり、適切なメカニズムを採用すると良いでしょう。
ケーブル冗長性は、1つのエラーだけに対応した対策です。例えば、ケーブルが一箇所で破断した場合には、スレーブとの通信は途切れません。通信が復旧すれば、元の通信方向も復旧します。しかし、通信が複数箇所で破断している場合には、別の障害が発生する前にすべての接続を復旧させる必要があります。

機能

ケーブルが切断された場合に、すべての種類の EtherCAT 通信(プロセスデータとメールボックスプロトコル)を、制限無しにサポートします。
下記のユースケースに対応しています。

• 通常稼働
• 2 つのスレーブ間でのケーブル切断発生時にも稼働継続
• プライマリ ポートと最初のスレーブ間でのケーブル切断発生時の継続稼働
• セカンダリ ポートと最後のスレーブ間でのケーブル切断発生時の継続稼働
• ケーブルが修理された場合の継続稼働
• ケーブル切断時のスタート/ストップ(ステート変更)
• ケーブル切断時に Auto Increment(自動加算)アドレスの調整
• ケーブル切断時のフレーム損失(対になるフレームが受信されなかった場合)

Feature Pack - Master Redundancy

In order to increase the availability of the EtherCAT system and provide for failure scenarios, a second fully redundant Master system can be added to the network via acontis' Master Redundancy feature. This new feature will create an ACTIVE Master and an INACTIVE Backup Master. In normal operation the INACTIVE Backup Master simply forwards frames through and back onto the network using acontis' optimized Ethernet drivers for fast packet forwarding:

Data Synchronization and Inter-Master Communication

By means of fast packet forwarding the ACTIVE Master still receives all the frames in time for the next cycle.
The INACTIVE Backup Master has access to all Process Data. It parses and modifies received frames and adds frames itself after cyclic slave frames. The ACTIVE and INACTIVE Backup Master can communicate with each other using Ethernet-over-EtherCAT (EoE).

Failover

If the ACTIVE Master fails, the INACTIVE Backup Master can takeover and become ACTIVE. Due to the fact that the INACTIVE Backup Master has been connected to the network the whole time, it can control the bus after getting ACTIVE in the case of a failover:

Cable Redundancy with Master Redundancy

Cable Redundancy can be combined with Master Redundancy. The ACTIVE Master communicates directly to one segment of the EtherCAT slave network and indirectly to the other segment of the EtherCAT slave network through the INACTIVE Backup Master:

Feature Pack - EoE Third Party Tool Support Package

Using the mailbox protocol Ethernet over EtherCAT (EoE) standard Ethernet frames can be tunneled trough an EtherCAT network. Based on this, a communication to slaves with locally running TCP/IP-based applications (e.g. Web Server) can be established. More and more manufacturers of EtherCAT drives are supported this connection in their drive setup and tuning tools.

EC-Engineer EtherCAT configuration tool

Acontis is offering all required software modules to enable TCP communication between a third party software on Windows and a EtherCAT slave supporting EoE. On the master controller just the proven RAS-Server has to be enabled. The RAS-Server is included in the EC-Master core license and available on many operating systems.

acontis EoE Gateway Tool for Windows

現在市場に出回っている多くのEtherCAT製品は、Ethernet over EtherCAT(EoE)のサポートを提供しています。EoEは、完全なEtherCATネットワークを実装する必要なしにEtherCATデバイスをセットアップおよび構成するための便利な方法を提供します。EoE対応のEtherCATデバイスの多くのメーカーは、製品をセットアップおよび構成するためのソフトウェアツールを提供しています。例としては、Bosch Rexroth IndraWorksYaskawa SigmaWin +Elmo Application StudioCopleyCME2などがあります。

acontisのEtherCATマスターソフトウェアであるEC-Masterの開発者およびユーザーにとって、ソフトウェアツールを実行しているWindowsコンピューターをネットワークから直接接続するために、EC-Masterを実行しているマスターコントローラーをネットワークから切断する必要があるため、これらのメーカーツールの利便性が失われます。 EtherCATデバイス。次に、製造元ツールを使用していくつかの簡単な変更を行った後、マスターコントローラーを再接続する必要があります。この問題に対処するために、acontisはWindows用のEoEゲートウェイツールをリリースしました。

EoEゲートウェイツールを使用すると、acontisはマスターコントローラーをEtherCATデバイスに接続したままにする便利な方法を提供しますが、セットアップと構成にはメーカーのツールを利用します。これは、イーサネットデータをツールからEC-Masterを実行しているマスターコントローラーを介してEtherCATネットワークにトンネリングすることで実現されます。

EoE-EC-マスタートンネル

このEoEゲートウェイツールはバックグラウンドのWindowsシステムトレイで実行されるため、EtherCATデバイスに直接接続されているかのようにメーカーのツールに集中できます。

EC-EoE-ゲートウェイ-システム-トレイ

EC-EoE-ゲートウェイ-ウィンドウ

Feature Pack - UDP Mailbox Gateway

The Mailbox Gateway functionality within a master device can be used to route the EtherCAT mailbox protocol from an (external) device configuration tool via the Mailbox Gateway to the EtherCAT devices and vice versa. All Mailbox protocols that are defined in the EtherCAT specification can be used in general, i.e. CoE, FoE, VoE, SoE.
There is no error handling specified for the Mailbox Gateway functionality. A request to a non-existing slave device can lead to no response from the master. According to Function Guideline „ ETG.8200 EtherCAT Mailbox Gateway“.

Mailbox Gateway Structure