EZ-Japan BLOG since 2017 真・MFC千夜一夜物語

EZ-Japanブログは、真・MFC千夜一夜物語という流体制御機器=マスフローコントローラ(MFC)の解説記事をメインに、闘病復帰体験、猫達との生活が主なコンテンツです

産業用イーサーネット

真・MFC千夜一夜物語 第346話 MFCだって自動運転! その9 

マスフローコントローラー(MFC)の自動運転のあり方に関して、お話をしています。
EtherCATのような理論上の最高速度 100Mbpsを有効に使えるフォーマットを持った通信ネットワークが現れたことは、MFCにどういった影響を与えていくのでしょうか?運命の分かれ道とは?というお話です。

MFCは装置のコントローラーと常に一対一の関係である事はありません。
MFCだけでも半導体製造装置の場合、1チャンバーに対して使用するガス種、流量レンジによって5~10台、それが複数のチャンバー分存在します。
装置のコントローラーが通信する相手はMFCだけではありません。
ガス系だけでも圧力センサー、バラトロン等のセンサー類に、バルブの数までいれるとなかなかの数量になります。
更に装置には、ガス系よりも更に高速で細やかに指示をしなくてはならない精密位置決めステージや搬送用ロボットアーム等もあります。

これだけのスレイブ点数があると、ネットワークも多層化していく可能性もあります。
つまりEtherCATのような高速通信がマストな機器は最新の高価なハイスピードネットワーク、そうでもない今までのMFCのように流量設定信号(SV)を貰ったら、流量信号(PV)と一致するように制御する“クルーズコントロールレベル”自動運転をしてくれるだけでいいなら実績のある安価なロースピードネットワークというゾーニングです。

これには現在求められておる“MFCの画期的なダウンサイジング“というもう一つの課題が密接に関わってきます。
10mmMFCのような薄いMFCを開発しようとすると、当然最新の高速ネットワーク通信用の基板が、そこに収まりきらないという問題が出来してしまうことも想定されます。
こういった中で今後開発されるMFCの位置づけはどうするべきなのか?という議論が必要な時期に来ているかとDecoは考えています。
ハイスピードネットワークに入ることで、ロボットアーム的な装置のコントロールを強く受ける機器となるか、従来通りロースピードネットワークで生きていくのか?
 
210927_01

これは装置がMFCにどこまでを求めるか?で変わってきます。
装置メーカー、デバイスメーカー、ガスボックスメーカー、マスフローメーカーによって未来図は異なってくるでしょう。

例えばDecoが考える未来のMFCにとってハイスピードネットワークは必須です。
なぜなら未来のMFC”として長年考えてきたのは、流量制御のイニシアチブをMFCと装置の双方で持った形で、各々のプロセスで使い分けていくものだからです。
流量制御モジュールであるMFCと装置との親和性を今の時点より更に高めていく方向性です。その為にはリアルタイムで複数のセンサー情報や指示を正確にやり取りする必要があり、ハイスピードネットワーク、特にEtherCATのような形態が望ましいのです。
この“未来のMFC”のコンセプトは、いずれご紹介するつもりです。
MFCの自動運転に絡めた未来像のお話は、今回はこれくらいにしておきましょう。

【あなたにMFCの夜が来る~真・MFC千夜一夜物語】by Deco EZ-Japan


真・MFC千夜一夜物語 第345話 MFCだって自動運転! その8 

マスフローコントローラー(MFC)の自動運転のあり方に関して、お話をしています。
「MFCに勝手をさせず、装置のオーダー下に置くのには、絶好の機会が訪れている」と前回お話ししました。
では、技術的な面で「産業用イーサーネット“EtherCAT”のような高速産業用ネットワークが装置のデフォルト通信規格となる」事がMFCの自動運転とどういった関係があるのでしょうか?

EtherCATを含む産業用イーサーネットの躍進は、2021年5月11日のMFCニュース“産業用イーサーネット vs フィールドバス マスフローでの対応”でも取り上げました。
ここで少しEtherCATの解説をしましょう。
EtherCATはドイツのベッコフオートメーション(Beckhoff Automation)によって開発された、イーサーネットと互換性のあるオープンな産業用ネットワークです。
相互互換性を保つことを目的に、2003年に設立されたEtherCAT Technology Group(ETG)よって管理されています。
ETGの加盟企業は国内300社、世界では2400社にも及びます。
EtherCATの最大の特長は、これまでのフィールドネットワークによく使われていたポーリングや、時分割、ブロードキャストのようなリアルタイム通信方式とは“全く異なるリアルタイム通信方式”を採用している事なのです。
EtherCATは、ハンドシェイクではありません。
ハンドシェイク通信は、相手の処理を待ってから先に進みます。
互いの状態をしっかりつかんで行う手順なので、ハンドシェイク(握手)と呼ばれているのです。
ところが、EtherCATでは、マスターから出発するパケットは、全てのスレイブを順番に通過して、最終端まで行ったら折り返して再びマスターへ戻っていくようになっています。
EtherCATでは、これを“1サイクル”とした伝達方法で全入出力処理を終えるのです。
使用されるイーサネットフレームのデータ部には、スレイブ毎に出力/入力データビットが与えられていて、各スレイブは自分に与えられた位置に送信データを書き込みます。
フレームから各ノードで受信データの読み込み、送信データの書き込みが完了したら、各スレイブは受信データを読み込みます。
その流れを下図に表してみました。
 210927_02


従来の通信の流れとは異なる事に気づかれたのではないでしょうか?
今までのフィールドバスや他の産業用イーサーネットでは、スレイブ個々にIPを振り当てて通信を行っているが為に、いくら高速通信対応を謳っていても、マスターが1台のスレイブと通信している間は、他の1台と通信できないという落とし穴があり、スレイブが増えるほど、それが実質的なネットワークの通信速度を下げていたのです。
それに対してEtherCATはその理論上の最高速度 100Mbpsを有効に使えるハイスピードネットワークなのです。

実はこの通信ネットワークの実質的な高速化が実現したことで、MFCはある運命の分かれ道に立たされることになります・・・

【あなたにMFCの夜が来る~真・MFC千夜一夜物語】by Deco EZ-Japan


真・MFC千夜一夜物語 第344話 MFCだって自動運転! その7 

マスフローコントローラー(MFC)PI(Pressure Insensitive)機能を題材にMFCが自動運転する事に関して論じてきています。
前回、PI機能に関して、”流量制御を一時停止!“を意味するコマンド=バルブホールドコマンドを装置側から受信した際に、MFCは設定信号(SV)と流量信号(PV)との比較制御を停止してバルブ制御信号(MV)を直前の値で保持する動作をすればいいのではないか?との問いかけをさせて頂きました。
つまり、MFCは自身の判断でPI機能を実行する=自動運転する必要は無いという考え方です。
これはMFCが装置側のPLC等のマスターに制御されるスレイブの存在である限り、正しいとDecoは思います。(この制御で使うスレイブ/マスターと言う言葉も使えなくなっていきそうですね・・・)
210906_01


ただ、このご提案を装置メーカーの方々に持ちかけると・・・あまりリアクションが芳しくないのも確かです。

「MFCの事なんだから、自分で何とかしてよ・・・」

「圧力式ならそういった問題は無いんだし・・・」

はっきりはおっしゃいませんが、こういった感想なのでしょうか?
確かに今まで、MFCメーカーって勝手に“デジタルで高性能、高速応答だ!”と半導体メーカー(エンドユーザー)さんに宣伝して、気に入ってもらえたお客様からの御指名で装置に搭載してもらうという、装置メーカーさんからしたら、「今更、システムのパーツの一つですよ!って顔されてもねぇ・・・」という気持ちになられても、不思議ではないんですよね。

それもこれもMFCは自動運転まではいかなくても、SVを貰ったら、PVと一致するようにMVを制御してしまうクルーズコントロール付き自動流量制御バルブ的な性格のせいなのです。
装置メーカーさんから見たら、自分たちの装置の中に存在しながら治外法権的なふるまいをするブラックボックスなのです。

210611_01

ただ、Decoが最近、こういったご意見をお届けしてるのは、MFCに勝手をささない、装置からのオーダー下に置くのには、絶好の機会が訪れているからなのです。
お前はどっちの味方なんだよ?と、言われそうですが・・・

1つには以前よりエンドユーザーさんのMFCに対する関心が低くなっている事です。
これは300mm装置以降、明らかな傾向です。
それだけMFCメーカーも淘汰されて、数社に絞られてきて、技術の差こそあれ、ある一線を超えるクオリティのものしか残っていない事が挙げられます。

そしてもう1点、これは技術的な面です。
産業用イーサーネット“EtherCat”のような高速産業用ネットワークがいよいよ装置のデフォルト通信規格となりつつあるからなのです。

【あなたにMFCの夜が来る~真・MFC千夜一夜物語】by Deco EZ-Japan

産業用イーサーネット vs フィールドバス マスフローでの対応

好評のネットワーク対応マスフローに関する記事です。

お馴染みのHMS社さんの産業用イーサーネット vs フィールドバスの占有率の統計ですが、2020年段階で以下のようになっています。(HMS社予測値)
210506_01


出典:”産業用ネットワーク市場シェア動向 2020” (HMS 社統計)by Thomas Carlsson | 5 29, 2020

3/31に発表された2021年予測では、産業量イーサーネットが1ポイント、無線が1ポイントさらに伸びていますが、おおむね同じ傾向です。
210506_02

マスフローコントローラー(MFC)、マスフローメーター(MFM)の産業用イーサーネット&フィールドバス対応で先端を行くブロンコスト(Bronkhorst High-Tech B.V.)の現在の対応状況は以下の通りです。

210506_03

<出典:ブロンコスト・ジャパン(株)>

ブロンコストは、マスフロー(MFCとMFMの総称)の通信機能をモジュール化して、通信モジュールを続々と開発していっていますが、昨年度だけでもフィールドバスではCANopen、産業用イーサーネットではEtherNet/IPModbusTCPと対応を増やしてきています。当然、モデルにより対応の可否があります。
例)IP65仕様の製品で通信規格が未対応のEtherCATタイプは用意できない
また、モデルによっては上図に記載のないHARTPOWERLINKに対応していたりしますので、詳細はお問い合わせください。

EZ-Japan MFCニュース by Deco

真・MFC千夜一夜物語 第319話 MFCに互換性はあるの?その5

マスフローコントローラー(MFC)マスフローメーター(MFM)のメーカー間での互換性に関するお話です。

アナログ信号でやり取りをするマスフロー(MFCMFMの総称)の場合、そのコネクターやピンアサイン、あげくは勘合ネジ腫に至るまで問題になる箇所が多いというお話を前回はさせて頂きました。

 

では、デジタルはどうなのだというと・・・

これもフィールドバス仕様が出てくるまでは、群雄割拠状態でした。

RS232CRS485RS422もありましたね)といったシリアル通信が多かったデジタル黎明期は、接続コネクターも独立した丸型コネクターだったり、前回のブロンコストさんのようにアナログ通信用D-ub9ピンの内2本分をRS232に割り振ったりと各社様々な仕様なのです。

 

でも、それ以上に問題なのは、プロトコルなのです。

いわゆる通信コマンド体系が各社ごとに異なるのです。

人間で言えば、日本語とドイツ語で話しているくらいの差があるのです。(いや、それ以上かもしれません・・・)

これでは互換性なんかある訳がありませんね?

(なぜか異なる2社で同じプロトコルを使っていたりしましたが、それは大人の事情ですw)

 

これに一石を投じたのが、前述のフィールドバスへの対応です。

例えばDeviceNetの場合、通信ケーブルはM12 DeviceNet コネクタケーブルを使うことになっています。

当然、プロトコルも共通の通信仕様が用意されています。

これで上述の互換性の問題は解消されましたね!


200720_01

 

出典:ブロンコスト・ジャパン(株)

 

ただ、互換性があるのは同じフィールドバスの中だけです。

DeviceNet と Profibus、そしてCC-Link の間には互換性は無いのです。

以前にも見てもらった統計を再度見てもらいましょう。

 

 200720_02

出典:産業用ネットワーク市場シェア動向 2019”” HMS 社統計)by Andrea Jacobson | 5 07, 2019

 

これだけの数のフィールドバスがあり、更に産業用イーサーネットが伸びてきているのです。

マスフローの本体性能には関係ないところなのですが、対応しないわけにもいかないですよね。

やはりマスフローの互換性を確保するのは、難しい事なのですね・・・

【あなたにMFCの夜が来る~真・MFC千夜一夜物語】by Deco EZ-Japan

EZ-Japan(イージージャパン)Deco こと 黒田です。 2014年6月開業です。流体制御機器マスフローコントローラーを中心に”流体制御関連の万(よろず)屋”として情報発信しています。 日本工業出版「計測技術」誌で”マスフロー千夜一夜物語”の連載中です。
QRコード
QRコード
Decoへのメッセージ

名前
メール
本文
記事検索
タグクラウド
タグ絞り込み検索
  • ライブドアブログ