【シリーズすごいぞiQ-F】「いわゆる構造化プログラミング」への道　オマケ1～構造体型ラベルの転送について

Posted at 2025-05-05

はじめに

ここまで「いわゆる構造化プログラミング」として4回に分けて記事にしました。
しかし、良いことばかりでは無く、従来型プログラムに慣れていると引っかかるポイントがいくつかあったので雑多ですがオマケとして紹介します。

あたりについて書きたいと思いますが、気が変わって歴史修正するかもしれません。

ST又はインラインSTを使用する
- 型が同じ構造体のインスタンス同士の代入で記述できます
- 構造体型ラベルにデバイスが割り付けられているとステップ数が増大します
汎用ファンクションの算術ファンクションを使用する
- 算術ファンクション　「MOVE」を使用する
- 構造体型ラベルにデバイスが割り付けられているとステップ数が増大します
CPUユニット命令を使用する
- ワードは「BMOV」、ビットは「BLKMOVB」を使用してブロック転送する
  - デバイスの連続性が保証される範囲を正確にしていする必要があります
  - 以下の例は「w_読み出しデータ」は配列型8要素で、連番で定義されている転送先の構造体メンバのw_Dat01からDat08へブロック転送されます
- 構造体型ラベルにデバイスが割り付けられていてもステップ数に影響はありません

デバイスを割り付けた構造体型グローバルラベルを転送すると、内部ではデバイス1点ずつのMOV命令に変換され、ステップ数が増大します。

この事がどのようにプログラミングに影響するか考えます

ハッキリしたことは言えませんが、従来1万ステップ程度で収まるプログラムであれば2，3倍のステップ数が必要になる可能性があります。

私の場合は48,000～64,000ステップの間に収まる事はほぼ確実なので問題視していませんが、皆さんの場合はどうなのか正直分かりません。

プログラムを全てMOV命令で埋め尽くしたとして概算します。
MOV命令4ステップ、命令実行時間（高速命令）として

私の場合はこの程度のスキャンタイムの増加は全く問題の無いプログラムしか組みませんが、影響がある方は事前に詳細な検討が必要かと思われます。

主にデバイスを割り付けてあるラベル同士での転送に使用します。

以前、構造体のメンバを8とか10とか連番で決まった数用意するというのはこれを行うためでもあります。

転送数の指定を間違えると思わぬバグを招くので十分注意してください。

構造体型ラベルにデバイスを割り付けてある場合はデバイス転送と同じ考えでBMOV系の命令を使用し、割付が無い場合はCPU命令以外でのSTなどでの転送を行うのが定石でしょうか。

ステップ数が許容できる範囲ならデバイスを割り付けていてもSTやMOVEでの転送でも良いでしょう。

マクロ型ファンクションブロックを使用すると、FBへの入出力は転送では無くFBのロジック内へ直接書き込まれる形で変換されるので転送によるステップ数の増加はありません。

但し、処理の方がプログラム中に配置したFBのインスタンスの数だけステップを費やす事になります。

三菱で用意しているユニットFBが全てマクロ型ファンクションブロックなのは、FBの入力に用いる巨大なユニットラベルの転送を行わないためです。

構造体型ラベルの転送について、プログラムをしていてステップ数の増加に驚いたので記事にしてみました。

この辺はプログラムの本質に関係ない小賢しい話ではありますが、過渡期として必要なテクニックと考えて諦めています。