コマンド: 生成
シンボル:
このコマンド (カテゴリ「Composer」) は、ビルド プロセスを開始し、 CODESYS モジュールツリーからアプリケーションを選択し、 発電機の構成。
メッセージとエラーはメッセージ ビューに表示されます。
標準ジェネレーターによって作成されたすべてのオブジェクト (タスク オブジェクトとアプリケーションを除く) は、それぞれのアプリケーションのサブフォルダーに保存されます。 POU プールの名前 AC_Std
そして AC_FBs
。同じ名前のフォルダーがすでに存在する場合は、サフィックスを追加して一意の名前が作成されます _0
。

によって作成されたすべてのオブジェクト 生成する コマンドには青いオーバーレイ アイコンが付いています。ユーザーがこれらのオブジェクトの 1 つを削除、移動、または変更しようとすると、この操作によりコンパイルの問題が発生する可能性があることを示すダイアログが開きます。ユーザーが続行すると、オーバーレイ アイコンの色が赤に変わります (機能ブロックを参照) AC_PRG_RMP (PRG)
上のスクリーンショットで)。
ヒント
Application Composer を併用する場合 CODESYS SVN:
Composer で生成されたすべてのオブジェクトには、 Ignore on Commit
SVNの場合。さらに、Build コマンドの実行中の SVN ロックを回避するために、SVN はオフライン モードに切り替えられます。
標準ジェネレーターによるファンクションブロックインスタンスの作成
モジュール インスタンスごとに、関数ブロックが (フォルダー内に) 作成されます。 AC_FBs
)。この機能ブロックはモジュール機能ブロックから派生します。
関数ブロックには、次の (入力) 変数が含まれています。
サブモジュールインスタンス
構成可能なサイズの配列
ダイレクト I/O 接続のバッファ変数
マルチスロットの配列とインスタンス参照
それぞれの配列変数の名前は接頭辞によって作成されます。 AC_ARRAY_
それぞれのポインター変数の変数名が続きます。可変インデックス サイズを持つ配列 (VarArrays) の場合、名前はパラメーターによって上書きできます。 VarArray.InstName
。
関数ブロックの実装部分には次のコマンドが含まれます。 SUPER^();
これはモジュール関数ブロックの実装部分を呼び出します。
モジュールインスタンス ModuleInstanceA
タイプです ModuleA
および関連する機能ブロック ModuleA_FB
。このインスタンスには、次のタイプのサブモジュール インスタンスがあります。 ModuleB
。
モジュールインスタンス ModuleInstanceA
タイプです ModuleA
および関連する機能ブロック ModuleA_FB
。このインスタンスには、次のタイプのサブモジュール インスタンスがあります。 ModuleB
。
FUNCTION_BLOCK AC_ModuleInstanceA EXTENDS ModuleA_FB VAR_INPUT Inst_Sub1 : AC_ModuleInstanceB ; END_VAR
関数ブロックの名前は、モジュール インスタンスのパスとプレフィックスから作成されます。 AC_
。
サブモジュール インスタンスの変数の名前は、それぞれのサブモジュール インスタンスの名前が続くプレフィックスから作成されます。
各関数ブロックは 1 回インスタンス化され、トップレベル モジュールの FB インスタンスは GVL 内で直接インスタンス化され、残りは親インスタンスの対応する関数ブロック内にインスタンス化されます。
別のアプリケーションにある参照されるモジュール インスタンスごとに、プロキシ FB の機能ブロック インスタンスが 1 つだけ、参照するモジュール インスタンスの 1 つの GVL に作成されます。プロキシ インスタンスの名前は次のとおりです。 AC_PROXY_<InstanceName>
<InstanceName> は、他のアプリケーションのターゲット インスタンスの名前です。
すべてのモジュール インスタンスには一意のアドレスが割り当てられます。プロキシ FB インスタンスは、リモート アプリケーションのモジュール インスタンスのアドレスによって割り当てられます。
方法 IBaseInstance.Main
プロキシ インスタンスの は、通信タスク内で周期的に呼び出されます。
アプリケーションとタスクの呼び出しの作成
存在しないアプリケーションにモジュールが割り当てられている場合、このアプリケーションが作成されます。
存在しない標準タスクの作成
TASK_MODULE_HIGH
TASK_MODULE_MEDIUM
TASK_MODULE_LOW
タスクの優先度とサイクル タイムは、ジェネレーターの設定に従って設定されます。さらに、指定された設定を持つモジュール固有のタスクが作成されます。
トップレベルごとに 1 つのグローバル変数リストを作成します。この GVL では、同じアプリケーションの最上位モジュール インスタンスの下に位置するモジュール インスタンスが作成されます。グローバル変数リストにはモジュールで定義された名前が付いています。名前が定義されていない場合は、その名前が取得されます。
GVL_MODULE
。 GVL は、選択したアプリケーションの下、またはグローバル POU ツリー内にあります。次の名前の GVL を 1 つ作成する
GVL_ MODULE_TREE
アプリケーションごとに。このリストには、モジュール ツリーを管理するための変数が含まれています。 GVL はフォルダー内に作成されますAC_Std
。ダウンロードおよびオンライン変更時に自動的に呼び出される初期化コードの作成:
ツリー構造が作成されます。
パラメータ値が設定されます。
参照とサブモジュールのインスタンスが割り当てられます。
可変サイズの配列は埋められます。
インスタンス参照が設定されます。
ダウンロード時のみ、デフォルト値に設定されていないパラメータが設定されます。オンライン変更では、すべてのパラメータが設定されます。 POU はフォルダー内に作成されます
AC_Std
。定義されたエントリ ポイントごとに、
PROGRAM
最上位モジュールの呼び出しを含む POU (言語 ST) が作成されます。この新しい POU の呼び出しはタスクの下に追加されます。標準タスクの場合、POU 名は次のとおりです。MODULE_CALL_<TASKNAME>_START
MODULE_CALL_<TASKNAME>_END
POU はフォルダー内に作成されます
AC_Std
。最上位モジュールの場合、 POU タスク呼び出しのプールはすべてのアプリケーションで作成されます。
I/O割り当ての作成
I/O 割り当てのタイプに応じて、次のアクションが実行されます。
[I/Oチャネル]: 対応するデバイスチャネルに、モジュールインスタンスのI/Oのインスタンス名が追加されます。
[ST 式]: 式の入力への割り当て、または式への出力の割り当ては、同じトップレベル インスタンスの下にあるすべてのモジュール インスタンスに対して行われます。対応する割り当てがある場合、トップレベルのインスタンスごとに、という名前の関数が作成されます。
AC_Io_SetInputs_<instance name>
またはAC_Io_SetOutputs_<instance name>
が作成されます。
入力と出力を定義するタスクはフラグによって識別されます。
UPDATE-IOS
モジュールの説明にあります。以下、このタスクを「I/Oタスク」と呼ぶ。入力の関数は、モジュール インスタンスのタスク メソッドが呼び出される前に、I/O タスクで呼び出されます。 (I/O タスクが標準タスクの場合、start メソッドの前。) 出力の関数は、モジュール インスタンスのタスク メソッドの後の I/O タスク内で呼び出されます。 (I/Oタスクが標準タスクの場合、endメソッド以降)
[モジュール I/O への直接接続、ローカル]: 互換性のある型のバッファ変数が入力のインスタンスのファンクション ブロック内に作成されます。バッファ変数の名前は接頭辞で始まります。
AC_Io_Buffer_
。バッファ変数は、アプリケーションの初期化中に、接続された出力の現在の値に初期化されます。ジェネレーターは、このバッファー変数への ST 割り当てと同様に、入力および出力の割り当てを処理します ([ST 式] を参照)。
[モジュール I/O への直接接続、リモート]: 別のアプリケーションからのモジュール インスタンスの入力に接続されている出力ごとに、互換性のあるタイプのバッファ変数が対応する送信ネットワーク GVL に作成されます。バッファ変数の名前は接頭辞で始まります
AC_RemoteIo_Buffer_
出力のインスタンス パスと変数パスから構築されます。バッファ変数は、出力変数が存在する場合、その初期化式を使用して初期化されます。この初期化式の値がプリコンパイル情報に含まれていない場合 (式では変数、関数、定数の例が使用されているため)、エラーが作成されます。ジェネレーターは、このバッファー変数への代入と同様に、出力の代入を処理します。他のアプリケーションでの入力割り当ては、受信側 NVL の対応する変数からの割り当てと同様に処理されます ([ST 式] を参照)。
注: ネットワーク変数が更新されるタスクとモジュールの I/O タスク間の同期はまだ実現されていません。したがって、I/O タスクが値を読み取るときに値が不完全に書き込まれている可能性があります。
通信インフラの整備
定義: 次の説明では、次の条件が満たされた場合に、アプリケーション A1 がアプリケーション A2 に送信します (または A2 が A1 から受信します)。
アプリケーション A1 に割り当てられたモジュール インスタンスは、アプリケーション A2 に割り当てられたモジュール インスタンスを参照します。また、その逆も同様です。
A1 に割り当てられたモジュール インスタンスの出力は、直接モジュール I/O 接続を使用して、A2 に割り当てられたモジュール インスタンスに接続されます。
以下に示すすべてのオブジェクトがフォルダー内に作成されます AC_RMP
ジェネレーターによって作成されたアプリケーションごとに。
通信タスクが作成されます。 (サイクル時間と優先度はジェネレーター構成の設定に応じます)。このタスクでは、プロキシ インスタンスが呼び出され、ミラーリングされたモジュールのプロキシ FB 変数がそれぞれ読み取られます。書かれた。
現在のアプリケーションに送信するアプリケーションごとに、(送信) GVL が作成され、ネットワーク設定が定義されます。 (プロトコル「UDP」、サイクリック送信、チェックサム、設定によるサイクルタイム、通信タスク)。 「リスト識別子」は 1 から 2^15-1 までの整数値である必要があり、生成の開始時にランダムに決定され、GVL を送信するたびに 1 ずつ増加します。この値は少なくとも 128 であり、有効範囲内です。アプリケーション間にモジュール参照がある場合、次の型の変数
RMPExchangeData
GVL 内に作成されます。変数の名前には、ソース アプリケーションとターゲット アプリケーションの名前が含まれます。モジュール インスタンスがプロキシ定義でミラーリングされる変数を定義している場合 (MirrorVar
) であり、他のモジュール インスタンスから参照されている場合、この MirrorVar ごとに、参照されたモジュール インスタンスの (送信) GVL に変数が作成されます。その名前には、モジュール インスタンスのインスタンス パスと、対応する「MirrorVar」定義の TargetID が含まれます。現在のアプリケーションが送信するアプリケーション A2 ごとに、(受信) NVL が作成され、A2 の対応する送信 GVL および通信タスクに接続されます。
タイプの関数ブロック
RMPService
でインスタンス化されますGVL AC_RMP
宣言内で初期化されます(属性付き)init_on_onlchange
)。型の 2 つの配列RMPConnection
作成されたタイプの変数を参照するものが作成されます。RMPExchangeData
GVL と NVL 内。プログラム
AC_PRG_RMP
タイプの関数ブロックを呼び出すものが作成されます。RMPService
。このプログラムは通信タスクに追加されます。さらに、ミラーリングされた変数 (「MirrorVars」) の値が設定され、AC_PRG_RMP
プログラム。これは、プロキシ「MirrorVars」が (受信) GVL の対応する変数に割り当てられることを意味します。そうしてMain
プロキシ インスタンスのメソッドが呼び出され、最後に「MirrorVars」モジュールの (送信側) GVL の対応する変数が呼び出されます。これは、モジュール インスタンスのプロキシへの送信方向に従って発生します。