tagCANDY CGI VBレスキュー(花ちゃん)の Visual Basic 6.0用 掲示板 [ツリー表示へ]   [Home]
一括表示(VB6.0)
タイトルシリアル通信で異常に時間がかかってしまう
記事No14420
投稿日: 2010/01/26(Tue) 13:13
投稿者ぽると
いつもお世話になってます。
以下の環境にて装置とのシリアル通信処理で通信時間が異常にかかるタイミングが不定期に発生して困っています。

PC1             : 統括用PC
OS              : Windows 2000 SP4
VB              : 6.0(SP6)
PG              : 統括用プログラム
TCP通信         : inetWinsock1.0J TCPコントロール

PC2             : 装置通信用PC
OS              : Windows XP SP2
VB              : 6.0(SP6)
PG              : 装置通信用プログラム
TCP通信         : Winsock コントロール
シリアル通信    : MsComm コントロール

システムの流れとして
@PC1から指令を送信する。TCP通信。
APC2が Winsock_DataArrival で受け取った指令に応じてPC1に装置状態を返したり( Winsock.SendData )、
  装置に命令( MsComm.Output )を送信します。
BPC1がPC2から受け取った内容に応じて、次の指令を出す or 装置状態の取得
@〜Bを繰り返しています。

シリアル通信プログラムの内容です。
シリアルの通信形式はテキストです。コマンド文字列作成や通信ログ出力処理はある程度省いてます。

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Dim mlngDoEventCount        as Long     ' グローバル変数( DoEvents 調査用 )

Dim lobjMsComm              as MsComm   ' MsComm コントロールオブジェクト
Dim lstrSendData            As String   ' 送信データ
Dim lstrReceiveData         As String   ' 受信データ
Dim lintDataLength          As Integer  ' 要求データサイズ
Dim ldatStartTime           As Date     ' シリアル通信開始時間
Dim ldatEndTime             As Date     ' シリアル通信完了時間
Dim i                       as Integer

lstrSendData = <コマンド文字列>
lintDataLength = <コマンドに応じて設定されてます>

For i = 0 To 3                          ' リトライ用ループ
    With lobjMsComm
        .InBufferCount = 0              ' バッファクリア
        .Output = lstrSendData          ' コマンド送信
        ldatStartTime = Now             ' 通信開始時間( ログ用 )
        mlngDoEventCount = 0            ' DoEvents カウンタ( 調査ログ用 )
        
        ' 受信待ち
        Do
            DoEvents
            mlngDoEventCount = mlngDoEventCount + 1
        Loop Until (DateDiff("s", ldatStartTime, Now) >= 10) Or _
                   (.InBufferCount >= lintDataLength)
        
        ldatEndTime = Now               ' 通信完了時間( ログ用 )
        lstrReceiveData = .Input        ' 受信文字列取得
        
        ' 通信ログ出力処理
        If DateDiff("s", ldatStartTime, ldatEndTime) >= 10 Then
            ' タイムアウトログ出力
            ' コールスタックログ出力
            ' 関数呼び出し履歴 mlngDoEventCount も出力して Do〜Loop に制御が
            ' 戻ってきているかもチェック
        End If
        
        ' パリティエラーチェック
        If InStr(lstrReceiveData, "?") = 0 Then
            Exit For
        End If
    End With
Next i
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

ldatStartTime と ldatEndTime の間隔が 10秒以上(ひどい場合だと1000秒とか)になるケースが不定期に発生しています。
タイムアウトログとして送信文字列、受信文字列、受信データ長と要求データ長等を出力していますが、
通信時間が異常にかかっている以外はデータには問題なさそうでした。
コールスタックログとして内部関数の呼び出し履歴を出力しており、そちらを調べたところ、
PC1とのTCP/IP通信による Winsock_DataArrival が連続して発生しており、
上記のシリアル通信プログラムの DoEvents に復帰しなくなっていることがわかりました。
( mlngDoEventCount のカウンタが同じ数値のまま Winsock_DataArrival が連続発生 )

========== コールスタックログ内容抜粋 ==========
0,<シリアル通信関数>
1,Winsock_DataArrival(14), DoEvents = 1000
2,Winsock_DataArrival(14), DoEvents = 1000
3,Winsock_DataArrival(14), DoEvents = 1000
4,Winsock_DataArrival(14), DoEvents = 1000
5,Winsock_DataArrival(14), DoEvents = 1000



================================================

現在、PC1とPC2の通信部分のみを抜き出したテストプログラムを作成しテストを行っていますが、
一向に再現できずな状態です。

以上、状況説明が長くなってしまいましたが、よろしくお願いします。

[ツリー表示へ]
タイトルRe: シリアル通信で異常に時間がかかってしまう
記事No14421
投稿日: 2010/01/26(Tue) 15:57
投稿者GOD
とりあえずDoEventsは使用しない方が良いですよ。
例えばDoEvents中にアプリ終了するとunload後に処理が戻ってきて、コントロールにアクセスした時点で勝手にロードされ、見えないフォームとして裏に残ってしまうことがありますよ。
PC1側のプログラムにはコマンドのリトライ制限はないのですか?また、リトライ処理があるなら正しく動作していますか?(コマンド送出タイミングと回数)
PC2側がわざと応答を返さない時(全コマンドで実験?)は正しく動作してるかな?

[ツリー表示へ]
タイトルRe^2: シリアル通信で異常に時間がかかってしまう
記事No14423
投稿日: 2010/01/26(Tue) 17:36
投稿者ぽると
GODさん
アドバイスありがとうございます。

> とりあえずDoEventsは使用しない方が良いですよ。

ご指摘のとおり、Unload 後に勝手にロードされる問題はありました。
強引ですが、全ての内部タイマーやオブジェクトを解放後に End で終了するようにしています。

> PC1側のプログラムにはコマンドのリトライ制限はないのですか?また、リトライ処理があるなら正しく動作していますか?(コマンド送出タイミングと回数)
> PC2側がわざと応答を返さない時(全コマンドで実験?)は正しく動作してるかな?

PC1とPC2の通信は  TCP/IP  による通信のみで、特にリトライ制限等は設けていません。
PC2側がなんらかの原因でPC1側に応答を返さない場合、PC1側で、異常と判断して知らせる形になっています。

システム構成について、もう少し全体の構成を説明しますと、
PC1を統括用として、そこから命令を受け取り、各装置に命令を送信するPCが複数あります。
PC1と各制御用PCは  TCP/IP  にて装置状態やコマンドをやりとりして、
制御用PCと装置は  シリアル通信  にて通信しています。

(図)
統括用PC        装置用PC
PC1      ⇔  PC2      ⇔ 装置2
            ⇔  PCX      ⇔ 装置X
            ⇔  PCY      ⇔ 装置Y
            ⇔  PCZ      ⇔ 装置Z
            ↑              ↑
        TCP/IP通信      シリアル通信

追記になってしまい恐縮ですが、通信関係のイベントの一覧をまとめました。
通信部分のみを抜粋しています。

'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
'//     PC1( TCP通信タイマー と TCPコントロール )
'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
'// --------------------------------------------------
'//     TCP通信タイマー
'// --------------------------------------------------
Private Sub timerTcp_Timer()
    ' .Interval は 100ms
    timerTcp.Enabled = False         ' タイマー停止
    
    With tcpControl                  ' TCP/IP 通信
        .Timeout = 3000
        
        ' 切断されている時は再接続処理
        If (.State <> tcpConnected) And (.State <> tcpConnecting) Then
            Call .Connect( <PC2>, <通信ポート> )
        End If
        
        Select Case .State
            Case tcpConnected       ' 接続状態ならコマンド送信
                Call .Send( <コマンド文字列> )
            Case tcpClosed, tcpClosing
            Case tcpConnecting
        End Select
    End With
    
    timerTcp.Enabled = True          ' タイマー再開
End Sub

'// --------------------------------------------------
'//     TCP コントロール処理
'// --------------------------------------------------
Private Sub tcpControl_State()
    <接続状態の表示を更新するだけなので省略>
End Sub

Private Sub tcpControl_Receive()
    With tcpControl
        .Timeout = 0
        Call .Receive(mstrBuffer)   ' mstrBuffer は Public 変数
                                    ' 状態判定等の処理は別関数で処理
        .Timeout = 3000
    End With
End Sub

Private Sub tcpControl_Error(ByVal Number As DartSockCtl.ErrorConstants, ByVal Description As String)
    With tcpControl
        .Timeout = 0
        
        If (.State <> tcpClosed) And (.State <> tcpClosing) Then
            Call .Close
        End If
    End With
End Sub

'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
'//     PC2( シリアル通信タイマーと MsComm、Winsock )
'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
Private Sub timerComm_Timer()
    ' .Interval は 100ms
    <前述したシリアル通信処理>
End Sub

Private Sub winsockDaemon_ConnectionRequest(ByVal requestID As Long)
    With winsockClient
        If .State <> sckClosed Then .Close
        .LocalPort = 0
        .Accept requestID
    End With
End Sub

Private Sub winsockClient_DataArrival(ByVal bytesTotal As Long)
    Dim lstrBuffer              As String
    
    winsockClient.GetData lstrBuffer
    
    If (winsockDaemon.State <> sckListening) And (winsockDaemon.State <> sckClosed) Then
        winsockDaemon.Close
    End If
    winsockDaemon.Listen
    
    If (winsockClient.State <> sckConnected) And (winsockClient.State <> sckClosed) Then
        .Close
    End If
End Sub

Private Sub winsockDaemon_Error( <省略> )
    If WinsockDaemon.State <> sckClosed Then .Close
End Sub

Private Sub winsockClient_Error( <省略> )
    If winsockClient.State <> sckClosed Then .Close
End Sub

以上のようなつくりになっています。
DoEvents 方式を排除してしまうのが一番だとは思うのですが、
装置毎に個別のPGがあり、Comm用クラスも個別にカスタマイズが入っているようで、
なんとか最小の変更で対応できないものかと苦心しています。

[ツリー表示へ]
タイトルRe^3: シリアル通信で異常に時間がかかってしまう
記事No14425
投稿日: 2010/01/26(Tue) 21:10
投稿者GOD
PC1→PC2の伝文は可変長になっているのでしょうか?もしそうなら最大長で試してみるのが
いいかもしれません。
あと、伝文の解析部があると思いますが、それはどこから呼ばれるようになっているのでし
ょうか。タイマー内なら今回は大丈夫でしょうが、DataArrivalで呼ばれているのなら、最
長の処理時間は次回のTCP受信に間に合っていますか?(DoEventsから復帰できるだけの余
裕がありますか?)
DataArrivalの処理内で毎回Closeされているようですが、分割して受信することがあるので
1伝文が揃ってからでないと下手をするとコマンドが落ちるかもしれません。
DataArrivalでログとかは出力していませんか?ログのファイルサイズが大きく(数百Mと
か)なっても処理時間に影響はありませんか?

[ツリー表示へ]
タイトルRe^4: シリアル通信で異常に時間がかかってしまう
記事No14426
投稿日: 2010/01/27(Wed) 09:04
投稿者ぽると
> PC1→PC2の伝文は可変長になっているのでしょうか?

PC1→PC2への伝文は14文字の固定長となっています。
PC2→PC1への応答伝文は可変長です。4文字〜130文字。

> あと、伝文の解析部があると思いますが、
> それはどこから呼ばれるようになっているのでしょうか。
> タイマー内なら今回は大丈夫でしょうが、DataArrivalで呼ばれているのなら、
> 最長の処理時間は次回のTCP受信に間に合っていますか?
> (DoEventsから復帰できるだけの余裕がありますか?)

伝文解析処理は DataArrival イベント内にて行っております。
PC1から送られてきた伝文を判断し、応答伝文を作成し、 SendData しています。
その部分の表記が抜けていたようで申し訳ないです。

処理時間が間に合っているかどうかについては、特に意識していませんでした。
早速確認してみようと思います。

> DataArrivalの処理内で毎回Closeされているようですが、
> 分割して受信することがあるので
> 1伝文が揃ってからでないと下手をするとコマンドが落ちるかもしれません。

コマンド落ちについては DataArrival イベント発生時の引数 bytesTotal が 14 で
コールスタックログに記録されているため大丈夫ではないかと判断しています。
また伝文解析処理にてコマンド落ち等でおかしな伝文が送信されてきた場合は、
コマンドエラーとしてPC1側に応答伝文を返しています。

PC2側の DataArrival 処理にて伝文解析処理とSendData部分が抜けていた為
修正しました。

'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
'//     PC2( DataArrival 修正版 )
'// ◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
Private Sub winsockClient_DataArrival(ByVal bytesTotal As Long)
    Dim lstrBuffer              As String
    
    winsockClient.GetData lstrBuffer
    
    If (winsockDaemon.State <> sckListening) And _
       (winsockDaemon.State <> sckClosed) Then
        winsockDaemon.Close
    End If
    winsockDaemon.Listen
    
    If (winsockClient.State <> sckConnected) And _
       (winsockClient.State <> sckClosed) Then
        .Close
    End If
    
    ' 受信した伝文に応じて応答伝文を作成します
    <伝文解析処理>
    
    ' 応答伝文送信( 文字数は可変長4〜130文字 )
    winsockClient.SendData <応答伝文>
End Sub

[ツリー表示へ]
タイトルRe^5: シリアル通信で異常に時間がかかってしまう
記事No14427
投稿日: 2010/01/27(Wed) 10:52
投稿者オショウ
横からすいません・・・

● 私も過去FA関係の装置制御で似たシステムを構築して行って
  おりましたが、たかが数台?の1対多通信でそのようなトラブ
  ルは無かったです。実際のところPC1に相当するサーバー的
  マシンに対し、クライアント側台数は制限なく増設可能な設計
  だった(実際には100台程度)もので。

  問題の切り分けをしないと、上位側(PC・PC間)と、装置
  (PC・装置間)のどちらかに問題があるのか、クライアント
  側イーサ通信とシリアル通信の橋渡し部分に問題があるのか、
  解らないと思います。

  似た構造で小さいプログラムを作り、上位側のイーサ通信機能
  のみの通信実験を行い、また、装置側もシリアル通信機能のみ
  の通信実験を行えば、自ずと見えてくるのでは?

  上位側は現在もタイマーで送信の起点となっていますので、そ
  れでもよいと思います。ただネットワークには遅延・障害は付
  きものなので、タイムアウトするまでの時間と次回タイマーで
  での送信が衝突していないか・・・とか。
  また、ネットワークケーブルやハブの劣化でも異常事態は発生
  しますので、その辺の調査も・・・

  装置側も同様にイーサ通信の受信で行うのではなく、タイマー
  でシリアル通信を行う仕掛けでシリアル通信実験を行い、機器
  との通信が保障できているのか確認する。
  こちらも機器の経年劣化で想定外の通信異常が発生する可能性
  はゼロではありませんので。

  そうしうシステム構造で、24時間稼働の生産ラインを連続数年
  のオーダーで稼働させてますが、異常が発生するのは、強大な
  ノイズ(雷とか、大電力を使う装置の稼働)か、経年劣化によ
  る通信デバイスの異常(熱劣化)で止まることくらいです。

  特にハブやLANカードが壊れやすいでしたが・・・

  たまに機器側シリアル通信の素子が故障したケースもありまし
  たが・・・

  それら異常が重なって、タイムアウトとリトライ動作が重複し
  異常事態を自分で作っていないか?とか・・・

  上位のタイムアウト(この場合イーサ通信の)より下流は全て
  そのタイムアウトより短い時間に設定しないと、重複しますヨ

以上。参考まで

[ツリー表示へ]
タイトルRe^6: シリアル通信で異常に時間がかかってしまう
記事No14428
投稿日: 2010/01/27(Wed) 16:11
投稿者ぽると
オショウさん
アドバイスありがとうございます。

問題の切り分けについては、
ハードウェア障害も考えてPC2は昨年のうちにPC交換しています。
( 交換したPCはシリアル通信単体テスト、TCP/IP単体テスト実施済 )
PC1側に問題がないかどうかはまだ確認が取れていません。
またFAネットワーク全体の通信量や装置側の問題になると私では判断できないので、
そちらの方も調査依頼中です。
調査している段階で判明したことですが、この現象事態は設備稼働当初からあったようです。
その都度PGの再起動等で逃げていたらしいのですが、そんなんじゃだめだろうという事で
今回調査に乗り出した次第です。

> 上位のタイムアウト(この場合イーサ通信の)より下流は全て
> そのタイムアウトより短い時間に設定しないと、重複しますヨ

TCP/IP通信のタイムアウトは3秒、シリアル通信のタイムアウトは10秒に設定されています。
シリアル通信ではそれほど膨大なデータはやりとりしていないので、
この過剰なタイムアウト時間は不要な気はしていたのですが、ここらへんを
見直してみる必要があるということでしょうか。

テストプログラムで調整してみようと思います。

[ツリー表示へ]
タイトルRe^7: シリアル通信で異常に時間がかかってしまう
記事No14429
投稿日: 2010/01/27(Wed) 18:09
投稿者オショウ
> またFAネットワーク全体の通信量や装置側の問題になると私では判断できないので、
> そちらの方も調査依頼中です。
> 調査している段階で判明したことですが、この現象事態は設備稼働当初からあったようです。

  なら、ソフトウェア的な要因・・・ということになりますかネ〜・・・

  ネットワーク上の他の装置・機器が激しく通信しているならばそういう
  こともあります。

  随分昔・・・まだ100Mではなく10Mの通信規格の折、Windowsサーバーで
  NOTESを稼働させていた企業があったのですが、通信量の帯域を測定した
  ら、ほぼ常時6Mくらい食ってました。

  SQL Serverを別に立てたんですが、通信帯域が一杯一杯で、どうにもなら
  ない状態・・・納品したシステムの問題では無かったので検収してもらい
  ましたが・・・

  細かいパケットが大量に飛び交ってますと、スイッチハブの性能で長いパ
  ケットが待たされることが多くなりますし、タイムアウトで再送等が発生
  すればネットワークが破たんする場合があります。

> TCP/IP通信のタイムアウトは3秒、シリアル通信のタイムアウトは10秒に設定されています。

  シリアル通信の方のタイムアウトですが・・・
  コマンドを投げかけて、返信があるまでの時間は、秒単位に必要なんです
  か?私もFA関係長いですが、そういう仕組みの装置だと3秒程度の時間
  が必要なものもありましたが、一般的?には、500msもあれば十分かと。

  どんな装置か解らないので、一概ではありませんが・・・

  TCP/IPも、PING打っての応答時間と、下流側の処理・応答時間を考慮し、
  その1.5倍程度が程度なタイムアウト値かと・・・

  プログラム的なリトライ通信動作を加味しているならば、特に問題にはな
  らないかと。

※ FA的に云えば、リトライ回数や通信エラーのログを出力して、機器や、
  ネットワーク上に何らかの異常が発生した可能性を捕捉することも可能か
  と。通信エラー率は生産ラインでは、出来高・歩留まりに影響しますので。

以上。

[ツリー表示へ]
タイトルRe^8: シリアル通信で異常に時間がかかってしまう
記事No14432
投稿日: 2010/01/27(Wed) 22:24
投稿者るる
はじめまして。
取り合えずソースを見た感じ、受信待ちループ抜けの条件としてタイムアウトとデータ長をされていますが、デリミタ(レスポンスの最後には必ずこの文字が来る)が決っているのであればその文字列が受信データに入っていれば?という条件を入れるのはどうでしょうか?

オショウさんの言うとおりタイムアウト10秒では長いです。実際100msあたりで帰ってくる機器が多いです。(プログラマブルコントローラ、RFIDモジュールなど)

[ツリー表示へ]
タイトルRe^9: シリアル通信で異常に時間がかかってしまう
記事No14435
投稿日: 2010/01/28(Thu) 10:34
投稿者ぽると
るるさん
アドバイスありがとうございます。

> 取り合えずソースを見た感じ、受信待ちループ抜けの条件として
> タイムアウトとデータ長をされていますが、
> デリミタ(レスポンスの最後には必ずこの文字が来る)が決っているのであれば
> その文字列が受信データに入っていれば?という条件を入れるのはどうでしょうか?

ACK、NAK、STXやETX 等でしょうか。
シリアル通信の処理部分でこのチェックがまったくされていないですね。

装置側のシーケンサの資料はあるようですので、
そちらを確認して見ようとおもいます。

現在実施中の作業として
@FAネットワークの通信量のチェック
A装置側の機器異常のチェック
BPC1の異常チェック
CLANやシリアルケーブルの再点検
  (ノイズの影響を受けにくいものを使用しているか等)
DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG )
EACK、NAK等のチェック処理の実装テスト( テストPG )

あまり考えられないですが、
何か理由があってタイムアウト時間やACK等のチェックをしていないかもしれないので
そちらも調べています。

[ツリー表示へ]
タイトルRe^10: シリアル通信で異常に時間がかかってしまう
記事No14437
投稿日: 2010/01/28(Thu) 11:58
投稿者GOD
結局、現象は再現できましたか?
もし、再現ができていないのならPCを3台用意して24時間フル稼働で数日間動作させ
てみてはどうでしょうか。PC3は装置の代わりにシリアル通信の送受信を行うプログラ
ムを用意してあげれば擬似的に環境が整うはずです。

PC1側は通信データのログ(ダンプみたいなやつ)とかありますか?あるならおかしく
なった時間帯のデータを検証するのも有効かもしれません。(本当はPC1とPC2の両方
にあるのが望ましいのですか。)
運用開始からおかしくなるまでの時間。おかしくなっている伝文の個数(伝文に番号があれ
ば)、種類。PC1-PC2の通信時間がどの程度かかっているか。などが検証できますよ。
---- 大体こんなの
時間         IP            送/受 データ部
hh:nn:ss.sss xxx.xxx.xxx.xxx [S] xx-xx-xx ... xx-xx
hh:nn:ss.sss xxx.xxx.xxx.xxx [R] xx-xx-xx ... xx-xx
----

あと、PC2側で画面表示とかしていませんか。

[ツリー表示へ]
タイトルRe^11: シリアル通信で異常に時間がかかってしまう
記事No14439
投稿日: 2010/01/28(Thu) 13:34
投稿者ぽると
テスト環境での再現はいまだに出来ておりません。

現在のテスト環境ですが、幸い装置側と同型のシーケンサを借りれましたので、
PC2台、シーケンサ1台で本番とほぼ同じような構成で実施しています。
24時間フルではなく私が業務している間になりますが、
この構成で稼動させて現象がでないかチェックしています。

@午前はタイムアウト時間とACK等を入れて動作チェック。
  こちらは今後のことを考えてなので再現優先であれは不要なのですが・・・。
A午後は現場環境と同じ設定で動作チェック。

PC1側の通信データログについては現在とっていないので、
上記フォーマットでPC1、PC2に実装してみようと思います。
PC1側の停止日が限られてしまっているため、テスト環境で現象が再現できない場合、
調査に時間がかかってしまうかもしれません。

> あと、PC2側で画面表示とかしていませんか。
PC2側では装置状態を画面表示しています。
シリアルで受信したデータを下に表示を更新しています。
また普段は自動運転なのですが、設備のメンテナンス等で手動で操作する時用に
コマンドボタンやリストボックスもあります。

[ツリー表示へ]
タイトルRe^12: シリアル通信で異常に時間がかかってしまう
記事No14440
投稿日: 2010/01/28(Thu) 15:28
投稿者オショウ
> 現在のテスト環境ですが、幸い装置側と同型のシーケンサを借りれましたので、
> PC2台、シーケンサ1台で本番とほぼ同じような構成で実施しています。

  PCは、シーケンサとシリアル通信するのネ・・・
  三菱?まぁ〜それはいいとして、私もシリアル通信でPLCとやってますが
  時間間隔は、100msで、PLC側メモリを読み込んで事象の変化があれば、
  その内容に従って読み込むエリアを変更したり、メモリに書き込んだりさせ
  てますが、その装置も24時間稼働で300日/年は動いているかナ〜

  ACKやNAK抜けでタイムアウトしたら当然応答停止するんでリトライさせてま
  すが、最初にあったそんな長時間応答が停止するなんてことは考えられなく。

  シリアル通信側での何らかの不具合に上位のイーサ通信の再送等が重なって
  複合的に問題が発生しているのでは?当然、相互のタイムアウト時間の設定
  も影響します。

  PLCならタイムアウト時間は、500msもあれば十分・・・
  ただし、そのPLCのサイクルタイムはどの程度で動いてますか?
  無茶苦茶忙しくて1サイクル数十msもかかっているならば、シリアル通信の
  応答もそれに影響されて遅くなります。

  因みに無手順じゃ〜ないですよね?

以上。

[ツリー表示へ]
タイトルRe^13: DoEventsの挙動
記事No14441
投稿日: 2010/01/28(Thu) 16:50
投稿者GOD
DoEvents の挙動で一つ思い出したのですが、DoEvents 中に 再度 DoEvents を行うと、
2回目の処理が終了しないと1回目の DoEvents には復帰しないようです。
ぽると さんのプログラムで DoEvents 中に DoEvents することはありませんか?

例.↓のサンプルでボタン1クリックの5秒後にボタン2クリック
Private Sub Command1_Click()
    Dim dt As Date
    
    dt = Now
    Debug.Print "Command1_Click in:" & Now
    Do
        DoEvents
    Loop While DateDiff("s", dt, Now) < 10
    Debug.Print "Command1_Click out" & Now
End Sub

Private Sub Command2_Click()
    Dim dt As Date
    
    dt = Now
    Debug.Print "Command2_Click in:" & Now
    Do
        DoEvents
    Loop While DateDiff("s", dt, Now) < 10
    Debug.Print "Command2_Click out" & Now
End Sub

結果として
Command1_Click in:2010/01/28 16:30:05
Command2_Click in:2010/01/28 16:30:10
Command2_Click out2010/01/28 16:30:20  <--- 10秒経過
Command1_Click out2010/01/28 16:30:20  <--- 15秒経過
となります。

[ツリー表示へ]
タイトルRe^14: DoEventsの挙動
記事No14443
投稿日: 2010/01/28(Thu) 17:53
投稿者ぽると
(返信先が混ざってしまいそうなので明記しておきます)
GODさん

DoEvents の挙動のサンプルありがとうございます。

> DoEvents の挙動で一つ思い出したのですが、DoEvents 中に 再度 DoEvents を行うと、
> 2回目の処理が終了しないと1回目の DoEvents には復帰しないようです。
> ぽると さんのプログラムで DoEvents 中に DoEvents することはありませんか?

まさかと思い全検索かけてみたところいくつか DoEvents しているところがありました。
何も考えずに取っ払ってしまいたいですが、とりあえず一つずつ調べてみようと思います。

[ツリー表示へ]
タイトルRe^13: シリアル通信で異常に時間がかかってしまう
記事No14442
投稿日: 2010/01/28(Thu) 17:40
投稿者ぽると
> PCは、シーケンサとシリアル通信するのネ・・・
装置と書いたりシーケンサと書いたりで誤解を招いてしまったようで申し訳ないです。
PC2はシーケンサとシリアル通信を行っています。

> 三菱?
シーケンサは三菱製 A1SJ71UC24-R2 というタイプです。

> PLCならタイムアウト時間は、500msもあれば十分・・・
> ただし、そのPLCのサイクルタイムはどの程度で動いてますか?
> 無茶苦茶忙しくて1サイクル数十msもかかっているならば、シリアル通信の
> 応答もそれに影響されて遅くなります。
サイクルタイムについては明日調査してみようと思います。
やはり無駄なタイムアウト時間の設定は見直した方がよさそうですね。

> 因みに無手順じゃ〜ないですよね?
方式は RS-232C 専用プロトコル 形式4 となっています。

[ツリー表示へ]
タイトルRe^14: シリアル通信で異常に時間がかかってしまう
記事No14445
投稿日: 2010/01/28(Thu) 20:10
投稿者オショウ
> シーケンサは三菱製 A1SJ71UC24-R2 というタイプです。

  Aですか・・・

> 方式は RS-232C 専用プロトコル 形式4 となっています。

  一般的ですが、Aシリーズなので、サイクルタイムが長い場合
  バシバシシリアル通信すると、一気に負荷が発生して応答性が
  低下する場合があります。

※ 各社PLCメーカーは、CPUのサイクルとシリアル通信には
  因果関係がなく通信できると言ってますが、そんなことありま
  せん。経験的に忙しいCPU(ラダー)やサイクルタイムが長
  い処理を行っている場合、シリアル通信の間隔が短い場合や、
  読みだすバイト量が多い場合、応答しなくなると言うか遅延が
  甚だしいです。
  読みだす際の実際のパケット長は何バイトくらいになるんでし
  ょうか・・・

以上。参考まで

[ツリー表示へ]
タイトルRe^15: シリアル通信で異常に時間がかかってしまう
記事No14448
投稿日: 2010/01/29(Fri) 10:26
投稿者ぽると
オショウさん

> 一般的ですが、Aシリーズなので、サイクルタイムが長い場合
> バシバシシリアル通信すると、一気に負荷が発生して応答性が
> 低下する場合があります。
> ※ 各社PLCメーカーは、CPUのサイクルとシリアル通信には
>    因果関係がなく通信できると言ってますが、そんなことありません。
>    経験的に忙しいCPU(ラダー)やサイクルタイムが長い処理を行っている場合、
>    シリアル通信の間隔が短い場合や、読みだすバイト量が多い場合、
>    応答しなくなると言うか遅延が甚だしいです。

そういうことがあるのですね。勉強になります。
サイクルタイムについては来週の月曜日( 2/1 )に確認できることになりました。

> 読みだす際の実際のパケット長は何バイトくらいになるんでしょうか・E・

一度に読み出す指定バイト数は最大の時で 255バイト でした。

[ツリー表示へ]
タイトルRe^10: シリアル通信で異常に時間がかかってしまう
記事No14446
投稿日: 2010/01/28(Thu) 23:27
投稿者るる
ぽるとさんのプログラムは受信データ長ですべてのデータが入ってきたと判断し、まとめて受信データをごっそり取り出す方法ですよね?
そこをデータ長で判断せず、確実に1文字とか数文字毎に取り出しその文字の中に最後の文字であるか?を判定してやる方がいいのかな?と思ったのです。
以下参照。

>ACK、NAK、STXやETX 等でしょうか。
>装置側のシーケンサの資料はあるようですので、
>そちらを確認して見ようとおもいます。
三菱シーケンサは使用した事ありませんが、おそらく最終文字がASCIIコードで言うLF(0x0A)とかCR(0xOD)とかでないですか?いずれにせよ資料を確認する必要がありそうですね。
ちなみにACK,NAKは通信成功、通信失敗を意味する場合が多いです。
STXは通信の始め、ETXは通信の終わりのアクセントとして使われます。


あと、
lstrSendData = <コマンド文字列>
lintDataLength = <コマンドに応じて設定されてます>
ここ。確実にコマンドに対する受信データ長がセットされてますかな?
送信コマンドと受信データ長が本来のと一致しない場合が出てる可能性もあるかも。

[ツリー表示へ]
タイトルRe^11: シリアル通信で異常に時間がかかってしまう
記事No14449
投稿日: 2010/01/29(Fri) 11:05
投稿者ぽると
るるさん

> ぽるとさんのプログラムは受信データ長ですべてのデータが入ってきたと判断し、
> まとめて受信データをごっそり取り出す方法ですよね?
> そこをデータ長で判断せず、確実に1文字とか数文字毎に取り出し
> その文字の中に最後の文字であるか?を判定してやる方がいいのかな?と思ったのです。

MsComm.InputLen = 1
で OnComm にて文字列結合していく手法でしょうか?
今の方法でやはり厳しそうならこっちの方式にするしかないかと思っています。

> 三菱シーケンサは使用した事ありませんが、おそらく最終文字がASCIIコードで言う
> LF(0x0A)とかCR(0xOD)とかでないですか?

資料を確認したところ、今回の設定での通信での最終文字は CR+LF でした。

> あと、
> lstrSendData = <コマンド文字列>
> lintDataLength = <コマンドに応じて設定されてます>
> ここ。確実にコマンドに対する受信データ長がセットされてますかな?
> 送信コマンドと受信データ長が本来のと一致しない場合が出てる可能性もあるかも。

シリアル通信ログにて送信文字列を出力しています。
確認してみましたが、やはり送信文字列の形式に誤りはなさそうでした。
受信文字列についても、通信タイムアウトログでその時点の受信文字列を出力しています。
送信コマンドに応じた受信データ長分のデータが取得できているようです。

> ちなみにACK,NAKは通信成功、通信失敗を意味する場合が多いです。
> STXは通信の始め、ETXは通信の終わりのアクセントとして使われます。

ここらへんも判定する処理が必要かと思い、この問題が解決後に処理部分を実装予定です。

[ツリー表示へ]
タイトルRe^12: シリアル通信で異常に時間がかかってしまう
記事No14450
投稿日: 2010/01/29(Fri) 13:02
投稿者オショウ
> MsComm.InputLen = 1
> で OnComm にて文字列結合していく手法でしょうか?
> 今の方法でやはり厳しそうならこっちの方式にするしかないかと思っています。

  基本的かどうかは解りませんが、やはり1バイト受信でイベント発生するよう
  に設定して、CR+LFが来るまで読みためて、1パケット分問題なく受信したら
  その後の処理に移行させるのが適切かと。

  VB6でPLCと通信していたのはもう7年も前・・・現在は.NETに完全移行
  してますので、結構楽に作れたりもするんですが。

  PLCとの基本的なプロトコルをちゃんとインプリメントすれば問題は解消す
  ると思います。

  要は電文が最後まで来ない場合をちゃんと想定して正常に動作するアルゴリズ
  ムをプログラミングできるか・・・ということかと。

> ここらへんも判定する処理が必要かと思い、この問題が解決後に処理部分を実装予定です。

  三菱PLCの電文では、最後にチェックサムを付加できたはずです。
  ノイズ等で文字バケが発生することも想定しないといけないので、チェックサ
  ム付けるようにし、受信した電文のチェックサムが一致しない場合、ノイズの
  影響等で通信が阻害されている可能性があります。その場合、NAK返してリトラ
  イ動作に入りますネ!

  一概には言えませんがボーレートを下げると軽減する場合がありますが、根本
  的な解決ではありませんので・・・

以上。参考まで

[ツリー表示へ]
タイトル経過報告
記事No14452
投稿日: 2010/02/04(Thu) 09:42
投稿者ぽると
別件の装置トラブルの為、数日こちらの作業滞っておりました。
まずは現状の経過報告を。

@FAネットワークの通信量
  担当者に確認してもらいましたが、通信に影響が出るほどの
  通信量の行き来は検出されなかったそうです。
A装置側の機器異常のチェック
  割と年数のたっている装置なので先日もパーツを交換したそうですが、
  PCとの通信関係に影響しそうなところは異常は出ていないそうです。
BPC1の異常チェック
  ハードウェアではTCP/IP、シリアル供に故障等はありませんでした。
  停止可能日に半日ずつ単体テストを実施。
CLANやシリアルケーブルの再点検
  ノイズ対策済みのものを使用中。
DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG )
  継続実施中。
EACK、NAK等のチェック処理の実装テスト( テストPG )
  継続実施中。
  チFック処理が無い理由は特にないようです。逆になんで無いのか聞かれました...。
FDoEvents の整理
  シリアル通信処理以外での DoEvents は全て外しました。
  しかしながら現象は解消されませんでした。
Gチェックサムについて
  現在のシリアル通信でもチェックサム有りで通信しています。
  ただ、肝心のNAKチェック処理が無いので機能していない。

今後の進め方として、
原因調査のリミットは来週中までとし、それでも原因がわからないとなれば
やはり現状の Do〜Loop 方式はこのシステムでは不適切とし、
1バイトずつ受信するやり方で見直す方向で進めていこうかと考えています。

再現方法が若干異なるので、今回の原因とは関係ないかもしれませんが、
似たような現象が出るパターンがあったので報告します。
・たまたまデバック用の変数をメッセージボックスで表示した時、
  シリアル通信の DoEvents 回数が同じまま、TCP/IP通信の DataArrival が連続発生。
  メッセージボックスを消すとシリアル通信も再開された。
上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ出る現象のようです。
何故かはよくわかりませんが...。

[ツリー表示へ]
タイトルRe: 経過報告
記事No14453
投稿日: 2010/02/05(Fri) 08:34
投稿者GOD
> ・たまたまデバック用の変数をメッセージボックスで表示した時、
>   シリアル通信の DoEvents 回数が同じまま、TCP/IP通信の DataArrival が連続発生。
>   メッセージボックスを消すとシリアル通信も再開された。
> 上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ出る現象のようです。
>
メッセージボックスでユーザーの入力待ちをしていれば多分止まりますよ。
関連として自作ウィンドウでもモーダルで表示すれば同じようになります。
理由としては、DataArrival はイベントだからユーザー問い合わせ中(処理中)でもCPU
に空き時間があれば処理を実行できます。(自イベントへの再突入はしないので例外はあり
ますが)
メッセージボックスはユーザー問い合わせという処理をしているので DoEventsには戻って
きません。(DoEvents中のDoEventsとかと同じです。)

--- サンプル(タイマのInterval=1000, ボタン1をクリック後、ボタン2クリック)
Private Sub Command1_Click()
    Dim dt As Date
    
    dt = Now
    Label1 = "Command1_Click in:" & Now
    Do
        DoEvents
    Loop While DateDiff("s", dt, Now) < 10
    Label1 = "Command1_Click out" & Now
End Sub

Private Sub Command2_Click()
    Form2.Show vbModal
End Sub

Private Sub Timer1_Timer()
    Label2 = "Timer1_Timer pass" & Now
End Sub

--- 例外のためのサンプル(自イベントへの再突入はしない、1秒毎にウィンドウは増えない)
Private Sub Timer1_Timer()
    Label2 = "Timer1_Timer pass" & Now
    Dim x As Form
    Set x = New Form2
    x.Show vbModal
End Sub

[ツリー表示へ]
タイトルRe^2: 経過報告
記事No14457
投稿日: 2010/02/08(Mon) 08:45
投稿者ぽると
GODさん
サンプルありがとうございます。

> メッセージボックスでユーザーの入力待ちをしていれば多分止まりますよ。
> 関連として自作ウィンドウでもモーダルで表示すれば同じようになります。
> 理由としては、DataArrival はイベントだからユーザー問い合わせ中(処理中)でもCPU
> に空き時間があれば処理を実行できます。(自イベントへの再突入はしないので例外はあり
> ますが)
> メッセージボックスはユーザー問い合わせという処理をしているので DoEventsには戻って
> きません。(DoEvents中のDoEventsとかと同じです。)

メッセージボックスにこんな落とし穴があるのは知りませんでした。
手動動作等で確認用メッセージ等を出すところ意外は、
メッセージボックスを表示している処理のところをリストボックス形式に変更しました。

現場でメッセージが表示されても基本的には「OK」ボタンを押すしかないので、
メッセージが出た時は「OK」を押していたそうです...。

経過として、メッセージボックスの修正で頻度的にはかなり減ったような気がします。
4〜5回/日 → 0〜1回/日 程度。
まだこの修正を実施して2日なので、判断するには早いかもしれませんが。
また、全く発生しなくなったわけでもないので、引き続き調査継続しています。

[ツリー表示へ]
タイトルRe: 経過報告
記事No14456
投稿日: 2010/02/06(Sat) 01:04
投稿者オショウ
今回の問題とは直接的には関わらないかもしれませんが
一応、突っ込んでおきます。

> @FAネットワークの通信量
>   担当者に確認してもらいましたが、通信に影響が出るほどの
>   通信量の行き来は検出されなかったそうです。

  パケットモニタとか入れて計測したんですか?

> A装置側の機器異常のチェック
>   割と年数のたっている装置なので先日もパーツを交換したそうですが、
>   PCとの通信関係に影響しそうなところは異常は出ていないそうです。

  希望的観測のような・・・何をどうやって調べたか・・・
  もっと物理的に調べる方法を導入しないと、調査にならないかと。

> BPC1の異常チェック
>   ハードウェアではTCP/IP、シリアル供に故障等はありませんでした。
>   停止可能日に半日ずつ単体テストを実施。

  異常って目に見えるくらいなら、もう終わってます。
  オシロとかレコーダー入れて波形を観測した結果ということなら
  納得します。

> CLANやシリアルケーブルの再点検
>   ノイズ対策済みのものを使用中。

  ええ〜と、FA関係では、ノイズ対策品というものは無意味。
  光ファイバ入れているなら納得。メタルケーブルなら鉄管に入れて
  第一種の電気工事でアースに落としてあるから・・・とかの保障が
  あるならばよし。

  それでもアースから回り込むと云う場合を想定して、特別な避雷機
  や逆流遮断回路が入っている。とか・・・

> DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG )
>   継続実施中。

  TCP/IP側には、パケットモニタ入れてログ解析するくらいでないと
  原因の切り分けの明確な材料にならない。

> EACK、NAK等のチェック処理の実装テスト( テストPG )
>   継続実施中。
>   チFック処理が無い理由は特にないようです。逆になんで無いのか聞かれました...。

  NAK時の再送要求が行われて、リトライ動作して保障されるアルゴリズム
  が、無いなら、その有用な機能を使っていない・・・ように思いますが。

> FDoEvents の整理
>   シリアル通信処理以外での DoEvents は全て外しました。
>   しかしながら現象は解消されませんでした。

  この辺は、プログラムのコーディング・アルゴリズムに依存するので
  一概には言えない・・・まぁ〜原因にはよくなりますが。

  どんな順序で動作しても、非同期通信が成り立つように作ってあるな
  らば、DoEvents入っていても問題にならない・・・(私のコードには、
  結構入っている。なんせ結構マルチスレッド的に作ってあるもので)

※  非同期スレッドと非同期スレッドを同期させる・・・みたいな仕組み
  をちゃんと作れれば、FA関係は怖くない・・・シリアル通信の同時
  8ポート通信+GP-IB機器12台+ネットワーク(DBサーバーやFTP)
  それらを絶え間なく通信させて24時間365日稼働してますが、も
  う数年のオーダーで特に問題なし・・・HDDやPCが壊れるのが先!

> Gチェックサムについて
>   現在のシリアル通信でもチェックサム有りで通信しています。
>   ただ、肝心のNAKチェック処理が無いので機能していない。

  勿体ない・・・

  あ!チェックサムありはいいけど、チェックサムチェックしてます?

  受信した段階で再度チェックサムを計算しなおし、受信データに付与
  されているチェックサムと一致するかを確認する。

  チェックサム付きでもチェックしていなければ、結果、何もしていな
  いのと同じ・・・

> 上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ出る現象のようです。
> 何故かはよくわかりませんが...。

  マイクロソフトの仕様というか、バグというか・・・

  メッセージボックスは結構問題になるので、24時間稼働装置のPC
  ソフトでは、メッセージボックスは使わない。
  ListViewとかに履歴表示を行うようなことにしている・・・

以上。

[ツリー表示へ]
タイトルRe^2: 経過報告
記事No14458
投稿日: 2010/02/08(Mon) 10:53
投稿者ぽると
オショウさん
アドバイスありがとうございます。

> > @FAネットワークの通信量
> パケットモニタとか入れて計測したんですか?
パケットモニタにて1週間通信量を計測してもらい、
装置で現象が発生していた時間と照合しました。
通信量自体にもあまり変化は見られませんでした。

> > A装置側の機器異常のチェック
> 希望的観測のような・・・何をどうやって調べたか・・・
> もっと物理的に調べる方法を導入しないと、調査にならないかと。
希望的・・・というのは当たりかもしれません。
調査方法について詳細を聞いてみたところ、
「PCを繋いで数回シリアル通信テストして通信できていた」とのことだったので。
継続調査・・・ということになりますね。

> > BPC1の異常チェック
> 異常って目に見えるくらいなら、もう終わってワす。
> オシロとかレコーダー入れて波形を観測した結果ということなら納得します。
計測器を使うのは考えに無かったです。
今回の現象の調査とは別としても、今後の調査方法として考えようと思います。

> > CLANやシリアルケーブルの再点検
> ええ〜と、FA関係では、ノイズ対策品というものは無意味。
> 光ファイバ入れているなら納得。メタルケーブルなら鉄管に入れて
> 第一種の電気工事でアースに落としてあるから・・・とかの保障が
> あるならばよし。
> それでもアースから回り込むと云う場合を想定して、特別な避雷機や
> 逆流遮断回路が入っている。とか・・・
そうなんですか!
正直なところ配線等にはあまり詳しく知らないです。
とりあえずこちらで出来るのはノイズ対策品使うくらいでいいかと思っていました。

> > DTCP/IP通信とシリアル通信のタイムアウト時間の調整( テストPG )
> TCP/IP側には、パケットモニタ入れてログ解析するくらいでないと
> 原因の切り分けの明確な材料にならない。
Dについては中断してます。

> > EACK、NAK等のチェック処理の実装テスト( テストPG )
> NAK時の再送要求が行われて、リトライ動作して保障されるアルゴリズムが無いなら、
> その有用な機能を使っていない・・・ように思いますが。
全くもってその通りでして、何でこんな作りになっているのか...。
チェック処理の実装についてはテストPGの方では動作確認がとれたので、
近いうちに本番PGにも追加する予定です。

> > FDoEvents の整理
> この辺は、プログラムのコーディング・アルゴリズムに依存するので
> 一概には言えない・・・まぁ〜原因にはよくなりますが。
> どんな順序で動作しても、非同期通信が成り立つように作ってあるならば、
> DoEvents入っていても問題にならない・・・
必要に応じて使われていていればいいんですが、
今回の場合ですと、色を付ける処理とかで使われており、別段処理に時間がかかるような
ところでもなかったので外しました。

> ※ 非同期スレッドと非同期スレッドを同期させる・・・みたいな仕組みを
>    ちゃんと作れれば、FA関係は怖くない・・・シリアル通信の同時
>    8ポート通信+GP-IB機器12台+ネットワーク(DBサーバーやFTP)
>    それらを絶え間なく通信させて24時間365日稼働してますが、
>    もう数年のオーダーで特に問題なし・・・HDDやPCが壊れるのが先!
すごいですね。
1ポート+ネットワークで苦戦している私にはまだ難しそうです・・・。

> > Gチェックサムについて
> 勿体ない・・・
> あ!チェックサムありはいいけど、チェックサムチェックしてます?
現状のPGには受信後のチェックサムについても、
ACK等と同じく全くチェック処理がないですね。
実装予定のACK等のチェック処理に受信後のチェックサムのチェックも入れてあります。

> > 上記現象はデバックモードではなく実行ファイル形式で動作させている場合のみ
> > 出る現象のようです。
> マイクロソフトの仕様というか、バグというか・・・
> メッセージボックスは結構問題になるので、24時間稼働装置のPCソフトでは、
> メッセージボックスは使わない。
> ListViewとかに履歴表示を行うようなことにしている・・・
応急対策ですが、メッセージボックスについてはリストボックスに表示する形式しました。

[ツリー表示へ]
タイトルRe^3: 経過報告
記事No14463
投稿日: 2010/02/11(Thu) 22:24
投稿者オショウ
> > > BPC1の異常チェック
> > 異常って目に見えるくらいなら、もう終わってワす。
> > オシロとかレコーダー入れて波形を観測した結果ということなら納得します。
> 計測器を使うのは考えに無かったです。
> 今回の現象の調査とは別としても、今後の調査方法として考えようと思います。
>
> > > CLANやシリアルケーブルの再点検
> > ええ〜と、FA関係では、ノイズ対策品というものは無意味。
> > 光ファイバ入れているなら納得。メタルケーブルなら鉄管に入れて
> > 第一種の電気工事でアースに落としてあるから・・・とかの保障が
> > あるならばよし。
> > それでもアースから回り込むと云う場合を想定して、特別な避雷機や
> > 逆流遮断回路が入っている。とか・・・
> そうなんですか!
> 正直なところ配線等にはあまり詳しく知らないです。
> とりあえずこちらで出来るのはノイズ対策品使うくらいでいいかと思っていました。

  ネットワークの敷設工事を行える電気業者さんには、持ってないところ
  もありますが、配線チェック用以外に帯域保障する為のアナライザーを
  持っていたりもします。

  昔は高価(100〜300万した)だったのですが、昨今は安価です。

  https://networkservice.blackbox.jp/shop/goods/goods.asp?goods=TS580A-R3

  線材以外でも環境ノイズの影響が解ったりもします。
  (安価すぎるのは、性能がよくないので注意)
  私が依頼している業者さんでは、8年くらい以前で130万した機材でした。

  シリアル通信の方に原因があるように思いますので、今回の件とは直接
  関わりないと思いますが、そういう機材を持っている業者さんに工事を
  依頼すれば、トラブル発生時でも迅速に原因の切り分けが可能です。

  スイッチハブやLANカードの経年劣化も解ったりしますし・・・
  まぁ〜パケットアナライザで再送頻度が高ければ、劣化かノイズという
  ことになるでしょうが・・・

以上。参考まで

[ツリー表示へ]
タイトルRe: 結果報告
記事No14525
投稿日: 2010/03/08(Mon) 10:29
投稿者ぽると
当初よりも期間を延長して検証を行っていましたが、
結果としてはプログラムのシリアル通信部分を見直すということに決まりました。

方針が決まるまでだいぶ時間がかかってしまったので、こちらへの報告が遅くなってしまいました。

GODさん、るるさん、オショウさん
アドバイスありがとうございました。大変参考になりました。
※ 次回利用する際には早めにレスつけるように気をつけます。

[ツリー表示へ]