(57)【要約】【課題】  複数の制御プログラムのＲＵＮ中一括更新を可能にする。【解決手段】  プログラムメモリ２３の空き領域に、制御プログラムＰＧ３，ＰＧ９の更新版である制御プログラムＰＧ３’，ＰＧ９’を格納する。これは、ＰＧ３又はＰＧ９を実行中であっても関係無く行える。そして、ＰＧ３’，ＰＧ９’の格納位置を、プログラム変更要求キュー２２に格納する。その後、スキャンエンド処理中に、キュー２２を参照して、ＰＧ３、ＰＧ９に関して順次、プログラム情報テーブル２１を更新する。【選択図】図２
2006202233.tif 000002
【特許請求の範囲】
【請求項１】
複数の制御プログラムを格納するプログラムメモリと、
該プログラムメモリに格納されている各制御プログラムの格納位置を記憶するテーブルと、
リードポインタとライトポインタを有するプログラム変更要求キューと、
外部から、前記プログラムメモリに格納されている何れかの制御プログラムの更新版が送られてくると、該更新版の制御プログラムを前記プログラムメモリの空き領域に格納すると共に、該格納位置情報を前記プログラム変更要求キューに記憶すると共に前記ライトポインタを進める更新版プログラム受付手段と、
スキャンエンド処理中に前記テーブルを更新するものであって、前記リードポインタの位置と前記ライトポインタの位置が一致しない場合には、更新要求有りと判定し、前記プログラム変更要求キューに格納されている前記更新版プログラムの格納位置情報を用いて、前記テーブルを更新するプログラム更新手段と、
を有することを特徴とするコントローラ。
【請求項２】
前記テーブルには各制御プログラムのサイズも格納されており、
前記テーブルにおける各制御プログラムの格納位置とサイズとに基づいて、各制御プログラム間に空き領域が存在するか否かを判定し、空き領域が存在する場合には、前記プログラムメモリにおいて該空き領域の直後に格納されている制御プログラムを前詰めする空き領域調整手段を更に有することを特徴とする請求項１記載のコントローラ。
【請求項３】
前記プログラムメモリに格納されている制御プログラムを一時的に退避させる退避領域を更に有し、
前記空き領域調整手段は、前記空き領域の直後に格納されている制御プログラムを該退避領域に退避させた後、該退避させた制御プログラムを前記空き領域の先頭から格納し直すことで前記前詰めを実現させることを特徴とする請求項２記載のコントローラ。
【請求項４】
コンピュータに、
複数の制御プログラムを格納するプログラムメモリと、該プログラムメモリに格納されている各制御プログラムの格納位置を格納するテーブルと、リードポインタとライトポインタを有するプログラム変更要求キューとを用いて、
外部から、前記プログラムメモリに格納されている何れかの制御プログラムの更新版が送られてくると、該更新版の制御プログラムを前記プログラムメモリの空き領域に格納すると共に、該格納位置を前記プログラム変更要求キューに格納すると共に前記ライトポインタを進める機能と、
スキャンエンド処理中に、前記リードポインタの位置と前記ライトポインタの位置が一致しない場合には、更新要求有りと判定し、前記プログラム変更要求キューに格納されている前記更新版プログラムの格納位置により、前記テーブルの格納位置を更新する機能と、
を実現させる為のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラマブルコントローラのユーザプログラム更新において、特に、プログラマブルコントローラの運転中に複数のプログラムを更新する手法に関する。
【背景技術】
【０００２】
プログラマブルコントローラは、FA(Factory Automation)などの用途に使われるコンピュータであり、その適用システムは、ユーザの要求仕様により、24時間稼動など極力停止が望まれないシステムが多く存在する。
【０００３】
しかしながら、システムで稼動するユーザプログラムは、ユーザの単純なプログラムミスや動作仕様の変更、機器の経年変化による設定値の変更など、さまざまな理由により、プログラムの更新が要求される。
【０００４】
これらの条件を満たすため、プログラマブルコントローラにおいては、コントローラの運転中のプログラム更新(以下RUN中更新と呼ぶ)機能が具備されているものがある。
現在、一般的に行われているRUN中更新には、その変更範囲からおおよそ以下の3パターンが考えられる。
【０００５】
すなわち
・プログラム内の1命令(ステップ)単位で命令を置き換える。
・複数あるプログラムのうちの1プログラムを全て変更する。
・ひとつのプログラマブルコントローラにある複数のプログラムを同時に変更する。
である。
【０００６】
近年のプログラマブルコントローラのメモリ容量大型化、処理の高速化により、ひとつのコントローラが同時に扱えるプログラムの本数は増加してきており、複数プログラムのRUN中同時更新機能は、その必要度が高くなりつつある。
【０００７】
このような複数プログラムのRUN中同時更新の問題を解決するため、特許文献１においては、コントローラ上にプログラムコード用メモリを2バンクもち、いずれかのプログラムコード用メモリを書き換え、プログラム格納バンクテーブルを変更することで、複数プログラムを同時更新する手法が提案されている。
【０００８】
しかしながら、ただでさえプログラム容量の大型化により大容量メモリが必要とされている中にあって、RUN中更新機能のためだけに普段使用しないメモリ(プログラムメモリと同サイズ)を持つことは、価格等の面で不利である。
【０００９】
これに対して、特許文献２においては、実際のコントローラの実行コードであるプログラムを格納する領域と、各プログラムの先頭アドレスを示したテーブルを持ち、更新プログラムをプログラム格納領域に書き込み完了した時点で、プログラムアドレステーブルのアドレスを変更する手法を提案している。
【特許文献１】特開平１０−２０７５１２号公報
【特許文献２】特開２００１−１４２５１０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記特許文献２の手法では、複数プログラムのRUN中同時更新を行うことは考えられない（特許文献１では行えるが、上記の通り、大容量メモリが必要とされるという問題が生じる）。すなわち、特許文献２ではＰＯＵを格納領域に格納し終わったことを条件にＰＯＵアドレステーブルを更新しているのであり、１つのＰＯＵの更新のみを考えている。もし複数ＰＯＵ同時（一括）更新するならば、ＰＯＵだけでなく何らかの追加の情報（例えば一括で更新したいＰＯＵのリスト等）も一緒にコントローラ側に渡す必要がある。そうでなければ、コントローラ側では、どのタイミングでＰＯＵアドレステーブルを置き換えてよいのか判断できない。あるいは、上記の通り、ＰＯＵを格納領域に格納し終わるとＰＯＵアドレステーブルを更新するので、例えばあるＰＯＵのバージョンアップ版等を、このＰＯＵの実行中に格納領域に格納した場合、問題が生じる可能性がある。
【００１１】
更に、上記特許文献２に記載の手法においては、プログラムのRUN中更新を繰り返していくうちに、プログラム格納領域の空き領域が細かく分断され、その分断された領域に更新プログラムを格納するために、ひとつのプログラムを空き領域にあわせ分割し、分割された個々のプログラム同士は新たにジャンプ命令を挿入することで、接続しようとしている。このようなやり方は実現可能ではあるが、支援ツール側で生成する場合、他の支援ツールで支援が不可能になる、コントローラ側で実現した場合、プログラム格納領域の空き領域管理、ジャンプ命令の生成、もともとのプログラムに存在するジャンプ命令のとび先アドレスの付け替えなど処理が重くなり、現実的ではない。
【００１２】
本発明の課題は、プログラマブルコントローラにおけるＲＵＮ中更新に係り、大容量メモリ（２バンクメモリ）を必要とすることなく複数プログラムの一括更新を可能にし、あるいは更にプログラムメモリ上の空き領域を分断させることのないようにし、更新版プログラムを格納済みプログラム群の最後尾に追加すれば済むようにできるプログラマブルコントローラを提供することである。
【課題を解決するための手段】
【００１３】
本発明によるプログラマブルコントローラは、複数の制御プログラムを格納するプログラムメモリと、該プログラムメモリに格納されている各制御プログラムの格納位置を記憶するテーブルと、リードポインタとライトポインタを有するプログラム変更要求キューと、外部から、前記プログラムメモリに格納されている何れかの制御プログラムの更新版が送られてくると、該更新版の制御プログラムを前記プログラムメモリの空き領域に格納すると共に、該格納位置情報を前記プログラム変更要求キューに記憶すると共に前記ライトポインタを進める更新版プログラム受付手段と、スキャンエンド処理中に前記テーブルを更新するものであって、前記リードポインタの位置と前記ライトポインタの位置が一致しない場合には、更新要求有りと判定し、前記プログラム変更要求キューに格納されている前記更新版プログラムの格納位置情報を用いて、前記テーブルを更新するプログラム更新手段とを有するように構成する。
【００１４】
上記構成のプログラマブルコントローラは、更新版の制御プログラムを受信すると、これをプログラムメモリの空き領域に格納するが、直ちにテーブルを更新するのではなく、一旦、プログラム変更要求キューに、プログラム格納位置等を格納しておく。よって、この処理は、制御プログラム実行中であっても行える。また、更新版の制御プログラムが複数あってもよい。そして、スキャンエンド処理中に、プログラム変更要求キューを用いて、上記テーブルを更新する。更新版の制御プログラムが複数ある場合には、プログラム変更要求キューに複数分の格納位置情報を記憶しておき、スキャンエンド処理中に一括して更新できる。
【００１５】
また、上記構成のプログラマブルコントローラにおいて、例えば、前記テーブルには各制御プログラムのサイズも格納されており、前記テーブルにおける各制御プログラムの格納位置とサイズとに基づいて、各制御プログラム間に空き領域が存在するか否かを判定し、空き領域が存在する場合には、前記プログラムメモリにおいて該空き領域の直後に格納されている制御プログラムを前詰めする空き領域調整手段とを更に有するように構成してもよい。
【００１６】
また、この構成に関して、更に、前記プログラムメモリに格納されている制御プログラムを一時的に退避させる退避領域を更に有し、前記空き領域調整手段は、前記空き領域の直後に格納されている制御プログラムを該退避領域に退避させた後、該退避させた制御プログラムを前記空き領域の先頭から格納し直すことで前記前詰めを実現させるようにしてもよい。
【発明の効果】
【００１７】
本発明のプログラマブルコントローラによれば、プログラマブルコントローラにおけるＲＵＮ中更新に係り、大容量メモリ（２バンクメモリ）を必要とすることなく複数プログラムの一括更新を可能にする。あるいは更にプログラムメモリ上の空き領域を分断させることのないようにし、更新版プログラムを格納済みプログラム群の最後尾に追加すれば済むようにできる。換言すれば、細かく分断された空き領域にあわせてプログラムを分割して格納する等の処理は必要なくなる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例で用いられるプログラマブルコントローラ・システムの概略構成図である。
【００１９】
図１において、コントローラ支援装置１０は、ユーザが所望の制御プログラムを作成する為に入力を行う入力装置１２と、この入力内容等を表示する表示装置１１、および所定のアプリケーション・プログラムを記憶するための記憶媒体１３等を有する。コンパイラ１は、コントローラ支援装置１０で作成された制御プログラムを、コントローラ３（プログラマブル・コントローラ本体等）で実行できるコードに変換する。尚、図では、コンパイラ１とコントローラ支援装置１０とを別に示しているが、これらは同一のハード(たとえばパソコン上)で構成されていてもよい。このようにして変換したプログラムコードを伝送装置２を介してコントローラ３に転送し、コントローラ３はこれを格納する。尚、以下の説明では、コンパイラ１及び伝送装置２に関しては省略して説明する。
【００２０】
尚、コントローラ支援装置１０は、例えばパソコン等のコンピュータにより実現されるものであり、従って特に図示していないが、当然、ＣＰＵ、メモリ、通信インタフェース等も有しており、ＣＰＵが上記記憶媒体１３に格納されている所定のアプリケーション・プログラムを読出し・実行することにより、ユーザに上記制御プログラム（コントローラ３で実行される、不図示の各種制御対象を制御する為のプログラムであり、例えば定周期プログラム等である）を作成させ、この制御プログラムを通信インタフェースを介してコントローラ３側に送信する処理を実行するものである。
【００２１】
同様に、コントローラ３も、特に図示していないが、ＣＰＵ／ＭＰＵ、メモリ等の記憶装置、通信インタフェース等を有している。この記憶装置は、例えば後述するプログラム情報テーブル２１，５１やプログラム変更要求キュー２２を格納するメモリ（ＲＡＭやフラッシュメモリ等）や、制御プログラムを格納するプログラムメモリ２３やシステム一時メモリ５２等である。また、この記憶装置には、例えば後述する図４、図１０等の処理を、ＣＰＵ／ＭＰＵ等により実行させる為のアプリケーション・プログラムも格納されている。
【００２２】
次に、コントローラ３における制御プログラムの格納方法について説明する。
コントローラ３は、図２（ａ）に示すプログラム情報テーブル２１と、図２（ｂ）に示すプログラム変更要求キュー２２と、図２（ｃ）に示すプログラムメモリ２３を有する。
【００２３】
図１のコンパイラで変換されコントローラ３にて実行可能なコードとなった制御プログラムは、上記不図示の通信インタフェースを介してコントローラ３側にロードされたら、図２（ｃ）のプログラムメモリ２３上に展開される。プログラムメモリ２３上に置かれる制御プログラムは、登録された順番に前詰で展開されている。プログラムメモリ２３に展開されている制御プログラムの番号とその格納場所の先頭アドレスは、図２（ａ）に示すプログラム情報テーブル２１のプログラム番号２１ａ、格納アドレス２１ｂにそれぞれに格納される。尚、プログラム番号とは、図示のＰＧ１、ＰＧ３のことであり、以下、各制御プログラムを、そのプログラム番号を用いて、例えばプログラムＰＧ１等と呼ぶ場合がある。
【００２４】
また、プログラム変更要求キュー２２は、ＲＵＮ中に複数の制御プログラムを一括更新する機能を実現するための構成であり、図示のリードポインタ３１、ライトポインタ３２を有している。これについて、図３を参照して説明する。
【００２５】
図３は、コントローラのRUN中に２つのプログラム（ＰＧ３とＰＧ９）の更新要求があった場合の例である。
すなわち、まず、コントローラ支援装置１０側において、プログラムＰＧ３及びＰＧ９の更新版（バージョンアップ版、修正版等であり、旧バージョン等と区別する為、以下、ＰＧ３’、ＰＧ９’と記す）が作成される。そして、支援装置１０は、このプログラムＰＧ３’とＰＧ９’とを、更新要求と共にコントローラ３側に送信する。これを受信したコントローラ３は、これら更新版の制御プログラム（ＰＧ３’、ＰＧ９’）を、旧版の制御プログラム（ＰＧ３、ＰＧ９）と入れ替える処理、すなわちプログラム更新処理を行う必要があるが、ＲＵＮ中であるので、一旦、図３（ｃ）に示すようにプログラムメモリ２３の最後尾（格納済みプログラム領域の後）にこれら更新版の制御プログラム（ＰＧ３’、ＰＧ９’）を格納する。この格納処理の間は、制御処理等は既存の制御プログラム(ＰG3、PG9)によって動いているので、特に書き込みのタイミングを意識する必要はない。尚、プログラムメモリ２３の記憶容量は、「全ての制御プログラムを格納できる容量＋１つ以上の更新版プログラムを格納できる容量」が必要となるが、上記２バンク構成に比べれば、メモリ容量は少なくて済む。
【００２６】
更新版の制御プログラム(ＰＧ３’、ＰＧ９’)の格納が完了したら、これらのプログラム番号(PG3、PG9)と、プログラムメモリ２３における格納場所の先頭アドレス（ADR5、ADR6）とを、図３（ｂ）に示す通りプログラム変更要求キュー２２に書き込むと共に、そのライトポインタ３２を進める（インクリメントする）。尚、プログラム番号は、旧版であっても更新版であっても同じである。上記ＰＧ３’、ＰＧ９’等の表記は、あくまでも本説明を分かり易くする為のものである。
【００２７】
尚、本手法は複数プログラムの一括更新を実現するものであるから、キューへの書き込みが行われている間に（複数プログラム全てについて書き込み完了する前に）図４の処理が開始されてしまうと、不完全な形で更新が行われてしまう。よって、これを防止する為に、例えば、キューへの書き込みが完了するまでは、割り込み禁止にするか、あるいはキューへの書き込み処理の優先度を、図４の処理と同じかそれ以上とすることで、中途半端な更新が行われないようにすることが望ましい。
【００２８】
次にこのプログラム変更要求を認識し、制御プログラムの更新処理（つまり、プログラム情報テーブル２１の格納内容の更新）を行うわけであるが、これは、全ての制御プログラムの実行が行われていないタイミングで行う必要がある。通常のコントローラ３は、プログラムへのデータ入力処理→プログラムの実行→プログラムからの結果出力処理を1スキャンとし、スキャンとスキャンの間にコントローラ３のシステムプログラムが処理を行う(以下、スキャンエンド処理という)。したがって、制御プログラムの更新処理は、スキャンエンド処理中に行う必要がある。
【００２９】
図４は、スキャンエンド処理から呼び出されるRUN中更新処理フローである。
以下、図４の処理について、図３、図５も参照しつつ説明する。
図４の処理では、まず始めにプログラム変更要求キュー２２のリードポインタ３１とライトポインタ３２とを比較して、両ポインタが指す位置が一致するか否かを判定する（ステップS１１）。両ポインタの位置が同じならば（ステップS１１，ＮＯ）、プログラム変更要求がないことになるので、処理を終了する。
【００３０】
一方、両ポインタの指す位置が違っていれば（ステップＳ１１，ＹＥＳ）、プログラム変更要求ありということなので、以下の処理を行う。
まず、リードポインタ３１が示すアドレスに格納されているプログラム番号(図３（ｂ）の例では最初はＰＧ３)を、変数Ｉに代入する。また、プログラム情報テーブル２１の先頭アドレス(図３（ａ）の例では仮にPtr_1とする)を、変数Ｊに代入する（ステップＳ１２）。
【００３１】
そして、変数Ｊが示すアドレス（最初は先頭アドレスPtr_1）に格納されているプログラム番号２１ａと変数Iの値とが等しいか否かを判定する（ステップＳ１３）。もし両者が不一致であれば（ステップＳ１３，ＮＯ）、一致するようになるまで繰返し変数Ｊの値を進めていく（例えばプログラム情報テーブル２１には１byte単位でデータが格納されているとした場合には、Ｊ＝Ｊ＋１(byte)等とする）（ステップＳ１４）。
【００３２】
そして、変数Ｊが示す位置のプログラム番号２１ａと変数Iの値とが一致したら（ステップＳ１３，ＹＥＳ）、当該プログラム番号２１ａに対応する格納アドレス２１ｂの値を、プログラム変更要求キュー２２のリードポインタ３１が示す位置の格納アドレス３３の値によって更新する（ステップＳ１５）。上記の通り最初はＰＧ３であるので、図３（ａ）では格納アドレス２１ｂにＡＤＲ２が格納されていたが、図５（ａ）のようにＡＤＲ５へと変更される。
【００３３】
変更後、リードポインタ３１を１つ進める（ステップＳ１６）。そして、再びステップＳ１１の処理に戻り、リードポインタ３１とライトポインタ３２が一致するまで(すなわち変更要求がなくなるまで)、上記ステップＳ１２〜Ｓ１６の処理を繰返し実行する。図３（ｂ）の例では、上記ＰＧ３以外にＰＧ９があるので、ＰＧ９についても上記処理を実行することで、図５（ａ）、（ｂ）に示す状態になったら、当該処理は終了する。
【００３４】
尚、本例においては、既存の制御プログラムの更新を前提としているので、全く新しい制御プログラムを追加する場合については想定していない。
尚、上記ステップＳ１１の処理は、特に、２チップ構成のコントローラにおいて意味がある。すなわち、従来より、制御プログラムを実行する第１のＣＰＵと支援ツールとのインタフェース処理を行う第２のＣＰＵとを有する２チップ構成のコントローラが存在する。この様な構成では、第１のＣＰＵは、上記ステップＳ１１の処理を行うことで、プログラム更新があったか否かを判別できる。
【００３５】
上記の一連の処理が完了したときのプログラムメモリ等の状態を示したものが図５である。図５（ａ）のプログラム情報テーブル２１は、PG3とPG9に対応する格納アドレス２１ｂがそれぞれＡＤＲ５とＡＤＲ６に更新され、図５（ｂ）のプログラム変更要求キュー２２は、リードポインタ３１の位置がライトポインタ３２の位置と一致している。更新後のプログラム情報テーブル２１の内容により、図５（ｃ）のプログラムメモリ２３において旧版プログラムＰＧ３とＰＧ９が格納されている領域４１，４２は、空き領域として管理されることになる。尚、特に図示していないが、プログラムメモリ２３には、格納している各プログラムの最後を示す各ポインタが用意されている。よって、図５（ａ）のプログラム情報テーブル２１には、例えばプログラムＰＧ１の格納領域の先頭アドレス（ＡＤＲ１）のみが記憶されているが、上記ポインタによって、ＡＤＲ１〜ＡＤＲ２までの記憶領域に、プログラムＰＧ１が格納されていることが分かるようになっている。但し、この例に限らず、例えば後述するプログラム情報テーブル５１の様に、サイズ情報も格納するようにしてもよい。
【００３６】
尚、上記図４の処理は、プログラム情報テーブル２１の格納アドレス２１ｂの値を更新するだけの処理であり、更新要求プログラムの数がさほど多くなければ、負担にならない処理である。
【００３７】
以上述べたように、本例では、複数プログラムの一括更新を行うことができる。また、更新版プログラムをプログラムメモリ２３に格納する処理自体は、更新対象のプログラムを実行中であっても行うことができる。
【００３８】
以上述べた処理により、プログラムのRUN中更新処理は一応完了するが、更新版プログラムを格納済みプログラム領域の後ろに付け足し、旧版のプログラムを無効化する(プログラム情報テーブル２１を更新する)処理を行っていくと、どうしてもプログラムメモリ２３上に空き領域が分散して存在することになる（図５（ｃ）参照）。
【００３９】
特許文献２においては、空き領域にあわせ、更新するプログラムを分割していたが、上述した問題が生じる。
これより、本例では、空き領域が生じた場合には、既にプログラムメモリ２３に格納した制御プログラムを、順次前詰めしていくことで、空き領域が分散配置されないようにする（最後尾の制御プログラムの後に空きスペースをまとめてしまう）方法を提案する。
【００４０】
本実施例では、簡単のためプログラムメモリ２３の先頭から順に領域をサーチし、最初の空き領域の次の制御プログラムを、この空き領域の先頭から始まるように移し、それによって新たに生じる空き領域や別の空き領域に関しても同様にしてその次の制御プログラムを詰めていく処理を示す。この処理の一部は、図４のアルゴリズムを利用できる。以下、図６〜図８を参照して詳細に説明する。
【００４１】
まず、本例では、プログラム情報テーブル５１は、図６（ａ）に示すように、プログラム番号５１ａ、格納アドレス５１ｂに加えて、制御プログラムのサイズを格納するサイズ５１ｃを有している。これより、上記プログラム格納・更新処理の際には、プログラムメモリ２３に格納した制御プログラムのサイズを、サイズ５１ｃに格納する処理も行う。また、本例では、図６（ｄ）に示すシステム一時メモリ５２も備える。システム一時メモリ５２は、プログラムメモリ２３に格納されている複数の制御プログラムのうち、格納場所を移動させるべき制御プログラムがある毎に、その制御プログラムを一時的に退避させる為のメモリである。空き領域のサイズが、移動させるべき制御プログラムのサイズより大きければ、直接移動が可能であるが、必ずしも大きいわけではないので、システム一時メモリ５２を準備している。このシステム一時メモリ５２は、コントローラ３が許す単一プログラムの最大サイズを確保している。尚、システム一時メモリ５２は、プログラムメモリ２３の記憶領域の一部を用いても良い（この場合、プログラムメモリ２３の記憶容量を、その分増やす）。
【００４２】
また、プログラム変更要求キュー２２は、その構成自体は、上述したものと変わらないが、使い方が異なる。すなわち、図６（ｄ）にはプログラムＰＧ８をシステム一時メモリ５２に退避させた状態を示しており、これに応じて、プログラム変更要求キュー２２には図６（ｂ）に示すようにプログラム番号ＰＧ８に対応付けて退避先の先頭アドレス（ＡＤＲ１０）が格納される。更に、プログラムＰＧ８をプログラムメモリ２３内の新たな格納先に書き戻したときには、後述する図８（ｂ）に示すように、新たな格納先の先頭アドレスが格納されるようになる。
【００４３】
以下、上記構成を用いたプログラム格納位置の再配置処理について説明する。
本プログラム再配置処理は、プログラム情報テーブル５１を参照して、格納アドレス５１ｂが若い順に、各制御プログラムの格納状態（その制御プログラムの前に空き領域があるか否か）をチェックして、空き領域がある場合にはその制御プログラムを移動させる（前へ詰める）処理を順次実行していくものである。図示の例では、格納アドレスは、ADR1＜ADR3＜ADR5＜ADR6であるので、ＰＧ１→ＰＧ８→ＰＧ３→ＰＧ９の順番で、各制御プログラムについて、以下に説明する処理を行う。
【００４４】
まず、処理対象とした制御プログラムの１つ前の制御プログラムの“格納アドレス５１ｂの値＋サイズ５１ｃの値”が、処理対象プログラムの格納アドレス５１ｂの値と一致するか否かを判定する。これは、各制御プログラムの“先頭アドレス＋サイズ”が次の制御プログラムの先頭アドレスになっているかどうかで、空き領域があるかないかを確認するためである。但し、一番最初のＰＧ１のみは、その前の制御プログラムが存在しないので、別の処理を行う。すなわち、ＰＧ１の格納アドレス５１ｂの値が、プログラムメモリ２３の先頭アドレスと一致するか否かを判定する。図示の例では一致するので、ＰＧ１は移動させることなく処理終了し、続いてＰＧ８を処理対象とする。
【００４５】
ＰＧ８に関しては、その１つ前の制御プログラムＰＧ１の“先頭アドレスＡＤＲ１＋サイズ５１ｃ”が、プログラムＰＧ８の先頭アドレスＡＤＲ３と一致するか否かをチェックするのであり、図６（ｃ）に示すように、ＰＧ１の“先頭アドレス＋サイズ”＝ＡＤＲ２であるので、一致しないので、プログラムＰＧ８の前に、空き領域があることが分かる。
【００４６】
この様に“一致しない”と判定した場合には、続いて、プログラムＰＧ８を、その先頭アドレスがＡＤＲ２となる位置へと移動させるが、その為には、上記の通り、システム一時メモリ５２に一時的に退避（コピー）させる。そして、退避させた制御プログラムのプログラム番号（ＰＧ８）と退避先の先頭アドレス（ＡＤＲ１０）とを、プログラム変更要求キュー２２に格納し、ライトポインタ３２をインクリメントする。これより、プログラム変更要求キュー２２は、図６（ｂ）に示す状態となる。
【００４７】
次に、図４に示す処理を呼出す。これにより、図４の処理が実行されることで、プログラム情報テーブル５１は、図７（ａ）に示す状態になる。すなわち、ＰＧ８に対応する格納アドレス５１ｂが、ＡＤＲ３からＡＤＲ１０へと更新される。また、ステップＳ１６によりリードポインタ３１が１つ進められるので、プログラム変更要求キュー２２は、図７（ｂ）に示す状態となる。すなわち、リードポインタ３１の位置とライトポインタ３２の位置とが一致する状態となる。また、図７（ａ）に示すプログラム情報テーブル５１の内容により、プログラムメモリ２３には図７（ｃ）に示す空き領域６１が存在することになる（プログラムＰＧ８があった領域も空き領域になっている）。
【００４８】
続いて、システム一時メモリ５２から空き領域６１の先頭へプログラムＰＧ８を書き戻す処理を実行する。すなわち、図８（ｃ）に示すように、システム一時メモリ５２に退避させていたプログラムＰＧ８のコピー先の先頭アドレスを、上記“ＰＧ１の先頭アドレス＋サイズ＝ＡＤＲ２”として、当該プログラムＰＧ８をコピーする。コピー完了したら、図８（ｂ）に示すように、プログラム変更要求キュー２２に、プログラムメモリに書き込んだプログラム番号ＰＧ８とその先頭アドレスＡＤＲ２をセットし、ライトポインタ３２をインクリメントする。
【００４９】
そして、再び図４の処理を呼出して実行させることにより、プログラム情報テーブル５１は、図８（ａ）に示す状態になる。すなわち、ＰＧ８に対応する格納アドレス５１ｂが、ＡＤＲ１０からＡＤＲ２へと更新される。
【００５０】
以上説明した処理は、他の制御プログラムについても同様にして実行していく。すなわち、上記の通りＰＧ１→ＰＧ８→ＰＧ３→ＰＧ９の順番でチェックしていくので、次はＰＧ３に関して、上記ＰＧ８の場合と同様にして処理を実行する。ＰＧ９についても同様である。尚、ある制御プログラムを移動させたら、基本的に、それ以降の制御プログラムは全て移動させることになるので、チェック処理は省いて直ぐに移動処理を行うようにしてもよい。
【００５１】
ＰＧ９についての処理が完了した時点で、プログラムメモリ２３の格納状態は、格納済みプログラムの後ろに一括して空き領域が存在する状態となる。よって、その後にプログラム更新が行われる場合には、更新版プログラムはこの空き領域に格納されるので、更新版プログラムを分割・格納する必要はない。
【００５２】
以上、本発明の実施の形態の一例について説明したが、本発明は、この様な一例に限らない。例えば、上述した一例では、ユーザ要求によるプログラム更新処理に用いるプログラム変更要求キュー２２を、システムによるプログラム格納位置の再配置処理の際にも用いた（共用した）が、２つのキューを用意して、別々に用いるようにしてもよい。この様に、ユーザ要求によるプログラム変更要求キューとシステムが使用するキューとを用意する構成としたのは、システムの要求を優先的に処理することにより、プログラム再配置を早めるためと、システム要求のプログラム再配置は、スキャン中かどうかにかかわらず実行可能なためである。なぜならば、システム要求によるプログラム格納位置再配置処理は、同一のプログラムを移動させるのであって、移動前のプログラムと移動後のプログラムのどちらを実行しても演算に影響しないからである。ただし、システム一時メモリ５２に格納されたプログラムを実行中にシステム一時メモリ５２に他のプログラムを上書きするのは問題外である。
【００５３】
あるいは、上記２つのキューを用いる方法以外にも、例えば、キューは１つのみを共有するが、プログラム変更要求キューに、システムからの要求かユーザからの要求かを判別する為のビット情報を設けてもよい。この変形例について、以下、図９、図１０を参照して説明する。本変形例では、概略的には、まず、図９（ｂ）に示すように、プログラム変更要求キュー７０は、リードポインタ３１、ライトポインタ３２だけでなく、システム用リードポインタ７１を用いて管理されている。更に、プログラム変更要求キュー７０には、プログラム番号７３、格納アドレス７４だけでなく、ビット情報７２が格納される。ビット情報７２が‘１’であれば、その格納データは上記プログラム格納位置の再配置処理による（システムからの要求による）ものであることを意味し、ビット情報７２が‘０’であれば、その格納データは上記ＲＵＮ中更新処理に係わるもの（ユーザ要求によるもの）であることを意味する。つまり、図６〜図８で説明したプログラム格納位置の再配置処理中に、プログラム変更要求キュー７０にデータ格納したときには、ビット情報７２に‘１’を格納する。一方、図３で説明したように更新版プログラムをプログラムメモリ２３に格納したことに伴ってプログラム変更要求キュー７０にデータ格納したときには、ビット情報７２に‘０’を格納する。尚、“ユーザ要求による”とは、支援装置１０から上記更新要求が送られてくることを意味する。
【００５４】
図９に示す例では、ユーザ要求により、プログラムＰＧ３の更新版であるプログラムＰＧ３’が送られてきて、これがプログラムメモリ２３に格納され、その後、ＲＵＮ中更新処理によってプログラム情報テーブル５１におけるＰＧ３に対応する格納アドレスがＡＤＲ５へと変更され、その後に上記プログラム格納位置の再配置処理によってＰＧ８がシステム一時メモリ５２に退避されると共にこの格納位置がプログラム変更要求キュー７０に格納されている。この場合、ビット情報７２は、図示の通り‘１’である。この状態で、ユーザ要求により、プログラムＰＧ９の更新版であるプログラムＰＧ９’が送られてきて、これがプログラムメモリ２３に格納されると共にその格納位置データが、プログラム変更要求キュー７０に格納されている。この場合、ビット情報７２は、図示の通り‘０’である。
【００５５】
以上説明したことにより、プログラム情報テーブル５１、プログラム変更要求キュー７０、プログラムメモリ２３、システム一時メモリ５２のデータ格納状態は、図９（ａ）〜（ｄ）に示す通りとなっている。
【００５６】
そして、この状態のときに、スキャンエンド処理に入り、この処理中に図１０に示すＲＵＮ中更新処理を実行する処理ルーチンが呼び出される。
図１０に示す処理は、基本的な処理内容は図４に示す処理と略同様であり、異なる点は、まず、システム用リードポインタ７１を用いて、ビット情報７２が‘１’であるデータを処理対象としたＲＵＮ中更新処理を実行し、次にリードポインタ３１を用いて、ビット情報７２が‘０’であるデータを処理対象としたＲＵＮ中更新処理を実行するものである。
【００５７】
図１０に示す処理では、まず、システム用リードポインタ７１の位置がライトポインタ３２の位置と同じであるか否かを判定し（ステップＳ２１）、同じであるならば（ステップＳ２１，ＮＯ）、ステップＳ２２以降の処理は実行せずに、ステップＳ２８の処理へと進む。
【００５８】
システム用リードポインタ７１の位置がライトポインタの位置と異なるならば（ステップＳ２１，ＹＥＳ）、更に、システム用リードポインタ７１が指すデータのビット情報７２が‘１’であるか否かを判定し（ステップＳ２２）、ビット情報７２が‘０’であるならば（ステップＳ２２，ＮＯ）、ステップＳ２３以降の処理は実行せずにステップＳ２７へと進み、システム用リードポインタ７１を進めて（インクリメントして）、ステップＳ２１に戻る。
【００５９】
一方、ビット情報７２が‘１’であるならば（ステップＳ２２，ＹＥＳ）、ステップＳ２３以降の処理へと進む。ステップＳ２３〜Ｓ２７の処理は、図４に示すステップＳ１２〜Ｓ１６の処理と略同様であるので、ここでは説明しない。
【００６０】
尚、システム用リードポインタ７１とリードポインタ３１は、最初は同じ位置にあり、上記処理によってシステム用リードポインタ７１を進めても、リードポインタ３１は進めない。
【００６１】
上記図９の例を対象として上記の処理を実行した場合、まず、システム用リードポインタ７１は、最初はＰＧ９に関するデータの位置を示しており、そのビット情報７２が‘０’であるので、ステップＳ２２の判定はＮＯとなり、ステップＳ２７でシステム用リードポインタ７１を１つ進めることで、今度はＰＧ８に関するデータの位置となり、そのビット情報７２は‘１’であるので、ステップＳ２３〜Ｓ２６の処理を実行することになる。これによって、プログラム情報テーブル５１は、図９（ａ）に示す状態ではＰＧ８に対応する格納アドレスはＡＤＲ３になっていたが、これがＡＤＲ１０へと更新されることになる。そして、再びステップＳ２７でシステム用リードポインタ７１を１つ進めると、当該ポインタ７１の位置はライトポインタ３２の位置と同じになるので、ステップＳ２１の判定はＮＯとなり、ステップＳ２８の処理へと進む。
【００６２】
ステップＳ２８では、リードポインタ３１の位置がライトポインタ３２の位置と同じであるか否かを判定し、同じであるならば（ステップＳ２８，ＮＯ）、ステップＳ２９以降の処理は実行せずに、本処理を終了する。一方、同じではないならば（ステップＳ２８，ＹＥＳ）、リードポインタ３１が指すデータのビット情報７２が‘０’であるか否かを判定し（ステップＳ２９）、ビット情報７２が‘１’であるならば（ステップＳ２９，ＮＯ）、ステップＳ３４に進み、リードポインタ３１を進めた後、ステップＳ２８に戻る。
【００６３】
一方、ビット情報７２が‘０’であるならば（ステップＳ２９，ＹＥＳ）、ステップＳ３０以降の処理に進む。ステップＳ３０〜Ｓ３４の処理は、図４に示すステップＳ１２〜Ｓ１６の処理と略同様であるので、ここでは説明しないが、この処理を上記図９の例を対象として実行した場合、プログラム情報テーブル５１は、図９（ａ）に示す状態ではＰＧ９に対応する格納アドレスはＡＤＲ４になっていたが、これがＡＤＲ６へと更新されることになる。
【００６４】
本発明は、上述した実施の形態の例に限らない。例えば、上記プログラム変更要求キュー２２を用いることに代えて、支援装置１０からコントローラ３に更新版プログラムをダウンロードする際に、“一括で更新したいプログラムのリスト”と更新要求のコマンドも一緒に渡すようにしてもよい。
【図面の簡単な説明】
【００６５】
【図１】プログラマブルコントローラ・システムの概略構成図である。
【図２】（ａ）はプログラム情報テーブル、（ｂ）はプログラム変更要求キュー、（ｃ）はプログラムメモリの一例である。
【図３】図２の例に基づき、RUN中に２つのプログラムの更新要求があった場合のデータ格納例である。
【図４】RUN中更新処理フローチャート図である。
【図５】図３の例に基づき、図４の処理を実行したときのデータ格納状態を示す図である。
【図６】プログラム格納位置の再配置処理を説明する為の図（その１）である。
【図７】プログラム格納位置の再配置処理を説明する為の図（その２）である。
【図８】プログラム格納位置の再配置処理を説明する為の図（その３）である。
【図９】変形例を説明する為の具体例である。
【図１０】変形例によるRUN中更新処理フローチャート図である。
【符号の説明】
【００６６】
１  コンパイラ
２  伝送装置
３  コントローラ
１０  コントローラ支援装置
１１  表示装置
１２  入力装置
１３  記録媒体
２１  プログラム情報テーブル
２１ａ  プログラム番号
２１ｂ  格納アドレス
２２  プログラム変更要求キュー
２３  プログラムメモリ
３１  リードポインタ
３２  ライトポインタ
３３  格納アドレス
４１，４２  領域
５１  プログラム情報テーブル
５１ａ  プログラム番号
５１ｂ  格納アドレス
５１ｃ  サイズ
５２  システム一時メモリ
６１  空き領域
【図１】
2006202233.tif 000003
【図２】
2006202233.tif 000004
【図３】
2006202233.tif 000005
【図４】
2006202233.tif 000006
【図５】
2006202233.tif 000007
【図６】
2006202233.tif 000008
【図７】
2006202233.tif 000009
【図８】
2006202233.tif 000010
【図９】
2006202233.tif 000011
【図１０】
2006202233.tif 000012