Qt で記述された DLL を使用する LabVIEW 8.6 プログラムがあります。DLL は着信メッセージの TCP ポートをリッスンし、一部の内部データを更新します。私のLabVIEWプログラムは時々DLLを呼び出して内部データを読み取ります。DLL は別の Qt プログラムで完全に動作します (つまり、TCP ポートからデータを受信します)。ただし、LabVIEW プログラムではまったく機能しません。
デバッガを DLL に接続し、LabVIEW からの呼び出しが DLL に接続されているのを確認できます。内部データを取得するための関数が呼び出されており、ステップ実行できます。ただし、TCP からデータを取得するコードは呼び出されません。TCP ポートの着信データの信号がトリガーされないようです。
これは Qt の問題のように聞こえますが、DLL は別の Qt プログラムで完全に動作します。残念ながら、LabVIEW では惨めに失敗します。
一説:
LabVIEWがDLLを呼び出すときにイベントループが実行されていません
- Qt DLL の run() 関数で、socket->waitForDisconnected() を呼び出します。イベント ループが実行されていないため、DLL が着信イベントを処理していない可能性があります。exec() を呼び出してイベント ループを開始すると、LabVIEW がクラッシュします (LabVIEW 8.6 開発システムで問題が発生したため、終了する必要があります。):
AppName: labview.exe AppVer: 8.6.0.4001 ModName: qtcored4.dll ModVer: 4.5.1.0 オフセット: 001af21a
- おそらく、別の Qt プログラムから DLL を呼び出すと、そのプログラムのイベント ループにより、DLL が TCP シグナルを認識できるようになります。残念ながら、DLL でイベント ループを開始すると、LabVIEW が停止します。
LabVIEWが呼び出しプログラムである場合、信号をDLLで実行し続ける方法について何か考えはありますか?
exec() 呼び出しの編集デバッグ トレース:
QThread::exec() -> eventLoop.exec() -> if (qApp->thread() == thread())
in the call to
QObject::thread() {
return d_func()->threadData->thread;
}
2 番目の呼び出しであるマクロ Q_DECLARE_PRIVATE(QObject) がクラッシュを引き起こします。
2009 年 8 月 17 日編集:ステータスの更新
これを機能させるためにさまざまな方法を2日間試した後、LabVIEWにTCPリスナーを直接実装することにしました。私の LabVIEW アプリケーションは、DLL 経由でデータを送信し、TCP 経由でデータを受信します。すべてがうまくいっています。
この質問は、http://forums.ni.com/ni/board/message?board.id=170&thread.id= 431779に相互投稿されました。