Thread Content
連続生産において、DCSやPLCが動作している間は、さまざまな通信の設定が不可欠です。その中には、コントローラー同士、オペレーションステーションとサーバー間、IOとコントローラー間、本システムとサードパーティ間、本システムとフィールドバス間などがあります。皆さんはご自身の理解や実際の運用に基づき、通信の方法やポイント数、あるいはご自身の所感について話してみてください!
私たちがよく使用しているシステムは、AB社のLogixハイブリッド制御システムです。IOとコントローラーの間は冗長なControlNet通信を用い、コントローラーと上位機の間は冗長なイーサネット通信を用いています。 現在、制御システムとサードパーティのコントローラーとの通信に関する問題もよく発生しています。昨年は当社の制御システムでもサードパーティのモジュールを使用し、シーメンスの315PLCとMODBUSプロトコルで通信を行っていました;今年もシーメンスの315PLCを使用しますが、イーサネット方式を採用しています。ABのPLCは通信機能が非常に強力で、できないことはなく、考えつかないだけだと感じます。それと、ABのソフトはとても使いやすいと感じます。
シーメンスS7400では、PLC制御ステーション間はPROFIBUS DPネットワークを使用している。総ポイント数は約1000ポイントである。上位機器との通信にはイーサネットを利用する。遠隔ステーションではDPバスとイーサネットの2つの方式が用いられており、コンピュータとの通信にはイーサネットの方が便利である。一方、下位制御においては機能がやや過剰になっている。
車載定量計のPLCを使って485バスとCS3000バスのPLCカード間で通信を試みたが、実現がかなり困難で、読み込めないか書き込めないかの状態だった。当時、CS3000のメーカー側でも解決できていなかった。 その後は積み込み装置を使わず、自分でプログラムを書いてCS3000で積み込みを制御するようにした。
シーメンス300、400およびNCシステムはPLC制御ステーション間でPROFIBUSを使用し、速度が速い。200はMPI通信を使用する
感**彩に富んだ一言で言えば、ABの通信はHoneywellの前ではほとんど子供騙しレベルだ。 CPUステーションからIOステーションまで。 ABのCLX5000はControlNetです。 HWのPKS C200もControlNetです。 しかし、ABのCNETメインサイトは1対のみで、HWは3対まで可能です。----単なる冗長性の問題だけではなく、接続数の累積機能もあり、冗長性やフォールトトレランスは最も基本的な機能に過ぎません。 ABのCNET IOの接続数は64で、新バージョンのCN2Rは128です。 HWのCNETモジュールは依然としてAB社によって製造されているが、HWは独自の冗長化および累積方式を用いることで128個のIO接続を実現した。一方、AB社の冗長システムではCNET IOステーションの数が2未満で、1つしかない場合、CPUの冗長切り替えが発生するとシステムは壊滅的な結果を招く——IOはまずリセットされ、その後切り替え前の状態に復帰する。 一方、HWのメインステーション上のCNETモジュールでは、最低2対が必要です。この状況は起こりません。 ABのCNET IOステーションのCNET通信モジュールCNBRは、1つしか存在できません。CNBR上でのケーブル冗長性を最大限実現する。 HWのCNET IOステーションは、2つのCNET通信モジュールCNI(ABのCNBRのOEM品)を標準装備しており、ケーブルの冗長性と通信モジュールの冗長性の両方があるため、4つのリンクに相当します。 ABのCLX5000 CPUメインコントロールステーションからコンピュータステーションまでのイーサネット通信は「冗長化不可」! CPUにENBTを2組搭載しても、冗長化は実現できない! ENBTが1本でも切断されるとCPUの切り替えが起こるため、ENBTを8本用意しても意味がありません。 一方、HWのFTEはイーサネットモジュールが2つで、リンク数は4本です。 イーサネット通信モジュールの冗長化に加えて、ネットワークケーブルも冗長化されている。非常に高いレベルのフォールトトレランスです。 もし、HWのC200がABのCLX5000を改造する上でまだ不十分な点があるとすれば、それはABのIOモジュールが今もなおIO冗長化を実現できていないことであり、これについてはHWにもどうすることもできない。 付け加えておくと、ABのコントローラーはModbusに接続するのが非常に面倒で、MVIというやつは調整がめちゃくちゃ難しい。 Profibusを接続するのはもっと汚い。SST-PFB-CLXはデバッグが非常に難しい。 第三者との通信には、ネットワーク管理ツールの使用を推奨します。 例えば、CNETからProfibus DPへの変換、またはCNETからModbusへの変換などです。
ABB AC800Fシステムでは、コントローラー間、およびコントローラーとコンピュータHMIステーション間は、イーサネットが10Mのみです。 しかし、データ通信は非常によく最適化されている。 データストリーム監視ソフトウェアを使えば、ほとんどの場合、データ転送速度が5M未満であることがわかります。 また、ABBはどう考えているのかわかりません。ヨコガワ、シーメンスは既に1000Mに進出している。 ABBは依然として10Mを堅持しており、現在の10Mイーサネットデバイスは実際にはギガビットよりも少し高価だということを知っておくべきです。 10Mがどれほど優れているかというわけではなく、主に部品がすべて生産終了してしまったからです。 各コンピュータステーションは同時に10セットのコントローラを接続でき、各コントローラは同時に10個のコンピュータステーションに接続されることができる。 まあまあだ。 ただ、OPC Serverステーションのデータ通信量が十分に大きくないだけです。 1400個の変数。 コントローラ同士の通信は非常にシンプルです。 AC800Fは標準のグローバルデータベースです。 AC800Fはサードパーティと接続可能で、Profibus DPやModbusをサポートしています。 通信は複雑ではない。 AC800FはFFシステムにも接続できます。国内ではすでにいくつか実績が出ています。