タッチディスプレイは開発ベンチでは正常に動作する。機器筐体に組み込んだ後、ガラスに指を触れていないのにボタンが作動する。別の試作機では、電源アダプタを接続すると連続ドラッグが個別のタッチに分断される。いずれの場合もLCD映像は安定している。.
これらの症状は、タッチパネルを直ちに交換することを正当化するものではない。センサー、タッチコントローラー、ホスト接続、ディスプレイ動作、電源システム、および最終組立の制御された比較が必要である。.
最初の作業は、不要な入力がどこで発生するかを特定することである。. タッチコントローラーが報告する誤接触は、正しい接触が誤った画面位置にマッピングされる場合とは異なる調査を必要とする。本ガイドは、OEMのハードウェアおよびHMIチームがこれらの障害を切り分け、再現可能なトリガーを特定し、エンジニアリングレビューに有用な証拠を準備することを支援する。.
1. ベンチではタッチが動作するのに筐体内で失敗する理由
ベンチ試作機と組立済み製品は異なるテスト構成である。組立中に、チームは電源アダプタ、ケーブル経路、カバーレンズ、取付圧力、近接金属部品、および周辺負荷を変更する場合がある。複数の変更が同時に発生した場合、最初の失敗テストではどの変更が重要であるかを特定できない。.
Infineonの産業用タッチスクリーン設計ガイダンスでは、近接する電子機器、ケーブル配線、およびコントローラーと周囲の金属部品の接地が、タッチ性能に影響を与え得る統合要因として特定されている。.[1] これは、緩いパネルでの合格デモンストレーションを最終検証として扱うのではなく、完全な組立品をレビューすることを支持する。.
トラブルシューティングの前に構成記録を作成する。LCDおよびタッチモジュールの型番、コントローラーの識別情報、ファームウェアおよび構成のバージョン、ホストボードのリビジョン、電源、ケーブルレイアウト、およびカバースタックを含める。動作しているベンチ構成と失敗している筐体構成を写真に撮る。.
次に、動作しているベースラインを復元し、可能な場合は一度に一つの変更を導入する。両方向で再現可能な比較が特に有用である。つまり、ある条件を導入すると障害が発生し、その条件を除去すると障害が消える場合である。.
これは関連性を特定するものであり、必ずしも結合メカニズムを特定するものではない。例えば、アダプタの変更は複数の電気的条件を同時に変化させる可能性がある。結論は証拠が許す限り具体的に保つこと。.
2. ゴーストタッチ、座標エラー、および入力喪失の切り分け
“「タッチが不安定」は診断レポートとしては広範すぎる。ユーザーが何を見ているか、および入力システムが何を報告しているかの説明から始める。.
| LCDスポット損傷 | 有用な区別 | 最初に収集すべき証拠 |
|---|---|---|
| ゴーストタッチ | 意図された物理的接触なしに接触が現れる。. | 未接触のテスト期間中のタイムスタンプ付き接触レポート。. |
| 固定座標オフセットまたは回転 | 各実際の接触が一貫しているが誤った位置を生成する。. | 既知のターゲットでのタッチ位置とホストの座標変換。. |
| ジッターまたはドラッグの分断 | 安定した指が移動する座標または繰り返しの接触解放を生成する。. | 再現可能なジェスチャー中の接触ID、座標、および連続性。. |
| タッチの見逃し | 意図的な接触がアプリケーションに到達しない。. | 同じ試行に対するコントローラーレポート、ホストイベント、およびアプリケーション応答。. |
| デバイスの切断またはリセット | ホストがタッチデバイスを失うか、それが再起動する。. | バス、ドライバー、および電源ログ(復旧動作を含む)。. |
利用可能な場合は3つの観察レベルを使用する:コントローラー診断、オペレーティングシステムの入力イベント、およびアプリケーション動作。ベンダー診断ツールからのセンサー取得データは、オペレーティングシステムの「raw input」イベントとは異なる。後者は既にコントローラー処理とホストドライバーを通過している。.
Androidのタッチデバイスドキュメントでは、デバイス固有の構成と方向処理について説明されている。したがって、一貫した回転またはスケーリングエラーは、センサー感度を変更する前にマッピングレビューを促すべきである。.[2]
適切なAndroidエンジニアリングビルドでは、 getevent ツールは入力機能とライブイベントを表示できる。そのラベル付きタイムスタンプ出力は、報告された接触とテストトリガーを関連付けるのに役立つ。.[3]
getevent -lpこれらを必要な権限でエンジニアリングシェルを通じて実行する。実際のタッチスクリーンイベントノードを特定すること。; eventX はプレースホルダーであり、固定されたデバイス名ではない。短い無接触期間を記録し、その後に既知のジェスチャーを続ける。対応するタッチイベントなしにアプリケーションがボタンを作動させる場合、そのイベント処理と他の入力ソースを調査する。.
ホスト入力層で誤接触が実際に現れる場合、上流に進む。その観察だけでは、センサーノイズとコントローラー、ドライバー、またはレポート障害を区別できない。.
3. ディスプレイおよび電源システムからのノイズの特定
静電容量式タッチセンシングは、センサーでの電気的結合の変化を検出する。ディスプレイおよび電源回路はそのプロセスに干渉する可能性がある。MicrochipのmXT640Uドキュメントでは、充電器ノイズとディスプレイノイズ抑制について明示的に論じており、これらが認識されたコントローラー設計上の懸念であることを示している。.[4]
これを、特定のソースが障害を引き起こした証拠としてではなく、可能性のあるソースをテストする理由として使用する。安定したLCD映像は、その電気的活動が隣接するタッチシステムにとって無害であることを証明するものではない。.
輝度と映像アクティビティの分離
いくつかの意図された輝度設定で固定画像を実行する。次に輝度を一定に保ち、静的コンテンツと代表的な画面更新を比較する。報告された接触および利用可能なコントローラーノイズ指標を記録する。.
障害が輝度変化に追随する場合、タッチデータとともにバックライトドライバーとその制御動作をレビューする。画面更新に追随する場合、ディスプレイ関連の経路を調査する。どちらの比較も単独では、PWMまたは特定のディスプレイ信号が原因であることを証明しない。.
電源、ケーブル配置、タッチファームウェア、筐体状態を含む残りの構成を固定に保つ。「画面オフ」が黒画像、バックライトオフ、または電源切断されたディスプレイのいずれを意味するかを文書化する。これらの条件は互換ではない。.

承認された電源構成を比較する
製品がバッテリー動作とアダプター動作の両方をサポートする場合、同一ワークロード下でそれらのモードを比較する。そうでない場合は、電圧、電流容量、および必要な電気的保護を維持したまま、適切な承認済み電源を比較する。障害が連続的に発生するか、接続時および負荷遷移時にのみ発生するかを記録する。.
電源の比較はトリガーの絞り込みに役立つ。それに続いて、タッチコントローラーの電源および関連する基準点を含む、設計に適した測定を実施する。遠隔のコネクターで測定された電源電圧は、コントローラーにおけるすべての条件を表すものではない。.
周辺機器の動作を意図的に導入する
代表的な負荷を個別にテストする:リレーの遷移、モーター動作、無線送信、または製品で使用されているその他のサブシステム。記録に各アクションの時刻を記す。繰り返されるアクティブ期間と非アクティブ期間を比較する。.
タッチ障害を消すために保護アースを切断したり、必要な絶縁をバイパスしたりしないこと。そのような結果は製品の電気的保護を変更するものであり、有効な生産解決策とはならない。.
4. グラウンディング、ケーブル配線、および機械的統合のレビュー
組立後にのみ障害が発生する場合、まずコントローラーのしきい値を変更することは避ける。故障した構成を保持し、組立によって何が変わったかを検査する。.
リファレンスパスとリターンパスを文書化する
回路図およびコントローラー統合指示書を使用して、シグナルグラウンド、シャーシ接続、シールド、および存在する場合は保護アースを特定する。実際の試作機においてそれぞれがどのように接続されているかを記録する。これらを別個の設計責任として扱う。.
接地されたベンチ計測器や接続されたラップトップもテスト配置を変える可能性がある。測定または診断接続が症状を変化させた場合、接続されている機器を記録する。そうでなければ、チームは気づかないうちに2つの異なる電気的構成を比較している可能性がある。.
一時的な変更には、定義された目的と文書化された接続が必要である。症状が改善した場合、提案された生産実装が製品の電気的アーキテクチャと互換性があることを確認する。「グラウンドを増やす」は完全な設計指示ではない。.

他のすべてを変更せずにケーブル経路を比較する
タッチFPCまたはケーブルを、ディスプレイケーブル、電源配線、およびスイッチング部品の隣に配置して撮影する。アセンブリが許容する場合、同じケーブルとコネクターを使用して制御された代替経路をテストする。ケーブル長、シールド、およびファームウェアを同時に変更することは避ける。.
代替経路が改善に寄与する場合、元の経路を繰り返して関連性を検証する。コネクターの装着状態および取り付けを含む物理的配置を報告書に保持する。再現できないテストは、サプライヤーレビュー中に使用することが困難である。.
生産カバーと取り付けを確認する
取り付けられたカバーレンズ、接着剤または接合層、クリアランス、サポート、および締結具を承認済み組立設計と照合して検査する。組立によって目に見える歪み、意図しない接触、またはコネクターのひずみが生じていないかを確認する。.
可能な限り機械的変更と電気的変更を分離する。例えば、エンクロージャー電子機器が動作する前にカバーを取り付けた状態を比較し、次に電子機器を動作させた状態で繰り返す。これにより、取り付け効果が電磁ノイズと誤って分類されることを防ぐのに役立つ。.
便利な代替品ではなく、生産アセンブリを検証する。より広い選定要件については、RJYの タッチスクリーン付きTFT LCDモジュールガイドを参照.
5. コントローラーチューニングが適切な場合の判断
チューニングは、コントローラーが必要な調整をサポートし、診断証拠がその目的を説明し、チームが結果として生じるトレードオフを検証できる場合に適切である。まず、電源、接続、センサーアセンブリ、およびホストマッピングが正しいことを確認する。.
MicrochipのmXT640Uは、モデル固有の取得フィルタリングおよびノイズ抑制機能を提供する。そのドキュメントには、一部のグラウンディング関連の信号劣化に対する補償についても記載されている。.[4] これらの例は、コントローラーの識別が重要である理由を示している。別のコントローラーまたはRJYモジュールが同じ機能を持つことを証明するものではない。.
| サポートされている場合の可能な調整 | 回答すべき質問 | 再テストすべき動作 |
|---|---|---|
| 検出しきい値 | 不要な変動が接触として受け入れられているか? | 意図的な軽いタッチ、エッジ、および必要な手袋。. |
| フィルタリングまたはデバウンス | 短時間の不要な報告を拒否できるか? | 応答遅延、短いタップ、およびジェスチャーの連続性。. |
| 取得頻度またはタイミング | コントローラーがサポートする取得変更は、測定された動作を改善するか? | 完全な動作範囲およびその他のノイズ源。. |
| ベースラインまたは再キャリブレーション設定 | リファレンス状態が正しく確立および維持されているか? | 起動、アイドル期間、環境変化、および持続的接触。. |
| 接触抑制機能 | 不要な接触タイプを区別できるか? | すべての意図されたジェスチャーおよび同時接触。. |
この表はレビューフレームワークであり、保証された制御のリストではない。コントローラーサプライヤーに、どのパラメーターが利用可能で、それぞれが何を変更するかを問い合わせる。異なるセンサー形状からレジスタ値やしきい値をコピーしないこと。.
すべての構成バージョンを復元可能に保つ。1つの設定または1つの文書化されたパラメーターグループを変更し、以前のファイルを保存し、理由を記録する。結果を元の障害と正常なタッチタスクの両方と比較する。.
すべての接触を抑制すると、ゴーストタッチは排除されるが、インターフェースが使用できなくなる。意味のある結果は、必要な条件下での正確な入力である。チューニング変更は、その変更によって最も弱くなる可能性が高いオペレーター操作を含め、その結果を維持しなければならない。.
6. 再現可能なタッチ検証マトリックスの構築
検証を拡大する前に、疑わしいトリガーを再現可能なテストに変換する。修正が提案されたら、より広範なマトリックスを使用して、改善が持続し、別の障害を生じさせないことを確認する。.
| 変数 | カバレッジ | 記録 |
|---|---|---|
| 電源 | 承認された各アダプタおよび対応するバッテリーモード。. | 電源識別情報、負荷、タッチ結果。. |
| 表示状態 | 文書化されたオフ状態、静的UI、および代表的な更新。. | 輝度および正確な表示アクティビティ。. |
| 周辺機器負荷 | 必要な無線、アクチュエータ、およびスイッチング負荷。. | アクティビティのタイミングおよび関連する入力障害。. |
| アセンブリ | 動作ベースラインおよび意図された生産筐体。. | カバー、実装、ケーブル経路、および構成変更。. |
| オペレータ操作 | 非タッチ間隔、タップ、ホールド、エッジターゲット、ドラッグ、および必要なジェスチャ。. | 誤報告、見逃しアクション、座標挙動、および連続性。. |
| 使用条件 | 必要な手袋、承認された清掃条件、および指定された環境状態。. | 正確な条件および合否結果。. |
| 状態遷移 | 起動、許容される電源変更、アイドル復帰、および対応するスリープ/ウェイク。. | 障害発生および復旧挙動。. |
試験前に合否基準を定義すること。意図しない接触の観察間隔、意図的なアクション数、許容座標誤差、および応答要件を指定すること。これらは製品ワークフローから選択し、普遍的な標準を考案してはならない。.

回数とコンテキストの両方を保持すること。「定義されたエッジターゲット試験中の2回のタップ見逃し」は「タッチはおおむね動作する」よりも有益である。同様に、失敗が発生しなかった場合も試行回数と条件を報告すること。クリーンな実行はその実行で何が起きたかを確立するものであり、すべての条件におけるリスクゼロを意味しない。.
手袋および湿潤表面の要件には、明示的なプロジェクト検証が必要である。マトリクスへの記載は、すべての静電容量式タッチスクリーンがそれらをサポートすることを意味しない。RJYの AndroidタッチおよびHDMIタッチ統合ガイド を、ホスト入力ルーティングと分離された映像/タッチ接続もレビューする必要がある場合に使用すること。.
7. サプライヤエンジニアリングレビュー用の証拠を準備する
サプライヤには、再現可能な障害と既知の構成が必要である。タッチコントローラおよびファームウェアの識別情報、LCDモデル、ホストリビジョン、オペレーティングシステムビルド、電源、組立写真、および正確な再現手順を提供すること。.
利用可能な場合は同期された証拠を添付すること:画面録画、入力イベントキャプチャ、コントローラ診断エクスポート、および関連する電力測定。各ファイルが何を表すかを特定すること。処理済みの接触ログをセンサ取得トレースとして提示してはならない。.
説明用の報告形式であり、RJYの試験結果ではない: 組み立て済みHMIを非タッチの状態で、定義されたアダプタ給電試験中に意図しない接触報告が発生する。同じソフトウェアおよびケーブル配置をベースライン比較に使用する。試行回数、イベントタイムスタンプ、電源詳細、コントローラ構成、および写真を添付すること。元の条件に戻したときに障害が再発するかどうかを記載すること。.
役に立たなかった変更も含めること。これにより作業の重複を防ぎ、提案された調整変更が観察されたメカニズムに対処しているかどうかを判断しやすくなる。確認された根本原因を主張することなく、一時的な改善を記述すること。.
次の試験およびその期待される証拠について合意すること。これは、不特定の「より高感度」または「より耐ノイズ性の高い」パネルを要求するよりも強力なエンジニアリングハンドオフである。.
8. FAQ
ゴーストタッチは常にタッチパネルの欠陥を意味するのか?
いいえ。意図しない接触は、センシング干渉、コントローラ構成、組立、または報告障害に関係する可能性がある。どのコンポーネントを交換する必要があるかを判断する前に、コントローラ診断、ホスト入力イベント、およびアプリケーション挙動を比較すること。.
タッチスクリーンがバッテリーでは動作するがアダプタでは失敗するのはなぜか?
アダプタ給電構成は、ノイズおよび電気的結合条件を変化させ得る。再現可能な比較は有用なトリガを特定するが、メカニズムおよび有効な修正を確立するには依然として測定が必要である。.
固定されたタッチ座標オフセットは通常ノイズ問題か?
一貫したオフセット、スケーリング誤差、または回転は、まず座標マッピングおよび表示関連付けのレビューを促すべきである。センサ設定を変更する前に、報告された位置を既知のターゲットと照合すること。.
より強力なフィルタリングはトレードオフなしにゴーストタッチを除去できるか?
必ずしもそうではない。コントローラおよび設定によっては、フィルタリングが応答時間または意図されたジェスチャに影響を与える可能性がある。調整後にショートタップ、連続ドラッグ、エッジ操作、およびすべての必要な入力条件を検証すること。.
すべての静電容量式タッチスクリーンが同じグラウンディングおよびチューニング設定を使用すべきか?
いいえ。正しい設計は、センサ、コントローラ、カバースタック、筐体、電源システム、およびホストに依存する。該当する統合手順を使用し、完全な製品構成を検証すること。.
RJYと埋め込み型タッチディスプレイについて相談する
RJY Displayは、プロジェクトの実現可能性に応じて、タッチ、カバーガラス、コントローラボード、ファームウェア、および機械的調整を含む、既存のディスプレイモジュールに基づくカスタマイズをサポートする。. タッチディスプレイ統合要件を提出してください モジュール詳細、筐体情報、動作条件、および再現可能な障害証拠を添えて。具体的なコントローラ機能および適応範囲はプロジェクトごとに確認が必要である。.
参考文献
メーカー資料は特定された製品または設計ガイダンスを記述するものであり、RJYモジュールにおける同等機能を確立するものではない。上記の診断手順および試験マトリクスは提案されたエンジニアリング手法であり、報告された製品試験結果ではない。.
