JP2016224558A - プログラム作成支援装置、制御方法およびプログラム - Google Patents

Abstract

【課題】グラフィカルプログラミング言語により記述されるプログラムについてのシミュレータと高級プログラミング言語により記述されるプログラムについてのシミュレータとを連携させることで、ユーザのプログラム開発負担を軽減すること。【解決手段】ラダーシミュレータ５１はグラフィカルプログラミング言語で記述された第１プログラムの実行をシミュレーションする。Ｃ言語シミュレータ５４は高級プログラミング言語で記述された第２プログラムを実行する。デバイス記憶部５３は第１プログラムにより設定されるデバイスの状態を記憶する。管理部５７はラダーシミュレータ５１とＣ言語シミュレータ５４との間でデバイスの状態を受け渡す。【選択図】図７

Description

本発明は、プログラマブル・ロジック・コントローラ用のプログラムを作成するプログラム作成支援装置、プログラム作成支援装置で実行されるプログラムおよび制御方法に関する。

特許文献１が示すようにラダープログラムとＣ言語プログラムとを実行するプログラマブル・ロジック・コントローラ（ＰＬＣ）が知られている。

特開２００６−１７８８１８号公報

ＰＬＣで実行されるラダープログラムとＣ言語プログラムとは連携して動作することがあるが、従来は、それぞれ専用の編集ソフトウエアを使用してプログラム作成支援装置で作成されていた。また、各編集ソフトウエアにはＰＬＣの動作を模擬するシミュレータが設けられており、ラダープログラムについてのシミュレーションとＣ言語プログラムとのシミュレーションとが個別に独立して実行されていた。ラダープログラムについてのシミュレータと、Ｃ言語プログラムとのシミュレータには連携機能がなかったため、従来は、相手方の動作を模擬するスタブなどを作成する必要があり、ユーザのプログラミングの負担が大きかった。

そこで、本発明は、ラダープログラムのようなグラフィカルプログラミング言語により記述されるプログラムについてのシミュレータとＣ言語のような高級プログラミング言語により記述されるプログラムについてのシミュレータとを連携させることで、ユーザのプログラム開発負担を軽減することを目的とする。

本発明は、たとえば、
プログラマブル・ロジック・コントローラで実行されるユーザプログラムを作成するプログラム作成支援装置であって、
グラフィカルプログラミング言語で記述されたユーザプログラムである第１プログラムの実行をシミュレーションする第１シミュレーション部と
高級プログラミング言語で記述されたユーザプログラムである第２プログラムを実行する第２シミュレーション部と、
前記第１プログラムにより設定されるデバイスの状態を記憶するデバイス記憶部と、
前記第１シミュレーション部と前記第２シミュレーション部を管理する管理部と
を有し、
前記管理部は、前記第１シミュレーション部と前記第２シミュレーション部との間で前記デバイスの状態を受け渡すことを特徴とする。

本発明によれば、ラダープログラムのようなグラフィカルプログラミング言語により記述されるプログラムについてのシミュレータとＣ言語のような高級プログラミング言語により記述されるプログラムについてのシミュレータとを連携させることで、ユーザのプログラム開発負担を軽減することが可能となる。

ＰＬＣシステムの一例を示す図 ユーザプログラムの一例を示す図 プログラム作成支援装置の一例を示す図 ＰＬＣの一例を示す図 スキャンタイムを説明するための図 ＰＬＣの機能を示す図 プログラム作成支援装置の機能を示す図 統合開発環境のユーザインタフェースの一例を示す図 統合シミュレーションにおける管理部の動作を示す図 統合シミュレーションにおけるラダーシミュレータの動作を示すフローチャート 統合シミュレーションにおけるＣ言語ミュレータの動作を示すフローチャート プログラム作成支援装置のコンバータに関する機能を示す図

以下に本発明の一実施形態を示す。以下で説明される個別の実施形態は、本発明の上位概念、中位概念および下位概念など種々の概念を理解するために役立つであろう。また、本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されるわけではない。

はじめにプログラマブル・ロジック・コントローラ（ＰＬＣ、単にプログラマブルコントローラと呼ばれてもよい）を当業者にとってよりよく理解できるようにするために、一般的なＰＬＣの構成とその動作について説明する。

図１は、本発明の実施の形態によるプログラマブル・ロジック・コントローラシステムの一構成例を示す概念図である。図１に示すように、このシステムは、ラダープログラムなどのユーザプログラムの編集を行うためのプログラム作成支援装置１と、工場等に設置される各種制御装置を統括的に制御するためのＰＬＣ（プログラマブル・ロジック・コントローラ）２とを備えている。ユーザプログラムは、ラダー言語やモーションフローなどのグラフィカルプログラミング言語を用いて作成されてもよいし、Ｃ言語などの高級プログラミング言語を用いて作成されてもよい。以下では、説明の便宜上、ユーザプログラムはラダープログラムとする。ＰＬＣ２は、ＣＰＵが内蔵された基本ユニット３と１つないし複数の拡張ユニット４を備えている。基本ユニット３に対して１つないし複数の拡張ユニット４が着脱可能となっている。基本ユニット３はＣＰＵユニットと呼ばれることもある。

基本ユニット３には、表示部５及び操作部６が備えられている。表示部５には、基本ユニット３に取り付けられている各拡張ユニット４の動作状況などを表示することができ、表示部５の表示内容は、操作部６を操作することにより切り替えることができる。表示部５には、通常、ＰＬＣ２内のデバイスの現在値（デバイス値）やＰＬＣ２内で生じたエラー情報などが表示される。なお、デバイスとは、デバイス値を格納するために設けられたメモリ上の領域を指す名称であり、デバイスメモリと呼ばれてもよい。デバイス値とは、入力機器からの入力状態、出力機器への出力状態およびユーザプログラム上で設定される内部リレー（補助リレー）、タイマー、カウンタ、データメモリ等の状態を示す情報である。

拡張ユニット４は、ＰＬＣ２の機能を拡張するために用意されており、基本ユニット３に対して側方から取り付けられる。１つ目の拡張ユニット４は、基本ユニット３に対して側方から直接的に取り付けられる。２つ目以降の拡張ユニット４は、既に取り付けられている拡張ユニット４に対して、側方から直列的に取り付けられる。たとえば、基本ユニット３の右側面と拡張ユニット４の左側面とが連結面になっている。同様に、１つ目の拡張ユニット４の右側面の形状等は基本ユニット３の右側面とほぼ同じであるため、１つ目の拡張ユニット４の右側面に２つ目の拡張ユニット４の左側面が連結される。このような連結方式は、数珠つなぎ方式とかデイジーチェーン方式と呼ばれてもよい。各連結面にはコネクタが設けられており、通信や電力供給を行うためのバスもコネクタを介して連結される。このようにして、基本ユニット３と複数の拡張ユニット４が直列的に取り付けられると、各拡張ユニット４内に備えられた配線（例：バス）を介して、各拡張ユニット４が基本ユニット３に対して通信可能に接続される。各拡張ユニット４には、その拡張ユニット４の機能に対応する被制御装置１６（図４）が接続され、これにより、各被制御装置１６が拡張ユニット４を介して基本ユニット３に接続される。被制御装置１６には、センサなどの入力装置や、アクチュエータなどの出力装置が含まれる。

プログラム作成支援装置１は、たとえば、携帯可能ないわゆるノートタイプやタブレットタイプのパーソナルコンピュータであって、表示部７及び操作部８を備えている。ＰＬＣ２を制御するためのユーザプログラムの一例であるラダープログラムは、プログラム作成支援装置１を用いて作成され、その作成されたラダープログラムは、プログラム作成支援装置１内でニモニックコードに変換される。そして、プログラム作成支援装置１を、ＵＳＢ(Universal Serial Bus)などの通信ケーブル９を介してＰＬＣ２の基本ユニット３に接続し、ニモニックコードに変換されたラダープログラムをプログラム作成支援装置１から基本ユニット３に送ると、そのラダープログラムが基本ユニット３内でマシンコードに変換され、基本ユニット３に備えられたメモリ内に記憶される。なお、ここではニモニックコードを基本ユニット３に送信するようにしているが、本発明はこれに限られず、例えばニモニックコードを更に中間コードに変換し、中間コードを基本ユニット３に送信するようにしてもよい。

なお、図１では示していないが、プログラム作成支援装置１の操作部８には、プログラム作成支援装置１に接続されたマウスなどのポインティングデバイスが含まれていてもよい。また、プログラム作成支援装置１は、ＵＳＢ以外の他の通信ケーブル９を介して、ＰＬＣ２の基本ユニット３に対して着脱可能に接続されるような構成であってもよい。

図２は、ラダープログラムの作成時にプログラム作成支援装置１の表示部７に表示されるラダー図１７の一例を示す図である。図２に示すように、ＰＬＣ２を制御するためのラダープログラムは、プログラム作成支援装置１の表示部７にマトリックス状に表示される複数のセル１８内に仮想デバイスのシンボル１９を適宜配置して、視覚的なリレー回路を表すラダー図１７を構築することにより作成される。

ラダー図１７には、たとえば、１０列×Ｎ行（Ｎは任意の自然数）のセル１８が配置されている。そして、各行のセル１８内に、図２に示す左側から右側に向かって、時系列的に仮想デバイスのシンボル１９を適宜配置することにより、視覚的なリレー回路を作成することができる。作成されるリレー回路は、１行で表される直列的なリレー回路であってもよいし、複数行に並列的に表されたリレー回路を互いに結合することにより作成された、並列的なリレー回路であってもよい。

図２に示すリレー回路は、入力装置からの入力信号に基づいてオン／オフされる３つの仮想デバイス（以下、「入力デバイス」と呼ぶ。）のシンボル１９ａ，１９ｂ，１９ｃと、出力装置の動作を制御するためにオン／オフされる仮想デバイス（以下、「出力デバイス」と呼ぶ。）のシンボル１９ｄとが適宜結合されることにより構成されている。

各入力デバイスのシンボル１９ａ，１９ｂ，１９ｃの上方に表示されている文字（「Ｒ０００１」、「Ｒ０００２」及び「Ｒ０００３」）は、その入力デバイスのデバイス名（アドレス名）２１を表している。各入力デバイスのシンボル１９ａ，１９ｂ，１９ｃの下方に表示されている文字（「フラグ１」、「フラグ２」及び「フラグ３」）は、その入力デバイスに対応付けられたデバイスコメント２２を表している。出力デバイスのシンボル１９ｄの上方に表示されている文字（「原点復帰」）は、その出力デバイスの機能を表す文字列からなるラベル２３である。

図２に示す例では、デバイス名「Ｒ０００１」及び「Ｒ０００２」にそれぞれ対応する２つの入力デバイスのシンボル１９ａ，１９ｂが直列的に結合されることにより、ＡＮＤ回路が構成されている。また、これらの２つの入力デバイスのシンボル１９ａ，１９ｂからなるＡＮＤ回路に対して、デバイス名「Ｒ０００３」に対応する入力デバイスのシンボル１９ｃが並列的に結合されることにより、ＯＲ回路が構成されている。すなわち、このリレー回路では、２つのシンボル１９ａ，１９ｂに対応する入力デバイスがいずれもオンした場合、又は、シンボル１９ｃに対応する入力デバイスがオンした場合にのみ、シンボル１９ｄに対応する出力デバイスがオンされるようになっている。

図３は、図１のプログラム作成支援装置１の電気的構成について説明するためのブロック図である。図３に示すように、プログラム作成支援装置１には、ＣＰＵ２４、表示部７、操作部８、記憶装置２５及び通信部２６が備えられている。表示部７、操作部８、記憶装置２５及び通信部２６は、それぞれＣＰＵ２４に対して電気的に接続されている。記憶装置２５は、少なくともＲＡＭを含む構成であり、プログラム記憶部２７と、編集ソフト記憶部２８とを備えている。

ユーザは、編集ソフト記憶部２８に記憶されている編集ソフトをＣＰＵ２４に実行させて、操作部８を通じてラダープログラムを編集する。ここで、ラダープログラムの編集には、ラダープログラムの作成及び変更が含まれる。編集ソフトを用いて作成されたラダープログラムは、プログラム記憶部２７に記憶される。また、ユーザは、必要に応じてプログラム記憶部２７に記憶されているラダープログラムを読み出し、そのラダープログラムを、編集ソフトを用いて変更することができる。通信部２６は、通信ケーブル９を介してプログラム作成支援装置１を基本ユニット３に通信可能に接続するためのものである。

図４は、ＰＬＣ２の電気的構成について説明するためのブロック図である。図４に示すように、基本ユニット３には、ＣＰＵ１０、表示部５、操作部６、記憶装置１２及び通信部１４が備えられている。表示部５、操作部６、記憶装置１２、及び通信部１４は、それぞれＣＰＵ１０に電気的に接続されている。ＣＰＵ１０は、必ずしも単一のＣＰＵを指しているわけではなく、１つ以上の演算ユニットをまとめて記載しているにすぎない。たとえば、ＣＰＵ１０は、ラダープログラムを実行する『ラダー実行エンジン』（ＡＳＩＣ等）と、Ｃ言語プログラムを実行する『Ｃ言語実行エンジン』（汎用ＣＰＵ等）を有していてもよい。記憶装置１２は、ＲＡＭやＲＯＭ、メモリカードなどを含んでもよく、ラダープログラムなどを記憶する。記憶装置１２には、プログラム作成支援装置１から入力されたラダープログラムやユーザデータが上書きして記憶される。また、記憶装置１２には基本ユニット用の制御プログラムも格納されている。図４が示すように基本ユニット３と拡張ユニット４とは拡張バスの一種であるユニット外部バス９０を介して接続されている。なお、ユニット外部バス９０に関する通信機能は通信部１４の一部として実装されてもよい。

図５は、本発明の実施の形態に係るプログラマブルコントローラの基本ユニット３でのスキャンタイムの構成を示す模式図である。図５が示すように１つのスキャンタイムＴは、入出力のリフレッシュを行うためのユニット間通信２０１、プログラム実行２０２、ＥＮＤ処理２０４により構成されている。ユニット間通信２０１で、基本ユニット３は、ラダープログラムを実行して得られた出力データを基本ユニット３内の記憶装置１２から外部機器などに送信するとともに、受信データを含めた入力データを基本ユニット３内の記憶装置１２に取り込む。たとえば、基本ユニット３のデバイスに記憶されているデバイス値はリフレッシュによって拡張ユニット４のデバイスに反映される。同様に、拡張ユニット４のデバイスに記憶されているデバイス値はリフレッシュによって基本ユニット３のデバイスに反映される。なお、リフレッシュ以外のタイミングでデバイス値をユニット間で更新する仕組みが採用されてもよい。ただし、基本ユニット３のデバイスは基本ユニット３が随時書き換えており、同様に、拡張ユニット４のデバイスは拡張ユニット４が随時書き換えている。つまり、基本ユニット３のデバイスは基本ユニット３の内部の装置によって随時アクセス可能であり、同様に、拡張ユニット４のデバイスは拡張ユニット４の内部の装置によって随時アクセス可能になっている。基本ユニット３と拡張ユニット４との間では基本的にリフレッシュのタイミングにおいて相互にデバイス値を更新して同期する。プログラム実行２０２で、基本ユニット３は、更新された入力データを用いてプログラムを実行（演算）する。基本ユニット３はプログラムの実行によりデータを演算処理する。なお、ＥＮＤ処理とは、プログラム作成支援装置１や基本ユニット３に接続された表示器（図示せず）等の外部機器とのデータ通信、システムのエラーチェック等の周辺サービスに関する処理全般を意味する。

このように、プログラム作成支援装置１はユーザの操作に応じたラダープログラムを作成し、作成したラダープログラムをＰＬＣ２に転送する。ＰＬＣ２は、入出力リフレッシュ、ラダープログラムの実行およびＥＮＤ処理を１サイクル（１スキャン）として、このサイクルを周期的、すなわちサイクリックに繰り返し実行する。これにより、各種入力機器（センサ等）からのタイミング信号に基づいて、各種出力機器（モータ等）を制御する。よって、ＰＬＣ２は汎用のパーソナルコンピュータ（ＰＣ）とは全く異なる動きをする。

＜基本ユニットの機能＞
図６は基本ユニット３のＣＰＵ１０が制御プログラムを実行することで実現する機能を中心に示している。ＣＰＵ１０において第１実行部３０は、グラフィカルプログラミング言語で記述されるユーザプログラムである第１プログラムを実行する演算ユニットである。第１実行部３０は、たとえば、ラダープログラムを実行する『ラダー実行エンジン』（ＡＳＩＣ等）である。第１プログラムの一例としてラダープログラムを採用するが、他のグラフィカルプログラミング言語で記述されるユーザプログラムであってもよい。第１実行部３０は、ラダープログラム（中間コード）４３を実行形式のコードに変換する機能を備えていてもよい。第１実行部３０の外部にこのような変換器が設けられていてもよい。第２実行部３１は、高級プログラミング言語で記述されるユーザプログラムである第２プログラムを実行する演算ユニットである。第２実行部３１は、たとえば、Ｃ言語プログラムを実行する『Ｃ言語実行エンジン』（汎用ＣＰＵ等）である。第２プログラムの一例としてＣ言語プログラム４４を採用するが、他の高級プログラミング言語で記述されるユーザプログラムであってもよい。なお、ＣＰＵ１０は第１実行部３０と第２実行部３１に相当する演算部を異なる複数のＣＰＵコアとして備えていてもよいし、一方はＣＰＵ１０のＣＰＵコアが担当し、他方はＡＳＩＣなどで実装されてもよい。特に、第１実行部３０がラダープログラムを実行する際には高速処理が要求されるため、高速処理対応のＡＳＩＣで実装し、第２実行部３１が通信処理などを実行する際には高速処理は要求されないため、高機能ＣＰＵなどで実装してもよい。この場合、第１実行部３０と第２実行部３１はユニット内部バス３２によって接続され、通信する。

記憶装置１２には、基本ユニット３のシステムプログラム（ファームウエア）である制御プログラム４０と、プログラム作成支援装置１から転送されてきたプロジェクト４１などが記憶される。プロジェクト４１には、プロジェクトデータ４２、ラダープログラム（中間コード）４３およびＣ言語プログラム（オブジェクトコード）４４などが含まれている。プロジェクト４１には、ラダープログラムのソースコードやＣ言語プログラムのソースコードが含まれていてもよい。プロジェクトデータ４２は、拡張ユニット４についての設定データなどが含まれている。ラダープログラム（中間コード）４３はプログラム作成支援装置１によりソースコードから生成された中間コード（ニーモニック）である。Ｃ言語プログラム（オブジェクトコード（実行コードや実行ファイルと呼ばれてもよい））４４はプログラム作成支援装置１によりソースコードから生成された実行形式のコードである。

プロジェクト管理部３３は、プログラム作成支援装置１から通信部１４を介してプロジェクト４１の書き込み要求を受信すると、プログラム作成支援装置１からプロジェクト４１を受信して記憶装置１２に格納する。また、プロジェクト管理部３３は、プログラム作成支援装置１から読み出し要求を受信すると、読み出し対象として指定されたファイル（例：プロジェクト４１の全体、ラダープログラム（中間コード）４３のみ、Ｃ言語プログラム（オブジェクトコード）４４のみ、Ｃ言語プログラムのソースファイルのみなど）を記憶装置１２から読み出して、プログラム作成支援装置１に転送する。プロジェクト４１の読み出し機能はプロジェクト４１の再編集に有用である。

＜プログラム作成支援装置１の機能＞
上述したようにＰＬＣ２の中には、ラダープログラムを実行する『ラダー実行エンジン』（ＡＳＩＣ等）と、Ｃ言語プログラムを実行する『Ｃ言語実行エンジン』（汎用ＣＰＵ等）が設けられている。一方、プログラム作成支援装置１には、１個の『ＰＣ用実行エンジン』（汎用ＣＰＵ等）が設けられうる。本明細書において“シミュレーション”とは、ＰＬＣ２内の『ラダー実行エンジン』と『Ｃ言語実行エンジン』といった２つの実行エンジンの機能を、『ＰＣ用実行エンジン』という１つの実行エンジンでシミュレートすることと言ってもよい。

図７はプログラム作成支援装置１が編集ソフトウエア５０を実行することで実現するＣＰＵ２４の機能を中心に記載している。編集ソフトウエア５０は、記憶装置２５の編集ソフト記憶部２８に記憶されている。とりわけ、編集ソフトウエア５０は、グラフィカルプログラミング言語によるプログラミング環境と高級プログラミング言語によるプログラミング環境とを統合した統合開発環境を提供するものである。従来はグラフィカルプログラミング言語と高級プログラミング言語とでそれぞれ別々の編集ソフトウエアが使用されていた。そのため、従来はグラフィカルプログラミング言語と高級プログラミング言語とでそれぞれ別々のプロジェクトが作成されて管理されていた。一方で、本実施例ではグラフィカルプログラミング言語と高級プログラミング言語とで１つのプロジェクトにより管理することが可能となる。つまり、１つのプロジェクトファイルによりＣ言語プログラムとラダープログラムとを管理できるようになる。

プログラム記憶部２７には、プロジェクト４１などが記憶されている。プログラム作成支援装置１が保持しているプロジェクト４１とＰＬＣ２が保持しているプロジェクト４１には、プロジェクトデータ４２、ラダープログラム４３、Ｃ言語プログラム４４などが含まれる。プロジェクト４１をＰＬＣ２に転送するときに一部のファイルが削除されてもよい。たとえば、ＰＬＣ２にとってソースコードなどは必ずしも必要ではないため、これらは転送されなくてもよい。なお、ソースコードも転送しておくと、ＰＬＣ２からソースコードを取得した別のプログラム作成支援装置１においてソースコードを再編集することが可能となる。プロジェクトデータ４２はプロジェクト４１を構成している複数のファイル名と、どのファイルがソースファイルであり、どのファイルが実行ファイルであるかなどを管理するためのデータを有している。また、プロジェクトデータ４２は拡張ユニット４の設定データなどが含まれていてもよい。

図８は統合開発環境のユーザインタフェースの一例を示す図である。ＣＰＵ２４はユーザインタフェース７０を表示部７に表示する。ワークスペース７１は、ラダープログラム４３の名称やＣ言語プログラム４４の名称などを設定するための設定エリアである。ＣＰＵ２４は、ワークスペース７１を通じてユーザにより入力されたプロジェクト４１の名称、ラダープログラム４３の名称、Ｃ言語プログラム４４の名称、各実行ファイルの名称などをプロジェクトデータ４２に格納する。ラダータブ７２はラダープログラムを編集するためのタブである。Ｃ言語タブ７３はＣ言語プログラムを編集するためのタブである。ユーザは操作部８を通じて各プログラムのソースファイルを編集する。ＣＰＵ２４はプロジェクト４１を１つの統合ファイルとしてまとめてもよいし、複数のファイルに分割して管理してもよい。後者の場合、ＣＰＵ２４はＣ言語プログラム４４をテキストファイルに保存してもよい。テキストファイルに保存されたＣ言語プログラム４４はユーザにとって使い慣れたテキストエディタによる編集を可能とする。

ＣＰＵ２４は、ソースコードのコンパイラー（実行コードや中間コードへの変換器（複数の中間コードをリンクして実行コードを生成するリンカーなどが含まれてもよい））を有し、実行形式や中間形式のファイルを生成する。ＣＰＵ２４は通信部２６を通じてＰＬＣ２に完成したプロジェクト４１を転送する。

また、ＣＰＵ２４はシミュレータメニュー７４を通じてシミュレーションの実行を指示されると、ラダープログラム４３とＣ言語プログラム４４の統合シミュレーションを開始する。なお、ＣＰＵ２４はＰＣ用実行エンジンの一例である。統合シミュレーションにおいては、ＣＰＵ２４は、一ステップずつユーザの指示に応じてラダープログラム４３とＣ言語プログラム４４を実行してもよいし、ユーザの指示を待たずに連続的にラダープログラム４３とＣ言語プログラム４４を実行してもよい。どちらを実行するかは、シミュレータメニュー７４を通じて選択される。

図７においてラダーシミュレータ５１は、ラダープログラム４３を実行するラダー実行部５２と、ラダープログラム４３によって使用されるデバイス（デバイスの状態）を記憶するデバイス記憶部５３とを有している。ラダーシミュレータ５１は、基本ユニット３の第１実行部３０をエミュレーションする第１エミュレータを有していてもよい。第１エミュレータは、ニモニックコードを『ラダー実行エンジン』が実行できる実行コードに変換する機能を有するとともに、この実行コードを実行する機能を有する。つまり、第１エミュレータによって変換された実行コードは、ＰＬＣ２内でラダー実行エンジンが実行する実行コードと同一のものである。ラダーシミュレータ５１における「シミュレーション」とは、たとえば、少なくともＰＬＣ２への入力動作（及び／又は出力動作）を仮想的に再現するものをいう。たとえば、入力リレーのオン・オフ、入力デバイスへの数値入力などが一例である。

Ｃ言語シミュレータ５４は、Ｃ言語プログラム４４を実行するＣ言語実行部５５とＣ言語プログラム４４により定義されるデータを記憶するデータ記憶部５６を有している。Ｃ言語シミュレータ５４は、第２実行部３１をエミュレーションする第２エミュレータを有していてもよい。なお、Ｃ言語シミュレータ５４は、Ｃ言語プログラム４４を『ラダー実行エンジン』が実行できるオブジェクトコードに変換する機能を有するとともに、Ｃ言語プログラム４４を『ＰＣ用実行エンジン』が実行できるオブジェクトコードに変換する機能も有する。つまり、Ｃ言語シミュレータ５４は、２種類のオブジェクトコードに変換することができ、一方のオブジェクトコードはＰＬＣ２に送られ、実際のＰＬＣ２の動作に用いられ、他方のオブジェクトコードはプログラム作成支援装置１におけるシミュレーションに用いられる。なお、Ｃ言語シミュレータ５４は、２種類のコンパイラーを有しているといってもよい。

デバイス記憶部５３とデータ記憶部５６の実態は記憶装置２５に確保されるものとする。管理部５７は、ラダーシミュレータ５１とＣ言語シミュレータ５４を管理する機能であり、これらの間でデバイスの状態（例：デバイス値やＣ言語シンボルなど）を受け渡す。

従来は、ラダープログラム４３とＣ言語プログラム４４とはそれぞれ専用の編集ソフトウエアにより作成されて、シミュレーションされていた。ラダープログラム４３とＣ言語プログラム４４とでデバイスの値を受け渡すようなプログラムコードが存在していても、これを受け渡すことができなかった。つまり、シミュレーションにおいては、Ｃ言語プログラム４４に対してラダープログラム４３から引数などのデバイス値を受け渡すことができなかったため、ユーザは操作部８を通じてＣ言語プログラム４４にデバイス値を入力する必要があった。デバイス値を入力するためのスタブが作成されることもあったが、これもユーザのプログラミング負担を増加させていた。なお、スタブは、本来はプログラムの実行結果に応じて動的に変化する変数であっても定数を返すことしかできない。そのため、スタブを利用するユーザはラダープログラム４３とＣ言語プログラム４４とが本当に連携して動作できるのかを確認できなかった。連携することが難しかった理由としては、ラダーシミュレータが確保する仮想メモリ空間と、Ｃ言語シミュレータが確保する仮想メモリ空間はそれぞれ独立していることがあげられる。そのため、両者は相互に相手方が確保したメモリ空間にはアクセスすることができず、デバイス値などを交換できなかった。

本実施例では、ラダーシミュレータ５１とＣ言語シミュレータ５４との通信を中継する管理部５７が設けられている。管理部５７は、デバイス記憶部５３やデータ記憶部５６について物理アドレスと論理アドレスとの対応関係を保持するテーブルを有していてもよい。たとえば、Ｃ言語プログラム４４上で定義されているシンボルをラダー実行部５２がラダープログラム４３にしたがって参照しようとすると、そのシンボルの論理アドレスを物理アドレスに変換して、シンボルを読み出し、ラダー実行部５２に渡す。逆に、ラダープログラム４３上で定義されているデバイスをＣ言語実行部５５がＣ言語プログラム４４にしたがって参照しようとすると、そのデバイスの論理アドレスを物理アドレスに変換して、デバイス値を読み出し、Ｃ言語実行部５５に渡す。なお、ラダーシミュレータ５１とＣ言語シミュレータ５４とが共通バスを介して接続されていてもよい。この場合、管理部５７は、共通バスを介したデバイス記憶部５３やデータ記憶部５６へのアクセスを調停する。管理部５７は、共通バスを介して情報を送受信するためのコマンドを必要に応じて発行してもよい。なお、管理部５７は、デバイス記憶部５３とデータ記憶部５６とに記憶されている情報をラダーシミュレータ５１とＣ言語シミュレータ５４とで共有するための共有メモリを有していてもよい。たとえば、ラダーシミュレータ５１からデータ記憶部５６へのアクセス要求が発生すると、管理部５７は、データ記憶部５６からデータを共有メモリにコピーし、コピーしたデータをラダーシミュレータ５１に渡す。同様に、Ｃ言語シミュレータ５４からデバイス記憶部５３へのアクセス要求が発生すると、管理部５７は、デバイス記憶部５３からデバイス値を共有メモリにコピーし、コピーしたデバイス値をＣ言語シミュレータ５４に渡す。

ここで、Ｃ言語プログラム４４からラダープログラム４３のデバイスを読み書きするために以下のようなＡＰＩ（アプリケーションインタフェース）を用いてもよい。
●（読み） ｖａｌｕｅ ＝ ＤｅｖｉｃｅＡｐｉ＿Ｒｅａｄ（３， １００）；
この命令は、デバイス種別が“３”に分類されるデバイスのうちデバイス番号“１００”番のデバイスの値を読み出してｖａｌｕｅに代入するための命令である。なお、デバイス種別やデバイス番号はデバイスを識別するためのシンボルであり、識別情報である。
●（書き） ＤｅｖｉｃｅＡｐｉ＿Ｗｒｉｔｅ（５， ２００， １２３）；
この命令は、デバイス種別が“５”に分類されるデバイスのうち、“２００”番のデバイスに“１２３”という値を書き込むための命令である。このようなＡＰＩを利用することで、Ｃ言語プログラム４４はラダープログラム４３のデバイスを読み書きすることが可能となる。上述したようにデバイスの実体はＲＡＭなどの記憶装置２５に存在する。管理部５７は上記のようなフォーマットで指定されたデバイスへの読み書き命令をＣ言語シミュレータ５４から受信し、指定されたデバイスの論理アドレス（デバイス記憶部５３におけるデバイスのアドレス）を、記憶装置２５におけるデバイスの物理アドレスに変換してアクセスし、デバイスの実態に対して値を読み書きする。このようなアクセスは代理アクセスと呼ばれてもよい。管理部５７は、Ｃ言語プログラム４４からデバイス記憶部５３に代理アクセスする代理アクセス部と、ラダープログラム４３からデータ記憶部５６に代理アクセスする代理アクセス部とをそれぞれ有していてもよい。これらの代理アクセス部はデータやデバイスの論理アドレスを物理アドレスに変換し、データやデバイスに直接アクセスして情報を読み書きする。

なお、ラダーシミュレータ５１とＣ言語シミュレータ５４との間で受け渡されるデータとしては以下のデータがある。
・ラダーシミュレータ５１におけるシミュレーションの実行結果
・Ｃ言語シミュレータ５４におけるＣ言語プログラム４４の実行結果
・引数
・Ｃ言語プログラム４４を起動するための起動指示
・Ｃ言語プログラム４４の実行完了と通知するための完了通知
＜管理部の動作＞
図９は管理部の動作を示すフローチャートである。管理部５７は操作部８を通じて統合シミュレーションの開始を指示されると以下のステップを実行する。なお、この指示は、図７を用いて説明したように、シミュレータメニュー７４を通じて入力される。

Ｓ１で管理部５７は、ラダー実行部５２を起動してラダープログラム４３のシミュレーションを開始させる。Ｓ２で管理部５７は、Ｃ言語実行部５５を起動してＣ言語プログラム４４のシミュレーションを開始させる。なお、Ｓ１とＳ２とはどちらが先に実行されてもよい。以下のステップにおいても実行結果が同一である限り、各ステップの実行順番は入れ替え可能である。

Ｓ３で管理部５７はＣ言語実行部５５からデバイスへのアクセスを要求されたかどうかを判定する。上述したようにＣ言語実行部５５はデバイスに対して直接アクセスすることができない。そこで、Ｃ言語実行部５５からデバイスへのアクセスを要求された場合、管理部５７はＳ４に進む。なお、Ｃ言語実行部５５からデバイスへのアクセスを要求されていない場合、管理部５７はＳ４をスキップしてＳ５に進む。

Ｓ４で管理部５７はＣ言語実行部５５からアクセスを要求されたデバイスに対してアクセスする。デバイス値の読み出し要求であれば、管理部５７はデバイス記憶部５３に記憶されている当該デバイスのデバイス値を読み出し、Ｃ言語実行部５５にデバイス値を渡す。デバイス値の書き込み要求であれば、管理部５７はＣ言語実行部５５から受け取ったデバイス値をデバイス記憶部５３に保持されている当該デバイスに書き込む。

Ｓ５で管理部５７はラダー実行部５２からＣ言語シンボルへのアクセスを要求されたかどうかを判定する。上述したようにラダー実行部５２はＣ言語シンボルに対して直接アクセスすることができない。そこで、ラダー実行部５２からＣ言語シンボルへのアクセスを要求された場合、管理部５７はＳ６に進む。なお、ラダー実行部５２からＣ言語シンボルへのアクセスを要求されていない場合、管理部５７はＳ６をスキップしてＳ７に進む。

Ｓ６で管理部５７はラダー実行部５２からアクセスを要求されたＣ言語シンボルに対してアクセスする。Ｃ言語シンボルの読み出し要求であれば、管理部５７はデータ記憶部５６に記憶されているＣ言語シンボルを読み出し、ラダー実行部５２にＣ言語シンボルを渡す。Ｃ言語シンボルの書き込み要求であれば、管理部５７はラダー実行部５２から受け取ったＣ言語シンボルをデータ記憶部５６に書き込む。

Ｓ７で管理部５７は操作部８を通じて統合シミュレーションの停止を要求されたかどうかを判定する。統合シミュレーションの停止を要求された場合、管理部５７は、ラダー実行部５２とＣ言語実行部５５をそれぞれ停止させる。統合シミュレーションの停止を要求されていなければ、管理部５７はＳ３に戻る。

＜ラダー実行部の動作＞
図１０はラダー実行部５２の動作を示すフローチャートである。Ｓ１１でラダー実行部５２は管理部５７によって起動されると、ラダープログラム４３を実行する。ラダー実行部５２は、ラダープログラム４３から一命令ずつ読み出して実行する。

Ｓ１２でラダー実行部５２は読み出した命令がデバイスへのアクセス命令であるかどうかを判定する。読み出した命令がデバイスへのアクセス命令でない場合、ラダー実行部５２はＳ１４に進む。一方、読み出した命令がデバイスへのアクセス命令であれば、ラダー実行部５２はＳ１３に進む。Ｓ１３でラダー実行部５２はデバイス記憶部５３に保持されている複数のデバイスのうちラダープログラム４３によりアクセス対象として指定されたデバイスにアクセスする。アクセスには、デバイス値の書き込みと読み出しとがある。

Ｓ１４でラダー実行部５２は読み出した命令がＣ言語シンボルへのアクセス命令であるかどうかを判定する。読み出した命令がＣ言語シンボルへのアクセス命令でない場合、ラダー実行部５２はＳ１６に進む。一方、読み出した命令がＣ言語シンボルへのアクセス命令であれば、ラダー実行部５２はＳ１５に進む。Ｓ１５でラダー実行部５２はラダープログラム４３によりアクセス対象として指定されたＣ言語シンボルに対して管理部５７を通じて代理アクセスする。Ｃ言語シンボルの書き込み命令であれば、ラダー実行部５２はＣ言語シンボルの書き込み命令を管理部５７に渡す。Ｃ言語シンボルの読み出し命令であれば、ラダー実行部５２はＣ言語シンボルの読み出し命令を管理部５７に渡し、管理部５７からＣ言語シンボルを受け取る。

Ｓ１６でラダー実行部５２は管理部５７からシミュレーションの停止を要求されたかどうかを判定する。シミュレーションの停止を要求された場合、ラダー実行部５２はラダープログラム４３を停止する。シミュレーションの停止を要求されていなければ、ラダー実行部５２はＳ１１に戻る。

＜Ｃ言語実行部の動作＞
図１１はＣ言語実行部５５の動作を示すフローチャートである。Ｓ２１でＣ言語実行部５５は管理部５７によって起動されると、Ｃ言語プログラム４４を実行する。Ｃ言語実行部５５は、Ｃ言語プログラム４４から一命令ずつ読み出して実行する。

Ｓ２２でＣ言語実行部５５は読み出した命令がＣ言語シンボルへのアクセス命令であるかどうかを判定する。読み出した命令がＣ言語シンボルへのアクセス命令でない場合、Ｃ言語実行部５５はＳ２４に進む。一方、読み出した命令がＣ言語シンボルへのアクセス命令であれば、Ｃ言語実行部５５はＳ２３に進む。Ｓ２３でＣ言語実行部５５はＣ言語プログラム４４によりアクセス対象として指定されたＣ言語シンボルに対して直接アクセスする。Ｃ言語シンボルの書き込み命令であれば、Ｃ言語実行部５５はデータ記憶部５６にＣ言語シンボルを直接書き込む。Ｃ言語シンボルの読み出し命令であれば、Ｃ言語実行部５５はデータ記憶部５６からＣ言語シンボルを直接読み出す。データ記憶部５６は、Ｃ言語実行部５５からアクセス可能なアドレス空間に確保されているため、Ｃ言語実行部５５はＣ言語シンボルを直接的に読み書きできる。

Ｓ２４でＣ言語実行部５５は読み出した命令がデバイスへのアクセス命令であるかどうかを判定する。読み出した命令がデバイスへのアクセス命令でない場合、Ｃ言語実行部５５はＳ２６に進む。一方、読み出した命令がデバイスへのアクセス命令であれば、Ｃ言語実行部５５はＳ２５に進む。Ｓ２５でＣ言語実行部５５はＣ言語プログラム４４によりアクセス対象として指定されたデバイスに対して管理部５７を通じて代理アクセスする。デバイスの書き込み命令であれば、Ｃ言語実行部５５はデバイスの書き込み命令を管理部５７に渡す。デバイスの読み出し命令であれば、Ｃ言語実行部５５はデバイスの読み出し命令を管理部５７に渡し、管理部５７からデバイス値を受け取る。

Ｓ２６でＣ言語実行部５５は管理部５７からシミュレーションの停止を要求されたかどうかを判定する。シミュレーションの停止を要求された場合、Ｃ言語実行部５５はＣ言語プログラム４４を停止する。シミュレーションの停止を要求されていなければ、ラダー実行部５２はＳ２１に戻る。

＜シミュレーションの高速化＞
一般にＰＬＣ２のＣＰＵ１０とプログラム作成支援装置１のＣＰＵ２４とではオブジェクトコード（実行コード）のレベルで互換性が無い。そのため、ラダー実行部５２やＣ言語実行部５５はそれぞれＰＬＣ２のＣＰＵ１０（第１実行部３０や第２実行部３１）をエミュレーションするエミュレータが必要となる。つまり、管理部５７はＣ言語プログラム４４を実行するためのスレッドやプロセスを生成し、エミュレータ上でＣ言語プログラム４４を実行させる。しかし、エミュレータを介してプログラムを実行すると、プログラムの実行速度が低下する。とりわけ、ＰＬＣ２ではラダープログラム４３やＣ言語プログラム４４が連携しながら高速に実行されるため、これらのシミュレーションも高速に実行される必要がある。そこで、ラダープログラム４３やＣ言語プログラム４４をプログラム作成支援装置１のＣＰＵ２４のネイティブコードに変換し、シミュレーションを実行することで、シミュレーションの高速化を達成する。また、ＰＬＣ２のＣＰＵ１０をエミュレーションするエミュレータも省略可能となろう。

図１２は、編集ソフトウエア５０をＣＰＵ２４が実行することで実現される機能の一例を示している。ここでは、ラダープログラム４３とＣ言語プログラム４４のうちＣ言語プログラム４４について説明するが、ラダープログラム４３に適用されてもよい。この場合の説明は、以下の説明におけるＣ言語プログラム４４という文言をラダープログラム４３に置き換えたものとなろう。

管理部５７は操作部８を通じてシミュレーションの実行指示やプロジェクト４１の転送指示を受け付ける。シミュレーションの実行指示を受け付けると、管理部５７は、Ｃ言語プログラム４４のソースコード６０をシミュレータ用コンバータ６１に渡す。シミュレータ用コンバータ６１はＣＰＵ２４のネイティブコードを生成可能なコンパイラーやリンカーなどを含む。シミュレータ用コンバータ６１はソースコード６０をコンバートし、ＣＰＵ２４で直接実行可能なオブジェクトコード（ネイティブコード）を生成し、Ｃ言語シミュレータ５４に渡す。これにより、ＣＰＵ１０（Ｃ言語シミュレータ５４）はＣ言語プログラム４４を高速に実行できるようになる。

プロジェクト４１の転送指示を受け付けると、管理部５７は、Ｃ言語プログラム４４のソースコード６０をＰＬＣ用コンバータ６２に渡す。ＰＬＣ用コンバータ６２はＰＬＣ２が備えるＣＰＵ１０のネイティブコードを生成可能なコンパイラーやリンカーなどを含む。ＰＬＣ用コンバータ６２はソースコード６０をコンバートし、ＣＰＵ１０で直接実行可能なオブジェクトコード（ネイティブコード）を生成し、プロジェクト転送部６３に渡す。プロジェクト転送部６３は、ＣＰＵ１０で直接実行可能なオブジェクトコードをプロジェクト４１に登録し、通信部２６を介してプロジェクト４１をＰＬＣ２のプロジェクト管理部３３に転送する。

＜まとめ＞
図７を用いて説明したように、ラダーシミュレータ５１はグラフィカルプログラミング言語で記述されたユーザプログラムである第１プログラムの実行をシミュレーションする第１シミュレーション部の一例である。Ｃ言語シミュレータ５４は高級プログラミング言語で記述されたユーザプログラムである第２プログラムを実行する第２シミュレーション部の一例である。デバイス記憶部５３は第１プログラムにより設定されるデバイスの状態を記憶するデバイス記憶部の一例である。管理部５７は第１シミュレーション部と第２シミュレーション部を管理する管理部の一例である。図７ないし図１１を用いて説明したように、管理部５７は、第１シミュレーション部と第２シミュレーション部との間でデバイスの状態を受け渡す。これにより、第１シミュレーション部と第２シミュレーション部とを動的に連携させることが可能となる。また、ラダープログラムのようなグラフィカルプログラミング言語により記述されるプログラムについてのシミュレータとＣ言語のような高級プログラミング言語により記述されるプログラムについてのシミュレータとを連携させることで、ユーザのプログラム開発負担を軽減する。従来は、各言語のプログラムについて個別にシミュレーションが実行されていたため、ユーザはスタブを作成したり、データを手入力したりするなど、ユーザのプログラム開発負担が多かった。また、ラダーシミュレータ５１とＣ言語シミュレータ５４はそれぞれ独立したアドレス空間内でプログラムを実行するため、相互に、アドレス空間を参照することができなかった。本実施例では、管理部５７がラダーシミュレータ５１とＣ言語シミュレータ５４との間でデバイスの状態（デバイス値やＣ言語シンボルなど）を受け渡すため、ラダーシミュレータ５１とＣ言語シミュレータ５４が動的に連携することが可能となる。

なお、ラダーシミュレータ５１はＰＬＣ２が備える第１実行部３０（ラダー実行エンジン）をエミュレーションする第１エミュレータを有していてもよい。ラダーシミュレータ５１は、第１エミュレータを介してラダープログラムに記述された命令語を解釈してシミュレーションを行う。一方、Ｃ言語シミュレータ５４は、第１エミュレータを介さずにＣ言語プログラムに記述された命令語を解釈してシミュレーションを行ってもよい。ＰＬＣ２はラダープログラム４３を高速に実行するためにＡＳＩＣ等により構成された第１実行部３０（ラダー実行エンジン）を有している。また、それとは別に汎用のＣＰＵ等により実装され、Ｃ言語プログラム４４を実行する第２実行部３１を有している。プログラム作成支援装置１は一般的なコンピュータであり、ＣＰＵ２４は汎用のＣＰＵにより構成される。ＰＬＣ２が備える第２実行部３１も汎用のＣＰＵにより構成される。したがって、プログラム作成支援装置１は、ＰＬＣ２のＣＰＵ１０で実行可能なオブジェクトコードと、プログラム作成支援装置１のＣＰＵ２４で実行可能なオブジェクトを生成するため、ＣＰＵ２４は、第２実行部３１をエミュレーションしなくてもよい。ただし、プログラム作成支援装置１は、一般的なコンピュータであるが故に、ラダープログラム４３を実行するラダー実行エンジン（ＡＳＩＣ等）を備えてはいない。そのため、ＰＬＣ２が備えるラダー実行エンジンをエミュレートする第１エミュレータがプログラム作成支援装置１には必要となる。

図７などを用いて説明したように、ラダーシミュレータ５１とＣ言語シミュレータ５４との間でデータ通信を実行するための共通バスが設けられてもよい。管理部５７は、デバイスの状態を受け渡すためのコマンドを、共通バスを介してラダーシミュレータ５１とＣ言語シミュレータ５４とに発行する。これにより、ラダーシミュレータ５１とＣ言語シミュレータ５４は相互にデータを交換できるようになる。

管理部５７は、ラダーシミュレータ５１とＣ言語シミュレータ５４との間でデータを共有するための共有メモリをさらに有していてもよい。管理部５７は、この共有メモリを介してデバイスの状態を受け渡してもよい。このように共通バスの代わりに共有メモリが採用されてもよい。

管理部５７は、ラダーシミュレータ５１の実行結果をＣ言語シミュレータ５４に受け渡してもよい。たとえば、ラダープログラム４３を実行することで得られるデバイス値をＣ言語プログラム４４に渡して、Ｃ言語プログラム４４がそれを用いて演算を行ってもよい。

管理部５７は、Ｃ言語シミュレータ５４の実行結果をラダーシミュレータ５１に受け渡してもよい。たとえば、Ｃ言語プログラム４４はラダープログラム４３と比較してテキスト処理や通信処理に向いているが、Ｃ言語プログラム４４で得られたテキストデータをラダープログラム４３に渡してもよい。上述したようにＣ言語プログラム４４にデバイスを操作するＡＰＩを用いた命令を記述しておくことで、Ｃ言語シミュレータ５４におけるＣ言語プログラム４４の実行結果（例：テキストデータや受信データなど）をラダープログラム４３に渡すことが可能となる。

図１２を用いて説明したように、Ｃ言語プログラム４４のソースコードをＰＬＣ２が備えるＣＰＵ１０用のネイティブコードに変換するＰＬＣ用コンバータ６２が設けられてもよい。この場合、Ｃ言語シミュレータ５４はＣＰＵ１０をエミュレーションするエミュレータを有し、当該エミュレータはＣＰＵ１０用のネイティブコードを実行する。また、プロジェクト転送部６３は、シミュレーションに使用したネイティブコードをプロジェクト４１に転送する。このように、エミュレータが存在する場合は、シミュレータ用コンバータ６１を省略できる利点がある。

図１２を用いて説明したように、Ｃ言語プログラム４４のソースコードをプログラム作成支援装置１が備えるＣＰＵ２４で直接実行可能なネイティブコードに変換するシミュレータ用コンバータ６１が設けられてもよい。この場合、Ｃ言語シミュレータ５４は、Ｃ言語プログラム４４のネイティブコードを実行する。これにより、エミュレータを省略できるとともに、Ｃ言語プログラム４４をより高速に実行できるようになる。

Ｃ言語シミュレータ５４は、ラダーシミュレータ５１がラダープログラム４３のエンド処理を実行している間に、Ｃ言語プログラム４４の実行をシミュレーションしてもよい。

管理部５７は、ラダーシミュレータ５１からＣ言語シミュレータ５４に引数をコピーしてもよい。これによりラダーシミュレータ５１上のラダープログラム４３とＣ言語シミュレータ５４上のＣ言語プログラム４４とが引数を通じて相互に連携動作することが可能となる。

管理部５７は、ラダーシミュレータ５１において実行されているラダープログラム４３にしたがってＣ言語シミュレータ５４においてＣ言語プログラム４４を起動してもよい。たとえば、ラダープログラム４３が起動呼び出し用のデバイスに起動を意味する値を書き込む。管理部５７は、Ｃ言語シミュレータ５４から当該デバイスの参照要求があると、起動を意味する値をＣ言語シミュレータ５４に渡す。Ｃ言語シミュレータ５４は、デバイス値が起動を意味する値になっていることを認識すると、Ｃ言語プログラム４４を起動する。

管理部５７は、Ｃ言語シミュレータ５４においてＣ言語プログラム４４の実行が完了したことを示す完了通知をラダーシミュレータ５１に伝達してもよい。たとえば、完了通知を保持するデバイス（完了通知デバイス）がデバイス記憶部５３に確保されていてもよい。管理部５７は、Ｃ言語シミュレータ５４から完了通知を受信すると（完了通知を示すＣ言語シンボルに完了を示す値が格納されると）、完了通知デバイスに完了を意味するデバイス値を書き込む。これにより、Ｃ言語シミュレータ５４においてＣ言語プログラム４４は呼び出したＣ言語プログラム４４が完了したことを認識できるようになろう。

Claims (14)

1. プログラマブル・ロジック・コントローラで実行されるユーザプログラムを作成するプログラム作成支援装置であって、
   グラフィカルプログラミング言語で記述されたユーザプログラムである第１プログラムの実行をシミュレーションする第１シミュレーション部と
   高級プログラミング言語で記述されたユーザプログラムである第２プログラムを実行する第２シミュレーション部と、
   前記第１プログラムにより設定されるデバイスの状態を記憶するデバイス記憶部と、
   前記第１シミュレーション部と前記第２シミュレーション部を管理する管理部と
   を有し、
   前記管理部は、前記第１シミュレーション部と前記第２シミュレーション部との間で前記デバイスの状態を受け渡すことを特徴とするプログラム作成支援装置。
2. 前記プログラマブル・ロジック・コントローラが備える前記第１プログラムの実行部をエミュレーションする第１エミュレータを有し、
   前記第１シミュレーション部は、前記第１エミュレータを介して前記第１プログラムに記述された命令語を解釈してシミュレーションを行う一方で、
   前記第２シミュレーション部は、前記第１エミュレータを介さずに前記第２プログラムに記述された命令語を解釈してシミュレーションを行うことを特徴とする請求項１に記載のプログラム作成支援装置。
3. 前記第１シミュレーション部と前記第２シミュレーション部との間でデータ通信を実行するための共通バスをさらに有し、
   前記管理部は、前記デバイスの状態を受け渡すためのコマンドを前記共通バスを介して前記第１シミュレーション部と前記第２シミュレーション部とに発行することを特徴とする請求項１または２に記載のプログラム作成支援装置。
4. 前記第１シミュレーション部と前記第２シミュレーション部との間でデータを共有するための共有メモリをさらに有し、
   前記管理部は、前記共有メモリを介して前記デバイスの状態を受け渡すことを特徴とする請求項１または２に記載のプログラム作成支援装置。
5. 前記管理部は、前記第１シミュレーション部の実行結果を前記第２シミュレーション部に受け渡すことを特徴とする請求項１ないし４のいずれか１項に記載のプログラム作成支援装置。
6. 前記管理部は、前記第２シミュレーション部の実行結果を前記第１シミュレーション部に受け渡すことを特徴とする請求項１ないし５のいずれか１項に記載のプログラム作成支援装置。
7. 前記第２プログラムのソースコードを前記プログラマブル・ロジック・コントローラが備えるＣＰＵ用のネイティブコードに変換するコンバータをさらに有し、
   前記第２シミュレーション部は、前記プログラマブル・ロジック・コントローラが備える前記ＣＰＵをエミュレーションする第２エミュレータを有し、前記第２エミュレータは、前記ＣＰＵ用のネイティブコードを実行することを特徴とする請求項１ないし６のいずれか１項に記載のプログラム作成支援装置。
8. 前記第２プログラムのソースコードを前記プログラム作成支援装置が備えるＣＰＵで直接実行可能なネイティブコードに変換するコンバータをさらに有し、
   前記第２シミュレーション部は、前記第２プログラムの前記ネイティブコードを実行することを特徴とする請求項１ないし６のいずれか１項に記載のプログラム作成支援装置。
9. 前記第２シミュレーション部は、前記第１シミュレーション部が前記第１プログラムのエンド処理を実行している間に、前記第２プログラムを実行することを特徴とする請求項１ないし８のいずれか１項に記載のプログラム作成支援装置。
10. 前記管理部は、前記第１シミュレーション部から前記第２シミュレーション部に引数をコピーすることを特徴とする請求項１ないし９のいずれか１項に記載のプログラム作成支援装置。
11. 前記管理部は、前記第１シミュレーション部において実行されている前記第１プログラムにしたがって前記第２シミュレーション部において前記第２プログラムを起動することを特徴とする請求項１ないし１０のいずれか１項に記載のプログラム作成支援装置。
12. 前記管理部は、前記第２シミュレーション部において前記第２プログラムの実行が完了したことを示す完了通知を前記第１シミュレーション部に伝達することを特徴とする請求項１ないし１１のいずれか１項に記載のプログラム作成支援装置。
13. プログラマブル・ロジック・コントローラで実行されるユーザプログラムを作成するプログラム作成支援装置の制御方法であって、
    グラフィカルプログラミング言語で記述されたユーザプログラムである第１プログラムの実行のシミュレーションと、高級プログラミング言語で記述されたユーザプログラムである第２プログラムの実行とを開始するステップと、
    前記第１プログラムにより設定されるデバイスの状態を、前記第１プログラムの実行のシミュレーションと前記第２プログラムの実行との間で受け渡すことで、前記第１プログラムの実行のシミュレーションと前記第２プログラムの実行とを連携させるステップと
    を有することを特徴とするプログラム作成支援装置の制御方法。
14. プログラマブル・ロジック・コントローラで実行されるユーザプログラムを作成するプログラム作成支援装置において実行されるプログラムであって、
    前記プログラム作成支援装置に、
    グラフィカルプログラミング言語で記述されたユーザプログラムである第１プログラムの実行のシミュレーションと、高級プログラミング言語で記述されたユーザプログラムである第２プログラムの実行とを開始するステップと、
    前記第１プログラムにより設定されるデバイスの状態を、前記第１プログラムの実行のシミュレーションと前記第２プログラムの実行との間で受け渡すことで、前記第１プログラムの実行のシミュレーションと前記第２プログラムの実行とを連携させるステップと
    を実行させることを特徴とするプログラム。