CANチュートリアル

(1)

(2)

改訂履歴 Ver 年月改訂内容 1.0 2004 年 7 月初版 1.1 2005 年 6 月・対応型式に CPZ 製品を追加 ・サンプルプログラムの変更（BPC-08xx→BPC-0820） ・図 2-4 調停の動作変更本チュートリアルをご使用の際は、必ず各製品型式の最新のドキュメント(ユーザーズマニュアル,オンラインヘルプ)をあわせて参照してください。また、最新のドライバソフトウェアをご使用ください。ユーザーズマニュアル, ドライバソフトウェアは弊社 Web site からダウンロードできます。(オンラインヘルプはドライバソフトウェアに含まれています) 商標/登録商標 本チュートリアルに掲載されている会社名、製品名は、それぞれ各社の商標または登録商標です。保証の内容と制限株式会社インタフェースはドキュメント内の情報の正確さに万全を期しています。万一、誤記または誤植などがあった場合、株式会社インタフェースは予告無く改訂する場合があります。ドキュメントまたはドキュメント内の情報に起因するいかなる損害に対しても株式会社インタフェースは責任を負いません。ドキュメント内の図や表は説明のためであり、ユーザ個別の応用事例により変化する場合があります。著作権、知的所有権株式会社インタフェースは本製品に含まれるおよび本製品に対する権利や知的所有権を保持しています。本製品はコンピュータソフトウェア（プログラム）、図、文章、写真などを含んでいます。複製の禁止株式会社インタフェースの許可なく、本製品(ドキュメント含む)の全て、または一部に関わらず、複製、改変などを行うことはできません。責任の制限株式会社インタフェースは、株式会社インタフェースまたは再販売者の予見の有無にかかわらず発生したいかなる特別損害、偶発的損害、間接的な損害、重大な損害について、責任を負いません。

(3)

目次はじめに ... 1 対象環境 ... 1 注意事項 ... 1 本チュートリアルの活用方法 ... 2 1. CAN とは？...3 2. CAN の解説...4 2.1. CAN の歴史...4 2.2. CAN の特長...4 2.3. プロトコル概要 ...5 2.3.1. バスレベルとビット ...6 2.3.2. CAN のバージョン...7 2.3.3. 調停の仕組み（優先順位の決定方法）...8 2.3.4. ビットスタッフ ...10 2.3.5. エラー状態 ...10 2.4. フレーム解説 ... 11 2.4.1. フレームの種類 ... 11 2.4.2. データフレームの解説 ...12 Start of Frame ...13 Arbitration field ...13 Control field...15 Data field ...16 CRC field...17 Acknowledge field ...18 End of Frame ...19 2.4.3. リモートフレームの解説...20 Arbitration field ...21 Control field...22 2.4.4. エラーフレームの解説 ...23 エラーフラグ ...24 エラーデリミタ ...24 2.4.5. オーバーロードフレームの解説...25 オーバーロードフラグ ...26 オーバーロードデリミタ...26 2.4.6. インターフレームスペースの解説...27 インターミッション ...28 サスペンドトランスミッション...28 バスアイドル ...28 2.5. エラーの種類 ...29 2.5.1. ビットエラー ...29 2.5.2. スタッフエラー ...29 2.5.3. CRC エラー ...29 2.5.4. フォームエラー ...30 2.5.5. ACK エラー...30 3. 弊社 CAN インタフェースの特長 ...31 3.1. 製品の特長 ...31 3.2. 製品のラインナップ ...33 4. チュートリアル ...34 4.1. 動作説明 ...35 4.1.1. 通常通信モード ...36 4.1.2. FIFO 送信モード ...38 4.1.3. モニタモード ...40 4.1.4. 受信メッセージ取り出し...42

(4)

4.1.10. 送信間隔指定 ...61 4.1.11. プロファイル機能 ...63 4.1.12. ユーティリティを用いた登録方法...64 4.1.13. API を用いた登録方法...67 4.1.14. プロファイルの適用方法...68 5. ドライバソフトウェア：GPC-4851 について...71 5.1. ドライバについて ...71 5.2. オンラインヘルプについて...71 6. サンプルプログラムについて ...72 6.1. サンプルプログラムの実行方法...72 6.2. サンプルプログラム早見表...73 7. 技術資料紹介 ...74 8. 参考文献 ...75

(5)

はじめに平素は格別のご高配を賜り、厚く御礼申し上げます。本冊子は、弊社 CAN インタフェース（PCI-485xxx、CTP-485xxx、CBI-485xxx、LPC-485xxx、CPZ-485xxx）が可能な動作、機能を余すところなく紹介し、コンピュータ上からこれらの機能を使用する為の制御方法、CAN 規格等について詳しく説明したものです。また、各種動作、機能を実際に使用した簡単なサンプルプログラムをご用意しております。これらを弊社 Web site（www.interface.co.jp）よりダウンロードしていただければ、一層ご理解を深めていただけるものと思います。これらを活用することで弊社 CAN インタフェースの制御方法が分からない方や、製品選定時の手助けになればと考えております。 ※ 本冊子では、詳細なプログラムコードは掲載しておりません。DLL 関数の説明を行っておりません。各種動作、機能を実現するために使用する関数の説明に関しては、弊社 Web site よりダウンロード頂いた GPC-4851 または GPG-4851 内のオンラインヘルプをご参照下さい。対象環境本チュートリアルは以下の制約事項があります。対応型式 PCI-485120 PCI-485111 PCI-485102 PCI-485220 PCI-485211 PCI-485202 PCI-485340 PCI-485322 PCI-485304 CBI-485120WA CBI-485120WB CBI-485220WA CBI-485220WB CBI-4851A CBI-4851B CBI-4852A CBI-4852B LPC-485120 LPC-485111 LPC-485102 LPC-485220 LPC-485211 LPC-485202 CTP-485340 CTP-485322 CTP-485304 CPZ-485340 CPZ -485322 CPZ -485304

対応 OS Microsoft Windows XP Home Edition Microsoft Windows XP Professional Microsoft Windows Server 2003 Microsoft Windows 2000 Microsoft Windows Me Microsoft Windows 98 対象言語 Visual Basic Ver. 6.0 以降

対象ユーザ制御用電子機器及び、パソコン等に関して、基本的な知識を有している方。

注意事項

本チュートリアルは以下の制約事項があります。

(6)

2 本チュートリアルの活用方法本チュートリアルでは基本的に、動作や機能の説明→パソコン上からの制御方法の順に説明を行っています。本チュートリアルにはパソコン上から制御する為のソースコードの記述はありません。ソースコード(サンプルプログラム)は弊社 Web site からダウンロードしていただくようお願い申し上げます。以下に本チュートリアルを十分に活用して頂くための手順を示します。 1. 動作、機能一覧や、ヘッダー部分から知りたい動作についてのページに移動します。 2. 動作や機能の説明と動作や機能をパソコン上から制御する為のプログラム手順をセットで掲載しています。 3. 弊社 Web site（www.interface.co.jp）へアクセスし、本チュートリアルのサンプルプログラム集(BPC-0820)をダウンロードします。 4. 各動作の末尾に記載されているプログラム格納フォルダ名から各サンプルプログラムを実行し、動作の確認を行ってください。注意）プログラム格納先フォルダに記載されている「言語」とは、プログラム言語を表しています。 ＜インストール先＞¥VB¥CAN¥4851¥4851_*** … Visual Basic によるサンプルプログラム

ヘッダ

動作、機能の説明パソコン上からのプログラム制御手順

(7)

1. CAN とは？

CAN とは「Controller Area Network」の略で、シリアル通信プロトコルの一種です。 CAN と聞くと多くの方が、自動車内ネットワークを連想されると思います。元々CAN は自動車内ネットワークで使用することを前提に開発されました。私たちの生活に欠かせない自動車ですが、近年では高機能化が進み、これまでには必要の無かった様々な部品が自動車内に搭載されるようになってきました。部品が増えるということはそれらを接続するための配線もまた、増えるということになります。また、省エネルギー化の波が押し寄せ、少ない燃料でより効率の良い走りが期待されています。このように一見矛盾した様に見える二つの要望を満たす為、新たな技術を開発する必要が出てきました。そこで考えられたのが、自動車内で使われている配線の数を減らせないかということです。例えば自動車内にスイッチや、センサを取り付けていくと、それらを集中管理しているところまで配線を行う必要があります。そこで自動車メーカ各社は、各種信号をシリアルデータに変換し独自のプロトコルで通信を行い、配線の数を減らすことに成功しました。しかし、規格が統一されていない為、開発の効率、部品の流通性の面では思うように改善が進みません。 1980 年代後半、ドイツの電装メーカ BOSCH 社により開発された CAN は、その仕様をオープンとすることで、多くの半導体メーカにより対応チップが開発、ISO による規格化も行われ、瞬く間に自動車内ネットワークの標準として位置づけられることになりました。また、フィールドバス（工業用途データバス）の一種である、DeviceNet の基礎技術としても使用され自動車の中だけにとどまることなく、幅広い分野で活用され始めています。次章からこの CAN について詳しく解説を行っていきます。

(8)

4 2. CAN の解説 2.1. CAN の歴史 簡単に CAN の歩んできた道を振り返ってみたいと思います。 1986 年ドイツ BOSCH 社により開発 1991 年 ISO11519-1 認証出版 1993 年 ISO11898 認証出版そして現在、日本国内において CAN 関連の製品、書籍などが多く見られるようになり、普及の兆しを見せています。例）

CAN 関連の電子部品や、CAN に対応した計測器、CAN の技術を解説した特集記事など

2.2. CAN の特長 CAN には、多くの特長がありますが、ここでは、そのうち幾つかの特長を取り上げます。 ◆ 低コスト・省配線 CAN は各デバイスをシリアルで接続するため、全体の配線コストを下げることができます。また、多くの半導体メーカより CAN 対応 IC が販売されており、価格競争面で優れています。 ◆ 高信頼性自動車内ネットワークということで、高い信頼性を誇っています。外部からのノイズに強い差動信号で外部からのノイズの影響を受けにくくし、データの正当性を保証する CRC などで、エラーを確実に検出します。 ◆ 調停 CAN はマルチマスタ方式で、バスが空いていれば、どの端末からでも送信を開始することができます。もし複数の端末から同時にデータが送信された場合、バス上で衝突を検知し、ID による優先順位の決定が行われます。衝突によりデータが無くなる事はありません。

→ CSMA/NBA 方式(Carrier Sense Multiple Access Nondestructive Bitwise Arbitration) この調停により、無駄の無い通信が可能です。

優先順位の高い端末は周期を乱されず、高いリアルタイム性を保つことができます。 ◆ 柔軟なシステム構築

(9)

2.3.プロトコル概要 CAN のプロトコルは、BOSCH 社の仕様書で規定されています。 http://www.can.bosch.com/ こちらで公開されている仕様書では、電気的特性などは規定されていません。 OSI 基本参照モデル 7 : アプリケーション層 6 : プレゼンテーション層 5 : セッション層 4 : トランスポート層 3 : ネットワーク層 2 : データリンク層 1 : 物理層ビットのコード化、ビットタイミング、同期方式については規定しているが、電気的仕様については規定していない。 CAN プロトコルは、OSI 基本参照モデルの 1，2，4 層を含むプロトコルです。このうち、1 層と 4 層については、一部しか規定されていません。再送制御のみ規定されている 図 2-1 OSI 基本参照モデル CAN プロトコルを使用する際には、電気的仕様などを決める必要がありますが、上記の様に、 CAN プロトコル自身では定められていません。

これらは、ISO では規定されています。ISO で規定された CAN プロトコルには、ISO11898-2、 ISO11519-2、ISO11898-3 等がありますが、これらはデータリンク層は同じで、物理層の電気的

(10)

6 2.3.1.バスレベルとビット CAN バスには二つのレベルがあります。ドミナントとレセシブと呼ばれる状態です。CAN バスは、必ずこの二つのレベルのうちどちらかのレベルになります。論理的にはドミナントが “0”、レセシブが“1”を指します。 CAN はバス接続なので、同一バス上に複数の端末が接続され、それぞれが送信を行います。この際、一つでもドミナントを出力する端末があると、バスのレベルはドミナントになります。全ての端末からレセシブが出力されていればバスのレベルはレセシブです。ドミナント、レセシブのそれぞれのバスレベルは、対応する規格により変わってきます。それらをまとめたのが以下の表です。 表 2-1 バスレベル 低速CAN 高速CAN ISO11519-2

ISO11898-2 Fault-tolerant CAN ISO11898-3 最高 1Mbps / 40m オープンバス最高 125Kbps / 40m オープンバスループバスバスの形状 × × ○ 障害発生時の自動復旧（片線での通信継続）通信速度最高 125Kbps バスレベル 0 1 2 3 4 レセシブドミナントレセシブ 0 1 2 3 4 レセシブレセシブドミナント (V) (V) CAN_High CAN_Low CAN_High CAN_Low このうち、弊社製品で対応しているのは ISO11898-2 と ISO11898-3 の二つです。

CAN バスのレベルの判断は CAN トランシーバが行います。CAN バスには CAN_High と CAN_Low という 2 本の信号線があり、この 2 本の電位差によりレベルの判断が行われます。上の表の通り、高速 CAN と低速 CAN では、バスレベルの判断の仕方が異なります。

高速 CAN の場合、CAN_High と CAN_Low の間に電位差が無いときがレセシブレベル、 CAN_High が高い電圧で CAN_Low が低い電圧になり、電位差が生じた場合がドミナントレベルとなります。

低速 CAN の場合、CAN_Low が CAN_High を上回っている場合、レセシブレベルで、CAN_High が CAN_Low を上回っている場合ドミナントレベルとなります。

(11)

2.3.2.CAN のバージョン 先述した BOSCH 社で規定されている CAN プロトコルには、幾つかのバージョンが存在します。それらをまとめたのが以下の表です。 表 2-2 CAN のバージョン バージョン 2.0A 2.0B パッシブ 2.0B アクティブ ID のビット数 11 ビット 29 ビット 29 ビット備考 29 ビット ID を受信するとエラー発生。送信は 11 ビットのみ 29 ビット ID を受信してもエラーは発生しないが無視される。送信は 11 ビットのみ 29 ビット ID を送受信可能弊社の製品は Ver2.0B アクティブに対応しております。バージョン間での違いは、扱える ID のサイズです。ID については後ほど説明いたしますが、識別する為の番号とお考え下さい。そこで使えるビットの数が多いということは、それだけ多くの端末を識別することが出来るということになります。備考に有る通り、2.0A では、11 ビットの ID しか扱うことができません。もし 29 ビット ID を持ったフレームを受信するとエラーが発生します。 2.0B パッシブでは、29 ビット ID の送信はできませんが、受信時、エラーが発生することはありません。しかし、データとしては取り込まれませんので、無視される形となります。 2.0B アクティブでは、送受信共に 29 ビットの ID を扱うことができます。

(12)

8 2.3.3.調停の仕組み（優先順位の決定方法） CAN の一つの大きな特長に、この調停の仕組みが挙げられます。バス上で複数の端末が同時に送信を開始した場合、送信されたメッセージに含まれる ID 等を用い優先度を判断し、より優先度の高いメッセージがバス上に生き残り、優先度の低いメッセージは再送することになります。では、どうやって優先度の判断を行っているのでしょうか？ここで重要になってくるのが先ほど説明いたしました『2.3.1バスレベルとビット』になります。 CAN では、自分の出力したレベルと、バス上の実際のレベルを常に監視しています。 CAN トランシーバ CAN コントローラ送信受信 CAN バスレセシブを出力。。バスレベルはレセシブだ。。 図 2-2 バスレベルの監視 そして一つでもドミナントレベルを出力する端末がいると、バスはドミナントレベルになります。 CAN バスバスレベルはドミナント CAN 端末レセシブを出力。。 CAN 端末レセシブを出力。。 CAN 端末 CAN 端末レセシブを出力。。ドミナントを出力。。 図 2-3 バスレベルの関係

(13)

この仕組みをつかい、調停を行います。下の図のように 2 台の端末から同時に送信が行われたとします。CAN のメッセージ送信は、ID の上位ビットからそれぞれ送信されます。自分の出力がドミナントレベルで、バス上もドミナントレベルであれば次のビットの出力を行います。自分の出力がレセシブレベルで、バス上もレセシブレベルだった場合も同様です。もし自分がレセシブレベルを出力したのに、バス上がドミナントレベルだった場合には、他の端末からドミナントレベルが出力されていることになります。 CANバス CAN端末１からの出力 CAN端末2 からの出力

…

CAN端末2からのレセシブ出力が CAN端末1からのドミナント出力に負けバスの状態はドミナントレベルになるそれ以降CAN端末2はレセシブを出力し続け、CAN端末1の送信が完了するまで待機する …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L 図 2-4 調停の動作 これが調停に負けたということです。調停に負けた端末はバスが空くのを待ち、再送を行います。 ※ このとき、自分よりも優先度の高い端末からの送信が入った場合、また調停に負け再送を行うことになります。時間を考慮した設計が必要になってきます。

(14)

10 2.3.4.ビットスタッフ CAN プロトコルでは、連続した同一ビットが続くことによる、同期ずれのエラーを防止するため、ビットスタッフを行います。ビットスタッフとは、連続した 5 ビットの同一レベルが出力された場合、次に 1 ビット、反転したビットを付加します。このビットは受信する際には取り除かれて受信されます。なお、この処理が行われるのは、後述するデータフレームとリモートフレームの 2 種類のフレームにおいてのみです。また対象となる範囲はスタートオブフレーム∼CRC フィールドの間です。 2.3.5.エラー状態 CAN プロトコルでは、CAN 端末の状態として 3 種類の状態を定義しています。・エラーアクティブ・エラーパッシブ・バスオフ CAN 端末は、最初通信に参加していない状態ではバスオフです。通信に参加するとエラーアクティブとなります。正常に通信が行えている間はエラーアクティブを維持します。エラーを起こしやすい状態になると、エラーパッシブになります。これらの状態は、エラーカウンターの値を元に遷移します。エラーカウンタには、送信エラーカウンタと受信エラーカウンタがあり、それらの値により以下の様に遷移します。エラーアクティブエラーパッシブバスオフ初期化時連続 11 ビットレセシブ検出を 128 回 TEC>255 TEC<128 及び REC<128 TEC…送信エラーカウンタ REC…受信エラーカウンタ TEC>127 又は REC>127 図 2-5 エラー状態

(15)

スミッションを含むインターフレームスペースを送信しなければならないためです。（『2.4.6インターフレームスペースの解説』参照）また、積極的にエラーを通知することができなくなります。 2.4.フレーム解説 2.4.1.フレームの種類 CAN では、フレームという単位で送受信を行います。以下の種類のフレームが CAN では定義されています。 表 2-3 フレーム一覧 フレームの種類主な役割データフレーム送信データリモートフレーム送信を要求するエラーフレームエラーを通知するオーバーロードフレーム受信が出来ないことを通知するインターフレームスペースフレームとフレームの間隔をあけるそれぞれのフレームの説明については後述致します。このうち、データフレームとリモートフレームについては、標準フォーマットと拡張フォーマットという 2 種類が存在します。標準フォーマットでは ID が 11 ビット、拡張フォーマットでは ID が 29 ビットという違いがあります。先述した CAN のバージョンの違いで、扱えるフォーマットの種類が決まります。バージョン 2.0A では、標準フォーマットだけを扱うことができます。バージョン 2.0B アクティブでは標準フォーマット、拡張フォーマットの両方を扱うことができます。バージョン 2.0B パッシブでは、送受信できるのは標準フォーマットだけですが、拡張フォーマットのメッセージを受信してもエラーは発生しません。（メッセージは破棄される）ご使用になるバージョンをご確認の上、使用するフォーマットをお選び下さい。

(16)

12 2.4.2.データフレームの解説 データフレームについて解説致します。データフレームはメッセージの送信の際に使用します。最大で 8 バイトまでのデータを含むことができます。データフレームの構成は以下の通りです。アイデンティファイヤ 11ビット DLC 4 ビット CRC 15ビット EOF データフィールド 0∼64ビットスタートオブフレームアービトレーションフィールドコントロールフィールドデータフィールド CRCフィールド ACKフィールド エンドオブフレーム …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L 図 2-6 データフレーム 大きく分け、7 つのフィールドで構成されています。先頭から・ Start of Frame ・ Arbitration field ・ Control field ・ Data field ・ CRC field ・ Acknowledge field ・ End of Frame という名前がついています。

(17)

Start of Frame

データフレームの先頭を表します。1 ビットのドミナントビットで構成されます。アイデンティファイヤ DLC データフィールド CRC EOF スタートオブフレーム 図 2-7 Start of Frame 標準・拡張フォーマット共通

CAN バスはデータの流れていないときはレセシブレベルを維持しています。Start of frame のドミナントレベルが出力されることでバス上にデータが流れ始めたことを知ることができます。

Arbitration field

調停を行う際に用いられるフィールドです。12 ビットまたは、32 ビットで構成されます。 DLC データフィールド CRC EOF アイデンティファイヤ ID28 11 ビット ID

ID27 ID26 ID25 ID24 ID23 ID22 ID21 ID20 ID19 ID18 RTR

ID は、28 から 18 の順番で出力されます。 RTR は 1 ビットのドミナントビットです。

(18)

14 DLC データフィールド CRC EOF アイデンティファイヤ IDE 11 ビット ID

ID17 ID16 ID15 ID14 ID13 ID12 ID1

1

ID10 ID9 ID8 RTR

ID は、28 から 0 の順番で出力されます。 RTR は 1 ビットのドミナントビットです。

ID28

11 ビット ID

ID27 ID26 ID25 ID24 ID23 ID22 ID21 ID20 ID19 ID18 SR

R ID7 ID6 ID5 ID4 ID3 ID2 ID1 ID0

図 2-9 アービトレーションフィールド拡張フォーマット時 ID は上位からバス上に出力され順次評価され調停が行われます。（『2.3.3調停の仕組み（優先順位の決定方法）』参照）ドミナントレベルの論理値は“0”ですので、ID の数値が小さい方が優先順位が高いことになります。なお、上位 7 ビットが全てレセシブビットになることは禁止されています。最強、最弱の ID は以下の通りです。（16 進数及び 2 進数で記述） 表 2-4 最強、最弱の ID 最強最弱標準フォーマット時 0h (00000000000b) (11111101111b)7EFh 拡張フォーマット時 0h (00000000000000000000000000000b) (11111101111111111111111111111b)1FBFFFFFh RTR はドミナントレベルです。この RTR は、リモートフレーム（後述）とデータフレームを識別するために使用されます。詳しくは、『2.4.3リモートフレームの解説』を参照ください。

(19)

Control field

データフレームに含まれるデータのサイズを表すフィールドです。6 ビットで構成されます。 CRC EOF データフィールドアイデンティファイヤ IDE r0 DL_C3 DL_C2 DL_C1 DL_C0 DLC 図 2-10 Control field 標準フォーマット時 CRC EOF データフィールドアイデンティファイヤ r1 r0 DL_C3 DL_C2 DL_C1 DL_C0 DLC 図 2-11 Control field 拡張フォーマット時 r0，r1 は予約ビットで、ドミナントレベルです。ただし受信側は、レセシブレベルであっても受信しなければなりません。データサイズは 4 ビットで表され、0∼8 以外は使用できません。

(20)

16 表 2-5 DLC の値 DLC3 DLC2 DLC1 DLC0 データフィールドに含まれるデータバイト数レセシブドミナントドミナントドミナント 8 ドミナントレセシブレセシブレセシブ 7 ドミナントレセシブレセシブドミナント 6 ドミナントレセシブドミナントレセシブ 5 ドミナントレセシブドミナントドミナント 4 ドミナントドミナントレセシブレセシブ 3 ドミナントドミナントレセシブドミナント 2 ドミナントドミナントドミナントレセシブ 1 ドミナントドミナントドミナントドミナント 0

Data field

データ本体を表すフィールドです。サイズは 0∼8 バイトです。 CRC EOF アイデンティファイヤ D ata1 B it7 D ata1 B it6 D ata1 B it5 D ata1 B it4 D ata1 B it3 D ata1 B it2 DLC D ata1 B it1 D ata1 B it0 D ata2 B it7 D ata2 B it6 D ata2 B it5 D ata2 B it4 D ata2 B it3 D ata2 B it2 D ata2 B it1 D ata2 B it0 ・・・・ D ata7 B it7 D ata7 B it6 D ata7 B it5 D ata7 B it4 D ata7 B it3 D ata7 B it2 D ata7 B it1 D ata7 B it0 D ata8 B it7 D ata8 B it6 D ata8 B it5 D ata8 B it4 D ata8 B it3 D ata8 B it2 D ata8 B it1 D ata8 B it0 データフィールド 図 2-12 Data field 標準・拡張フォーマット共通 最上位ビットから出力が行われます。データは 8 ビット（1 バイト）単位で、Control fileld の DLC で指定されたサイズ分格納されます。

(21)

CRC field

フレームが正しいかチェックをする際に使用します。 16 ビットで構成されます。 EOF データフィールドアイデンティファイヤ CRC6 DLC CRCフィールド CRC14 CRC13 CRC12 CRC1 1 CRC10 CRC9 CRC8 CRC7 CRC5 CRC4 CRC3 CRC2 CRC1 CRC0 CRC d eli m ite r 図 2-13 CRC field 標準・拡張フォーマット共通 15 ビットの CRC シーケンス、1 ビットの CRC デリミタから構成されます。CRC シーケンスの生成多項式は以下の通りです。 X15_+X14_+X10_+X8_+X7_+X4_+X3₊₁

なお対象は Start of Frame、Arbitration field、Control field、Data field（存在する場合）です。生成された CRC シーケンスは最上位ビットから出力が行われます。 CRC デリミタは 1 ビットのレセシブビットです。 CRC デリミタがレセシブ以外のレベルだった場合、フォームエラー（『2.5エラーの種類』参照）が発生します。受信側端末では受信したフレームから同様に CRC シーケンスを求め、受信した CRC シーケンスと比較し、フレームが正しいかどうかをチェックします。一致しない場合、CRC エラーが発生します。

(22)

18

Acknowledge field

送信されたフレームが正常に受信されたかどうかの確認を行う為のフィールドです。 2 ビットで構成されます。 EOF データフィールドアイデンティファイヤ DLC CRCフィールド ACK sl ot ACK d eli m ite r 図 2-14 Acknowledge field 標準・拡張フォーマット共通 ACK スロット、ACK デリミタから構成されます。 ACK スロットは送信側端末からはレセシブレベルで出力されます。このフレームを受信し CRC チェックでエラーの発生しなかった受信側端末は ACK スロットに対しドミナントレベルを出力します。送信側端末は ACK スロットがドミナントレベルになることで、自分の送ったフレームがエラーになることなく、いずれかの受信側端末で正常に受信されたことを知ることが出来ます。もしも ACK スロットがレセシブレベルのままの場合、ACK エラーが発生します。 ACK デリミタは 1 ビットのレセシブビットです。 ACK デリミタがレセシブ以外のレベルだった場合、フォームエラーが発生します。

(23)

End of Frame

データフレームの終了を表すフィールドです。 7 ビットのレセシブビットで構成されます。データフィールドアイデンティファイヤ DLC CRCフィールド EO F EOF EO F EO F EO F EO F EO F EO F 図 2-15 End of Frame 標準・拡張フォーマット共通 End of Frame にレセシブ以外のビットが含まれる場合、フォームエラー（『2.5エラーの種類』参照）が発生します。

(24)

20 2.4.3.リモートフレームの解説 リモートフレームは、データ本体を持たないデータフレームの様に見えます。通常、受信側の端末から、送信側の端末へデータ送信を要求する際に使用します。リモートフレームの構成は以下の通りです。アイデンティファイヤ 11ビット DLC 4 ビット CRC 15ビット EOF スタートオブフレームアービトレーションフィールドコントロールフィールド CRCフィールド ACKフィールド エンドオブフレーム …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L 図 2-16 リモートフレーム 大きく分け、6 つのフィールドで構成されています。先頭から・ Start of Frame ・ Arbitration field ・ Control field ・ CRC field ・ Acknowledge field ・ End of Frame という名前がついています。

このうち、データフレームと違いがあるのは Arbitration field と Control field なので、ここでの説明は、この二つだけとさせて頂きます。

(25)

Arbitration field

データフレームと同様、調停を行う際に用いられるフィールドです。12 ビットまたは、32 ビットで構成されます。 DLC CRC EOF アイデンティファイヤ ID2 8 11 ビット ID ID2 7 ID2 6 ID2 5 ID2 4 ID2 3 ID2 2 ID2 1 ID2 0 ID1 9 ID1 8 RT R ID は、28 から 18 の順番で出力されます。 RTR は 1 ビットのレセシブビットです。 図 2-17 Arbitration fiedl 標準フォーマット時 DLC CRC EOF アイデンティファイヤ IDE 11 ビット ID ID1 7 ID1 6 ID1 5 ID1 4 ID1 3 ID1 2 ID1 1 ID1 0 ID9 ID8 RT R ID は、28 から 0 の順番で出力されます。 RTR は 1 ビットのレセシブビットです。 ID2 8 11 ビット ID ID2 7 ID2 6 ID2 5 ID2 4 ID2 3 ID2 2 ID2 1 ID2 0 ID1 9 ID1 8

SRR ID7 ID6 ID5 ID4 ID3 ID2 ID1 ID0

図 2-18 Arbitration field 拡張フォーマット時

データフレームとの違いは RTR ビットの違いです。リモートフレームでは RTR ビットはレセシ

ブレベルです。、データフレームではドミナントレベルでした。

もしデータ本体を持たないデータフレーム（DLC=0）が届いても、RTR ビットを見ればデータフレームかリモートフレームかを判断することができるというわけです。

(26)

22

Control field

データフレームと同様、6 ビットでデータのサイズを表します。 CRC EOF アイデンティファイヤ IDE r0 DL_C3 DL_C2 DL_C1 DL_C0 DLC 図 2-19 Control filed 標準フォーマット時 CRC EOF アイデンティファイヤ r1 r0 DL_C3 DL_C2 DL_C1 DL_C0 DLC 図 2-20 Control field 拡張フォーマット時 データフレームと同じフォーマットですが、リモートフレームには Data field がありません。ここで表すサイズは送信側端末に対して送信を要求する際のデータサイズを表しています。

(27)

2.4.4.エラーフレームの解説 エラーフレームについて解説致します。エラーフレームはエラーを検出した端末が他の端末にエラーを通知する際に使用します。データフレームの構成は以下の通りです。エラーフラグエラーデリミタエラーフラグエラーデリミタ …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L エラーフラグ 6 ビット 0∼6 ビット 図 2-21 エラーフレーム 標準・拡張フォーマット共通です。大きく分け、2 つのフィールドで構成されています。先頭から・エラーフラグ・エラーデリミタという名前がついています。エラーフレームの送信のタイミングは、発生したエラーの種類により異なります。ビットエラー、スタッフエラー、フォームエラー、ACK エラーの場合、エラーを検出した次のビットからエラーフラグの送信が開始されます。

(28)

24

エラーフラグ

エラーフラグは 6∼12 ビットで構成されます。エラーフラグエラーフラグエラーデリミタ 6 ビット 0∼6 ビット 図 2-22 エラーフラグ標準・拡張フォーマット共通 エラーフラグには 2 種類のフラグがあります 表 2-6 エラーフラグの種類 エラーフラグの種類構成内容アクティブエラーフラグ 6 ビットのドミナントビットエラーアクティブの端末がエラーを検出した際に送信するパッシブエラーフラグ 6 ビットのレセシブビットエラーパッシブの端末がエラーを検出した際に送信するパッシブエラーフラグはレセシブビットの為、他の端末からのドミナントビットによって上書きされる可能性があります。これは、エラーパッシブの端末はエラーが発生しやすい状態ということで、バス上に積極的にエラー通知ができない為です。つまりエラーパッシブの端末がエラーフラグを送出しても他のエラーアクティブの端末がエラーを検出し通知を行わない限り、バス上にはエラーは発生していないことになるのです。エラーを検出した端末はアクティブエラーフラグとして 6 ビットのドミナントを出力します。この時、ビットスタッフは行われないので、他の端末ではビットスタッフエラーを検出し、アクティブエラーフラグを送出します。これがエラーフラグの重ね合わせで、エラーフラグは最長で 12 ビットとなります。

エラーデリミタ

エラーデリミタは 8 ビットのレセシブビットで構成されます。エラーフラグエラーフラグ 6 ビット 0∼6 ビットエラーデリミタ 8ビット 図 2-23 エラーデリミタ標準・拡張フォーマット共通 各端末はエラーフラグを送出後、1 ビットのレセシブビットを出力し、バスがレセシブレベルになるまで繰り返します。レセシブレベルを検出すると続けて残り 7 ビットのレセシブビットを出力します。

(29)

2.4.5.オーバーロードフレームの解説 オーバーロードフレームについて解説致します。オーバーロードフレームは受信側端末の受信準備が整っていないときに送信されます。オーバーロードフレームの構成は以下の通りです。オーバーロードフラグオーバーロードデリミタオーバーロードフラグオーバーロードデリミタ …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L オーバーロードフラグ 6 ビット 0∼6 ビット 図 2-24 オーバーロードフレーム 標準・拡張フォーマット共通です。大きく分け、2 つのフィールドで構成されています。先頭から・オーバーロードフラグ・オーバーロードデリミタ

(30)

26

オーバーロードフラグ

オーバーロードフラグは 6∼12 ビットのドミナントビットで構成されます。オーバーロードフラグオーバーロードデリミタオーバーロードフラグ 6 ビット 0∼6 ビット 図 2-25 オーバーロードフラグ標準・拡張フォーマット共通 ドミナントビットで構成される為、オーバーロードフレームを送出している間は、他の端末からはデータを送信することができません。オーバーロードフラグは、アクティブエラーフラグと同じ構成です。

オーバーロードデリミタ

オーバーロードデリミタは 8 ビットのレセシブビットで構成されます。オーバーロードフラグオーバーロードフラグ 6 ビット 0∼6 ビットオーバーロードデリミタ 8ビット 図 2-26 オーバーロードデリミタ標準・拡張フォーマット共通 オーバーロードデリミタは、エラーデリミタと同じ構成です。

(31)

2.4.6.インターフレームスペースの解説 インターフレームスペースについて解説致します。インターフレームスペースは、データフレーム、リモートフレームの、フレーム間を分離する為に送信されます。インターフレームスペースの構成は以下の通りです。インターミッション 3ビットバスアイドル 0∼ インターミッションサスペンドトランスミッション …ドミナント …レセシブ …任意のレベル CAN_H CAN_L CAN_H CAN_L サスペンドトランスミッション 8ビットバスアイドル 図 2-27 インターフレームスペース 大きく分け、3 つのフィールドで構成されています。先頭から・インターミッション・サスペンドトランスミッション・バスアイドルという名前がついています。

(32)

28

インターミッション

インターミッションは 3 ビットのレセシブビットで構成されます。バスアイドル 0∼ サスペンドトランスミッション 8ビットインターミッション 3ビット 図 2-28 インターミッション標準・拡張フォーマット共通 この間、全ての端末はデータフレーム、リモートフレームを送信することができません。例外として、オーバーロードフレームだけは送信可能です。

サスペンドトランスミッション

サスペンドトランスミッションは 8 ビットのレセシブビットで構成されます。インターミッション 3ビットバスアイドル 0∼ サスペンドトランスミッション 8ビット 図 2-29 サスペンドトランスミッション標準・拡張フォーマット共通 サスペンドトランスミッションは、エラーパッシブ状態のユニットから送信されたフレームに続いて送信されたインターフレームスペースに限り含まれます。

バスアイドル

バスアイドルは任意のビット数のレセシブビットで構成されます。インターミッション 3ビットサスペンドトランスミッション 8ビットバスアイドル 0∼ 図 2-30 バスアイドル標準・拡張フォーマット共通 長さに制限はありません。0 ビットでも構いません。バスアイドル時、どの端末からも送信を行うことができます。

(33)

2.5.エラーの種類 CAN では、以下の 5 つのエラーが定義されています。・ビットエラー・スタッフエラー・ CRC エラー・フォームエラー・ ACK エラーエラーが発生した場合、自分自身のエラー状態に合わせエラーフレームの送信を行います。エラーフレームについては『2.4.4エラーフレームの解説』を参照下さい。 2.5.1.ビットエラー CAN では送信を行う端末がバスを監視し、1 ビット毎に自分の出力したレベルと同じかをチェックします。もし、自分の出力したレベルと現在のバスのレベルが異なる場合、ビットエラーとなります。例外として、Arbitration field、ACK スロットに対してレセシブビットを出力したのにドミナントビットを検出したときはビットエラーになりません。また、パッシブエラーフラグを送信中の時もビットエラーにはなりません。ビットエラーは送信側、受信側端末の両方で検出されます。 2.5.2.スタッフエラー 『ビットスタッフ』が行われるべき所で、ビットスタッフが行われていないときにスタッフエラーとなります。スタッフエラーは送信側、受信側端末の両方で検出されます。 2.5.3.CRC エラー 受信を行った端末が CRC を計算し、メッセージに付随する CRC シーケンスと一致しない場合、 CRC エラーとなります。『CRC field』の説明を参照下さい。 CRC エラーは受信側端末においてのみ検出されます。

(34)

30 2.5.4.フォームエラー 受信を行った端末が、特定のビットで期待された値（固定値）以外の値を検出した場合に発生するエラーです。例えば CRC デリミタはレセシブでなければなりませんが、ここでドミナントレベルを検出した場合、フォームエラーとなります。フォームエラーの発生する可能性としては以下の通りです。・データフレームにおいて、CRC デリミタ、ACK デリミタ、EOF のいずれかでドミナントレベルを検出した。・リモートフレームにおいて、CRC デリミタ、ACK デリミタ、EOF のいずれかでドミナントレベルを検出した。・エラーフレームにおいて、エラーデリミタでドミナントレベルを検出した。・オーバーロードフレームにおいて、オーバーロードデリミタでドミナントレベルを検出した。フォームエラーは受信側端末においてのみ検出されます。 2.5.5.ACK エラー

送信を行った際、ACK スロットに ACK が返ってこなかった場合、ACK エラーとなります。『Acknowledge field』の説明を参照下さい。

(35)

3. 弊社 CAN インタフェースの特長 3.1.製品の特長 弊社 CAN インタフェース製品は、以下の機能、特長を持ちます。これらの機能、特長の一部は 4 節（34ページ以降）に詳しく解説しています。 ◆ 豊富なラインナップ（バスの種類、チャンネル数、機能の違いなど）通常のパソコンで採用されている PCI バスの他、省スペースデスクトップで採用されている Lowprofile PCI、ノートパソコンで採用されている CardBus、耐環境性に優れた工業用途の Compact PCI それぞれのバスに対応した製品をラインナップしております。また、搭載される機能の違いで、スタンダード版、高機能版、バスマスタ版とご用意いたしております。（詳細は『3.2製品のラインナップ』で解説致します） ◆ 大容量 FIFO バッファの搭載で、データの取りこぼしを防止（高機能版、バスマスタ版） 送信、受信にそれぞれ 64 メッセージ分の FIFO バッファを搭載しています。また、エラー情報用にも 64 件のバッファが用意されています。なお、スタンダード版は 64 バイトの FIFO しか搭載しておらず、1 バイトのデータを含むメッセージを受信した場合、64 バイトの FIFO の中には 16 個のメッセージしか蓄えることができません。データを 8 バイトにした場合、5 個しか蓄えることができません。一方、高機能版、バスマスタ版ではデータの長さに依らず 64 個のメッセージを蓄えることができます。 ※ これらの FIFO バッファは、デバイスドライバ内部で使用していますので、アプリケーション側から直接使用することはできません。デバイスドライバ内部のバッファへ随時転送されます。どの製品をお使い頂く場合も、デバイスドライバ内部のバッファサイズは任意のサイズを指定可能ですので、この FIFO のサイズの違いはデータの取りこぼし発生の確率を下げる物とご理解下さい。 ※ 最高速度（1Mbps）で、1 バイトのデータを持つフレームを連続で受け取った場合、64 メッセージを実時間に当てはめると、約 3ms になります。 ◆ バスマスタ機能を搭載し、CPU の負荷を軽減（バスマスタ版） バスマスタ版では、上記の FIFO バッファに加え、データの転送にバスマスタ方式を採用していますので、CPU に負荷をかけることなく、FIFO バッファから受信メッセージを取り出すことができます。

(36)

32 ◆ 10µs 単位のカウンタを搭載し、正確なタイミングを取得可能（高機能版、バスマスタ版） 10µs 単位のカウンタを搭載しています。メッセージの受信時、FIFO バッファに格納する際にこのカウンタの値を一緒に格納しますので、メッセージの受信したタイミングを正確に知ることができます。また、メッセージ受信と同様に、エラーの発生時にも同様にこのカウンタの値が格納されますので、受信メッセージとエラー発生のタイミングの関係も知ることができます。 ◆ 10µs 単位で、繰り返し送信、メッセージ送信間隔指定可能（高機能版、バスマスタ版） 繰り返し送信の周期を設定することで、ソフトウェアに影響を受けることなく、自動で繰り返し送信を行うことができます。もちろん、送信のメッセージを途中で変更することも可能です。変更後は、次の送信タイミングから新しいメッセージが送信されます。試験装置を作る際など、正確な周期が必要な場合に便利です。通常の送信の場合、メッセージ送信の完了後、一定間隔を空けて次のメッセージを送信することが可能です。例えば、こちらから相手にメッセージを送った後、他の端末からの送信のためにバスを一定時間空けておきたいといったときに便利です。

(37)

3.2.製品のラインナップ 弊社 CAN インタフェース製品の機能、特性の比較一覧を示します。 表 3-1 型式の見方 ○○○−485◎□△ 低速CANのチャンネル数（0∼4）高速CANのチャンネル数（0∼4）製品カテゴリ 1・・・標準版 2・・・高機能版 3・・・バスマスタ対応版バスの種別 PCI・・・PCIバス対応版 CTP・・・CompactPCIバス対応版 CBI・・・CardBus対応版

LPC・・・Low Profile PCI対応版

CPZ・・・3.3V信号環境CompactPCIバス対応版型式名 PCI-4851xx PCI-4852xx PCI-4853xx LPC-4851xx、LPC-4852xx CTP-4853xx CPZ-4853xx CBI-4851xx、CBI-4852xx 外観図価格弊社 Web site をご覧下さい特長・各種バス向けに豊富なラインナップ・ Windows、Linux 用デバイスドライバを無償提供使用コントローラ SJA1000 (Philips 社) 高速 CAN 低速 CAN

(38)

34 4. チュートリアル ここでは、弊社 CAN インタフェースにおいて、可能な動作、機能の説明を行います。表 4-1 に本チュートリアルで使用する用語の意味を示しておきます。 表 4-1 用語の説明 用語名意味 CAN メッセージデータフレーム、リモートフレームと同義です。プロファイル CAN メッセージに含まれるデータが、どの様な意味づけで格納されているかを定義した情報。GPC-4851、GPG-4851 でライブラリとして機能を提供しています。アクセプタンスフィルタ受信許可フィルタです。設定された条件の ID、データを持つ CAN メッセージのみ受信し、それ以外は破棄します。エラー情報 CAN バスで発生した各種バスエラーの情報です。発生した時間、エラーの種類などが含まれます。送信バッファ、受信バッファ主にデバイスドライバ内で確保されるバッファを指します。高機能版ではボード上に FIFO バッファを拡張していますが、ここでいう送信バッファ、受信バッファはソフトウェアレベルでのバッファですので、製品による違いはありません。本チュートリアルに記載されている動作を確認する為には以下のものが必要となります。 表 4-2 必要機材 弊社 CAN インタフェース（PCI-485220） 1 枚：『3.2製品のラインナップ』を参照下さい GPC-4851 1 本：弊社 Web site よりダウンロード下さい CAN ケーブル 1 本：弊社ではご用意致しておりません ※本チュートリアルは D-Sub9 ピンコネクタを両端に付けたケーブルを使用しています。 2 番ピン … CAN_L 7 番ピン … CHN_H をそれぞれストレートで接続します。パソコンに CAN インタフェースを実装し、ケーブルを用いてボードのチャンネル同士を接続してください。このとき、注意することとしては、高速 CAN と低速 CAN は通信することが出来ませんので、高速 CAN は高速 CAN 同士、低速 CAN は低速 CAN 同士で接続してください。適合コネクタ、ピン配置などは、お使いの CAN インタフェースのマニュアルに掲載されておりますので、ご確認下さい。

(39)

CAN_H(ピン番号 7) GND(ピン番号 3) D-Sub9 ピン CAN_L(ピン番号 2) D-Sub9 ピン 図 4-1 PCI-485220 における CH1 と CH2 の接続例 バスの両端に来るチャンネルには、必ず終端抵抗の設定を行ってください。 4.1.動作説明 表 4-2において可能な動作一覧を示します。 表 4-3 動作一覧 動作一覧 Page 通常通信モード 36 FIFO 送信モード 38 動作モードモニタモード 40 受信メッセージ取り出し 42 受信フィルタ設定 44 エラー情報取り出し 51 受信動作バッファサイズ変更 53 通常送信 55 繰り返し送信 57 CAN 通信送信動作送信間隔指定 61 ユーティリティを用いた登録方法 64 登録 API を用いた登録方法 67 プロファイル変換プロファイルの適用方法 68

(40)

36 4.1.1.通常通信モード

指定可能製品弊社 CAN インタフェースシリーズ全製品

動作説明通常の CAN 通信を行うモードです。

CAN メッセージの受信時、ACK（P.18『Acknowledge field』）を返します。

動作図端末 A CANバス端末 B データ送信データ受信 ACKを返信する ACK返信するデータ受信他の端末と同様に、 CAN インタフェースはA CK を返します。通常通信モードのPCI-485220

(41)

アプリケーション例通常通信モードで CAN インタフェースをオープンします。なお、CAN バスの通信速度は 500kbps とします。プログラムでの制御手順サンプルプログラムプログラム名プログラム格納先フォルダ 4851_PORTINIT ＜インストール先＞¥言語¥CAN¥4851_PORTINIT ボードのオープン CanOpenPort CAN インタフェースを使用可能にします。設定値取得 CanGetConfig CAN バスへ接続 CanActivate CAN バスへの接続を有効にします。ボードのクローズ CanClosePort CAN インタフェースを使用不可にします。まず、CanGetConfig で動作パラメータのデフォルト値を取得します。その中で、変更を行いたいパラメータだけ変更し、 CanSetConfig で設定します。パラメータ設定値 ulLineMode CAN_NORMAL_MODE ulBaudRate CAN_BAUDRATE_500k これ以外のパラメータはデフォルト値とします。各種処理受信メッセージの取り出しなど行います。動作パラメータ設定 CanSetConfig

(42)

38 4.1.2.FIFO 送信モード 指定可能製品高機能版 PCI-485202,PCI-485211,PCI-485220,LPC-485202,LPC-485211,LPC-485220 CBI-485220WA,CBI-485220WB,CBI-4852A,CBI-4852B バスマスタ対応版 PCI-485304,PCI-485322,PCI-485340,CTP-485304,CTP-485322,CTP-485340, CPZ-485304, CPZ -485322, CPZ -485340 動作説明『通常通信モード』に加え、メッセージ送信時に拡張された FIFO バッファを使用し、送信のパフォーマンスを向上させるモードです。ボードから発生する送信割り込みの頻度が減り、パソコンへの負荷が軽減されます。動作図端末 A CANバス端末 B 通常送信モードでは、デバイスドライバ内部のバッファから少しずつCANコントローラに転送されます。 FIFO送信モードでは、ボード上のFIFO バッファに一括で転送し、そこから自動的にCANコントローラへ転送されます。 C A N コントローラ FI FO バッファドライバ内部バッファアプリケーション内部バッファ

(43)

アプリケーション例 FIFO 送信モードで CAN インタフェースをオープンします。なお、CAN バスの通信速度は 500kbps とします。プログラムでの制御手順サンプルプログラムプログラム名プログラム格納先フォルダ 4851_PORTINIT ＜インストール先＞¥言語¥CAN¥4851_PORTINIT

※ 実際は、CAN_NORMAL_MODE が ”0” を表す為、CAN_FIFO_SEND_MODE だけを指定しても FIFO 送信モードで動作します。ボードのオープン CanOpenPort CAN インタフェースを使用可能にします。設定値取得 CanGetConfig CAN バスへ接続 CanActivate CAN バスへの接続を有効にします。ボードのクローズ CanClosePort CAN インタフェースを使用不可にします。まず、CanGetConfig で動作パラメータのデフォルト値を取得します。その中で、変更を行いたいパラメータだけ変更し、 CanSetConfig で設定します。パラメータ設定値 ulLineMode CAN_NORMAL_MODE OR （論理和） ※ CAN_FIFO_SEND_MODE ulBaudRate CAN_BAUDRATE_500k これ以外のパラメータはデフォルト値とします。 CAN_FIFO_SEND_MODE は、単独で指定するのではなく、 CAN_NORMAL_MODE との論理和を指定します。各種処理 CAN メッセージの送信などを行います。動作パラメータ設定 CanSetConfig

(44)

40 4.1.3.モニタモード

動作説明 CAN メッセージの受信時、ACK（P.18『Acknowledge field』）を返しませ

ん。データの横取りするだけで、CAN バスに対しては一切影響を与えません。 CAN バスをモニタしたい時に使うモードです。 CAN バス上に、モニタモード以外の CAN 端末が存在しない場合（例えば、弊社 CAN インタフェースの CH1 と CH2 を接続し、片方をモニタモードとした時）、送信データに対し、ACK を返す端末がいないことになりますので、ACK エラーが発生します。ご注意下さい。本モードを使い、次々に通信速度を変更していき、通信速度の検出に使うこともできます。動作図端末 A CANバス端末 B モニタモードのPCI-485220 データ送信データ受信 ACKを返信しない ACK返信するデータ受信通常、データ受信した端末はACK を返しますが、モニタモードで初期化された CAN インタフェースはACK を返しません。 ※ モニタモードでは、エラーパッシブ状態（P.23『2.4.4エラーフレームの解説』を参照下さい）となり、通信エラーを検出してもアクティブエラーフラグを送信することができません。

(45)

アプリケーション例モニタモードで CAN インタフェースをオープンします。なお、CAN バスの通信速度は 500kbps とします。プログラムでの制御手順サンプルプログラムプログラム名プログラム格納先フォルダ 4851_PORTINIT ＜インストール先＞¥言語¥CAN¥4851_PORTINIT ボードのオープン CanOpenPort CAN インタフェースを使用可能にします。設定値取得 CanGetConfig CAN バスへ接続 CanActivate CAN バスへの接続を有効にします。ボードのクローズ CanClosePort CAN インタフェースを使用不可にします。まず、CanGetConfig で動作パラメータのデフォルト値を取得します。その中で、変更を行いたいパラメータだけ変更し、 CanSetConfig で設定します。パラメータ設定値 ulLineMode CAN_LISTEN_ONLY_MODE ulBaudRate CAN_BAUDRATE_500k これ以外のパラメータはデフォルト値とします。各種処理受信メッセージの取り出しなど行います。動作パラメータ設定 CanSetConfig

(46)

42 4.1.4.受信メッセージ取り出し

動作説明弊社 CAN インタフェースを使用し CAN 通信を行う際、受信された CAN

メッセージは一旦、デバイスドライバ内部のバッファに蓄えられます。そのバッファからアプリケーション側に受信メッセージを取り出す動作を行います。動作図端末 A CANバス端末 B CAN バスから受信したメッセージは CAN コントローラに一旦蓄えられます。標準版では、直接CAN コントローラからデバイスドライバにデータを転送しますが、高機能版では、拡張されたFIFOバッファに蓄えられ、そこからまとめて取り出すことができます。 C A N コントローラ FI FO バッファドライバ内部バッファアプリケーション内部バッファデータ送信データ受信データ受信この処理はハードウェア、デバイスドライバ内部で自動的に行われます。この処理をお客様のプログラムで行います。ボード内標準版の処理高機能版の処理 ※ ドライバ内部の受信バッファサイズは任意のサイズに指定が可能です。『4.1.7バッファサイズ変更』を参照下さい。

(47)

アプリケーション例受信メッセージ数を確認し、受信メッセージが有れば取り出します。プログラムでの制御手順サンプルプログラムプログラム名プログラム格納先フォルダ 4851_RECEIVE ＜インストール先＞¥言語¥CAN¥4851_RECEIVE ※ 最大値は、CanSetConfig 関数で設定した値です。ステータス取得 CanGetStatus CAN インタフェースのステータスを取得します。変数参照受信メッセージ取得 CanReceiveMessage 受信メッセージを取り出します。一度に複数のメッセージを取り出すことができます。先ほど取得した ulRXBCount を使用し、受信している全てのメッセージを一度に取り出すことも可能です。その場合、格納先の領域の確保には十分ご注意下さい。ボードのクローズ CanClosePort CAN インタフェースを使用不可にします。取得したステータスから必要な箇所を参照します。ステータスは CAN_PORT_STATUS 構造体に格納されています。そのうち、受信メッセージ数を表すメンバは以下の変数です。メンバ内容 ulRXBCount 受信したメッセージ数 0∼最大値※ これ以外のメンバ変数はここでは参照しませんが、状況に応じて参照して下さい。 ulRXBCount 1 以上？ YES

(48)

44 4.1.5.受信フィルタ設定 指定可能製品弊社 CAN インタフェースシリーズ全製品動作説明多くの CAN メッセージが CAN バス上を流れているとき、全てのメッセージを取り込むと件数が膨大になります。そのようなときに、受信フィルタ機能を使用すると、特定の条件を満たす CAN メッセージだけを受信する事ができます。条件を満たした CAN メッセージは受信バッファに蓄えられますが、条件を満たさなかった CAN メッセージは破棄されます。ただし、ACK は返します。動作図端末 A CANバス端末 B 受信フィルタに設定された条件を満たすメッセージのみ、フィルタを通過し、 CAN インタフェースに取り込まれます。データ送信 ID:11011000001 データ受信データ送信 ID:00011000001 受信されない IDの上位5ビットが “11011” のフレームだけ受信する受信フィルタ

(49)

アプリケーション例受信フィルタを設定し、特定のメッセージだけを受信するようにします。プログラムでの制御手順サンプルプログラムプログラム名プログラム格納先フォルダ 4851_FILTER ＜インストール先＞¥言語¥CAN¥4851_FILTER ステータス取得 CanGetStatus CAN インタフェースのオープンなどを行っておきます。フィルタ設定 CanSetAcceptanceFilter 各種処理受信メッセージを取り出すなどの処理を行ってください。ボードのクローズ CanClosePort CAN インタフェースを使用不可にします。 dwAcceptanceCode と dwAcceptanceMask の二つの変数でフィルタの設定を行います。（次頁で詳しく解説しております）変数名内容 dwAcceptanceCode 該当するビットに期待する値をセットします。 dwAcceptanceMask そのビットをフィルタの条件に使うかどうかを選択します。 0…フィルタ条件に使用する 1…フィルタ条件に使用しない設定後、通信を開始します。通信開始 CanActivate

(50)

46

dwAcceptanceCode と dwAcceptanceMask の関係

図で表すと以下のようになります。（シングルフィルタで標準フォーマットを使用している場合） 0 0 0 0 1 1 1 1 1 1 1 1 ・・・ 0 1 1 1 0 0 0 0 0 0 0 0 ・・・ dwAcceptanceCode dwAcceptanceMask dwAcceptanceMaskにセットされた値で、使用するビットを決めます。 0・・・フィルタに使用する 1・・・フィルタに使用しない 0 1 1 1 ・・・比較用の値この二つの変数を合わせて、フィルタを通過する為の条件を設定します。計算すると・・・このようになります 0 1 1 1 0 1 1 1 0 0 1 0 ・・・ 0 0 1 1 0 1 1 1 0 0 1 0 ・・・ ○ ○ ○ ○ ○ × ○ ○ 受信したメッセージが以下の場合。。受信したメッセージが以下の場合。。一致しているので受信されます一致していないので破棄されます 図 4-2 dwAcceptanceCode と dwAcceptanceMask の関係

(51)

使用できるフィルタの種類

dwAcceptanceCode、dwAcceptanceMask は、CanSetConfig 関数で設定する CAN_PORT_CONFIG 構造体の ulFilterMode 及び、使用するフレームフォーマット（標準/拡張フォーマット）により、内容が異なります。 ulFilterMode が CAN_SINGLE_FILTERの場合 1 種類のフィルタを設定することが可能です。 ●標準フォーマット 11 ビット ID 全てに対しフィルタを設定することが可能です。また、データバイトの先頭 2 バイトに対してもフィルタを設定することが出来ます。 表 4-4 標準フォーマット時のフィルタ適用範囲 ←フレームの先頭 ID（11 ビット） RTR 1 バイト目データ 2 バイト目データ 3 バイト目 28 27 26 … 20 19 18 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 フィルタの適用範囲

ビット(※1) bit31 bit30 bit29 bit28 bit27 bit26 bit25 bit24 ID.28 ID.27 ID.26 ID.25 ID.24 ID.23 ID.22 ID.21 フィルタ対象

ID.28∼ID.21

ビット bit23 bit22 bit21 bit20 bit19 bit18 bit17 bit16

ID.20 ID.19 ID.18 RTR 0 0 0 0

フィルタ対象

ID.20∼ID.18、RTR 予約(※2)

bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0

フィルタ対象

受信データ 1 バイト目

(52)

48 ●拡張フォーマット 29 ビット ID 全てに対しフィルタを設定することが可能です。 表 4-5 拡張フォーマット時のフィルタ適用範囲 ←フレームの先頭 ID（29 ビット） RTR 1 バイト目データ 2 バイト目∼ 28 27 26 … 2 1 0 0 7 6 5 4 3 2 1 0 フィルタの適用範囲

ID.28 ID.27 ID.26 ID.25 ID.24 ID.23 ID.22 ID.21 フィルタ対象

ID.28∼ID.21

ID.20∼ID.13

ID.12 ID.11 ID.10 ID.9 ID.8 ID.7 ID.6 ID.5

フィルタ対象

ID.12∼ID.5

ID.4 ID.3 ID.2 ID.1 ID.0 RTR 0 0

フィルタ対象

(53)

ulFilterMode が CAN_DUAL_FILTERの場合 2 種類のフィルタ（No.1 フィルタ、No.2 フィルタ）を設定することが可能です。 No.1 フィルタ、No.2 フィルタのいずれか片方のフィルタさえ通過すれば、データは受信されます（No.1 フィルタを通過したデータに、さらに No.2 フィルタを通過させ、両方のフィルタを通過するデータのみを受信するのではありません）。 ●標準フォーマット 11 ビット ID 全てに対し 2 種類のフィルタを設定することが可能です。そのうち No.1 フィルタについては、データバイトの先頭 1 バイトに対してもフィルタを設定することが出来ます。

dwAcceptanceCode、dwAcceptanceMask の bit0∼bit3、および bit16∼bit31 の部分が No.1 フィルタになり、bit4∼bit15 の部分が No.2 フィルタになります。 表 4-6 標準フォーマット時のフィルタ適用範囲 ←フレームの先頭 ID（11 ビット） RTR 1 バイト目データ 2 バイト目∼ 28 27 26 25 24 23 22 21 20 19 18 0 7 6 5 4 3 2 1 0 No.2 フィルタの適用範囲 No.1 フィルタの適用範囲

ID.28∼ID.21

フィルタ No No.1 フィルタ

ID.20 ID.19 ID.18 RTR bit7 bit6 bit5 bit4

フィルタ対象

ID.20∼ID.18、RTR 受信データ 1 バイト目上位 4 ビット

ID.28∼ID.21

(54)

50 ●拡張フォーマット

29 ビット ID のうち、先頭の 16 ビットに対し 2 種類のフィルタを設定することが可能です。 dwAcceptanceCode、dwAcceptanceMask の bit16∼bit31 の部分が No.1 フィルタになり、bit0∼bit15 の部分が No.2 フィルタになります。 表 4-7 拡張フォーマット時のフィルタ適用範囲 ←フレームの先頭 ID（29 ビット） RTR 1 バイト目データ 2 バイト目∼ 28 27 26 … 15 14 13 12∼0 0 7 6 5 4 3 2 1 0 No.2 フィルタの適用範囲 No.1 フィルタの適用範囲

ID.28∼ID.21

ID.20∼ID.13

ID.28∼ID.21

ID.20∼ID.13