Instant Engineering

エンジニアの仕事効率を上げる知識をシェアするブログ/QC統計手法/公差設計・解析/TPS(トヨタ生産方式)

Plant Simulation:Source属性タブのブロッキングとバッチとして生成 -Number Adjustable-

DX時代:【第4回】シーメンス製の生産シミュレータ「プラントシミュレーション」の使い方を習得

www.plm.automation.siemens.com

 

Plant Simulation 15に収録されているサンプルモデルを使って基本操作を習得する。

第4回はカテゴリ「マテリアルフロー」、トピック「Source」、サンプル「Number Adjustable」を使っていく。サンプルモデルからの学び方は、以下の手順で行う。

STEP1:サンプルモデルを開き、どのような仕事内容をシミュレーションするものかを把握する。

STEP2:それぞれのオブジェクトの設定項目を参照し、定義の仕方を確認する。

STEP3:概要を理解したところで、設定の一部を変更して、意図した通りにシミュレーションの結果に反映されるかを確認する。

サンプルモデルの難易度によって、多少の変更はあるかもしれないが、流れとしては概ね上記のような進め方で習得していく。

 

◆サンプルモデル

 マテリアルフロー ⇒ Source ⇒ Number Adjustable

 

STEP1:どのようなサンプルモデルか?

どのようなサンプルか把握するためにまずはイベントコントローラを実行してみる。シミュレーション動画を以下に示す(Vimeo)

Sourceが上下に2つあって、それぞれLineオブジェクトにつながっている。Sourceはどちらともその左側にある同じData Tableを参照してると思われる。シミュレーションを実行すると、赤・緑・青の箱(MU)がLine上に流れてきて、下側のSourceの方が多くのMUを作成したようだ。ざっくりとサンプルモデルの動きの概要は以上だ。

(全然どうでも良いが、赤・緑・青というこの組み合わせに何か既視感があると思ったら初代ポケモンだった)

さて、では各オブジェクトの設定項目詳細を順に確認していく。

 

STEP2:オブジェクトの設定項目を確認

まずは左上の「Source」オブジェクトから属性タブを開くと以下のようになっている。 

f:id:yuinomi:20210717144238p:plain

MU選択は「順番に繰返して選択」が指示され、参照先としてData Table「MUSelection」が定義されている。

作成の時間は「個数による調整」で個数が5個なので、参照先Data Tableの表で上から順に5個まで作成するSourceだ。

作成時は「一定」で1:00としているので、シミュレーション実行後1分経過時点からData Tableに従ってMUを作成する。(”作成時”というのはSourceが最初のMUを生成する時点を指す。)

Sourceの属性タブで特に重要な「作成の時間」についてさらに細かく見ていく。

f:id:yuinomi:20210717145758p:plain

作成の時間は4種類から選択する。それぞれ内容は以下のような感じだ。

間隔時間による調整・・・MUの作成を開始する時間、次のM作成までの間隔、終了時間を指定する。

個数による調整・・・量として入力した数のMUを作成する。【今回はコレ】

配布テーブルによる調整・・・配布テーブルで定義した配布時間、クラス、個数、名前、属性に従ってMUを作成する。

トリガ・・・一連のトリガオブジェクトが制御する値に従ってMUを作成する。

 

次に参照先として指定されているData Table「MUSelection」を確認する。

f:id:yuinomi:20210717144507p:plain

MUとして3つ定義されている。指定パスは .Models. SourceTrigger. A~Cである。個数はAが1個、Bが2個、Cが3個として指示されている。

クラスライブラリのツリーを確認すると「A~C」のMUオブジェクトが確認できる。

f:id:yuinomi:20210717144515p:plain

「A」という名称のMUを開いてみたが、特に設定はされていないようだ。グラフィックタブの色だけ設定があって、Aが赤、Bが緑、Cが青として定義されている。

f:id:yuinomi:20210717150959p:plain

 

次に下段の「Source_AsBatch」オブジェクトを確認する。

f:id:yuinomi:20210717151346p:plain

属性タブを確認するが、上段の「Source」と同じに見えてどこが違うのか一見分からない。間違い探しのように見比べると、”バッチとして生成”にチェックが付いてるということだけが、上段のSourceとの違いだった。

f:id:yuinomi:20210717151350p:plain

この”バッチとして生成”の有無が今回のサンプルモデルの最重要ポイントである。

【作成の時間:個数による調整】で”バッチとして生成”を有効にした時、個数として入力した5という数字は、単体MUの数ではなく、バッチ数を表すことになる。

今回のモデルを実行した時、上のLineには5個のMUが流れたのに対して、下のLineはそれよりも多い9個のMUが流れていた。

f:id:yuinomi:20210717160836p:plain

下のSourceはバッチとして生成をするため、参照先のMUSelectionの1行を1バッチとして処理するためにこのような違いが生まれる。

”バッチとして生成”の選択有無による差を以下に示す。

f:id:yuinomi:20210717161546p:plain

上の表がバッチとして生成にチェックを入れないパターンだが、この場合は「個数による調整」で指示した5個までMUを生成するので、MUSelectionにはMU「C」の個数は3個として定義されているが、Cを2個作った時点で合計が5個になりSourceとしては打ち止めになる。

下の表はバッチとして生成を有効にしたパターンで表の1行が1バッチとして処理される。

 

 

次に、同じSourceオブジェクトの属性タブにある「オペレーティングモード:ブロッキング」についてだが、これは特別な事情がない限りは普通チェックを付けて有効にしておけば良い。Plant Simulationヘルプには以下のように説明されている。 

 

ブロッキングを選択すると、Source は次のMU を生成するはずだったタイミングを記憶します。その場合、次の可能な時間の点で、つまり、下流によってブロックされていたMU が移動されたときに、次に続くMU を生成します。シミュレーション時間が停止時間に達すると、Source はパーツの作成を停止します。

ブロッキングをクリアすると、Source は入力した生成のタイミングで別のMU を排他的に作成します。

 

後工程が受け取りできるかを無視して排他的に生成するというのは、現実のラインで考えにくいので、あまり使うことはなさそうだ。少し長くなったが、Sourceオブジェクトに関して設定が異なる箇所は以上だ。

 

次にLineオブジェクトを確認する。上下に2本Lineが並んでいるが、どちらも設定は同じである。属性タブを以下に示す。

f:id:yuinomi:20210717152043p:plain

コンベア長さ20m、送り速度0.5mなので、入ってきて出ていくまでの時間が40秒である。余談だが、Lineは”長さ”がオブジェクトサイズにそのまま反映される。

容量は-1なので定義されておらず、今回のサンプルモデルではMU「A~C」の長さがいずれも1mなので、最大で20個のMUが詰めれば配置できるサイズである。

 

続いてはDrainオブジェクトを確認したが、こちらはデフォルトのままで特に設定はされていなかった。

f:id:yuinomi:20210717152840p:plain

そしてDrainの右側にはData Tableが並んでいる。上段の「GeneratedParts」を開くと、以下のような空マスの表があった。

f:id:yuinomi:20210717152858p:plain

訳すと「生成されたパーツ」という表なので、シミュレーションを実行することによって、ここに実績データが反映されるものと思われる。列は名称、パス、生成時間の3つがある。イベントコントローラの隣に「endsim」メソッドオブジェクトがあるので、ここにプログラムがある。

シミュレーション実行後にData Table「GeneratedParts」を開くと、データが5行分展開されていた。

f:id:yuinomi:20210717152905p:plain

3列目の生成時間はSourceオブジェクトが当該のMUを生成した時間だ。2~5行目が2秒ずつ時間差があるのは、今回のサンプルモデルではSourceから直接Lineに移送していて、Lineの送り速度が遅いためにLine上に次のMUを配置できるだけのスペースをできるのにラグがあるからである。

2列目 .Models. SourceTrigger. A:2 MU名称の後に付く数字は生成された順番を示す。

 

では、次はSourceの生成情報をGeneratedPartsへ書き出すよう指示している「endsim」メソッドを見ていく。(endSimは、Plant Simulationでシミュレーション実行完了後に呼び出されるメソッド)

f:id:yuinomi:20210717154953p:plain

書かれているプログラムはシンプルなたった2行だった。

 

source.creationTable(GeneratedParts)
source_AsBatch.creationTable(GeneratedParts_AsBatch)

 

メソッドの”creation Table”文は、パスで指定したSourceの生成テーブルを戻し、それをテーブルに記述する。ところで、ただ転記しているだけなら、そもそもSourceオブジェクト自体で生成記憶を持っているはずで、Sourceオブジェクトの統計情報タブから同じものを見ることができる。

f:id:yuinomi:20210717155649p:plain

統計情報タブの「生成テーブル」にチェックを付けておけばシミュレーション実行時のSourceの生成イベントをすべて記憶してくれる。これを別の表に転記したのが今回のサンプルモデルのようだ。

 

STEP3:一部を変更してシミュレーション結果の確認

サンプルモデルの設定を逐一確認して概要を理解できたので、一部を変えてみよう。今回の主要部であるMUSelectionの表を以下のように書き換えた。

f:id:yuinomi:20210718065622p:plain

Aが1個、Bが4個、Cが5個とする表。これで上段のSourceは生成個数が5個なのでCが一つも生成されなくなり、下段のSource_AsBatchは合計15個のMUが生成されるはずである。

f:id:yuinomi:20210718065627p:plain

シミュレーション実行をすると上記のようになった。狙い通りの動きに変更することができた。