ブレーカ選定表 400V直入れ
三菱電機　N250-CV/175A
富士電機　BW250EAK/175A

なんで125Aにした？内規？

そもそも通常運転中で何A？　＜それが最優先！、起動電流云々は置いといて
一応、定格電流100Aなんだけど？
ただ、本当に直入れ？
インバータじゃないの？

小型機は別にして55kw直入れは売ってない？
http://www.hitachi-ies.co.jp/products/cmp/screw_oil/next55-75/stn_spec.html
http://kobelco-compressors.com/jp/ja-jp/products/oil-injected/vs


      

      

      

      いつも勉強させていたぢております。
先日、変わった事故に遭遇し、担当の説明がよく分からないので、こちらで質問します。
【現象】
・400V系(440V　60Hz)分電盤内の問題
・125AF/125ATのMCCBに55kWのNo.1コンプレッサー接続
・125AF/125ATのMCCBに55kWのNo.2コンプレッサー接続
　No,1とNo.2はどちらかが稼働中。
　ちなみに、起動方式は直動です。（エー！！と思っている）
・容量不明のMCCBに100kVAのトランス(440/200）接続
・その他、6台ほどの機器が各単独でMCCBに接続されている
【問題】
・No.1コンプレッサー稼働中に、100kVAトランスのMCCBをONすると、
　No.1コンプレッサーのMCCBがトリップする。（5回中3回ほど）
・No.2もほぼ同様（トリップ回数は低かった様な気がしますが・・）

【担当者の説明】
１．100kVAトランスのMCCBを入れると、全体に電圧降下が確認された。
　　トランスの初期の突入電流によるものと思われる
２．結果、電圧が下がった為、コンプレッサーの電流が上がり、
　　コンプレッサーのMCCBがトリップしたと考えられる

【よく分からん】
トランスMCCBをON時、突入で瞬時電圧降下を起こすことは理解できる。
コンプレッサーが、No.1,No2と状況が違うことや、トリップが毎回で
無い事も、”たまたま”コンプレッサーがNo-Loadの状態で有ったの
ではないかと推測できる。

電圧降下が起き、電圧不足によりコンプレッサーの電流が増す。←本当？
どの位の電圧降下か聞いていないが、コンプレッサーのMCCBを瞬時にト
リップさせるほど電流が流れるものだろうか？？
この辺り、担当者に聞いても、ゴニョゴニョ言われて、よく分からん！

皆様の正しいお考えをお聞きしたく、投稿します。

      

      

      

      WINDOWS_7の頃は、
おそらくPL2303というドライバチップが市場を占めていたと推測します。
（lumiheartさんが、いきなり結論に飛んでますが）

PL2303を作ってるのが数社あって、
この製品の海賊版ＩＣが沢山作成されました。
ジェネリックと言えば聞こえが良いですが無許可ですので。
Prolific社
↓
FTDI社も作る＝互換品FT232系列＝いまはこれが主流
↓
両社に関係ない海賊版が乱造される
の流れだと思います。
（間違っていたら修正お願いします）

海賊版対策として、
ドライバ側に海賊版チップを使用すると通信できなくなるという
処置をおこなって外部から大ブーイングを受けた経緯があります。
「PL2303 PHASED OUT SINCE 2012. PLEASE CONTACT YOUR SUPPLIER」
と出ている場合は海賊検知している可能性があります。

初期版PL2303は既にサポート終了となり、
最新OS用のドライバは出ていません。
（派生タイプが沢山あって、最新は今でもあります）
      

      

      

      (1)デバイスマネージャ画面で「！」マークが付いているかどうか
この場合は、ドライバが当たっていないのでインストールする必要があります。
掲示板にたどりつく時点で大概メーカーさえ不明という状態と思われます。
blog.at-mac.com/archives/8478
最終手段として↑の方法があります。
ベンダーIDから必要なＩＣチップメーカが判ります。
ケーブル作製メーカーではなく、中核チップのＩＣ製造会社がベンダーIDに出てくるので。
そこからドライバを入手すると良いでしょう。

(2)三菱の設定画面の「接続設定」が間違ている可能性
面倒がらずに、PDFマニュアルの接続方法を読みながら行うことをお勧めします。
      

      

      

      あなたの所持しているケーブルが三菱純正品である場合は、
www.mitsubishielectric.co.jp/fa/products/faspec/detail.do?kisyu=/plcq&formNm=700005394&popup=1
こんな形をしていると思います。

私の記憶が正しければ、Q00-CPUや、Q01-CPUなどのポート仕様はRS232です。
つまり、ケーブルは単なるピン変換をしているだけ。
（丸ピン←→USBになっているのは海賊版です）

お持ちのUSB-RS232変換ケーブルと、QC30R2を使用して接続してください。

RS232変換ケーブルはWIN7以前のケーブルでは
ドライバ認証が通らないのでWIN8以降では使用できません。
最新のドライバでWIN8以降対応しているのならOKですが、
開発が停止しているケーブルは新規に買い直した方が良いです。

      

      

      

      悩んでるより買いなおしたほうが早いのでは？
｛USB-QC30R2｝でググるとアマゾンで\2,400-也

      

      

      

      僕の方でも、キーエンスの営業さんに電話して聞いてみた所
最初に、正規で買った物をユーザー登録すると、最新版をいただける様ですね

しかし、僕が持っているのは、以前、お客さんと共同購入したコピー品なので
ユーザー登録が出来ないので、今度、キーエンスのPLCを触る機会があれば
体験版でも、DLして、やる事にします。
      

      

      

      インターフェイスがシリアルなので（RS422)
三菱品でもなくともRS422仕様であれば何でも使えると思いますよ！
ポート番号が選択出来ればＯＫ
近い将来232C,RS422なんて無くなる・・ってどこかの記事にありましたが
無くなるどころか最強！！？

      

      

      

      lumiheartさんレスありがとうございます。
一応、ご指摘があった方法を色々試してみましたが、やはりダメでしたね。
もう少し、何かよい方法があればと、調べてみます。
貴重なご意見ありがとうございました。
      

      

      

      キーエンスに相談すれば新しいバージョンのKV STUDIOをくれると思いますよ。
以前そのような話を営業マンから聞いた記憶があります。
      

      

      

      amazonとかで売ってる中韓模造品？
ダメ元で三菱純正ドライバ
http://mitsubishi-plc.xyz/?p=1354

どーせ中身はFTDI互換素子であろうと憶測して
http://ftdichip.com/drivers/d2xx-drivers/

或いは競合メーカの素子
http://romly.com/blog/usb_to_serial_ic_note/

以前は秋月電子からダウンロード出来たんだけど　いつの間にか消えてる
http://akizukidenshi.com/catalog/g/g108343/


      

      

      

      今回、以前使っていたWin7の古い現調用ノートPCが故障した為、新たに、Win10搭載のノートPCを購入しましたが
KEYENCEのKV STUDIO Ver5.6をインストールしようとすると、「対応ＯＳではない。」とのメッセージが出てインストール出来ません。
一応KEYENCEのHPより新しいバージョンのKV STUDIOはDL済ですが
アップデート版なので旧バージョンがインストールされていないとインストール出来ません。
新しいKV STUDIOを購入すればよいのかもしれませんが
KEYENCEのPLCを使う頻度がかなり低いので、出来れば、以前購入した「KV STUDIO Ver5.6」を使ってインストールしたいです。
ちなみにPCは[Win10 64Bit 22H2]です。
やり方をご存じな方がおられましたら。ご教授寝返れば幸いです。宜しくお願いいたします。
      

      

      

      今回、以前使っていたWin7の古い現調用ノートPCが故障した為、新たに、Win10搭載のノートPCを購入しましたが
以前使っていたMELSEC-Q用の接続ケーブルの型式が｛USB-QC30R2｝と言う物で、かなり昔に買った物なので

付属していたドライバCDを紛失してしまいました。何処かのHPでDL出来る所をご存じな方は是非教えて下さい。
ちなみにOSはWin10 64Bit 22H2です。宜しくお願いいたします。
      

      

      

      >コンポバスにはCompoBus/SとCompoBus/Dの2種類が存在しました
2022年生産中止と記載されているので、DeviceNetではなくCompobus/Sですね
ttps://www.fa.omron.co.jp/products/family/30/

>この際 多数のメーカーで販売しているデバイスネットに 変更するのもありだと思うのですが
今後どの程度装置を使用するかによって置き換え先は変わると思います
 1.CompoNet
 → 通信ケーブルが流用出来るので工事期間を短縮出来る

 2.EtherCAT/EtherNetIP
 → 主流ネットワークのため当分生産中止にならない

 3.DeviceNet
 → 過去主流だったため他設備で採用されていれば予備品共通化が出来る

DeviceNetは通信チップ自体が無くなり始めているため、型式によっては生産中止になっているものもあります
今後5年以上使用する予定がある場合、DeviceNetへの置き換えはお薦め出来ません

注意点ですがCompobus/SはI/Oスレーブのサイズが小さいです
既存設置スペースに入らない可能性があるので、設置スペース確認をしておいた方がいいです

またインバータ・サーボドライバなどがスレーブとして接続出来ます
単純にネットワーク置き換えだけでなく、全体の見直しが必要になる可能性があります


      

      

      

      ご教授ありがとうございます


      

      

      

      コンポバスにはCompoBus/SとCompoBus/Dの2種類が存在しました
CompoBus/Sは昔ながらのOMRON独自の省配線ネットワーク
（黒い電線２芯のケーブル配線のヤツと同軸での配線のヤツの２種類あったような記憶）
CompoBus/Dは互換性というか、DeviceNetそのものです。
ですので、/DならDeviceNet置き換えが確実かと。



      

      

      

      マニュアルダウンロードしてみました

CPM-2C-シリーズの型番末尾に「DRT」が付いた機種ダケがDeviceNet対応らしい？
CompoBus/S　ユーザーズマニュアル　Man. No. SCCC-307N

必ずしも全部の機種がDeviceNet対応となってるんでは無さそう？



DeviceNet ユーザーズマニュアル　SCCC-308R
を、読んでみたけれど　 
やはりCPM2C-S100C-DRT　ダケらしい？


      

      

      

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