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

【お知らせ】

今まで本ブログは、"EZ-Japan BLOG since 2017”と　"真・ＭＦＣ千夜一夜物語”@niftyココログ版の2つで同時連載進行を行って参りましたが、既に告知の通り2019/5/11をもって@niftyココログ版の方を終了させていただきました。こちらのブログ"EZ-Japan BLOG since 2017"版での連載は、変わらず続けて参りますので、どうか千夜一夜＝1001話にたどり着く迄、宜しくお願い申し上げます。

前回はPI（=Pressure Insensitive）、つまり圧力変動影響緩和型マスフローコントローラー（MFC）を例に取って、MFCの自動制御をやめさせる機能が、逆にプロセスでは役に立つこともあるというお話をしました。
MFCが外部から入力されたSV(流量設定信号)と、流量センサーが計測したPV(流量信号)が一致するようにMV(バルブ制御信号）を可変させる自動制御機能を搭載している事は、一つの大きなアイデンティティなのですが、時と場合によるという事ですね。

自動制御という独自性をMFCから奪うならば、MFCを流量センサーと流量制御バルブ、そして調整計の一体型である必要性も薄くなることになります。

特に調整計の機能は、装置側のPLCでPID制御を行い、大量のデータを高速で伝達できる産業用イーサーネットで流量センサーからのPVと流量制御バルブのMVをやり取りすればいいのではないかとDecoは考えています。(下図)

このシステム案は20年近く前、フィールドバスが普及し始めた頃にDecoと業界に友人で考えたシステムに遡るのですが、コストや互換性、通信速度他の問題があってお蔵入りにしたものでした。その後のMFCの進化の道を振り返ってみると、PI-MFCに行く前にもっと積極的に熟成して御提案すべきだったかと、悔やんでもいます。

この独立した流量制御バルブ(比例制御弁)をメインに据え、流量センサーによる流量制御、圧力センサーによる圧力制御、そしてPLCからの指示で任意開度でバルブをホールドする等の機能を備えた流量モジュールに関しては、これから色々と発信していこうと考えています。

【あなたにＭＦＣの夜が来る～真・ＭＦＣ千夜一夜物語】by Deco　EZ-Japan

【お知らせ】

今まで本ブログは、"EZ-Japan BLOG since 2017”と　"真・ＭＦＣ千夜一夜物語”@niftyココログ版の2つで同時連載進行を行って参りましたが、既に告知の通り2019/5/11をもって@niftyココログ版の方を終了させていただきました。こちらのブログ"EZ-Japan BLOG since 2017"版での連載は、変わらず続けて参りますので、どうか千夜一夜＝1001話にたどり着く迄、宜しくお願い申し上げます。

前回はPI（=Pressure Insensitive）、つまり圧力変動影響緩和型マスフローコントローラー（MFC）のお話をしました。

PI-MFCはMFCの上流で一時的にレギュレーターからの供給圧力が急降下した場合、MFCはその急峻な圧力変動に応じた制御をMFCが行った結果、流量制御にスパイク波形が入ることを、内蔵した圧力センサーで感知して、流量センサーと制御バルブのフィードバック制御に「待った！」をかけ、バルブ開度を一時的にホールドすると事で緩和させる仕組みを持っています。

これはSV(流量設定信号)＝PV(流量信号)とするようにバルブ制御信号（MV）を自動制御するのをやめさせる仕組みを持っていると言い換えられます。

　同じようにSVが０以外のある値でMFCに入力された状態で、何らかの理由でガスの供給が遮断された場合、MFCの調整計はSV＞PVの状態をSV=PVとすべく、MVを増やすことでバルブ開度最大で待機することになり、導入時に大きなガスサージを発生させるトラブルに対しての対応も、MFCに自動制御をやめさせる、つまりSV＝PVとするようにMVを制御するのをやめさせることでした。

つまり、MFCの引き起こしたと思われていた流量制御波形に関するトラブルは、実はMFCが忠実に自動制御を行った結果生じたものであった可能性が高いのです。

忠実に動作するが故にトラブルとなる。

不思議ですよね？

配管機器の中で唯一といっていいい、「流量センサーの値を用いて、予め設定された流量値になるよう、比例制御弁を操作する」という自動制御を行うMFCですが、決して万能ではありません。
その対処方法として「自動制御をやめさせる」のですが、そのタイミングを判断するのは何か？を考えると前述の事例では2種類があります。
1つが外部、上位制御系から、自動制御を停止するコマンド、信号類を入力する方法。
もう一つは圧力センサー等を追加し、その信号を元にMFC自身がその判断をする方法です。

Decoの持論では、通信速度や情報量が拡大された産業用イーサーネットの時代である現在では、後者の選択（PI-MFCのようなMFCで判断するタイプ）は意味がないのではないかと思っています。
なぜならPI-MFCの項でお話ししたように、MFCがPI動作をするか？しないかを判断するのは圧力センサーからの信号に時間軸と大きさで閾値を設ける必要があります。
でも、それでも誤った判断をMFCが100%しないわけではないのです。
100%、その答を知っているところからMFCへ指示した方が確実ですし、MFCに無駄なコストを追加する必要もありません。

それは他ならぬ装置自身、例えば制御を司るPLC自身なのです。

配管ラインのバルブの開閉は全てPLCからの指示で行われている筈です。

ならばPLCは、どのタイミングで、どのラインのMFCに一次圧変動影響が出るかは知っている筈ですね？

その情報を元に、MFCに自動制御を停止する“バルブホールドコマンド”を送ればいいのです。

それとMFCの上流にある圧力センサーからの信号を用いれば、その変動影響の規模もある程度把握できるので、PLC側でホールドコマンドを解除するタイミングの確認に使えます。

このホールドコマンドをデジタル＆アナログでMFCメーカー各社統一仕様にして置けば、装置メーカーさんも使いやすいのではないでしょうか？

【あなたにＭＦＣの夜が来る～真・ＭＦＣ千夜一夜物語】by Deco　EZ-Japan

 そもそもマスフローに対するフィールドバスとは、どういった役割を果たしているのでしょうか？

この質問に正確に答えられる人は、あまりいないかもしれません。

少し前によく聞いたのは、以下のやり取りです。

「フィールドバス ＝ DeviceNet対応マスフローは性能がいい。」　

答）　×　マスフローとしての基本性能は変わりません。

「フィールドバス ＝ DeviceNet対応マスフローは通信速度が早くて、大量のデータが送れる。」　

答）　△　ネットワークとしては早いですが、そもそもマスフローの熱式流量センサーはいたって遅いセンサーですし、SV値に対するPV値とMV値以外に特にやり取りすべきコマンドは存在していないので、大量のデーター通信は不要です。

「フィールドバス　＝ DeviceNetに対応できていないマスフローは、世界的にガラパゴスな存在になってしまう。」

答）　×　前回の市場シェアグラフ（出典：HMSインダストリアルネットワークス 産業用ネットワーク市場シェア2018）を見る限り、産業用イーサーネットの躍進を見ると、むしろ逆かもしれませんね。

フィールドバスは、そもそもマスフローと何との間を取り持とうとしているのでしょうか？

答えはPLCです。

PLCとはProgrammable Logic Controller の略称で、シーケンサーとも呼ばれます。
ただ、シーケンサーは、三菱電機(株)の製品名ですので、一般的な機器を指す場合はPLCと呼称した方が良いでしょう。

PLCが何をするものか？というと、簡単に言えば「要求された入力内容に従って、予めインプットされたプログラムを動かし、接続された機器(マスフロー等)へ動作指示を出力する役割を果たす機器」です。

装置の自動制御に特化したコンピューターのようなものと考えればいいでしょう。

で、そのＰＬＣは単独では何もできない箱ですので、多数の機器と接続することになります。

その一例がマスフローですね。

マスフローへ設定指示(ＳＶ値)を送る場合、マスフローの流量信号(ＰＶ値)を読み出す場合、このＰＬＣとマスフローの間で共通言語が必要になります。

これがフィールドバスです。

例えるなら、サッカーチームの監督がドイツ人で、ドイツ語で指示をするのに、選手が日本語しかわからなかったら、指示は伝わりません。

ミーティングで選手からの日本語での情報も監督には全く伝わりません。

それではチームは機能しませんね？

ＰＬＣがアレンブラットリーやオムロンならば、DeviceNet　で対話するのをルールにしていて、シーメンスならProfibus、三菱電機ならばCC-Linkといった具合に、PLCメーカーは自らの製品に対応するPLCを決めています。

「えっ、それってPLCメーカーの数だけ、フィールドバス対応品をマスフローメーカーは開発しなきゃいかんの？それにどんな意味があるの？」　

こんなセリフを十数年前にDecoはフィールドバスの説明に来てくれた業界の友人に投げかけたのでした・・・・

＜つづく＞

マスフロー徒然日記　by　Deco EZ-Japan