永続変数でデータを保存する
永続変数は、ダウンロード、ウォームスタート、またはコールドスタートの後、アプリケーションがリロードされたときにその値を保持します。
NVRAMやUPSなどの耐用年数を延ばすには、コントローラに特別な不揮発性メモリ領域が必要です。このようなストレージへのデータのバックアップには追加の時間が必要ありません。これは、PersistenceManagerを使用したデータ保持よりも優れています。コントローラがハードウェアサポートを提供しない場合、データは通常ファイルに保存されます。コントローラを正しくシャットダウンすると、データが保持されます。ただし、停電や「プラグを抜く」とデータが失われます。
行動
価値の保持
制御されていない終了
コマンドを呼び出してウォームスタート ウォームリセット
コマンドを呼び出してコールドスタート コールドリセット
アプリケーションを再度ダウンロードします
起動アプリケーションのロード
での再初期化
コマンドを呼び出す 原点をリセット
永続変数は、コントローラーを配信ステータスにリセットした場合にのみ再初期化されます。たとえば、コマンドを使用した場合などです。 選択する。
一方、アプリケーションを再度ロードすると、永続化されたデータは可能な限り保持されます。それは、変化がどれほど深遠であったかによって異なります。アプリケーション名を変更すると、常に完全な再初期化が行われます。実装を変更しても、再初期化が発生することはありません。データの永続性は完全に保持されます。宣言を変更すると、既存の変数が永続的である場合にのみ、新しい変数が初期化されます。宣言を変更して、永続的な変数リストの一貫性を保つようにする必要があります。これは、新しい変数を追加するか、既存の変数を削除する場合です。以前に宣言された永続変数の識別子またはデータ型を編集および変更すると、不整合が発生する可能性があります。
アプリのダウンロード時や起動アプリのロード時の仕組み
永続性エディターで変数リストを編集すると、エディターに表示されるように変数リストが保存されず、保存される前に自動的に後編集されます。
後処理では、削除した変数が同じメモリフットプリントのプレースホルダー変数に置き換えられます。これは、次の変数がプロセスイメージ内のアドレスを保持することを意味します。また、追加した変数はすべてリストの最後に移動します。後処理により、永続性の喪失につながる変更を無効にすることができます。ただし、追加のメモリを消費するギャップが作成されます。
アプリケーションをロードすると、変数リストの CRC 値とリストの長さ (変数の数) がコントローラに保存されます。アプリケーションを再度ロードすると、新しいテスト値が現在コントローラにあるテスト値と比較されます。次に、変数リストは、指定された長さまで連続して比較されます。宣言 (名前やデータ型など) を編集した場合、変数は再初期化されます。それ以外の場合、その値は保持されます。アプリケーションが再度読み込まれると、 CODESYS 永続性エディターで宣言された変数リストが、コントローラーに既にある変数リストとまだ整合性があるかどうかを確認します。
このメカニズムは、変数自体が大幅に変更されていない場合にうまく機能します。識別子とデータ型を過度に変更すると、再初期化と永続性の喪失につながり続けます。したがって、アプリケーションのニーズに基づいて頻繁に変更されることが予想される場合は、通常、このようなリストはお勧めしません。さらに、データ型の変更後にオンラインで変更が発生した場合、永続変数は通常の有効期間を持つ変数よりも堅牢性が低くなります。
基本的に、しばらくすると、ギャップの変数リストとコマンドをクリーンアップする必要があります リストを並べ替えてギャップをクリーンアップします 走る。ただし、クリーニング後、リストはコントローラー上のリストと一致しなくなり、すべての永続変数の初期化がトリガーされました。すべての変数の永続性が失われます。
ヒント
V3.5 SP1より前のバージョンでは、永続性エディターでの変更により、常に再初期化が行われます。
レシピマネージャーを介してデータを保存する
永続性を失うことなくグローバル永続変数リストをクリーンアップするために、レシピマネージャーを使用してレシピにデータを保存できます。永続変数リストのすべての変数のリストがレシピマネージャーで生成されると同時に、それらの現在の値がコントローラーによってレシピとして保存されます。次に、コマンドを選択します リストを並べ替えてギャップをクリーンアップします その後、再度ダウンロードします。あなたが今コマンドなら レシピから値を復元する を選択すると、レシピに保存されている値が復元されます。
永続変数リストの既存の宣言を変更する
変数の名前またはデータ型を変更すると、これは新しい宣言として解釈され、次回のオンライン変更またはアプリケーションのロード時に変数が再初期化されます。複雑なデータ型の場合、新しいコンポーネントが追加されたとき、または変数の型を変更したときに変更が発生します。 INT に UINT 例えば、使用された構造の深さにおいて。
基本的に、複雑なユーザー定義データ型は、永続変数リストでの管理には適していません。小さな変更でも、変数がすべてのコンポーネントで初期化されるためです。
インスタンスパスでのメモリの二重割り当て
グローバル変数またはローカルで宣言された変数を関数ブロックまたはプログラムに永続化できます。これを行うには、宣言にキーワードを追加します PERSISTENT。さらに、永続グローバル変数リストのこの変数にインスタンスパスを追加します。これを行うには、永続性エディターでコマンドを選択します すべてのインスタンスパスを追加します。
永続性は、次のメカニズムによって保証されます。
変数にアクセスする循環タスクが決定されます。
（各サイクルの）最初の循環タスクの終了時に、変数が永続グローバル変数リストにコピーされます。
コントローラを再起動すると、値が永続変数から通常の変数にコピーされます。
このメカニズムの欠点は、宣言のポイントとインスタンスパスのポイントの両方でメモリが割り当てられることです。この永続変数は占有します ダブル 収納スペース。さらに、データは各サイクルで両方の場所にコピーされます。これは、特に大きな構造化された値になると、時間がかかる可能性があります。
永続機能ブロックインスタンスのメモリ位置
機能ブロックインスタンスは常に完全にメモリ内にあります。これは、同じコードが異なるインスタンスで機能できるようにするために必要です。今なら、関数ブロック内の1つの変数のみ PERSISTENT がマークされている場合、関数ブロックインスタンスはすべての変数とともに完全に残留メモリに格納されますが、1つの変数のみが永続として扱われます。ただし、不揮発性メモリはメインメモリと同程度には使用できません。
変数としてSRAM内のインスタンスへのポインタを持つ機能ブロックは、保護されたメモリに格納されません。
からのインポート CoDeSys V2.3-プロジェクト
開くと CoDeSys V2.3 インポートするプロジェクト CODESYS V3 では、永続変数の宣言は保持されません。宣言を修正し、別の永続グローバル変数リストに再度作成する必要があります。