0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【シリーズすごいぞiQ-F】GX_Works3でGX_Works2時代に挫折した構造化プログラムに再び挑む

Last updated at Posted at 2024-04-12

本記事はラダー言語を対象として記述しています。

GX_Works2での構造化プログラムとは

2008年頃に発行されたマニュアルを一部引用して記載します
従来のラダープログラムマニュアルとは別に、構造化プログラムマニュアルがシリーズ化され発行されていました。

定義

「構造化プログラムとは、シーケンサCPU(PLC)で行う制御内容を階層的な構造にできるように小さな処理単位(部品)に分けて、プログラミングする手法です。」

作成手順

  1. プログラム構成の作成
  2. プログラム部品の作成
    • ファンクションブロックの作成やラベルの定義
  3. プログラムの編集
    • プログラム部品をプログラムに配置して編集
  4. コンパイル
    • 変換の事を構造化プログラムではコンパイルと呼んでいた

ラベルとファンクションブロックやファンクションを使用したプログラミングと理解できます。

GX_Woks3での構造化プログラムとは

iQ-Fでは「MELSEC iQ-F FX5プログラミングマニュアル(プログラム設計編)」にてプログラムの構成について説明されていますが、構造化プログラムと記載されることは無く、順番にラベルやファンクションブロックの説明がされるようになりました。
それに伴い、コンパイルに関しては記述が無くなり従来からの「変換」が使用されています。

1ヵ所コンパイルという記述が残っていますが校正ミスと思われます

それにしてもGX_Developer、GX_Works2と順番に使ってきたのでマニュアルの基本的な部分に注意を凝らして読んでこなかったのですが、(プログラム設計編)ではラベルやファンクションブロックを使用してプログラムを組むのが当たり前という立ち位置で驚きました。
デバイスの種別の説明は(応用編)にて記載がありますが、桁指定などの説明はいったいどこにあるのでしょうか。

  • 従来通りのアドレスプログラムでプログラムをしたい
  • 市販の参考書を見ながらPLCを覚えたい

といったときにFX3のマニュアルを推奨するしかありません。

色々長くなりましたが、GX_Works3でラベルやファンクションブロックを使用するにあたって払拭した懸念についての記事です。

GX_Works2での構造化プログラムで挫折した理由

ラベルメモリとデバイスメモリが共用だった

GX_Works2でのラベルには必ずデバイスが割り付けられる仕様でした。

  • グローバルラベル
    • ラベル定義時に手動でデバイスを割り付ける
  • ローカルラベル
    • コンパイル時に割り付け範囲から自動デバイスが割り付けられる

今考えると上手く使えばこれは問題なかったのかもしれませんが、気持ちが悪くて使う気になれませんでした。

ラベルではデバイスで多用する記述方法が使用できなかった

ビットラベルの桁指定が出来ない

「K4M0」なとと同様な「k4b_label1」という指定ができません。
アラーム処理などで複数ビットをワードに変換する処理はよく行っているので困りました。

ワードラベルのビット指定が出来ない

「D0.1」などと同様な「w_label1.1」という指定ができません。

他にも制約があったのですが使ってないので良く思い出せません。

ソース情報を書き込むメモリがプログラムメモリと共用

PLCから読み出したプログラムを復元するためにはソース情報をPLCに書き込む必要があるのですが、これがプログラムメモリと共用でした。

結局、上記の仕様があって、「デバイスで組めばいいじゃん」となってしまいました。

GX_Works3では改善されたか?

結論から言って、私がGX_Works2での構造化プログラムで挫折した理由は全て改善されていました。

ラベルメモリがデバイスメモリから独立した

ローカルラベルにはデバイスは割り付けられなくなりました。
グローバルラベルには必要に応じてデバイスを割り付けるのですが、

  • デバイスを割り付けた場合
    • デバイスメモリを消費
  • デバイスを割り付けない場合
    • ラベルメモリを消費

となっています
デバイスは通信用にまとまった領域を確保するのでラベルとの取り合いが無くなりました。

ラベルでもデバイスで多用する記述方法が使用できるようになった

ただし、ビットラベル配列を桁指定する場合
「k4w_label1[0]」では無く、添え字を省略して「k4w_label1」となります。
従って、0以外を始点とすることができません。
0以外を指定したい場合はビット転送や多点ビット転送を併用します。

ソース情報を書き込むメモリはプログラムメモリから独立した

プログラムのソース情報は下記に分散して保存されるようになりました。

  • データメモリメモリ/プログラム 1024kB
  • データメモリ/復元情報 1024kB
  • データメモリ/パラメータ 1024kB
  • データメモリ/デバイスコメント 2048kB

ただし、どれに何が保存されるかは正確には分かりません。
私がテストしたときはローカルラベルはデータメモリ/プログラム、グローバルラベルはデータメモリ/パラメータといった具合でした。
マニュアルにも詳細な記載は無く、メーカーに問い合わせてもハッキリとした回答はありませんでした。

おわりに

私以外にもGX_Works2での構造化プログラムの印象が悪く、GX_Works3そのものやGX_Works3でもラベルを使用していない方もいるかもしれないという想いで記事にしてみました。

過去記事一覧

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?