問題タブ [jssc]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - Linux の USB 経由のシリアル ポートが予期せず変更される
USB インターフェイスの RS232 経由でワークステーションと通信するカスタム電子デバイスに問題があります。デバイスが接続されるとすぐに、アドレスを受信し、/dev/ttyUSB0
(ランダムに) 受信コマンドを送信した後、デバイスがハングしたように見えます。デバイス イベント ( dmesg
) を調べると、次のエラーが見つかりました。
したがって、明らかにシステムはデバイスの切断/再接続を認識し、デバイスが別のポート、つまり /dev/ttyUSB1
にマウントされ、さらに通信障害が発生します。テスト ベッドを作成すると動作が変わります。完全なアプリケーションを使用している間、エラーは頻繁に発生しないように見えますが、エラーは繰り返し発生します。アプリケーションは jSSC-2.8.0 を使用してシリアル ポートと通信します。アプリケーション全体は Java 8 で記述されており、Restle ライブラリを使用して、いくつかの Web サービスにいくつかの REST 要求を発行します。これらの奇妙な動作の原因は何ですか?
以下の@DarkFalcon コメントに従って追加されました。テストベッドは通常、実際のアプリよりも速くデバイスをポーリングします。これは、テストが他のアプリよりも優れている理由を説明できる可能性があります。
java - jssc は常にタイムアウトします
そのため、JSSC ライブラリを使用してデバイスにコマンドを送信しようとしていますが、まだ成功していません。これは私のコードで、オンラインのいくつかの例から構築されています:
私がそれを実行したとき、私が得た唯一の出力は
デバイスから明らかな応答がありません。しかし、この構成を使用してminicomを使用すると
デバイスは何かを返します。
私は何を間違えましたか?
編集:タイムアウトメソッドで読み込もうとしましたが、メソッドはタイムアウトをスローし続けます。
multithreading - JavaFX+JSSC(Java Simple Serial Connector)スレッド通信
バーコードスキャンプロジェクトに取り組んでいます。バーコード スキャナーを使用してバーコードをスキャンし、スキャナーは Bluetooth 経由でラップトップと通信します。Bluetooth 接続は、シリアル ポート通信としてエミュレートされます。
スキャンしたバーコードを取得して表示する Java デスクトップ アプリケーションを開発しました。UI に Javafx を使用し、オープン ソース ライブラリ JSSC (Java Simple Serial Connector) を使用して、シリアル ポートをリッスンし、スキャンしたバーコードを取得します。ただし、JSSC serialPort が追加/開始されると、新しいスレッドが作成されます。この新しいスレッドは、シリアル ポートをリッスンし、スキャンされたバーコードを取得します。私が望むのは、スキャンしたバーコードを Javafx UI に表示することです。JSSC リスナー スレッドで取得したバーコードを親 Javafx アプリケーション スレッドに送り返す必要があります。
javafx.concurrent パッケージを調査しましたが、JSSC がスレッドの作成を独自のクラスにラップしていて、それを制御できないことがわかりました。誰かがそれに対する解決策を提案できますか? Javafx コントローラー内で JSSC リスナーを開始するためのコード スニペットを次に示します。基本的に、バッファをFXMLラベル変数バーコードに戻すにはどうすればよいですか?
事前に本当に感謝します!
multithreading - JavaFX の同時実行性とタスク (タスクでスレッドを実行)
私は JavaFx/Concurrency を初めて使用するので、Concurrency in JavaFXのチュートリアルを読みましたが、JavaFX Gui でのバックグラウンド スレッドの実装についてまだ少し混乱しています。
いくつかのシリアル デバイス (JSSC-2.8 を使用) とインターフェイスし、それらのデバイスからの応答に基づいて GUI を更新する小さな GUI を作成しようとしています。しかし、メッセージが書き込まれてからデバイスが応答するまでにはタイムラグがあり、任意の時間 Thread.sleep() を使用することは、私がプログラムする信頼できる方法ではありませんでした。代わりに、同時実行パッケージの wait() メソッドと notify() メソッドを (すべての適切な同期と共に) 使用したいのですが、実装方法がわかりません。私が最初にしたことは、タスク内に別のスレッドを作成し、メッセージを書き込んで応答を待ち、いくつかのバインディングを使用して GUI を更新することでした。最後にコードを含めました。実装しようとしている擬似コードの短い形式を次に示します。
しかし、何が起こっているのかというと、wait() を呼び出すとすぐに、アプリケーション全体がアイドル状態になり、(応答が発生してイベントが発生した後) notify() が呼び出されると、レシピで中断したところから続行されません( ) ループ、またはそのことについての startTdk() ループ、それはただのアイドル状態です。スレッドを間違って実装しましたか? wait() を呼び出しているときに、EventDispatch または JavaFX アプリケーション スレッドが一時停止する可能性はありますか?
質問が明確であることを願っています。明確化が必要な場合は、投稿を更新できます。
Pvci クラスは含めません。これは Tdk クラスの単なるコピーですが、そのマシンと通信するための特定のメッセージ シーケンスを備えているためです。
java - COM ポートを要求すると、同じ要求が返されます
COM ポート経由で AT コマンドを送信しようとしていますが、同じコマンドしか受信できません。
ログ:
16:19:21.910 [main] DEBUG SerialConnections.M234Serial - インスタンスの作成..
16:19:21.974 [メイン] DEBUG SerialConnections.M234Serial -送信要求: AT^SCFG?
16:19:23.976 [EventThread COM55] DEBUG SerialConnections.M234Serial - 受信メッセージ: AT^SCFG?
16:19:23.977 [メイン] DEBUG SerialConnections.M234Serial - 終了
私は何を間違っていますか?どうすれば修正できますか?
java - Windows 上の Java 通信ポート - 自動ポート検出
Windows OS でシリアル通信を介してデバイスと通信できるようにする必要があるアプリケーションを開発しています。アプリケーションはJavaで書かれています。jSSC ライブラリを使用しています。(Javax.comm には問題があり、RxTx は非公式の更新を除いて Java 8 をサポートしていません) デバイスは、シリアル ポートを使用して PC に直接接続するか、代わりに USB-to-Serial コンバーターを使用して接続できます。
私の質問: Windows の COM ポートは動的です。これにより、接続する通信ポートを定義する際に問題が発生します。どの COM ポートに接続するかを自動的に判断する方法はありますか?
これまでのところ、私が思いついた唯一の解決策は、すべてのCOMポートをスキャンしてアクティブなポートを探し、このリストを保存してから、ユーザーにデバイスを挿入するように求め、別のスキャンを実行することです.追加のCOMポートは、に接続します。
または、デバイスは特定の「識別」パケットに応答します。各 COM ポートを開いてこのパケットを送信し、応答を評価できます。これには、他のデバイスが短期間ハイジャックされるリスクがあり、理想的ではありません。
java - ポートを閉じて再度開いた後のシリアル ポート通信
外部デバイスとjSSC(java-simple-serial-connector)というライブラリを使ってJavaでシリアルポート通信アプリを書いています。
メッセージを送信してその返信を待った後、一定時間 (2 秒) 後に読み取りがない場合に読み取りを中止するタイムアウトがあります。その場合、ポートは閉じられ、その後のメッセージ交換のために再度開かれます。
私が気付いたのは、何らかの理由でタイムアウトが発生し、ポートが閉じられて再度開かれた場合、ポートからのメッセージの読み取りが妨げられる (つまり、読み取られたメッセージをデコードできない) ことです。デバイスからの前のメッセージがまだ回線上にあり、次の読み取り操作のために着信し続けているように見えます。
私はシリアルポートにあまり詳しくないので、これが当てはまるかどうかは完全にはわかりません。私は(TCP/IP通信のように)自分の側から接続を閉じた後、他の部分によって送信された前のメッセージが破棄されると思います(しかし間違っているかもしれません)。
シリアルポートが閉じてから再度開いた後にどのように動作するかについて、このトピックに光を当てられる人はいますか? アプリケーションで接続を閉じた後も、他の部分 (デバイス) が古いメッセージを送信し続けることは可能ですか?