自分自身のネットワーク化テスト機器をコーディングする

はじめに

もし、あなたが手動で部品のバッチテストを行ったことがあるなら、そのプロセスがいかに手間がかかり時間を要するかを知っているでしょう。各テストは、テストしている各アイテムに対して繰り返される基本的なステップに従います。また、これらのステップを代わりに実行するようにプログラムできるテスト機器を使用することの力を理解しているでしょう。つまり、すべてを設定して接続した後、ボタンを押すだけでテストを実行できるのです。コンピューターマウスのクリック一つで全てのテスト機器の設定を自動化することで、さらに時間を節約できます。

しかし、自動テストスイートに追加するためのカスタムテスト機器を作成したい場合はどうでしょうか？このステップバイステップガイドでは、コンピューターの快適さからネットワークテスト機器を設定するためのコードの書き方を示します。

ネットワーク化された自動化は、個々のテスト機器を別々に設定する必要をなくし、将来同じテストを繰り返す必要がある場合に時間を節約します。電源切断や機器の誤操作による電源オフ後の設定の復元が迅速かつ簡単であるというのがボーナスです。

SCPIへの導入

もし、ネットワークテスト機器に不慣れなら、プログラマブル機器のための標準コマンド（SCPI）について知る必要があります。昔、ヒューレット・パッカードは、正しいインターフェースを持つ任意のコンピューターが任意のテスト機器に接続できる標準インターフェースバスのコンセプトを考案しました。このHPIB標準は、General Purpose Interface Bus（GPIB）として知られるようになり、独自のIEEE 488標準指定を持つようになりました。この標準化により、ネットワーク化された各テスト機器は、信号を出力したり測定を実行したりするようにコンピューターからのコマンドに応答できるようになりました。

SCPIは、IEEE-488標準に追加のレイヤーを追加することで、テスト機器のネットワーキングの標準化原則を拡張し、テスト機器が理解できるコンピューターコマンドを規制しました。このアプローチにより、HPが製造したオシロスコープは、Keysightが製造したオシロスコープと同じコマンドに応答するようになりました。コマンドの標準化以前は、同じメーカーが製造した異なるモデルが異なるコマンドに反応することがよくありました。この標準化により、コンピューター上のテスト機器制御プログラムは、任意のメーカーやモデルの実験室機器で動作するため、たとえばネットワーク化されたベンチ電源をより良いモデルに変更しても、制御プログラムを変更する必要がなくなります。

この標準化は、このステップバイステップガイドで書かれた任意のコードが、適切なコンピューターに接続された同じネットワークテスト機器タイプを持つ他のラボで動作することを意味します。

SCPIへの導入

SPCIコマンドは、読んで理解しやすいシンプルなASCII文字列の形式であります。例えば、テスト機器に対して「*RST」というコマンドを送信すると、それをリセットします。「*WAI」というコマンドを送信すると、待機するよう指示します。

SPCIコマンドは、その形式に応じてテスト機器にアクションを実行させたり、情報を要求したりすることができます。例えば、「TIM:ACQT 20ms」というコマンドはオシロスコープの取得時間を20msに変更しますが、「TIM:ACQT?」というコマンドは現在の取得時間を返すようにします。

重要な点は、コマンドが大文字小文字を区別せず、省略形をサポートしていることです。したがって、例えば、「TRIG SOUR CH1」と「Trigger source Channel1」は同じコマンドの有効な代替形です。また、コマンドを連結することもできます。例えば、「TRIG SOUR CH1」、「TRIG LEVEL1 10」、「TRIG POL INV」は、「TRIG:SOUR CH1;LEVEL1 10;POL INV」として書くことができ、すべてのコマンドが同じTRIGに適用されます。これらのコマンドはソースチャネル、そのボルト単位のレベル、および極性を設定します。この例では、チャネル1のレベルを10Vに設定し、極性を反転させます。トリガー1を指定する必要はありませんが、曖昧さを避けるために「TRIG1:」を使用することもできます。

コーディングプロジェクト

この記事の付随するビデオは、SCPIコマンドを使用するネットワーク化されたテスト機器を自作する方法を示しています。これは、テスト機器との通信を自動化する方法を示した前のビデオに基づいています。

この演習の目的は、LAN eXtensions for Instrumentation (LXI)やVirtual Instrument Software Architecture (VISA)など、SCPIコマンドを扱うことができる既存のテストソフトウェアにカスタムテストハードウェアをシームレスに組み込むことを可能にすることです。最終的な目標は、マイクロコントローラを自動テストハードウェアに組み込むことにより、包括的で統合されたテストデバイスを開発することです。

プロジェクトの中心にあるのは、産業用途向けに作られたInfineon XMC4700 Relax Kit開発ボードです。このボードには、静的および動的メモリ、クロック、電源、標準インターフェース、基本的なコントロールを備えたマイクロコントローラが含まれています。また、ネットワーキングのためのメディアアクセスコントロール（MAC）アドレスを備えたオンボードイーサネット接続も含まれています。

このセットアップの主な利点は、Infineonが提供するDigital Application Virtual Engineer (DAVE)統合開発環境の利用可能性です。DAVEは、マイクロコントローラアプリケーションのためのCベースのソフトウェア開発およびコード生成ツールです。これにより、コーディングプロセスが簡素化され、SCPIコマンドの実装に集中できるように、ほとんどのセットアップタスクを便利に処理できます。

作成するテストコードは、ボタンの位置を読み取り、LEDの状態を制御します。この単純なテストは、理解しやすい例を提供し、自動テストの力と利点をさらに探求するための素晴らしい出発点となります。

ステップバイステップのコーディングガイド

プロジェクトのセットアップ：

新しいプロジェクトにDAVEツールを使用する場合、最初のステップは「File -> New -> DAVE Project」のコマンドシーケンスを使用して新しいプロジェクトファイルを作成することです。この操作により、新しいウィンドウが表示され、「DAVE CE Project」オプションを選択し、適切な名前を付けることができます。

次に、ターゲットハードウェアを選択する必要があります。この場合は、XMC4700 Relax Kitです。

プロジェクトがリソースに制約を受けることがない限り、ナノサイズオプションよりもフル機能のnewlib標準ライブラリを使用することが常に良い習慣です。

次のステップは、「DAVE -> Add New APP」コマンドを使用してプロジェクトの周辺機器を設定することです。

最初に設定する構成はネットワーク接続であり、「Ethernet -> ETH_LWIP」コマンドを使用して、このインターフェースを処理するためにプロジェクトに軽量インターネットプロトコル（IP）スタックを追加します。

また、この例ではテスト機器の入出力（IO）インターフェース、ボタン、およびLEDインジケータを追加する必要があります。両方とも離散コンポーネントであるため、Systemコマンドオプションの下に「DIGITAL_IO apps」を2つ追加する必要があります。1つは各要素に対してです。

IOアプリの名前をその機能を識別できるように変更することは、誤って間違ったアプリにアクセスするのを防ぎ、作業を容易にするための良い習慣です。このエラーは、予期しない動作をするテストプログラムをデバッグしようとするときに、見つけるのが難しい場合があります。

また、「ETH_LWIP App」を右クリックして「Configure APP Instance」をクリックすることで、Ethernet接続のIPスタックを設定する必要があります。XMC4700 Relax Kitはすでに事前設定されているため、時間を節約できます。自動テスト用に使用しているコンピュータのサブネットに合わせて、IP設定ページで静的IPアドレスを変更する必要があります。また、この例ではユーザーデータグラムプロトコル（UDP）は必要ないため、プロトコル設定タブでこれを非アクティブ化できます。

最後に、各コンポーネントの手動ピン割り当てオプションを使用して、APPピン設定とマイクロコントローラハードウェアの間のマッピングを提供する必要があります。離散ボタンを設定するには、ボタンを右クリックして「Manual Pin Allocator」コマンドを選択します。

次に、ドロップダウンメニューからRelax Kitのボタンに適切なピン番号を選択できます。これは、ラベルを提供して直感的に行えるようにする便利な機能です。LEDとEthernet接続の設定も同じプロセスに従います。ピンアロケータ機能は、必要な機能を持つピンのみを選択できるようにすることで、このプロセスを簡素化します。ツールは自動的にすべてのXMC4700 Relax Kitのラベルを提供して、これを直感的に行えるようにします。

これらのステップで自動テストプロジェクトの設定が完了し、テストコードを書く準備ができました。

プロジェクトアプリコーディング

アプリのコードは、DAVEツールバーの「Generate Code」ボタンをクリックするだけで生成でき、操作が完了するのを待つだけです。

いきなりコーディングを始める前に、マイクロコントローラからコンピュータへコンソールを転送し、簡単に`printf`アクセスを提供することをお勧めします。これにより、データのフォーマットと印刷が可能になり、コードの記述とデバッグが迅速かつ容易になります。「GDB Semi-Hosting」を設定で有効にすることでこれを行うことができます。「プロジェクトのプロパティ」に移動し、「C/C++ ビルド」に進んでから「設定」を選択します。

「ARM-GCC, C リンカー, その他」の下で、「その他」のフラグに「–specs=rdimon.specs」を追加する必要があります。このステップはリンカーのセミホスティング設定を組み込みます。

次に、「ARM-GCC C コンパイラ, プリプロセッサ」セクションに移動し、「XMC_DEBUG_ENABLE」という新しく定義されたシンボルを追加します。この設定は、デバッグビルド構成でのコンソールのリダイレクトを保証します。

プロジェクト設定の下で、「ARM-GCC C リンカー, 一般」設定の「default newlib system calls」のチェックボックスをオフにする必要があります。これをチェックしたままにしておくと、モニターハンドルの初期化が中断され、ビルドが失敗する原因となります。

次に、モニタリングを初期化する必要があります。これは、コードの最初に「extern void initialise_monitor_handles(void);」を追加することで行うことができます。この関数は、DAVE_Init();の呼び出し後に呼び出す必要があります。

「initialise」のスペルは、ARMの基盤がイングランドのケンブリッジにあるため、イギリス英語のバリアントです。米国のスペルを使用すると、微妙なスペルの違いに気づかない場合に解決が困難なエラーが発生します。

プロジェクトネットワーキングコーディング

イーサネットネットワークを動作させる最初のステップは、軽量IPスタックを有効にして、新しいメッセージを定期的にチェックするようにすることです。これは、初期化が完了した後に実行される無限ループ内で「sys_check_timeouts();」関数を呼び出すことで行うことができます。

この機能は、マイクロコントローラー上で実行するためにデバッグが必要になります。新しいデバッグ設定を作成することでこれを行うことができます。「Set breakpoint at: main」オプションをオフにすることを推奨します。これにより、マイクロコントローラーが起動するとすぐにコードが実行されます。デバッグオプションを選択すると、新しいコードがマイクロコントローラーにロードされます。

コードが実行されていることを確認するには、コンピューターでWindowsコンソールを起動し、この例ではXMC4700 Relax Kitである開発ボードのIPアドレスにpingを送ります。開発ボードは各pingに応答し、ボードが動作しており、ネットワーク接続が機能していることを確認できます。

Lightweight IPスタックコードは、インターネット制御メッセージプロトコル（ICMP）機能を自動的に処理します。しかし、着信するトランスミッション制御プロトコル（TCP）接続とデータを処理するコードを作成する必要があります。これは、マイクロコントローラー固有ではない標準のLightweight IPスタックコードステートメントを使用して行うことができます。

ネットワーク接続の設定を完了したので、SCPIコードが通信に使用するポート5025でプロトコル制御ブロックをリッスンするように設定できます。Lightweight IPスタックを設定して、すべての新しい接続をclient_acceptという関数に委任する必要があります。この関数は新しいクライアントを処理するために拡張する必要があります。受信したすべてのデータは、新しい接続の受領を示すデバッグメッセージを出力する別の関数処理にリダイレクトする必要があります。

client_recvメソッドを実装すると、受信したデータが処理用のバッファにコピーされます。この関数は、データがない接続もチェックする必要があります。これは、リモートホストが接続を閉じたことを示します。この状態の場合、コードは閉じた接続によって残された望ましくないアーティファクトを削除するためのクリーンアップアクションを実行できます。

コードのコンパイルは、デバッグするコーディングエラーがない場合、機能的なビルドを生成します。

Project IO Coding

次のステップは、「Digital IO Apps」を必要な操作を実行するように設定することです。

各アプリを右クリックし、「Configure App Instance」オプションを選択します。IOコンポーネントのデフォルト設定は、ボタンに最適なトライステート入力です。しかし、LEDには、「入力/出力」を強いドライブとソフトエッジで設定する必要があります。この強いドライブ設定は、ボードがLEDを点灯させるのに十分なドライブ電流を生み出すことを保証します。ソフトエッジ設定は、ピンのエッジ遷移速度を指します。ソフトエッジは、電力分配ネットワークにおける一時的な影響を和らげ、電磁適合性への悪影響のリスクを減らします。ナノ秒のエッジレートが必要でない限り、離散出力にこのオプションを使用することは良い習慣です。

更新されたコードの再生成は、これらの新しい変更を機能ビルドに追加します。DAVEアプリに変更を加えた後は、常にコードを再生成することが重要です。

プロジェクトSCPIコーディング

設定と初期化機能が完了すると、プロジェクトのコーディングはついにテストのためのSCPIコマンドの実装に移ることができます。SCPIコマンドを一から実装する必要はありません。Jan Breuerによる優れたSCPI-ParserライブラリがGitHub上で利用可能です。

このリソースを活用するには、libscpiフォルダをプロジェクトのLibrariesフォルダに抽出し、次に「examples -> common」からscpi-defフォルダをプロジェクトフォルダに抽出します。このステップはSCPI-Parserライブラリをインポートし、プロジェクトの実装に良いスタートポイントを提供します。

DAVEの統合開発環境内のlibscpiライブラリからtestフォルダとmakefileを削除する必要があります。これらは使用中のARM-GCCライブラリと互換性がありません。

次に、「Build, Settings, Compiler, Directories」の下にあるプロジェクトプロパティウィンドウに戻り、libscpiのincludesフォルダへの参照を追加します。

また、scpi-def.cファイルを開き、「dave.h」のinclude文を追加して、IO関数をscpi-defファイルにリンクする必要があります。

ちなみに、このファイルにはデジタルマルチメーターの素晴らしいデモ実装と自動テスト用の関数が含まれています。残念ながら、これらの関数はこの例で使用されているARMコンパイラと互換性がないため、削除する必要があります。しかし、将来自分の関数を実装する必要がある場合は、参照のために元のファイルに戻ることができます。

ファイルを編集するときは、コマンド設定ブロック内のすべてのDMMおよびテスト関数を削除しますが、TSTコマンドとそれに続くすべてのステートメント、およびライブラリが処理する標準SCPIコマンドのコードは保持します。

テストセットアップの識別情報は「scpi-def.h」ファイルで定義できるため、SCPI *IDNコマンドを使用すると、任意の識別要求に対して有用な情報が返されます。

プロジェクトの「main.c」ファイルでSCPIコマンドを設定できます。メイン関数にSCPIコンテキストをuser_contextプロパティを使用して追加し、Lightweight IPプロトコル制御ブロックへの参照を渡すことでSCPIライブラリの初期化を許可する必要があります。その後、libscpiがネットワーク接続を介して通信できるように関数を追加する必要があります。この例では、次の関数を定義する必要があります：

• 「SCPI_Write」関数は、libscpiがネットワーク接続を介してデータを送信することを可能にします。

• 「SCPI_Flush」関数は、バッファ内のデータを直ちに送信するようにLightweight IPスタックに通知します。

• 「SCPI_Error」関数は、SCPIエラーを処理する手段を提供します。この基本的な例では、printf関数への単純な呼び出しでこれをバイパスできます。

• 「SCPI_Control」関数は、TCPポート5026の制御チャネルに書き込むことを可能にするオプション機能ですが、この例では必要ありません。

• 「SCPI_Reset関数」は、リセットコマンドを受信した際に呼び出され、すべてのテスト機器をデフォルト設定に戻します。この基本的な例では接続されたテスト機器がないため、printf関数への単純な呼び出しでこれをバイパスできます。

最後に、Lightweight IPスタックへの接続を行う際には、新しいクライアント接続のためにuser_contextを設定する必要があります。これにより、client_recv関数を介してバッファからSCPIライブラリにデータが渡され、「SCPI_Input」に処理されます。この実装は複数の接続を同時に処理することはできませんが、良い練習となるネットワーク構成を表しています。

更新されたコードをコンパイルしてマイクロコントローラにアップロードすると、Windowsコンソールからのpingに応答するだけでなく、SCPIコマンドにも応答するテストシステムが得られるはずです。

プロジェクトSCPIコードテスト

この例プロジェクトでは、Rohde & Schwarz VISAテスターアプリケーションを使用してSCPIコマンドをテストしました。

テスト機器にアプリケーションを接続した後、最初のテストは身元確認（IDN?）リクエストを発行することです。これは推奨される最初のステップであり、コマンドはSCPIライブラリによって完全に処理され、通信が操作可能であり、ライブラリが正しく設定されていることを保証します。これは、周辺機器またはテスト機器からの応答を必要とするテストに関連する問題を解決する場合、通信とライブラリがデバッグプロセスで疑わしい原因ではないと仮定できることを意味します。

周辺機器のテストには、必要な機能を実装するために`scpi_commands`配列に新しいパターンを追加する必要があります。機能のデバッグを行うために、“printf”関数の呼び出しを含めることができ、コードの実行を簡単に確認する方法を提供します。

例では、コードは“scpi_result_t IO_Btn“関数を使用してボタンの状態を読み取り、DAVEアプリで以前に設定されたボタンハンドラーを使用して状態を“SCPI_ResultBool”応答を使用して送信します。このボタンはアクティブローのコンポーネントであるため、返される値は反転されます。

LEDハンドラー関数は、受信したボタンの状態パラメータを解析し、適切なLEDの状態を設定します。パラメータが存在しない場合は、この例では何も行われません。このステップでは、“scpi_result_t IO_Led”関数を使用してその機能を実行します。

マイクロコントローラをプログラムした後、DAVEツールのコンソールタブを使用してコードをテストできます。これにより、接続の受領と身元確認コマンドの操作が示されます。

SCPIクエリを送信してボタンの状態を確認し、ボタンを押すと返される状態が変化することを観察することで、機能をテストできます。

LEDの機能は、オンとオフのコマンドを送信し、ライトの状態を観察し、コンソールの状態を監視することで簡単にテストできます。

ボタンとLEDが正しく動作している場合、完全に機能するネットワーク接続型の計測器の基盤を持っています。テスト自動化プラットフォームの接続またはテストコードの記述により、ボタンの状態を遠隔で確認し、LEDを制御できるようになります。

結論

この記事では、開発ボードとDAVE統合テスト環境を使用することで、自分自身のネットワーク化されたテスト機器を作成し、ベンチ機器と統合してラボテストを自動化する方法を示しています。

このステップバイステップガイドは、初歩的な概念実証デモンストレーション用ですが、ステップに従って動作するテストシステムを取得することで、独自のテスト機器を作成するために必要なすべてを装備することができます。

このプロジェクトで探求した原則を使用して、近い将来、実用的なテスト機器を作成しますので、さらなる開発にご期待ください。