Skip to main content

モジュール宣言

モジュールの宣言は、構造化テキスト (ST) コードでの変数の宣言に似た独自の記述言語を使用して行われます。

モジュール宣言の形式

フォームのヘッダー MODULE<name> 宣言が始まります。これに「セクション」のリストが続きます。

各セクションをキーワードで紹介 SEC (「セクション」の場合) および一意の名前。キーワード END_SEC セクションを閉じます。セクションの内容には、さらなるセクションまたはいわゆる定義で構成されるエントリのリストが含まれています。

定義は名前とオプションの値で構成され、セミコロンで終わります。

コメントは ST コードと同様に使用できます。単一行コメントの場合は「//」、複数行コメントの場合は「(*」および「*)」です。各部分の区切りには空白 (タブとスペース) と改行/改行を使用できます。それ以外の場合は、以降の処理中に無視されます。

ST コードと同様、大文字と小文字の区別は関係ありません。

14. 次の例では、モジュール宣言の要素について説明します。
01    MODULE Persistence IMPLEMENTED_BY PersistenceFB
02    SEC MetaData
03        NAME       := TL.ChannelName ;
04        DESC       := TL.ChannelDesc ;
05        COLLECTION CATEGORY := ’Persistence’TL.Collection  ;
06        ICON_16    := IP.Channel16 ;
07        ICON_32    := IP.Channel32 ;
08    END_SEC
09    SEC Toplevel
10              SEC STANDARD_TASK : LOW
11                      NAME  := LOW ;
12                      DESC  := TL.TaskLow ;
13                      FLAGS := CREATE_IF_MISSING | READONLY ;
14              END_SEC
15              GVL_NAME := 'GVL_%InstanceName%' ;
16     END_SEC

01行目にはモジュール名「Persistence」の定義があります。 IMPLEMENTED_BY モジュールのロジックを含む関数ブロック「PersitenceFB」を定義します。この関数ブロックは次から派生する必要があります。 IModule。 02 行目のセクション MetaData このセクションには 5 つの定義が含まれています。ネストされたセクションの可能性は、セクションに示されています。 Toplevel (行 09 ~ 16) にはサブセクションが含まれています STANDARD_TASK (10行目)。



モジュール宣言の構文

このセクションでは、モジュール宣言の構文と許可される構文構造について説明します。

次のスキャナーでは、トークンは大文字で書かれます (例: ID)。文法の非終端は中括弧で書かれます (例: {Entry})。

字句解析(スキャナー)

最初のステップでは、いわゆるトークン (または語彙素) がモジュール宣言の文字 (例: キーワード、定数、識別子) から作成されます。

空白文字と改行/改行文字はトークンを区切りますが、それ以外の場合は無視されます。コメントも、宣言の今後の処理では無視されます。 (コメントは一行で記述できます(//") または複数行のコメント ((* そして *)) ST 言語と同様です。複数行のコメントは入れ子にすることができます。

基本的に、トークンには常に最大長があります。例えば a123 識別子としてではなく識別子として解釈されます a 続いてリテラル 123

以下のリスト内のトークンの順序は、その優先度を示しています。たとえば入力 MODULE は識別子ではなくキーワードとして理解されます。

. 利用可能なすべてのトークンのリスト:
  • キーワード: MODULESECEND_SECIMPORTS、 そして IMPLEMENTED_BY

  • OP: 次の文字の空でないシーケンス: .:,%()[]{}<>|+-*/@!?^°=\~

    注: コメント マーカー //(* そして *) 演算子よりも優先度が高くなります。一方、コメントは演算子内で始めることはできません。たとえば、 +//+、最大長のルールに従って、演算子としてではなく演算子として読み込まれます。 + コメントが続きます。

  • LIT: ST で使用される IEC リテラル。例: 1.4tod#12:13:14。これにはブール値リテラルが含まれます TRUE そして FALSE (大文字または小文字は関係ありません)。

    注: 型なしリテラルの前に負符号 (-1-3.2) は 2 つのトークン、つまり演算子として読み込まれます。 - その後に型なしリテラルが続きます。したがって、型なしの数値リテラルは決して負になりません。型付きリテラル (INT#-34) は常にトークンとして読み取られます。

  • ID: 有効な IEC 識別子 ([a-zA-Z_][a-zA-Z0-9_]*)、2 つの連続した下線は許可されません。これには、ST とは対照的に、ST のキーワードも含まれます (つまり: FUNCTIONINTEXTENDS、…)

  • セミコロン: 文字 ;

構文 (パーサー)

モジュール宣言の構文は次の文法で定義されます。 µ は空のシーケンスです。

{MDecl}        ::= MODULE {QID} {ImplSpec} {ImportsSpec} {MBody}
{ImplSpec}     ::= IMPLEMENTED_BY {QID} | µ
{ImportsSpec}  ::= IMPORTS {QID} | µ
{MBody}        ::= {SecList}
{SecList}      ::= {Modifiers} {Sec} {SecList} | µ
{Sec}          ::= SEC {QID} {SecTarget} {EntryList} END_SEC
{SecTarget}    ::= OP(":") {QID} | µ
{Modifiers}    ::= OP("[") {ModifierList} OP("]") | µ
{ModifierList} ::= {QID} OP(",") {ModifierList} | {QID}
{EntryList}    ::= {Modifiers} {Entry} {EntryList}
{Entry}        ::= {Sec} | {Def}
{Def}          ::= {QID} OP(":=") {ValList} SEMICOLON |
                   {QID} SEMICOLON
{ValList}      ::= {Val} {ValList} | {Val}
{Val}          ::= ID | LIT | OP
{QID}          ::= ID | ID OP(".") {QID}

定義値のリスト ({ValList}) はセミコロンで完了する必要があります。これにより、文法が簡素化され、曖昧さが回避されます。これは、セミコロンを値の一部にすることができないためです ({VAL})、文字列リテラル内を除く。

代入演算子 (:=) の定義 ({Def}) 曖昧さを避けるのにも役立ちます ({QID}) の定義名と値。

定義の定義済みタイプ

  • テキスト: ID.ID (テキスト リスト名およびテキスト リスト識別子) - を参照してください。 テキストリスト文字列のローカライズ

  • 画像:ID.ID(イメージプール名とイメージプール識別子)

  • ID(IEC識別子)

  • QID (修飾された識別子): {QID} ::= ID | ID.ID

  • CategoryPath ::= {StringLiteral} | {CategoryPath}

  • カーディナリティ: [{MIN} .. {MAX}] | [ {MIN} .. INF [ {MIN}、 そして {MAX} は整数の非負のリテラルです。もし {MAX} != INF、 それから {MIN} <= {MAX} 申請しなければなりません。

  • StringLiteral: IEC 文字列リテラルには改行が含まれる場合があります。

  • StdTaskFlags ::= {StdTaskFlag} | {StdTaskFlags} StdTaskFlag ::= NONE | CREATE_IF_MISSING | READONLY

  • リテラル: 任意の IEC リテラルまたは QID (Enum 定数の場合)

  • DTBoolフラグ: µ (空のシーケンス) | TRUE | FALSE

  • スロットタイプ: SUBMODULE | REFERENCE

  • プラグマ: [ {PragmaList} ] {PragmaList} ::= {Pragma} | {Pragma} , {PragmaList} {Pragma} ::= { ( ID | {StringLiteral} | {OP2} )+ } {OP2} : を除くすべての演算子 {, }, [, ] そして ,

  • インスタンスパス:

    InstancePath ::= {IComp} | {IComp} . {IComp} ミット {IComp} ::= ID {ArrayAccess}*{ArrayAccess} ::= [ {IntList} ]{IntList} ::= Int | Int , {IntList}

  • タスク参照: Standard_Task。 ( Low | Medium | High) | Custom_Task.ID

インスタンスパス

モジュール宣言の一部の位置では、関数ブロックの変数をアドレス指定するためにインスタンス パスを定義できます。パラメータ、スロット、I/O、可変サイズの配列、およびインスタンス参照の場合です。

インスタンス パスは、ドットで区切られた空でないコンポーネントのシーケンスとして定義されます。 C1.C2…CN。コンポーネントは、IEC 識別子、またはその後にインデックス式が続くコンポーネントである必要があります。 [i1, …, iN]、 どこ i1iN は整数値です。

インスタンス パスは常に、モジュール ロジックを実装する関数ブロックに対して相対的です。インスタンス パスの最初のコンポーネントはメンバー (VAR_INPUT または VAR_OUTPUT、ユースケースに応じて)機能ブロックの。インスタンス パスに追加コンポーネントがある場合、これらのコンポーネントはメンバー内の変数に対応します。それ以外の場合は、メンバー自体がアドレス指定されます。インスタンス パスは、入力変数または出力変数に制限できます (例: I/O の場合)。構造体の場合、これらの制限は無効です。この種のインスタンス パスは、それぞれ入力インスタンス パスと呼ばれます。インスタンスのパスを出力します。

テキストリスト文字列のローカライズ

モジュール内のテキスト (例: モジュールの説明、名前、パラメータの説明) をさまざまな言語で表示できます。これらのテキストはテキストリストで管理されます。

. 言語名の仕様:
  • 言語の名前は次の形式です <LanguageCode>[-<Country/Region>] (例: en-USde-DE)。

  • <LanguageCode> ISO 639-1 に基づく言語の名前です (例: de または en)。

  • <Country/Region> ISO 3166 に準拠した国コードです。

  • テキスト リスト エントリを取得するとき、システムは最初に言語名全体を検索します。何も見つからない場合は、 <LanguageCode>。この検索も失敗した場合は、デフォルトのテキストが使用されます。

8. テキストリスト内の言語名の例

言語

言語の名前

中国語

zh-CHS

英語

en-US

フランス語

フランス-フランス

ドイツ人

脱DE

イタリアの

IT-IT

日本語

日本

ポルトガル語

pt-PT

ロシア

るる

スペイン語

エスエス



モジュール宣言の導出

ファンクション ブロック B からのファンクション ブロック A のオブジェクト指向継承 (「EXTENDS」) と同様に、 IMPORTS キーワード。修飾子 UPDATE そして HIDE 特別扱いされている。

. 次のルールが使用されます。
  • このモジュールが別のライブラリで定義されている場合は、インポートされたモジュールの名前を名前空間で指定する必要があります。

  • 周期的なインポートは許可されていません。特に、モジュール自体をインポートしてはなりません。 (循環インポートの例: モジュール M_1 がモジュール M_2 をインポートし、M_2 が M_3 をインポートし、…、M_N が M_1 を再度インポートします。)

  • 派生モジュールは、 IMPLEMENTED_BY 指令。この場合、基本モジュールの機能ブロックが使用されます。

  • 派生モジュールが関数ブロックを指定している場合 ( MPLEMENTED_BY)、この機能ブロックは基本モジュールの機能ブロックから派生するか、それと同一である必要があります。

  • 派生モジュールは、基本モジュールのすべてのセクションを継承します。新しいセクションを追加したり、既存のセクションを変更したりできます。

  • 派生モジュール内のセクションは、修飾子で拡張された同じ名前とターゲットを使用して変更できます。 UPDATE。この場合、そのエントリは変更されます。派生モジュール内のセクションの欠落している定義はすべて、基本モジュールから引き継がれます。

  • 修飾子 UPDATE そして HIDE それぞれのセクション (名前とターゲット) が基本モジュールで定義されている場合にのみ使用できます。逆に、ベースモジュールで定義されたセクションは、派生モジュールでのみ使用できます。 HIDE または UPDATE 修飾子。だけあれば HIDE セクション内の修飾子とそうでないもの UPDATEの場合、定義は許可されません。

  • 一部のエントリは派生モジュールで変更する必要があります (例: 説明)。

15. 例:
MODULE MBase IMPLEMENTED_BY FBBase
SEC MetaData
        DESC := TL.Desc_Base ;
END_SEC
SEC Parameters
        SEC Param : paramxIn
                Variable := xIn ;
                Name     := TL.Param1_Name ;
                Desc     := TL.Param1_Desc ;
        END_SEC
END_SEC

MODULE MDerived IMPORTS MBase
[UPDATE] SEC MetaData
        DESC := TL.Desc_Derived ;
END_SEC
[UPDATE] SEC Parameters
        [UPDATE,HIDE] SEC Param : paramIn
                Variable := xIn ;
                DEFAULT := TRUE ;
        END_SEC
END_SEC


上記の例では、パラメータ paramIn モジュールの MBase 派生モジュールに隠されています MDerived (を使用して HIDE 修飾子)、同時に新しいデフォルト値 (TRUE)が設定されています。

セクションと定義の順序に関する注意

モジュールヘッダーの直後のセクションの順序は関係ありません。セクション内では順序が非常に重要になる場合があります。たとえば、スロット宣言の順序によって、モジュール ツリー内のモジュールの順序が定義されます。

定義の順序は常に無関係です。

. 順序に関連する派生モジュールのルール:
  • 基本モジュールのセクションは、常にモジュール自体のセクションの前に定義されます。

  • 基本モジュールのセクションが以下を使用して変更された場合 UPDATE または HIDE、その順序は影響を受けません。

  • 派生モジュールが、基本モジュールで定義されている順序を変更することはできません。

オートコンプリートと「コンポーネントのリスト」

モジュールエディターで入力を開始すると、使用可能なすべてのセクション定義が「コンポーネントのリスト」メニューに表示されます。現在の位置の意味のあるセクションと定義のみが表示されます。一部のサブセクション エントリが他のセクションのサブセクション エントリと同じ名前である場合でも、一致するセクション定義のみを表示しようとします。

もし 戻る セクションの最初の行を完了した後に を押すと、セクションは必要なすべての定義/セクションで完了し、 END_SEC

変数定義の後、入力/出力変数は「リスト コンポーネント」定義によって表示されます。フラグまたは事前定義された値は、「リスト コンポーネント」の選択にも表示され、可能なフラグ/値が示されます。

テキスト リスト エントリまたはイメージ プール エントリを使用する定義後 (例: ほとんどの場合 Desc :=)、すべての利用可能な表示可能なテキスト リストまたは画像プールとそのエントリを含む「リスト コンポーネント」メニューが表示されます。

押すことで F2、対応する入力サポートを開くことができます。

モジュール宣言のセクション

セクション: メタデータ

セクション: トップレベル

セクション: IO

セクション: パラメータ

セクション: スロット

セクション: ビジュアル

セクション: プロキシ

セクション: VarArray

セクション: 制約

セクション: InstRef

セクション: mse.Sequence

デバイスジェネレーター

アラームアラーム