2022年にオムロンのコンポバスが生産中止になりました

メーカー推薦ではコーポネットに置き換えになっていますが
皆さんどのようにお考えですか

コーポネットはあまり普及している印象は受けないので
また生産中止になりそうで不安があります

この際　多数のメーカーで販売しているデバイスネットに
変更するのもありだと思うのですが

また　コンポバスはデバイスネット準拠との話を聞くのですが
混在とかは可能なのでしょうか

申し訳ないですがご教授願います
      

      

      

      広義に「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 にも手順はちゃんと、ある)
      

      

      

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

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

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

      

      

      

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


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

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

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


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

      

      

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

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

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

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

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

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

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

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

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

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

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

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

      

      

      【70193】むえ様

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

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


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

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

      

      

      

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

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

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

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

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

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

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

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

      

      

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

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

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

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

      

      

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


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

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


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

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

      

      

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

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

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



      

      

      

      >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

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

      

      

      

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

三菱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なのだから、返答が無ければ再送？等


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

      

      

      のぼるさん解決してよかったですね。

CV5500等の電源投入後の立ち上がりが遅いものと通信すると
サイクリック通信エラーが出たりしますね。
私も納入後にしばらくしてからたまに出るようになった設備がありました。
客先からエラー出なくしてほしいと要望があり
サイクリック通信エラー検出マスク時間(接続時)を延ばし回避しました。
      

      

      

      アドバイス下さった皆様

ありがとうございます。
今回のトラブルが解消致しましたので、ご報告させて頂きます。


�@電源が落ちる
　表現が間違って申し訳ございません。正しくはエラーによりPLCがOFFになりその後ONに復旧。
　これを繰り返すといった現象した。
　こちらについては電力不足は無かったのですが、拡張ユニットの接続に問題がありそうで、
　ひとつずつ確認しながら動作確認すると上記の現象は解消しました。
　確認するまえに抜いてしまったので定かではないのですが、おそらく入出力のコネクタを逆にして
　電源接続してしまったいたのではないかと思います。初歩的なミスでございました。

�AEIPの通信不具合は上記とは直接関係無いらしく、機器のEDSファイルを再インストールすると
　通信が問題なく開始されました。デバイスモニタで入力情報も確認できました。

ありがとうございました。

のぼる(修行中)


      

      

      

      なんで誰も最重要項目を確認しないんだ？
電源は何？
http://www.keyence.co.jp/products/controls/
「KV-7500：200mA以下」　

「性能仕様−AC電源ユニット（KV-8000、KV-7000シリーズ用）KV-PU1」
「DC 24V±10% 1.8A（各種ユニットへの供給とサービス電源の合計）」

「CV-5000」
「電源　DC24V±10%　2.2A （2カメラ接続最大負荷時）」

FC400-EIP
http://www.unipulse.tokyo/product/fc400-eip/
DC 24 V（±15%）　4W

KV純正のKV-PU1が1個で全部に電源供給してるんならOUTだな



まぁ、最優先でオムロンの電流計表示付き機種に替えるとかして消費電流を確認しましょうね
http://www.fa.omron.co.jp/products/family/807/lineup.html
最低90w以上、　出来れば120wは欲しい

それでも、電源が落ちるのか？


      

      

      

      EthernetケーブルにPOE給電などの余計な電力が乗っているとか？

まさかとは思うけど
KV7500シリーズというだけで、
KV7300とVTとしてシリアル通信していた、というオチ？
      

      

      

      今回の内容に当てはまるかどうかは分かりませんが、
これから話すのは、CAT6AとかCAT7辺りになるのでしょうかね、
コネクタ部が金属ケース付きのケーブルは使わない方が良いですよ。
見た感じシールド効果が高そうという理由で選定してはいけません。
ポート側でシールドを接地する機構が備わっていない場合、
むしろ害が出る可能性があります。

現状FA用途での伝送レートは１ギガ帯域なのでCAT5Eで十分です。
ちゃんとしたケーブルならCAT5でも行けるはずなのですが、
CAT5ケーブルの性能はピンキリなので除外。
従って、CAT5E以上CAT6A未満(未満なので6Aは含まない)が無難です。
      

      

      

      PLCの電源が落ちる、の意味が分かりません。
PLC自体に電源スイッチがついていて(ついてないですよね)それがOFFになるなんて話ではありませんよね。
PLCの電源に繋がっているブレーカなりCPなりが落ちるわけでは無いでしょうし。
エラーでリセットがかかって再起動してるのなら分からないでも無いですが(それでも異常ではありますが)それを電源が落ちると表現するのは間違っていると思います。
      

      

      

      諸先輩方が仰るように通信エラーで電源が落ちることが異常です。
メーカに問い合わせましょう。
http://www.keyence.co.jp/support/user/controls/faq/answer.jsp?faq_id=68422
      

      

      

      URL  

FA屋さくら様
ありがとうございます。
機器同士直結でも同じ現象が出ますので、直接の原因では無いかと思われます。

名無しさん様
ありがとうございます。

確かに電源が落ちています。
そのあと復旧を繰り返しております。

サイクリック通信モニタを確認すると
送受信が増加してある時点までカウントアップするとそのような挙動をすることが
確認できました。

それぞれ直結で通信しても問題なく動作するのはVTのみでございます。

ちなみにケーブルはカテゴリ5以上のもの使用してるのですが、種類によっては問題が起こることはあり得るのでしょうか？

      

      

      

      FA屋さくら様
ありがとうございます。
機器同士直結でも同じ現象が出ますので、直接の原因では無いかと思われます。

名無しさん様
ありがとうございます。

確かに電源が落ちています。
そのあと復旧を繰り返しております。

サイクリック通信モニタを確認すると
送受信が増加してある時点までカウントアップするとそのような挙動をすることが
確認できました。

それぞれ直結で通信しても問題なく動作するのはVTのみでございます。

ちなみにケーブルはカテゴリ5以上のもの使用してるのですが、種類によっては問題が起こることはあり得るのでしょうか？


      

      

      

      >ＰＬＣの電源が落ちる、

というのは普通じゃないね、というか落ちるものなのか？
(ちなみに、エラーSTOPすることは、電源落ちると言ったらいかんよ）

いつ落ちるのか。電投数分後？、毎回？　ごくまれに？

vt、CV5000、FC400EIP それぞれ１個所だけ抜いて試したりしてないの？

      

      

      

      的外れかもしれませんがHUBはEthernetIPに対応していますでしょうか？
      

      

      

      よろしくお願いします。
題名の件、
下記の機器構成で通信を試みているのですが、

KV7500---------HUB--------VT
                |
                |-----�@CV5000
                |
                |-----�AFC400EIP

どうしても、サイクリック通信エラーが発生します。256
エラー発生後ＰＬＣの電源が落ちます。
VTのみ接続時は問題なく接続できております。
�@と�Aの機器はオートコンフィギレーションで設定(�AはメーカーのEDSファイルを使用)

手動で特に設定する項目はあるのでしょうか？
お知恵をお借り頂ければ幸いです。

※CV5000のビットデバイスはモニタで動作していることが確認できているのですが、
ワードデバイスが入ってこないことが確認取れています。
      

      

      

      私見です　単純にR1は外部機器の負荷抵抗　入力の入力電圧制限が12Vから15Vの為　R2-R3の抵抗で分圧している判断では？
CMOSTTL等のロジック電源電圧が24Vより低いので　分圧しているのでは？

      

      

      

      おそらく入力側に保護として下記のようにダイオードが入っているのではないかと思われます
（D1,D2とも上がカソード/下がアノード。要は下から上に電流が流れる）

             　         Vcc            内部ロジック電源
                         |                  |
                         |                  |
                         R1                 D1
                         |                  |
                 ○----------R2-----------------
                                   |        |
外部機器                          R3        D2     入力
                                   |        |
             GND ○-----------------------------
             
ダイオードを入れることによりVcc＞内部ロジック電圧の場合であってもR2で電力消費させて
内部ロジック電圧>入力>0Vの電圧しか印加されないようになります。
R3は入力インピーダンスを下げてノイズ耐性を上げる意図ではないかと思います。

またR1はプルアップの意味と、もう一つ12kΩと低い抵抗値にして外部入力のトランジスタや接点がOnした場合に
多少電流が流れないと入力がOnしないようにしてノイズ耐性を上げる意味と外部機器が接点の場合は
ある程度の電流を流して接点の接触不良を予防する(最低負荷電流を確保する)意図もあるかと想像します。

>CMOSに電圧を与えるとして、OCのOn,Offを考えたとき、入力側にどの様な電圧が
>発生するのかが、いまいち、不明で投稿しました。
OCがOnの場合はR2/R3が外部機器側で短絡されることと等価なので入力側には0Vが印加されます
OCがOffの場合はR1/R2/R3にVcc/(R1+R2+R3)=24/(12k+200k+200k)=0.0583mAの電流が流れることになるので
R3の両端には200k*0.0583mA=11.66Vが発生します。
内部ロジック電源が24Vでれば11.66Vそのままですし、5VであればD1によって入力電圧は5Vにクリップされます

FA屋を始める前の古いマイコン屋時代（かれこれ40年位前）の知識です。間違ってたら訂正お願いします
ダイオードの順電圧やトランジスタ飽和電圧等々細かいことは無視できる範囲と考えられるので配慮してません。突っ込まないでくださいね。
      

      

      

      >トランジスタの所は、おそらくNPN型の
>入力用のトランジスタ回路があるはず。
おしい！
恐らく、トランジスタはトランジスタでも電界効果トランジスタ　よーするにFET
具体的にはC-MOS論理素子
http://toshiba.semicon-storage.com/jp/semiconductor/knowledge/e-learning/cmos-logic-basics/chap2/chap2-1.html
TTL互換の4000シリーズ
http://toshiba.semicon-storage.com/jp/semiconductor/product/general-purpose-logic-ics/detail.TC4049BP.html

定石的にcmosにはプルアッププルダウン両方入れる

      

      

      

      【70169】の人です。

Ｒ３対トランジスタの分流比回路になる。
と書きましたが、ここで言うところのトランジスタは
「トランジスタ」＝「入力」回路部のことです。

トランジスタの所は、おそらくNPN型の
入力用のトランジスタ回路があるはず。
（１２Ｖで電圧駆動するトランジスタなのか？？）

トランジスタのONトリガ＝ベース電流は小さいのです。
というか、ここに大電流を流したくない。
「Ｒ３対トランジスタの分流比回路になる。」と書いているのは
そういった意味で、
Ｒ３対トランジスタの比率で電流が流れるようになっていると思われます。

間違ってたらごめんなさい


      

      

      

      "名無し"さん、lumiheartさん
ご返答、ありがとうございます。

計算抜きで、平たく言えば（limiheartさんURLより）、
　OCがOffの時、電源は、ほぼほぼ右側（入力側）に流れ、Ｈとなる。
　OCがOnの時、右側に比べ、左側（OC側）の抵抗値が極端に低いので、
　電源は、ほぼほぼ左側に流れ、入力側はＬとなる。
と、理解しました。（で、合っているかしら？？）
（ちゃんとした計算値は、もう少し勉強します）

にしても、プルアップとプルダウンが同時に存在しているのが理解できない。
電子回路は奇々怪々。

      

      

      

      >このようにコモン線を遮断する観点で、PNP仕様の場合、Nコモンも遮断する必要があるのでしょうか。

最大の問題は何処の国？
日本国内ならどっちでも構わない
ＥＣ諸国ならＮ相を切ってはナラナイ（切ると違反）
所謂、機械指令
http://www.pilz.com/ja-JP/support/law-standards-norms/manufacturer-machine-operators/machinery-directive