National Instruments USBtoGPIBを使用して通信しているGPIBデバイスがあります。USBtoGPIBはうまく機能します。
GPIBデバイスが応答しなくなる原因は何でしょうか。デバイスの電源をオフにしてから再びオンにすると応答しますが、プログラムを実行すると最初は応答します。その後、切断され、GPIBデバイスと通信することすらできなくなります。
バッファがいっぱいになりましたか？
別の質問者からのいくつかの詳細
PyVisaでNationalInstrumentsGPIBカード（USBではない）を制御しています。GPIBバス上の計測器は、NewportESP300モーションコントローラです。数時間のセッション中（ESP300へのコマンドの送信およびESP300からの読み取り中）、ESP300はリスニングを停止し、応答しなくなることがあります。すべての読み取りがタイムアウトし、*idn?応答も生成されません。
この状態をクリアする可能性が高い私にできることはありますか？たとえば、IFCラインを運転しますか？
明確なコマンドがあるはずです（のようなものですが"*CLS?"、それについて私を引用しないでください）。私は最初にデバイスに接続するときに常にそれを実行します。次に、適切なタイムアウト期間があることを確認します。私は自分のデバイスで約1秒の動作を見つけました。1秒未満であるため、書き込み後の読み取りを見逃します。ほとんどの場合、タイムアウトは、それを見逃したか、コマンドを返さずに読んでいることが原因です。書き込みの合間にエラーキューのエラーもチェックして、書き込みが実際に正しく行われていることを確認してください。
デバイスがもうリッスンしていない場合、コマンド* CLSでさえ機能しません（これはここに当てはまる可能性があります）。デバイスのステータス（リッスンしているかどうか）に関係なく、デバイスのインターフェイスを強制的にリセットする唯一の方法は、低レベルのgpibバスメッセージ「SelectedDeviceClear」を送信することです（標準のgpibライブラリの関数「ibclr」によって実装されます。例：https ：//www.l-com.com/multimedia/manuals/M_USB-488.PDF 3〜7ページですが、Pythonで同等のものが何であるかわかりません）。このコマンドは、GPIBエラーが発生するたびに使用することを目的としています。私は常にそれを実行しており、問題は発生していません。これがうまく機能するためには、すべてのgpib呼び出しの戻り値も監視する必要があります。通常、人々はそれを行わないため、プログラムがハングするまでエラーに気づきません。
National Instrumentsのハードウェアを使用しているため、バックグラウンドでNI Traceを実行して、プログラムから送信されるすべてのコマンドをチェックできます。トレースで、ハードウェアがハングする原因となるプログラムから送信される最後のコマンドとそのパラメーターを確認してください。