現在、PCとPLC間のシリアル通信にて、受信データの欠損が発生しております。  
ソフト上のログにて受信データを確認しますと、必ず最初の16Byteは受信出来ていることが分かりました。  
対策としてFIFOバッファ内のデータをメインメモリに移動する割り込み優先度を上げて検証してみました（レジストリのPriorityControlにて、DWORD32ビット値を新規追加し、対象のCOMポートの優先度を
"2" に設定）。

参考サイト：  
[WindowsのRS-232Cシリアル通信で受信データに欠落が発生する](https://gabekore.org/windows-
rs232c-deficit-recv-data)

上記対応で大きく改善はしましたが、受信データの欠損はまだ発生が見られます。  
そこで質問ですが、

  * 上記設定にて、優先度を "3" に上げると何か問題等発生する可能性はあるのでしょうか？
  * 他に対策等あれば教えていただけないでしょうか？

宜しくお願い致します。

下記、追記致します。宜しくお願い致します。

# 追記

  * 使用言語 C#
  * baurate 115200
  * タイムアウト値 1秒
  * PLC オムロン 型式は直ぐには分かりませんでした。

# コマンド送信プログラム

```

     //' ﾊﾞｯﾌｧ ｸﾘｱ
                try
                {
                    Obj.DiscardOutBuffer();    //送信バッファのクリア
                    Obj.DiscardInBuffer();     // '受信ﾊﾞｯﾌｧ ｸﾘｱ
                }
                catch (Exception exp)
                {
                    return -1;                       //' [NG] 送受信ﾊﾞｯﾌｧ ｸﾘｱ
                }
    
                 myComStatusParams.Serial.PLC.ReceiveData = "";      //' 受信ﾃﾞｰﾀ ｸﾘｱ
    
                ////FINSｺﾏﾝﾄﾞ送信
                 rtn = SerialDataSend(ref Obj, strCommand);
                     if(rtn==false)
                    return -2;
    
                myComStatusParams.Serial.PLC.TickCount = 0;    //' ﾀｲﾑｱｳﾄ監視ｶｳﾝﾀ初期化
                return 1;
    
    # 受信プログラム
     ①private void SerialPortStage_DataReceived(object sender, 　　System.IO.Ports.SerialDataReceivedEventArgs e)
            {
                Serial.myComStatusParamsStage.Serial.PLC.ReceiveData += SerialPortPLC.ReadExisting();
            }
    　②  private void SerialPortStage_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
            {
                do
                {
                    string StrLDReceiveData = "";
                    string Delimiter = "\r\n";
    
                    do
                    {
                        //1byteずつ受信(１文字ずつ)
                        StrLDReceiveData += ((char)(SerialPortPLC.ReadChar())).ToString();
                    } while (StrLDReceiveData[StrLDReceiveData.Length - 1] != Delimiter[Delimiter.Length - 1]);
                } while (SerialPortPLC.BytesToRead != 0);
            }
    
```

①、②の受信方法でデータ欠損の発生状況を確認しましたが、①②においても発生状況は変わりませんでした。  
（ただし、②の方法では、割り込み優先度を上げる対策を行っての検証は実施していません。）

【追記】  
GUIアプリケーションです。  
送信は専用スレッドで動かしています。  
上記、受信のイベントハンドラはメインスレッド上です。
CC BY-SA 4.0
2019-05-09T10:37:15.647
54862
2019-05-10T12:53:33.623
2019-05-10T08:42:07.913
34247
32748
question
シリアル通信
シリアル通信時の受信データ欠損について
提示された部分程度のプログラムでは、データの取りこぼしが発生するほどの負荷は無いでしょう。  
DataReceivedハンドラでどちらの方法を取っても状況が変わらないことが、それを示しています。

強いて言えば、以下の点が気になるところです。

  * 「タイムアウト値 1秒」は、PLC装置の仕様書等に記載された、根拠のある数値ですか？
  * 入出力バッファをクリアしてから？コマンド送信を行っているようですが、これでデータが削除されることはありませんか？ つまり、コマンドを送信しない限り、PLCからのデータが発生することは無い、ということが保証されていますか？
  * 前のコマンドに対するデータ受信が完了する前に次のコマンド送信を行っていませんか？
  * ご自身の紹介先記事にあるように、.NETの受信バッファ[SerialPort.ReadBufferSize Property](https://docs.microsoft.com/ja-jp/dotnet/api/system.io.ports.serialport.readbuffersize?view=netframework-4.8#System_IO_Ports_SerialPort_ReadBufferSize)のサイズは十分に取られていますか？(発生する可能性のある受信データの最大長以上のサイズになっていますか？)
  * [ErrorReceived](https://docs.microsoft.com/ja-jp/dotnet/api/system.io.ports.serialport.errorreceived?view=netframework-4.8)は実装されていますか？ それが呼ばれている、ということはありませんか？
  * ②の方法を取るなら、1文字づつReadCharするより、BytesToReadサイズ分を1回のReadで読みましょう

* * *

他には、質問記事には書かれていない、アプリケーションのこれ以外の部分で以下のような処理が無いかチェックしてみてください。あればそれらがデータ受信に影響無いように対処してください。

  * DataReceivedハンドラの中で画面/ファイル/データベース/サーバー等へのデータ出力を行っている
  * 同じくDataReceivedハンドラの中で複雑な統計処理等を行っている
  * 同じくDataReceivedハンドラの中で何か時間の掛かる処理をLock等の排他状態で行っている
  * 同一アプリケーションまたは同一PCの他プロセスの中で、ある程度データが溜まった等をトリガに、上記に関連する高負荷の処理が行われる

* * *

ちなみに、可能ならばC#のスクラッチでプログラムを作るよりも、メーカーの用意している開発環境/ライブラリ/ツールを使った方が良いと思われます。  
性能・機能に関しては検証済みでしょうし、何か問題があっても対処してくれるはずです。

おそらくこれらのものが関連するソフトウェアではないでしょうか？  
[ソフトウェア -
商品カテゴリ|オムロン制御機器](https://www.fa.omron.co.jp/products/category/automation-
systems/software/)

[FA統合ツールパッケージ CX-One](https://www.fa.omron.co.jp/products/family/1605/)  
[Sysmac Library](https://www.fa.omron.co.jp/products/family/3459/)  
[代官山32（簡易データ収集ソフト）](https://www.fa.omron.co.jp/products/family/62/)
CC BY-SA 4.0
2019-05-10T05:08:56.067
54866
2019-05-10T12:53:33.623
2019-05-10T12:53:33.623
26370
26370
54862
answer