この場を借りて失礼します。

三菱Qシリーズの
UDEHにて内蔵Ethernetを12ポートほど用いて、PCと通信を行っています。

内訳
コネクションNo, プロトコル, 方式
1, TCP, MCP
2, TCP, Socket(以下、全て無手順）
3, TCP, MCP
4, TCP, Socket
5, TCP, MCP
6, TCP, Socket
7, TCP, Socket
8, UDP, Melsoft(GOT)
9, TCP, MCP
10, None
11, TCP, MCP
12, TCP, Socket
13, TCP, Socket
14, TCP, MCP
15, TCP, MCP
16, TCP Melsoft(PC接続用）


MCプロトコルの返答が稀にPLCからPCへ返ってこない場合があります。（頻度は１〜２ヶ月に1度）
そのため対策として、UDEHからUDVに置き換えを行った結果改善しています。

動作としては改善していますが、なんの根拠も無い状態のため情報収集させてください。

・連続通信によるパケロス、パケづまりのような症状が発生したことがある
・そもそも内蔵Ethernetに期待するな
・TCP/IPなのだから、返答が無ければ再送？等


なにか情報をいただけますと幸いです。

>MCプロトコルの返答が稀にPLCからPCへ返ってこない場合があります。（頻度は１〜２ヶ月に1度）
一番めんどくさい頻度のヤツだなぁ
1日に一度なら、それなりに検証可能
1年に一度なら、諦めた方が安い　＜コスパで決まる

>動作としては改善していますが、なんの根拠も無い状態のため情報収集させてください。

結果が出るのが1ケ月先って
それで、3ケ月に一回とか６ケ月に一回とかになってたとしたらどーする？

ところーで、ＰＣ側ソフトは何？
１、市販SCADA?インテルーションとか
http://www.proface.com/ja/article/scada
http://www.mitsubishielectric.co.jp/fa/products/hmi/scada/pmerit/genesis64/index.html

２、ＶＢとかＶＣとかで内製したとか？
事務系ソフト屋さんがＦＡ系を作るとハマりやすい
よーするに単純にバグとか？

【70189】むえ様
気になることがありますが、外れていたらすみません。

ポートですと自局ポート番号と勘違いしそうなので、接続番号と記載します。
内蔵Ethernetを接続番号12とありますが、設定上はnone含め接続番号16全て設定されている状態ですよね。

一度遮断されたEthernet通信が再接続を行う際、遮断前と違う接続番号でオープンしようとする事があります。
Ethernet診断を見ているとよく解ります。遮断されると｢遮断中｣となり、同じ自局ポート番号で異なる
接続番号で通信をしています。これが接続設定がフルになると、再接続時にオープンすることが出来ず通信
途絶となる事があります。
客先で同時症経験したのですが、接続設定に空きを作り解決しました(と思っている)。三菱電機からの回答は
要領を得ませんでした。
取扱説明書にも設定を超える接続はしないようにとあるので、接続設定に予備を作る(未設定)のが吉だと思います。

>> lumiheart様
回答ありがとうございます。


> 結果が出るのが1ケ月先って
> それで、3ケ月に一回とか６ケ月に一回とかになってたとしたらどーする？
記載しておらず、後出しになりますがUDVに変更後は6ヶ月は出ていない状況です。
もちろんその後出るかもしませんし、出ないかもしれないのでひとまず応急策という位置づけになっています。

現在同等のローカル環境で、ひたすら通信を繰り返すことで再現できないか？
その時の状況はどうだったか？を検証し続けているような状態です。


> PC側ソフト
2番に該当します。
C++の内製ソフトで、ソフトA、ソフトBが存在し
通信工程は違う構造となっており、（作っている人が違う）
かつ、同じタイミングでMCPの返答がないためPLCが原因では・・・と焦点を絞っています。

単純なバグの可能性ももちろんあるので、それが問題だと言われた場合それまでですが。
これも後出しで申し訳有りませんが、UDVや、KV-8000などでは数年でも再現していません。

>> 流れ星様
回答ありがとうございます。
情報いただけ嬉しい限りです。

> 内蔵Ethernetを接続番号12とありますが、設定上はnone含め接続番号16全て設定されている状態ですよね。
16ch全て設定している状態です。

> 一度遮断されたEthernet通信が再接続を行う際、遮断前と違う接続番号でオープンしようとする事があります。
こちらに関しては、情報足らずで申し訳有りません。
PLCがサーバ（LISTEN）として自局ポートは固定しています。
PC側がクライアントでOPENする形を取っています。
ですので、こちらの環境では1〜65535（実際はもう少し少ないですが）の範囲を超過するようなことは無いように感じています。

> 客先で同時症経験したのですが、接続設定に空きを作り解決しました(と思っている)。三菱電機からの回答は要領を得ませんでした。
> 取扱説明書にも設定を超える接続はしないようにとあるので、接続設定に予備を作る(未設定)のが吉だと思います。
接続設定と言いますと、16chの中に予備を作るということでしょうか？
たとえば、Noneとしてる部分は未設定としたり、余裕が無ければイーサネットユニットを増設してゆとりをもたせる？のような・・・
あまり熟読したわけではないので、取扱説明書を再度確認してみようと思います。

【70191】流れ星 さんの内容について補足

これは三菱に限らない話でありTCPのプロトコル仕様に関係する事です。
TCPのコネクションが突然断路となった場合、冷却時間が必要で、
(記憶によれば、確か４０秒ほどの無処理時間を置いて）
再度接続をトライします。
この場合多くのアプリで３回のリトライ処理を行うので、
（接続待機＋冷却時間）×３の時間のあいだ、再接続モードになります。
同様に、相手側も同様な再接続モードになり、
お互いが手探り状態で再接続を待つようになります。

再接続モードの際に、自局のポート番号を変更すると、
冷却時間を無視して、再接続のトライをすることができます。

ここで問題になってくるのが、
お互い迷走したあげく、３回のリトライを終了してしまった場合であり、
三菱の場合などは、よく「接続不可」などのステータスで表されます。
接続不可のステータスの解除は処理系によって違います。

例を挙げると、三菱の内臓ＣＰＵの簡易リンク機能の場合は、
「接続不可」になると解除方法がありません。ＣＰＵリセットのみです。

ちなみに、「接続不可」というのはプロトコルがTCPであるため
発生する症状で、UDPの場合は発生しません。
これは、TCPがコネクションを切る処理をおこなうまで、
常時コネクションが繋がっていることを前提とした
プロトコルであるためです。
逆にUDPは１送信毎にコネクションが閉じるという送信方法なので
発生しないのです。

そのため、たとえば、１か月とか長い間TCPを維持できる、
という自信や根拠がない場合(再接続体制が万全である事)は、
長時間コネクション保持はおすすめしません。

そういった意味で、UDPがおすすめなのですが、
UDPにはTCPに備わっているエラー訂正機能や、
不達時再送信機能などがありませんので、
パケット到達の確認の厳密性という意味では
アプリケーション側でこれらを実行する必要があります。

【70193】むえ様

補足説明を追加して頂いていますが、少しすれ違っている内容が有るので...

》ですので、こちらの環境では1〜65535（実際はもう少し少ないですが）の範囲を超過するようなことは無いように感じています。
私が書いたのは自局ポート番号ではなく、再接続時に同じポート番号で異なる接続番号(異なるch)でオープンするということです。
Ethernet診断を見ると、同じ自局ポート番号での接続が複数の接続番号で確認することが出来ます。


》接続設定と言いますと、16chの中に予備を作るということでしょうか？
》たとえば、Noneとしてる部分は未設定としたり、余裕が無ければイーサネットユニットを増設してゆとりをもたせる？のような・・・
その通りです。通信再接続の場合は未設定分の領域を使いオープンするように見えます。
接続設定数を減らし、PC側にて取得データを目的別に分けるという手もあります。

因みにですが、iQ-Rですとこの辺の処理について通信途絶しないように対応している感じがします。接続設定をフルに行い、
故意に通信途絶して再接続しても、きちんとオープンして通信継続しています。Qシリーズでは通信不可になります。
尚、この辺の処理に関する情報は取扱説明書は見つけられませんでした。

ちょっと気になったのですが。
随分と沢山のコネクション設定をしていますね。

そこで問題になるのが、
「ａ：制御をメインにしているのか」
「ｂ：ライン物などで統括ＰＬＣとしてＰＣ通信をメインとしているのか」
という点であります。

基本は制御主体の装置だけれども、ＰＣ通信も大事となると、
もう、どうしようもないです。

話題にしたいのはｂの方でございます。

ＰＣなどの通信はどのタイミングで行われているかご存じでしょうか？
ＰＬＣのスキャンは、若干の異論はありましょうが、概略といたしまして、
【１】一括入力取り込み
【２】ラダー条件の解決
【３】一括出力処理（ラダー解決値の転送）
【４】ツールサービス
となっています。

ここで問題になってくるのが４のツールサービスでして、
三菱の標準設定ですと、スキャンの数％を割り当てるだけなのですよね。

ツールサービスは、ラダーツールのモニタや電文処理などを
行うフェーズです。

そうなんですよ、ｂとして、めちゃ重要なのです。

スキャン方法の指定を変更してツールサービスに
余剰リソースが大量に割り当てられるようにする必要があります。
（コンスタントスキャンにして、空きコンスタントを充てる、等）

ツールサービス枠に通信が集中すると、枠取得ができなかった人は
次スキャンにまわされます。
しかも渋滞整理がされているというよりは、
「次枠取得も早いもの勝ち」になってる気がすんですけど、
どうなんでしょう？
（ここら辺の仕組みに詳しい方いますか？）

たまに、通信が失敗するのって、
何枠かハブられたからなんじゃないでしょうか？
処理が速いＰＬＣにしたことで間に合ったと推測します。

追伸
イーサーネット通信といえばＱＪ７１でしょう！と
通信カードを載せて、そちらでＰＣ通信してませんか？
実はＰＣ通信として最速なのはＣＰＵイーサーです。
体感的にはＱＪ７１の５〜１０倍くらい早いんじゃなかろうか。
今回の方は、ちゃんとＣＰＵみたいですね。
低速通信や、確実性を求めないもの、
たとえばＧＯＴ通信なんかを、ＱＪ７１を用意して
分散するのも手かもしれません。

>>【70194】名無しさん様
ご回答ありがとうございます。
簡易リンクでは再接続できないのですね。勉強になります。
情報ありがとうございます。


>>【70195】流れ星様、及び【70196】名無しさん様
ご回答ありがとうございます。

【70196】名無しさん様の回答にもある内容と関連していると考え、
制御シーケンスとの関係性でもかなり影響がありそうなので、そのあたりに負荷をかけつつ確認してみます。

またUDVでは多少性能が上がっているため、
>たまに、通信が失敗するのって、
>何枠かハブられたからなんじゃないでしょうか？
>処理が速いＰＬＣにしたことで間に合ったと推測します。
や
>因みにですが、iQ-Rですとこの辺の処理について通信途絶しないように対応している感じがします。接続設定をフルに行い、
>故意に通信途絶して再接続しても、きちんとオープンして通信継続しています。Qシリーズでは通信不可になります。
が改善の糸口になりそうですね。。。ありがとうございます。
（早合点かもしれませんが）


まだ再現テストで結果は出ていませんのでひとまず検証を行い。
何か進展があれば、ここに追記したいと思います。

Socketってのはどんな通信でしょう？
これも、PLCがサーバーですか？
CPUのEThernetポートを使って、PLCから他の機器に
データを送信するときは、確実に相手がいないと
30秒固まったりいろいろ起きました。

UDEとUDVではかなり修正されているようです。
UDVの中でも古い物と新しい物で動作が違います。
Rはさらにいいみたいです。

CPUのポートの方が速いというのは知らなかったので
いい勉強になりました。
ただ、安定して動作させたければ、Ethernetユニット
必須だと思っています。（確かに遅いけど・・・CPUのほうが
速いのか・・・そっちは測定したことなかったな)

広義に「Socket」といった場合は
「Socket APIを用いた通信」という意味合いだと思います。

Socketとは、本来の英語が意味するように
「差し込み口」であり、
TCPやUDPが「通信規格」であるのに対して、
実際のOSなどから提供されている、
LAN通信の「入出口」を指します。

LAN上の信号はデジタル信号なので、
LANのポート上のTX+、TX-、RX+、RX-などを
直接Y1000から割り当ててあるよ、と説明を受ければ、
理論上一般I/O端子を用いてもLAN通信可能ですが
この方法は、速度が出ませんし、現実的ではありません。

そこでOS側が用意した
別アクセス手段が「Socket」になります。

将来、M社からS-CPUが発売されて、
M社が、S-CPU用に「Socket」を
用意したとアナウンスされるかもしれません。
その場合に、同時提供されるのが
「Socket API」であり、
ラダー用Socketとして、
　[Z.SOCK D100 D200 D300]
という感じでCPU専用命令が用意されることでしょう。
ラダーから見れば、Socket APIということですね。
これによってY1000などという
実アドレスを意識せずに済みます。

Socketを用いれば、TCP、UDP、
さらにはFTPやメールプロトコルまで扱えますね。
ただし、これでもまだ面倒なので、
実際はTCP命令みたいな、
さらに上位階層のプロトコル命令が
用意されるんじゃないかな。

MCプロトコルや、MODBUS-TCPなどは、
TCPのプロトコルを使った
さらに上位のプロトコルということになります。
TCPのパケットの内部に、
独自通信の要素を組み込んで通信してます。
これを、TCPカプセル通信などと呼んだりします。

単純にSocketとコネクションリストを組んだ場合、
Ethernet通信的には、シリアルで言うところの
「無手順」に近いんじゃないかな。
(実際にはSocket にも手順はちゃんと、ある)