«前の日記(2016年04月05日) 最新 次の日記(2016年04月07日)» 編集

一往確認日記


2016年04月06日 [長年日記]

_ ラダーのクロスプラットホーム化を考えてみる(6)

前回は抽象化したラダーデータをPLC内で解析して実行するという案を出しました。

抽象化されたラダーデーターという事で書きましたが、こういうのは名は体を表すというように名前が後々響いてくるんですよね。 大事な事ですが、とりあえずLadder(梯子)より早く進める(実行速度ではなく開発期間を早める)という意味でEscalator(エスカレーター)にしておきましょう。

今回はそのPLC内部を図式化してみます。

右側のデータエリア内の~~Elevator~~ Escalator Programが抽象化されたラダーデータを表します。 用語の統一というのは苦手なのですが、中間ラダーデータとでも呼びましょうか。

左側のプログラムエリア内の~~Elevator~~ Escalator Runtimeが、その中間ラダーを読み取って実行する部分です。 ~~Elevator~~ Escalator Work Dataはその処理で使うワークエリアや、ローカル割り当てのエリアとなります。

黄色の部分が今考えている~~Elevator~~ Escalatorの部分となります。

PLC Firm Wareが元々のPLCがラダープログラムを実行する部分ですが、その上に同じようなことをするプログラムを置くのですから、非効率ですね。 さらに、少ないメモリの中に中間ラダーデータを取るわけで、こんなのが本当にできるのか?という感じですね。

しかし、この様な課題は時間やお金で解決できる場合もありますので、遠い将来にはそういうリソースを持っている方が現れることを願いましょう。

元々のラダー*1を併用できますので、速度やクリティカルな部分はネイティブなラダーにお任せします。

一部訂正しました

続く

*1 User Program、User Dataの部分