９．システム・コントロールソフト：フリーソフト
ハードウエアと同様に星図等との連携のためにシステムコントロールソフトが必要ですが、現時点ではソフトを作成することは可能であってもあまり良い方法とは思えません。
というのも、自らシステムを設計し製作するには第一に時間が掛かりすぎることと、さらに制御仕様はいずれ標準的なものを選択し、その仕様に互換なソフトを作らなければあまり利用者メリットが無いなどの理由のためです。
最近ではフリーソフトといわれる星図ソフトの中には非常に出来の良いものがあり、制御仕様そのものも公開されており、ファームウエアが作成しやすく使いやすいという観点から、有用で完成度のあるものを選択してシステムコントロールアプリとする方がよいと考えることができます。
このため、ＥＪＡＮ赤道儀制御システムに搭載するファームウエアは、リンクするシステムコントロールソフトの仕様に合わせて新規に書き起こして搭載することになります。とりあえずコマンド仕様が公開されていれば作成も可能となり、ユーザとしてもシステムを受け入れやすく使用しやすいと考えます。
ＥＪＡＮ赤道儀制御システムのシステムコントロールアプリとして採用することにしたフリーソフトは Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ と Ｙｏｃ の両ソフトウエアです。
また、市販のソフトしてはＥ－Ｚｅｕｓの開発にも参加された谷藤賢一氏のＳｕｐｅｒＳｔａｒやアストロアーツ社のステラナビゲータも選択肢として挙げておきます。
以下に各ソフトの特徴及びそれぞれのシステムコントロールアプリの仕様に合わせたＥＪＡＮ赤道儀制御システムの開発秘話のような事柄も記述しておこうと思います。
９．１ Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ（ＳｋｙＣｈａｒｔ）
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ（ＳｋｙＣｈａｒｔ）はフリーソフトとして開発が行われている星図ソフトですが、それと同時に望遠鏡のコントロールや天体を自動導入する機能などを持っている総合的なシステムになっています。
開発は Lazarus/FreePascalの環境において行われており、実行オブジェクトだけでなくソースファイルも公開されているのが特徴です。
また、各国の言語に対応できるようなシステム構成になっており、作成されたオブジェクトの実行時のプログラム文字表示を所定の定義ファイルを修正することにより変更できます。日本語表記も当然できるのですが、現執筆時点（２０１３／０４）では、概ね日本語表示化は完了しているのでなかなか使い勝手がよいものになっていると思います。
更に、星図データはネット上からフリーで手に入るので、市販の星図ソフトに負けない非常に優れたソフトウエアであるとも感じます。
このソフトは現在も日々進化して新しいバージョンがリリースされたり、バクフィックスされたりしているので少しずつですが機能も高度になり、画面や使い勝手もバージョンが上がるたびに良くなっています。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ（ＳｋｙＣｈａｒｔ）Ｖ．３．４には、以下の望遠鏡の制御インターフェースが提供されています。
◆ＩＮＤＩドライバ ◆ＡＳＣＯＭ ◆ＬＸ２００ ◆手動装置
ＥＪＡＮ赤道儀制御システムは、このうちＬＸ２００コマンドをサポートするシステムとして設計されました。内情を話せばＥＪＡＮ赤道儀制御システムを作成しようと思い立ったそもそもの要因は、自らのミードＬＸ２００－２５システムが故障したことに端を発して、この赤道儀の修理が出来ないことによって必然的にコントロールシステムを作成しなれければならないことになったためです。
幸い、ＬＸ２００コントロールコマンドはある意味、天体の自動導入におけるスタンダードシステムになっておりコマンド仕様が公開され、フリーソフトのＣａｒｔｅｓ ｄｕ Ｃｉｅｌ においてもかなり前からＬＸ２００コマンドによる自動導入がサポートされています。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌを選定した主な理由は、以下の条件を満足させることによります。
ａ．第一にフリーソフトで、開発が今も進展していること、
そして、オープンソースなシステムなこと・・
現在もユーザの要望により少しずつ機能強化され、星図関連に関しては日々のバグフィクスと機能拡張が少しずつ進んでいるようです。
ただし、望遠鏡の制御機能に関してはｖｅｒ．２から見ていますがあまり進展していないようです。
開発パッケージのバージョン２では望遠鏡のコントロールライブラリが外部ソースとしてリンクされており、バージョン３ではメインプロジェクトに組み入れられていましたが、ソースそのものは全く同じものが入っていましました。
このシステムの純正バージョンはＥ－ＺＥＵＳコマンドをサポートしていません。
そのため、私が提供するＳｋｙＣｈａｒｔ Ｖ３．４は、新規にプログラムを書き起こしてＥ－ＺＥＵＳシステムでも天体の自動導入（ＧＯＴＯ）ができるように機能拡張しました。このようなことができることの意味合いがフリーソフトウエアの強みとも言えます。同時に、ＬＸ２００システムでのバグを修正しています。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ（ＳｋｙＣｈａｒｔ）Ｖ３．４には、様々に望遠鏡の制御インターフェースが提供されており、以下のようなものがサポートされています。
◆ＩＮＤＩドライバ ◆ＡＳＣＯＭ ◆ＬＸ２００ ◆Ｅ－ＺＥＵＳ ◆手動装置
ｂ．ＬＸ２００コマンドがサポートされた自動導入システム機能を持つこと
ミードのＬＸ２００システムは早くから天体の自動導入と自動追尾機能を持っており、かつ、制御コマンドが公開されたことから天体の導入システムの制御コマンドとしてアマチュアの間でもかなり使われていたようです。
このためにＬＸ２００望遠鏡の制御コマンドは天体の自動導入システムの事実上スタンダードコマンド仕様と言っても良いと思います。
ｃ．日本語表記ができること（既にほぼ日本語化は完了された）
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌシステムの良さは、タイトル表記の言語体系とロジック処理とを論理的に分離させ多国化言語に対応していることです。
更に日本語表記を行わせるためにはタイトルとヘルプに関連するタグの入ったテキストファイルの内容を日本語に翻訳するだけで良いのです。
多くに国の言語でプログラム表記ができるのは非常に良いことで、ユーザが自国の言語表記でシステムを操作できることはシステムが普及するためにも必要なことと思われます。
ｄ．使用ユーザが多いこと（日本だけではなく世界的に見ても）
システム開発者はヨーロッパ及び英語圏の人々を対象に作りはじめたようです。
しかし、このソフトウエアはシステム表記やヘルプの内容を多言語化して表示できるように設計されているので、これらを英文から自国語への翻訳データを用意するだけで表記が自国語に自動変換されます。
ｅ．星図その他のシステム環境が豊富なこと
星図データは全てフリーのものが使えるので、環境の構築も容易で費用が掛かりません。
このような条件に合致するソフトが存在するのことで、私と同じような境遇のユーザのためにも使いやすく、比較的安い予算で自動導入システムが作成できるのではないかと思い、初めにこのシステムと対になるＥＪＡＮ赤道儀制御システムの開発を決意したわけです。
このソフトが最もよい点はオープンソースであることです。これは、システム開発を行っているものにしか分からないことかもしれないけれど、往々にしてハードが絡むシステム開発というものにはアプリケーションとファーム（ハード側のＲＯＭ化される制御ソフト）との間の通信に関わる不具合に悩まされることが多いのです。その様なときには相手側のソースが身近にあるということの意味合いは、オープン化された仕様書よりも更に有用なものとなることが多いものです。
９．２ Ｙｏｃ-Yoshida Observatory Control System
Ｙｏｃは、瀬戸口 貴司さん（注 ０）が開発したＥ－ＺＥＵＳ対応の天体の星図表示及び天体の自動導入システムです。
このアプリケーションを システム・コントロールソフトとして上位アプリに採用するきっかけは、Ｅ－ＺＥＵＳの記事そのものを以前から知っていたことによりますが、何よりも国内で開発されたソフトなので利用者も多いのではないかと思ったからなのです。
また、Ｅ－Ｚｅｕｓ対応のアブケーションでは、フリーではないけれど優秀なシステムとして、ＳｕｐｅｒＳｔａｒ IV があります。このソフトウエアは様々なコマンドに対応しており、当然ながらＥ－ＺＥＵＳもその中のひとつとしてサポートされています。（注 １）
Ｅ－Ｚｅｕｓの開発は当初 月刊 天文ガイド誌の工作記事として星の自動導入と追尾ができる赤道儀で稼働するシステムとして企画され、Ｅ－Ｚｅｕｓ開発プロジェクトが発足したようです。プロジェクトは以下の主要メンバーで進められたということです。
◆プロジェクトリーダー ： 高槻幸弘氏
◆モータドライバ設計 ： 外山保広氏
◆ソフトウエア開発 ： 谷藤賢一氏(ＳｕｐｅｒＳｔａｒ IV)
： 瀬戸口貴司氏(ＹＯＣ)
◆コントローラ設計 ： 早水勉
日本のアマチュア天文家が、天文の普及と天文界の発展を第一の目的として作成したシステムであるとプロジェクトのホームページで謳われています。
このため、ハード設計及びソフトウエアの仕様が全て公開されていることは本当に有り難いことです。
プロジェクトのホームページによれば、システムの設計は以下を重点に設計されているということです。 （詳細な仕様はＨＰにて参照 http://www2.synapse.ne.jp/haya/zeus/zeus_tech.html ）
＜Ｅ－ＺＥＵＳの設計方針＞
◆駆動はステッピングモータを用いる
・現状のステッピングモータバイポーラ型のものを使用しており、コントローラとステッピングモータドライバが別ボードで設計されているので、さまざまなコントローラが使用可能です。
当然のことながら、５相のステッピングモータの使用も可能なのですが、おそらくこの
ハード仕様を満たすドライバが存在しないので採用はできませんが、稼働そのものには問題がないと思われます。
◆制御はパソコンを使用する
望遠鏡の主要な操作をパソコン側のプログラム側で行うので、モータのドライバ側で行う処理は少なくなりますが、パソコン側のソフトウエアの処理が増すことと、処理の方法や機能も若干
異なることになります。
Ｅ－Ｚｅｕｓは主にパソコン側と赤道儀のモータ制御について規定した規格なので、ソフトウエア側の機能は開発者の設計し思想で異なることになるわけです。
・恒星時の計算や星の位置、座標等の情報処理は全てパソコン側のソフトウエアが処理を実行します。
・天体の導入や赤道儀の回転に関わるステッピングモータ制御データはモータのパルスカウントとして計算し、指示コマンドを送付することで行います。
◆パソコンが無い場合、マニュアル操作もできる
・ハンドボックスを接続することで、回転速度の調整や方向なとの制御ができます。
◆星の座標はステッピングモータのパルス数に置き換えてパソコン側が指定する
・ステッピングモータの回転数と方向はパソコン側のソフトウエアのコマンド指示で行います。
・パソコン側のソフトウエアは、コントローラからのステッピングモータの回転位置で画面更新を行います。つまり、 ステッピングモータの回転数で角度制御と座標変換を行っているわけです
Ｙｏｃは私がＬＸ２００コマンド対応のＥＪＡＮ赤道儀制御システムを作成した後、システムのチューニングを行うことを考えているときに存在を知ったソフトです。
ＬＸ２００とＣａｒｔｅｓ ｄｕ Ｃｉｅｌ は世界的にはポピュラーな存在であっても、必ずしも日本ではスタンダードとはいえないかもしれません。むしろＥ－Ｚｅｕｓを使う人の方が多い様な気がします。これはＬＸ２００やそのコマンドが使われていないというわけではなく、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌそのものを制御用に使う天文愛好家が少ないのではないかと思うのです。
というのも、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌでコントロールするための安くて良い制御システムが少ないのではないかと考えるのです。Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌというのは望遠鏡を制御するというよりも星の座標をコントローラに対して指定をするプログラムの意味合いが強いので、コントローラ側の処理が多いのです。市販のＦＳ２というコントローラなどの多くは回転と停止のコマンドのみを利用して動作していますから、制御方法はＥ－Ｚｅｕｓの考えと共通したところがあります。
Ｅ－Ｚｅｕｓ版の開発ではＬＸ２００システムが稼働したことから、モータ駆動部分は大方流用が可能と考えて、主に通信処理部分を設計すればシステムは稼働する状況にありました。
というわけでＥ－Ｚｅｕｓ版の開発を始めたのですが、モータコントロールのチューニング（加減速性能と一般化）を行うことを前提にシステム設計しようとしたために、実際には全ての設計を見直すことになってしまいました。
いずれにしても、甘い憶測とは裏腹にモータコントロールのチューニングを行うことは、結局のところはソースの再設計につながり、Ｅ－ＺＥＵＳシステムはフルスクラッチと同じことになってしまった訳ですが、その反面システム設計としてはより引き締まった良い設計になったのではないかと考えます。
ＥＪＡＮ赤道儀制御システム：Ｅ－ＺＥＵＳ対応版は上記仕様に沿ってＹｏｃシステムとの間で通信を行い、天体の自動導入をサポートするものです。しかしながら、ＥＪＡＮ赤道儀制御システムのハードはＥ－ＺＥＵＳプロジェクト本来のものとは全く異なるのでシステム構成や機能そのものも若干異なることを予め明記しておきます。
また、純正（プロジェクトで設計された）ハードは私の個人的な主観なのですが、やや高度なハードにしすぎたような気がします。
コントロール部分の大方を上位アプリが行ってしまうＥ－ＺＥＵＳシステムでは、赤道儀側のファームが行うことは主にマニュアルコントローラ（ハンドボックスと呼んでいる）の制御とステッピングモータのパルス制御とカウンタ制御くらいなので、通常８ビットのマイクロコントローラ一つでも十分に制御できる位のボリュームであると思われます。
ただし、モータ制御に関しては加減速処理が大型赤道儀では特に重要になってくるので処理が重たくなるので、純正ハード処理ではこの点を重視した設計をしたのでしょう。（注２）
ＥＪＡＮ赤道儀制御システム：Ｅ－ＺＥＵＳ対応版は、あくまでもＥ－ＺＥＵＳ仕様の通信により天体が自動導入できるシステムですが、同一のハードを提供しようとするものではないということをご理解いただきたいと思います。
従って、現状ではマニュアルコントローラは提供されていないし、モータの加減速処理も十分とは言い難いということも明記しておきます。（注 ３）
ＥＪＡＮ赤道儀制御システム：Ｅ－ＺＥＵＳ対応版では、システムメンテナンスを容易にするためと様々なハード環境に対応するために、Ｅ－ＺＥＵＳ仕様にない追加コマンドもサポートしています。
これらのコマンドは、システムのチューニングやメンテナンス用にサポートしているものなので、公式なものではないのですが、ＥＪＡＮ赤道儀制御システムではＬＸ２００版も含め共通のコマンド仕様にし、メンテナンスしやすくしています。
これらのコマンドについては、章を別に設けて詳細を記すことにします。
概要のみ記すと以下のようなコマンドがあります。
表 ＥＪＡＮ赤道儀制御システム の追加コマンド
<No> < 追加コマンド > < 機能 >
１ LCD ON/OFF ＬＣＤの表示とＯＮ／ＯＦＦ制御を行う
２ ギア比設定 ハード的なギア比を設定する
３ ステップパルス設定 ステップパルス書き込み設定/読み出し設定
４ 回転スピードの変更 高速、中速、低速のスピードの増加・減少
５ システム制御データ設定 システム制御データをＥＥＰＲＯＭに設定
（注 ０）瀬戸口 貴司様は、２０１５年１月にお亡くなりになられました。
同時に、ＹＯＣのホームページもクローズされてしまいました。そのため、残念ですがＹＯＣをホームページから入手することができくなってしまいました。
（注 １）このシステム作成するにあたって Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ と同様のコマンドシーケンスにおけるトラブル（後述：これは私の理解不足も原因）が発生したとき、瀬戸口様には仕様等について多くのご指導を頂きました。
お忙しい中、当方のしつこい程の質問メイルに対して、毎回丁寧に快くご返事いただいて、本当に有り難く心強い手助けを頂いて、本当に人柄のよい方なのだと感心すると同時に嬉しくも感じた次第です。
ＳｕｐｅｒＳｔａｒ IV を作成された谷藤賢一さんにもシステムテスト用にプログラムの提供をして頂きましました。
（注 ２）私はＥ－ＺＥＵＳシステムを使用したことがないので、利用中やシステムの販売 をしている業者様のホームページの内容からしかＥ－ＺＥＵＳのハードに関する情報を得られないので、実際のところＥ－ＺＥＵＳの加減速処理に関しては正しい評価ができないことを明記しておきます。
また、モータの加減速処理は８ビットマイクロコントローラにはやや重たい作業であることは、実際に作ってみて実感しているので特記させて頂きました。
ただし、ネット上でのＥ－ＺＥＵＳと ＳｕｐｅｒＳｔａｒとで動作するビデオ映像をみたがやはりスムースな動作であることは間違いありません。
（注 ３）本文執筆時点では加減速処理は出来ていなませんでしたが、2012/11/10以降では加減速処理はサポートされています。
ただし、ＥＪＡＮ赤道儀制御システムの加減速処理は、Ｅ－ＺＥＵＳシステムのようにハードウエアで行う到着予告（Pre-Arrive）パルスの考えではなく、ソフトウエアによるモータ回転の加・減速度の制御という考えで行っています。
ステッピングモータの加減速処理は詰まる所、ステップ割り込みの時間変化で行うのが正しいのでしょうが、ＡＴｍｅｇａ３２８には１６ビット割り込みが１つしかないのでそのようなことはできません。そのため、割り込みチックの遅延処理という固有の考え方で行っております。
ＥＪＡＮ赤道儀制御システムでは、総ステップ数とモータ回転の加・減速度の値により、モータを加・減速するステップ数が変化します。
ただし、現状ではハードによる加減速度の可変処理は行わないことにし、ソフトウエア拡張コマンドにて対応ということにします。
９．３ Ｓｕｐｅｒ Ｓｔａｒ Ⅳ、Ⅴ
Ｓｕｐｅｒ ＳｔａｒⅣ（注 ）はＥ－ＺＥＵＳのソフト開発に携わった谷藤賢一氏によって作成された星図ソフトです。したがって、Ｅ－ＺＥＵＳとは非常に連携性の良いもので使用実績も多いようです。
Ｓｕｐｅｒ ＳｔａｒⅣは、一般ユーザ向け機能として日付時間に沿ったその地方の星野を表示するプラネタリウムソフトと天文の愛好家向けに赤道儀を用いた天体の自動導入機能とが合わさったシステムです。Ｓｕｐｅｒ ＳｔａｒⅣは画面の形態も操作法もＹＯＣとは異なりますが、機能という点ではほぼ同じです。ただ、こちらはフリーソフトから出発して製作されていましたが、現在では製品として（１２０００円）として販売されている点が異なります。
現バージョンは天文愛好家向けとして、様々な天体の自動導入機能と追尾機能がサポートされています。特に、自動導入に関するサポートシステムが非常に多く、現在国内で稼働している自動導入システムのほぼ全てのコマンドがサポートされているといっても良いでしょう。
下表はＳｕｐｅｒ ＳｔａｒⅣで接続できる望遠鏡として一覧表示されるものですが、これらは望遠鏡の種別を示したものなので制御コマンドの種別ではないことに注意が必要です。
表 Ｓｕｐｅｒ ＳｔａｒⅣ、Ⅴで接続可能な望遠鏡の一覧
<動作可能な望遠鏡> <動作可能な望遠鏡>
手動ナビゲーションＩＺＡＮＡＩ ＳＨＯＷＡ ＡＴＲＡＳ－Ｗａｒｐ
ＳＫＹ ＳＥＮＳＯＲ ２０００ＰＣ ＰＥＮＴＡＸ
ＴＥＭＭＡ－ＰＣ，ＪＲ，Ⅱ Ｓｋｙ Ｅｘｐｌｏｒｅｒ
ＮｅｘＳｔａｒ Ｓｋｙ Ｅｘｐｌｏｒｅｒ ＥＱ６Ｐｒｏ
ＮｅｘＳｔａｒ ｉ Ｓｋｙ Ｅｘｐｌｏｒｅｒ Ⅱ
ＮｅｘＳｔａｒ ＧＰＳ Ｅ－ＺＥＵＳ（Ｆｏｒｋ Ｖｅｒ．２．００）
ＮｅｘＳｔａｒ ＧＴ，ＧＴＲ Ｅ－ＺＥＵＳ（Ｆｏｒｋ Ｖｅｒ．２．２１）
ＣＥＬＥＳＴＲＯＮ ＣＧＥ Ｅ－ＺＥＵＳ Ｖｅｒ．２．００
Ａｄｖａｎｃｅｄ ＧＴ Ｅ－ＺＥＵＳ Ｖｅｒ．２．２１
ＣＥＬＥＳＴＲＯＮ（Sky Align System) ＡＧＳ Ｖｅｒ．２．２１
ＣＥＬＥＳＴＲＯＮ（Sky Align System) ＩＺＡＮＡＭＩ ｆｏｒ ＴＥＭＭＡ－ＰＣ，ＪｒⅡ
Ｍｅａｄｅ ＬＸ－２００ ＳＴＡＲ ＢＯＯＫ Ｖｅｒ．１．０１
Ｍｅａｄｅ Ａｕｔｏｓｔａｒ
Ｍｅａｄｅ Ａｕｔｏｓｔａｒ Ⅱ
蛇足ですが、ＥＪＡＮ赤道儀制御システムはこの表において、ＭｅａｄｅとＥ－ＺＥＵＳの機種を選択すれば良いことになります。これは、ＥＪＡＮ赤道儀制御システムが両機種の全コマンド処理をサポートしているからです。現時点でのＥＪＡＮ赤道儀制御システムは、両コマンド体系毎に別々のコントローラ機種として製作されています。これは、開発システムのメインボードのシステムメモリの制約によるものですから、この問題さえ解決すれば全てのコマンド体系をサポートできるわけです。
（注）２０１５年９月現在、Ｓｕｐｅｒ ＳｔａｒはＶｅｒ．Ⅴにバージョンアップしました。
９．４ ステラナビゲータ １０
ステラナビゲータは（株）アストロアーツ社が販売している星図／望遠鏡制御ソフトです。このソフトは現在市販され使用されている一般的な天文機器の大方の機種に対応しています。Ｅｊａｎ赤道儀制御システムのコマンドはＥ－ＺｅｕｓとＬＸ２００の二種ですが、ステラナビゲータはＥ－Ｚｅｕｓコマンドには対応していませんからＬＸ２００コマンドシステムについて動作確認テストを行ってみました。
ステラナビゲータとＥｊａｎ赤道儀制御システムとの通信開始処理が正常に行なえるか否かのテストを行います。ステラナビゲータの観測（Ｂ）を押下して、メニューを表示してた後、望遠鏡コントロール（Ｔ）を選択すれば以下の画面が表示されます。
ここでコントローラが接続されていれば、ＣＯＭポートが表示され、通信が可能なことが知らされます。メーカー（Ｖ）と望遠鏡（Ｔ）の種別を選択してから、接続（Ｎ）ボタンを選択するとコントローラとのＬＸ２００コマンド接続処理が開始されます。接続処理で何らかの不具合が発生した時はエラーを表すポップアップ画面が表示されます。また、ＬＸ２００コマンド以外のコマンド体系の望遠鏡では当然のことながら接続はできませんから設座く不良の表示が出ます。正常な接続が開始されれば、星図の中の天体を指定し、同期、導入等の望遠鏡コントロール処理を行うことができます。コントローラとの接続テストの結果は、表 と表 に一覧表示されています。
蛇足ながら、ステラナビゲータはソフトの星図表示とコントローラ側の処理とのタイムラグを解消するために、ＬＸ２００コマンドの望遠鏡座標取得コマンド（：ＧＲ＃，：ＧＤ＃）を０．２秒ごとに送信しています。このため、コマンドの受信とレスポンス処理の時間がかかり、コントローラのリソースに負荷がかかります。このときの、通信ボーレートは９６００ｂｐｓですから、通信そのものにかかる時間が大きなウエイトを持つことになり、コントローラ側からすれば時間の無駄遣いということになります。通信ボーレートの設定はＬＸ２００コマンドにもある訳ですからできれば可変にしたいのですが、この点は現時点では架台としておきます。
１０．ＥＪＡＮ赤道儀制御システム開発秘話
－苦しみの跡
以下に、ＥＪＡＮ赤道儀制御システムの開発において発生した様々な不具合の内の主要な事柄について、ＹＯＣ Ｅ－Ｚｅｕｓ対応版 及び Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ ＬＸ２００対応版に分けて、それぞれの内容と対処法の内容を記述しておくことにします。
１０．１ Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ（ＳｋｙＣｈａｒｔ）対応版－苦しみの跡
第一にＣａｒｔｅｓ ｄｕ Ｃｉｅｌ ＬＸ２００対応版において、コマンド通信による問題点とハードリセットに関して発生した問題について記述します。
１０．１．１ Ａｒｄｕｉｎｏにおけるハード的な問題点
ファームウエアの開発ではハード的（ＵＳＢやＲＳ２３２Ｃの様）な通信タイミング処理も当然発生するが、それよりもむしろ通信仕様から発生するソフト的なコマンド処理のタイミングやコマンドシーケンスに関するものの方がより深刻でした。
というのも、Ａｒｄｕｉｎｏのように良く使われたハードというものは既にハード的な不具合が解消されているか又は明確に分かっているいるからです。Ａｒｄｕｉｎｏについては、データの入出力に関する部分はマイクロコントローラ自身が単独でも利用できる状態に設計されているので、あまり大きな問題は生じないように思います。
それでも、Ａｒｄｕｉｎｏには組み込みシステムでは致命的ともいえるリセット動作に関するハード的な問題点が存在することも事実なのです。これは、Ａｒｄｕｉｎｏの利点でもあり欠点でもあるともいえるハード仕様の一部です。
それは、リセットに入ったときの１～２秒程の間、一切の通信処理が出来なくなるという一見するとソフトウエアトラブルのように見えるわけですが、実は通信開始時のハード的な遅延に関する問題なのです。
Ａｒｄｕｉｎｏはファームの開発をしやすくするためにＲＯＭの上位部分にダウン（ブート）ローダが配置されており、このローダーはリセット信号が入ったときに初めに実行されるものとなっているのです。
要するにハードによるリセット直後にこのダウンローダは、Ａｒｄｕｉｎｏ開発システムからのダウンロードすべきプログラムの有無を検査し、プログラムがあればダウンロードを開始するというように作られているのです。
さらに言えば、リセット信号は通信制御信号（ DTR信号 ）と連動しており、ソフトウエアが通信を開始しようとするとポートをオープンすると同時にこの信号がＬｏｗになってリセットが入る仕組みなのです。このため、上位側アプリケーションにはＡｒｄｕｉｎｏがブートローダを実行し終わるまでの１～３秒程の通信待ち時間が生じることになるのです。
通常、ハードへの通信開始は上位側アプリケーションからみれば即座にオープン処理が終了し、機器の正常動作を確認するための何らかのコマンド送出を行った後、正しいレスポンスが返ることを確認して初めて通常のコントロール処理が開始となることが前提です。（注 ３ 参照）これは、上位側アプリケーションがコントローラとの間で通信を正常に開始しようするための確認動作ですから、方法は異なっていても正しい接続が開始されたか否かを問うために必要な操作として、特別にハード的な仕組みがないシステムでは必ず行われるものなのです。
そして、この通信処理に対して上位側アプリケーションは必ず何らかの固定的なレスポンス（返答となる文字列や制御コードなど）が所定の時間内に返答されることを要求しているのです。
上位側アプリケーションは、このコマンドレスポンスを所定時間内に正しく受け取った後に、システムが正常な接続を開始したと認めてそれに続く制御コマンドの通信処理を開始します。
ところが、実際のＡｒｄｕｉｎｏでは前述のリセット動作のために上位側アプリケーションはレスポンスを所定時間内に受け取れず、通信エラーが発生したとして把握してしまうのです。
更に問題だったのは、このリセットの問題が解決して開始処理のシーケンスが正常に行われるようになったとしても、その直後のコマンドレスポンス・エラーとなってシステム間の正常な接続が行われなかったことです。
こちらの問題の根本は Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ側の通信開始処理の内容が正式なコマンド仕様とは若干異なっていることにあり、その内容が仕様書だけでは想像が付かない内容（注 ３参照）だったことです。
幸いにも、こうしたときオープンソースのシステムの良さは、このような不具合内容をソースの形で明確に示してくれるので、不具合を見つけるだけでなくその修正をも容易にできるところがよいのです。
同様にして、Ａｒｄｕｉｎｏのようなオープンハードのボードシステムは、前述のようなリセットに関する問題点についても同様なことがいえるのです。
Ａｒｄｕｉｎｏのリセット時の開始遅延に関しても回路図が明示されているので、対処の仕方も検討ができるのです。
前記の遅延に関する対応としては、当初 Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ側が機器接続のコマンドを送出する前に待ち時間（遅延２秒）を入れるいうソースの修正で解決したけれど、この起動時の待ち時間に対してはたとえ２秒間であっても良しとしないという人は多いものです。また、この修正は根本的に問題を解決するものではなく、一種の対処療法的な意味合いが強くあまり進められる方法ではありません。
更にこのアプリの修正は、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌがバージョンアップされる毎にプログラムに修正をかける必要があるという面倒な事態を引き起こすと同時に他のシステムではやはり受け入れられない方法なので、できる限り避けたい修正方法でもあります。
このような場合、ハード側で対処できることであればそれを行った方がメリットは多いものです。
というわけで公開されているＡｒｄｕｉｎｏのハード回路をよくよく検討してみたところ、回路を修正せずに容易に対処できる方法があることが分かったのです。（最近のＡｒｄｕｉｎｏボードではハードにより予め対応処置をしているものもあるのですが、このようなハード修正無しでも簡単に対処が出来る方法があるのです）
一般的に商業ベースのハードは回路図を公表しないクローズドなものです。これは自社のハード開発に対するコストが回路を作成する中に多く含まれているからで、会社の利益確保に対するコスト回収の権利保持という意味で当然の行為と思われます。
逆にオープンソース又はオープンハードと呼ばれるものは、複数の開発者がプロジェクトあるいはフォーラムと呼ばれる開発グループをつくって非営利的に開発を行い成果物を得るものです。
このようなかたちで得られた成果物は共有の理念に則って権利を独占しない又はさせないことが特徴ですから、当然のことながらプロジェクトで得られた成果物に関して特定な商業的権利を認めてはいません。
もちろん商業的な価値としては唯一著作権を保持することと、著作権等に基づいた名称などの使用権は保持する場合が多いのです。
これは、会社のクローズドな成果物の場合とは逆に、オープンで開発された成果物そのものを名称も含めて特定なユーザに独占使用させないＣｏｐｙｌｅｆｔ（コピーレフト）という概念沿っているためでもあります。
Ａｒｄｕｉｎｏの場合も例外ではなく、世の中には互換という名の下に様々なボート完成品やキットボードが発売されていますが、それらのボードには”Ａｒｄｕｉｎｏ”の名称は本家以外のボードでは使用することが許されてはいないのです。
いずれにしても、Ａｒｄｕｉｎｏは正式版であろうと互換品であろうと全く同じ機能であっも良いし、拡張された機能を有するものであってもかまいません。要するに、”Ａｒｄｕｉｎｏ”の名称だけは使えないけれども、ボードそのものを単独販売しても製品に組み込みとして使用したとしても、回路そのものには関しては商業的なロイヤリティの必要がないのが特徴です。
（ 注 ３）事実、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌは、赤緯取得コマンド（Ｄｅｃ'#:GD#'）を出力しておりこのコマンドのレスポンスが正常か否かで機器接続の可否を判断しています。
赤道儀側のファームは前記のようにＡｒｄｕｉｎｏによるタイムラグ（だけでなくデータそのものが破棄される）があるので、このコマンドは受け取れずレスポンスはもちろん返さないことになり接続ができないことになってしまいました。この状況は、ハードをＡｒｄｕｉｎｏにした場合の話なので、通常はこのようなことにはなりません。より詳しくは、たとえハード仕様に問題がなくとも､Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ における機器接続処理では、赤緯取得コマンドを送出しているので通常接続はできません。
この開始処理の仕方は仕様上正しくなく、正式にはＡＣＫを待たなければならないような仕様になっている訳ですが、実際のＬＸ２００機種の中にはＡＣＫを返さないものがあるとのことでこのような操作記述になっているようです。
いずれにせよ、このような修正は既に稼働しているＬＸ２００等の機器に対しては有効であっても、新規に作成されるシステムにおいては不具合となりうるものです。
こういったことに起因する不具合はソース内容を見なければ分からないわけで、コマンド仕様を頼りに作成してるものにとっては致命的な不具合となりうるもののひとつなのです。
しかしながら、仕様上は不具合（バグ）というべきであっても、運用的にはこの修正に合わさなければならないのが、下位のコントローラソフトの宿命という訳なのです。
１０．１．２ Ａｒｄｕｉｎｏの ＤＴＲ信号 によるハードリセットの回避
前述のようにリセット信号はシリアル通信の通信制御信号（ DTR信号 ）と連動しており、ソフトウエアが通信を開始しようとしてシリアルポートをオープンすると同時にこの信号がＬｏｗになるためにリセットが入る仕組みなのです。そのため、Ａｒｄｕｉｎｏがブートローダを実行し終
わるまでの１～３秒程の上位アプリケーションに対する通信待ち時間が生じることになるのです。
ＤＴＲ＃（アクティブ・ロー）端子がアクティブ（Ｌｏｗ）になってから、その状態が一定時間維持され、リセット端子（ＲＥＳＴＥ）の電圧値が閾値電圧を一定時間維持（２．５μｓ）されるとアクティブ（Ｌｏｗ）状態になりシステムがリセットされます。
Ａｒｄｕｉｎｏ環境では、リセット後のファーム開始はブートローダの所定の位置からに決まっています。このブートローダの主な仕事はユーザプログラムを回線を介してロードし、フラッシュメモリに書き込むことです。もしも、書き込むプログラムが転送されてこないのならば、ブートローダは既に書き込まれているユーザプログラムの先頭から実行するようにします。このようなブートローダ処理のおかげで、特定なハードウエアがなくともユーザが作成したプログラムをＡｒｄｕｉｎｏのＭＣＵにダウンロードできるということなのです。
通信制御信号（ DTR信号 ）によりハードリセットが起こり、かつコントーラ側が一定の時間何もできないように見えるのはこのブートローダの処理のためなのです。これは、Ａｒｄｕｉｎｏ環境では有用ですが、上位プログラムとの通信を行うファームウエアでは致命的です。
さて、それではどのようにして回避すればよいのでしょうか。その答えは、非常に簡単です。
＜通信制御信号（ DTR信号 ）によるリセットの回避＞
要はDTR信号がＬｏｗになってもリセット信号がＬｏｗに落ちなければいいのです。
リセット（ＲＥＳＥＴ）端子は、ＩＣＳＰ（In Circuit Serial Programming）端子のピン番号５とＦＴＤＩチップからのＤＴＲ＃端子とＲＴＳ＃端子に繋がっています。ＤＴＲ＃端子とＲＴＳ＃端子は共にアクティブ・ローなので、シリアル回線をオープンしデータを送ろうとするとこれらの端子はアクティブ（Ｌｏｗ）状態になります。その結果、リセット（ＲＥＳＥＴ）端子も同様にローになってハードリセットがかかります。（下図 を参照してください）
Ｓ１スイッチが押下されるか又はＤＴＲ＃（アクティブ・ロー）端子がアクティブ（Ｌｏｗ）になってその状態を一定時間維持されると、リセット端子（ＲＥＳＥＴ）は電圧値がアクティブ（Ｌｏｗ）状態になりになりシステムがリセットされます。
このとき、Ａｒｄｕｉｎｏシステムは新しいファームウエアのローディングを開始しようとしますが、所定の手順がなされない場合は、フラッシュ上のファームウエアの実行を開始します。つまり、この待ち時間の間は、上位パソコン側のアプリケーションは通信が開始できずにいます。通常のアプリケーションはこのとき何らかのコマンドやレスポンスをファームウエアが即座にかえすとして、それらを通信が正常に接続されるものとして待っています。
ファームウエアから期待するレスポンスが返ったときは正常な接続が完了したものとして次の処理に入りますが、一定時間内（又は即座に）正しいレスポンスが返らない時は接続エラーとして定常処理を停止します。
この場合、ＤＴＲ＃端子とＲＴＳ＃端子は共にアクティブになってもリセット（ＲＥＳＥＴ）端子がＨｉｇｈのままならば、シリアル通信は即座にそのまま続けられる訳です。好都合なことに ＩＣＳＰ端子は通常の処理には絶対使わないし、端子２に電源（表では５Ｖ）が入っていますから、この電源を端子５につないで電力供給を行えばよいということになります。
こうすることで、リセット（ＲＥＳＥＴ）端子には常に電源電圧がかかりますし、リセットボタンも問題なく効きます。
ただし、このＩＣＳＰ端子はハンダ付けするのではなく、６ピンソケット（２×３）などでジャンパ回路を形成するようにすれば良いですが、次の様な留意点が必要です。
＜リセットの回避処置のジャンパ使用時の留意点＞
・プログラム開発時はファームウエアのダウンロードのためにジャンパを外す
・プログラム実行時はシリアル通信開始によるリセット回避のためにジャンパを付ける
１０．１．３ コマンド解釈におけるソフト的な問題点
次にコマンド解釈による処理内容や手順に生じた問題点について記述します。
Ｃａｒｔｅｓ ｄｕ ＣｉｅｌのＬＸ２００制御でもミードの複数の機種制御に関する座標の送受信制御の部分でコマンド処理を簡略化している部分（注２）があり、データ変換に不具合が生じました。
Ｃａｒｔｅｓ ｄｕ ＣｉｅｌとＹｏｃとは星の追尾に関わる部分コマンド設計が全く異なります。
Ｙｏｃは星の座標（赤経Ｒａ、赤緯Ｄｅｃ）を赤道儀の基点位置からのステッピングモータのパルス数に換算し、そのパルス数をコントーラ側にコマンド（ＤＶコマンド）で指示した後、コントローラ側で追尾更新された位置をパルスカウントの形態で取得するのです。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌの場合は赤道儀側のコントローラに対して、星の座標（赤経Ｒａ、赤緯Ｄｅｃ）をコマンドテキスト形式で与え、それ以後の星の導入と追尾制御の全てをコントローラに任せているのです。
また、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌは望遠鏡の追尾中の望遠鏡座標を星図表と同期させるために、コントローラに対して座標取得コマンドを送出し、そのレスポンスを取得することによって追尾位置を望遠鏡の座標データとして取得することにより、現位置の座標と地方時にあわせた星図表とともに表示しているということになります。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌでの不具合は、この星の座標（赤経Ｒａ、赤緯Ｄｅｃ）データの送信と受信処理そのものにあります。
ＬＸ２００のコマンド仕様書を見ると分かるのですが、これらの仕様は大変良く錬られたものであり、各コマンドが独立して処理されるような仕様となっています。
それは、一つのコマンドは終端コード（’＃’パウンドマーク）で区切られており、単独ラインで送っても複数ラインを同時に送付してもこの終端コードがあることで問題は生じないのです。
さらに、コマンド仕様の関係上一つのコマンドには、通常はレスポンスデータがあるわけですから、コマンドを正常に処理するためには正常なレスポンスデータの処理ができるようにっていなければなりません。つまり、コマンド送出とレスポンスデータの返りによる一種のハンドシェイクのような処理を行っているのです。
ところが、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌのコマンド処理の望遠鏡の座標の授受の処理において、座標取得のレスポンス（戻り値）が２つのコマンドが同時に返されるような固定フォーマット処理を行うようになっているのです。（注 ４ コマンドの授受 を参照する）
つまり、望遠鏡の座標は星と同じようにテキスト情報で座標（赤経Ｒａ，赤緯Ｄｅｃ）又は方位と高度（Ａｚ， Ａｌｔ）データによって把握されるのですが、これらのデータ取得処理において赤道儀側のコントローラからのレスポンスデータを一つの文字列の様な固定フォーマットで処理をしているのです。のみならず、処理方法が統一されたているのならまだ良いのですが、そうではなくサポートされた時期・機種毎にバラバラなのです。
具体的に話すと、望遠鏡の座標取得（":Gr#",":Gd#"）並びに望遠鏡の方位と高度取得コマンド（":GZ#",":GA#"）の処理についてなのですが、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ ではこれらの処理がＬＸ２００の機種毎に条件分けして書かれています。
その中で、ＬＸ２００の処理に前述のような不具合があるのですが、ＥＪＡＮ赤道儀制御システムは、全ての機種についてサポートするつもりであるのでこれは容認できないことになるのです。
具体的には、望遠鏡の赤経（":GR#"）と赤緯（":GD#"）座標取得コマンドが１つのコマンド文字列（"#:GR#:GD#"）のコマンドとして出力され、同様に望遠鏡の方位（":GZ#"）と高度（":GA#"）取得コマンドが１つのコマンド文字列（"#:GZ#:GA#"）として送出されるのです。
このこと自体はコマンド処理そのものが最終的にはＥＪＡＮ赤道儀制御システム側の処理として、仕様の範疇ですから何ら問題は生じないのですが、これらの２コマンドのレスポンスデータまで同一文字列のレスポンスとして”固定長”の処理を要求しているのには困惑しました。
レスポンスはあくまで個別に処理されなければならないのが仕様なのですから、レスポンスを２コマンド分同時に返すような固定長として処理することは一種の手抜きともいえるコーディングなのです。事実、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ の処理において、他機種の処理ではこのようなコーディングをしていないことからもやはり手抜きということなのかもしれません。
というわけで、最も簡単でシステムの処理に影響を与えない様にソース修正を加えなくては成りません。
不具合の要因は、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ側がコマンドレスポンスをきっちりと処理しておらず、２つのコマンドレスポンスを一つのコマンドレスポンスのように同時処理しようとすることにあるので、要するにレスポンスの取得が一回足りない訳ですから、その分のデータを取得して既存のデータに付加してやればよいことになります。
Ｃａｒｔｅｓ ｄｕ ＣｉｅｌのＬＸ２００コマンド処理はこのような要因で接続不可になるケースが多いと報告されているらしいのですが、これは当然帰結でつまりバグなのです。
いずれにしても、これらを作成した人々は望遠鏡制御については素人でしょうから仕方がないといわざるを得ないのですが、彼らはソフトウエア技術者としては一流ですから、ＬＸ２００コマンド処理は星図を有効に使うおまけみたいなものと考えているのかもしれません。
１０．１．４ Ｃａｒｔｅｓ ｄｕ ＣｉｅｌのＬＸ２００ライブラリの一部を修正
この不具合に対する具体的な修正について簡単に記すと、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ のＬＸ２００ライブラリの一部を修正することになる訳ですが、次の２つの関数にステートメントを追加することで修正が完了します。(以下のステートメントは省略形で概要のみ記述)
＜Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌのソース修正＞
//望遠鏡の座標取得（":Gr#",":Gd#"）
Function LC200_QueryEQ(ver RA, DEC: double) :boolean;
//”GR#”，”GD#”コマンド出力
if WriteCom(LX200_port, buf, count) = false then exit;
count = 20;
if ReadCom(LX200_port, buf, count) = false then exit; //レスポンス
// -------------------追加ステートメント:start of add statement
buf1 = '';
if ReadCom(LX200_port, buf1, count) = false then exit;
buf := buf + buf1;
//------------------- 追加ステートメント :end of add statement
//ステートメントは省略形で概要記述
end ;
// 望遠鏡の方位（":GZ#"）と高度（":GA#"）
unction LC200_QueryAZ(ver AZ, AL: double) :boolean;
//”GZ#”，”GA#” コマンド出力
if WriteCom(LX200_port, buf, count) = false then exit;
count = 20;
if ReadCom(LX200_port, buf, count) = false then exit; //レスポンス
//------------------- 追加ステートメント:start of add statement
buf1 = '';
if ReadCom(LX200_port, buf1, count) = false then exit;
buf := buf + buf1;
//------------------- 追加ステートメント:end of add statement
//ステートメントは省略形で概要記述
end ;
（ 注 ４ ）
表 に望遠鏡及び星の座標取得のコマンドとレスポンスの内容が示されています。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ ではこれらの設定コマンド(":SrHH:MM:SS#"，":SdsDD'MM#")は主に赤道儀コントローラ側の処理なので不具合は常にコントローラ（ＥＪＡＮ側）に責任があることにな ってしまいます。
表 コマンドの授受 ： 望遠鏡及び星の座標は以下のコマンドで行われる
<Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌコマンド送出> <赤道儀レスポンス>
星の赤経Ｒａ 設定コマンド :SrHH:MM:SS# <-----> '0' or '1'
星の赤緯Ｄｅｃ設定コマンド :SdsDD'MM# <-----> '0' or '1'
望遠鏡の赤経Ｒａ 取得コマンド :Gr# <-----> "HH:MM.T" or "HH:MM:SS"
望遠鏡の赤緯Ｄｅｃ取得コマンド :Gd# <-----> "sDD'MM" or "sDD'MM'SS"
望遠鏡の方位Ａｚ 取得コマンド :GZ# <-----> "DDD'MM.T" or "DDD'MM'SS"
望遠鏡の高度Ａｌｔ取得コマンド :GA# <-----> "sDD'MM" or "sDD'MM'SS"
しかし、座標取得コマンドの処理は Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ側に処理の主体があり、こちらに不具合が見つかった場合は、赤道儀側の開発者である私にとってやや厄介な状況が生まれてしまいます。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌ側の不具合原因が特定されていれば赤道儀側でも対処は可能ですが、通常、このような場合はソースが無いために不具合の原因を特定することはかなり難しいものになるのです。真っ暗闇に投じられた小ものを手探りで探し当てることに等しい作業になってしまうのです。大方はこのような不具合に遭遇すると様々な通信実験を行ったり、通信データのモニタリングなどを行って情報を収集した後、不具合を類推することになるのです。
このような状況を避けるためにもオープンソースであることは非常に有意義なことでなのです。
いずれにしても、ブレイクポイントの設定とその時点での変数値が表示確認できるような良いデバッガでもあれば、これらの不具合はそれ程多くの労力を使わなくてもよいものであると思います。ソースを実行しながら実行状況を追うことで、双方にあるバグの特定が非常にしやすくなるのです。もちろん、ソースを読み解くことはそれ自体が面倒なことなのですが、何も情報が取得できない中でデバッグを続ける時の苛立ちやもどかしさに比べたら、こちらの方が遙かに容易なことなのです。
ついでに記すと、今回採用したＡｒｄｕｉｎｏは未だ開発途上の環境ですから、上記のようなデバッグ環境が整備されていません。確かに、様々なライブラリを使用すること でＬＥＤを点灯するような簡単な処理や単一デバイスを操作することなどにおいては多く利点があります。
それでも、ＥＪＡＮ赤道機制御システムのような数千ステップにも及ぶものになると、プログラムの開発とデバックはそう簡単には行えません。というのも、ＡｒｄｕｉｎｏはプログラムデバッグはＵＳＢポートを介して行うことが前提で、実機での動作をエミュレートするようなソフトウエアではないので、不具合は即暴走の要因となって状況判定が不能な状況に陥るのです。
唯一のデバッグ手段は自らのソースの中に次のステートメントを加えます。
改行無しのSerial.Print()文または改行ありのＳｅｒｉａｌ．ｐｒｉｎｔｌｎ（）文をソースに入れておき、そのカレントデータ内容をシリアルモニタ（これは）に出力させて、動作状況とデータの内容を確認することだけです。
これは無いよりはましというくらいの機能であって、サンプルソースにあるような簡単なプログラムを作るくらいのデバッグに対する意識しかないことと同じです。とにかくＡｒｄｕｉｎｏはフリーなソフトウエアなのであって、元々簡単なハードを操作するようなシステムをより簡易で容易に楽しむ趣旨で作られたものですからあまり文句は言えません。それでも、プロジェクトは進展していますから、いずれより良いデバッグ環境が提供されるかもしれません。
いずれにしても、大きなソースプログラムのデバッグは本当に大変ですから、ＥＪＡＮ赤道機制御システムをより発展させるためには、統合デバッグ環境のあるＡＶＲまたはＡＲＭシステムなどにシステム移行することを検討しなければならないかもしれません。
幸い、ＡｒｄｕｉｎｏはＣやＣ＋＋をべースに作成され、コンパイル時にＣのソースに展開される様なのでＡＶＲ ＳｔｕｄｉｏなどのＣ環境とは相性が良いことが救いです。
１０．２ Ｙｏｃ 対応版－苦しみの跡
１０．２．１ Ａｒｄｕｉｎｏにおけるハード的な問題点
Ｙｏｃ（Yoshida Observatory Control System）との通信においてハード的な問題となったことは、Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌの場合と同様でＡｒｄｕｉｎｏのブートローダ絡みのものなので内容は全く同じです。
従って、対処法は前章までに記しておいたのでここでは特に記述しないですが、要するに通信開始にタイムアウトエラーがでてＹｏｃは処理やめてしまいます。これは、Ｙｏｃとしては全くの正常な処理状態なのですが、同様にしてハード側は、リセット処理をしてコマンド待ちに入っている状態なのです。
１０．２．２ コマンド解釈におけるソフト的な問題点
Ｃａｒｔｅｓ ｄｕ ＣｉｅｌにおけるＬＸ２００コマンドとＥ－Ｚｅｕｓコマンドとの最も大きな相違は、コマンドの終了を表す”終端コード”という概念の有無です。
もちろん個々のコマンドの仕様が異なることは当然のことなので、要はコマンドラインに関する考え方の相違と言うべきなのかもしれません。
Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌでは、コマンドラインの終わりを表すコード（これを終端コードといい'#' : pound mark）が定義されています。
このためコマンドが複数同時に届いてもコマンド区切りがはっきりしているので、コマンド処理は非常に明瞭です。
しかし、Ｅ－Ｚｅｕｓには終端コードの考えが無い（というか、特に記述がない）ので、コマンドの終了が分かりません。
このため、私の開発システムがｗｉｎｄｏｗｓであることと、開発言語がＣベースであることから、コマンド文字列はＣＲ＋ＬＦ('\r\n')で終わるものと考えていましました。
通常、コマンドとしてのテキスト（文字列）は、改行コードを終端コードとして使用する場合が多く、次の３パターンのコードが付けられるものと考えられます。
・ ＣＲ('\r')のみ、 ： ＭａｃＯＳ （ただし、バージョン９まで）
・ ＬＦ('\n')のみ、 ： ＵＮＩＸ， Ｌｉｎｕｘ
・ ＣＲ＋ＬＦ('\r\n') ： Ｗｉｎｄｏｗｓ， ＭＳ－ＤＯＳ
テキストの終端コードは、使用しているパソコンのシステムに依存する訳で固定的なものではありません。プログラム開発言語における仕様と共にオペレーティングシステムとの兼ね合いでき
まるものなのです。ところが、実際に通信をしてみるとコントロール側がうまく動かないのです。
このときはまだ、後述のＹｏｃ <--> Ｅ－Ｚｅｕｓ通信記録を取る仕組みを追加していなかったので苦労する羽目になってしまいました。
幸い、何回かの瀬戸口様とのメイルのやりとりで、”Ｙｏｃ からのコマンドにはＣＲ('\r')のみが付加されてコマンドが送付されている”と教えて頂いたおかげでこの問題は一気に解決することになったのです。 （瀬戸口様からのメイルで教えて頂いて確認した）
ただし、コントローラ側からＹｏｃへのレスポンスには、ＣＲ＋ＬＦ('\r\n')の形式で返答を返しているのですが、それでもＹｏｃ側は問題ないようです。
(余談 １)
余談ですが、ＡｒｄｕｉｎｏシステムはＣベースで開発できる大変分かり易いシステムですが、前述のように唯一の欠点はデバッグ機能（実際にはない）が非常に貧弱であることです。
デバッガがしっかりしていれば、このようなトラブルは直ぐに解決していたと思われます。あくまでも私感ですが、Ａｒｄｕｉｎｏはごく小さなプログラム開発には向いていますが、大きなプログラムではデバッグに苦労するのであまり良い開発環境とはいえないようです。
現状でも、ＬＸ２００対応版は既にシステムのサイズが３２Ｋ(すでに超えた)バイトに迫っ
ており、これ以上機能拡張ができないので、ＡＴｍｅｇａ３２８を使用するＡｒｄｕｉｎｏ
ボードでの開発は限界に達しています。
ボード性能的には何ら問題が生じていませんし、速度的にも望遠鏡の制御に支障は生じていませんが、今後の開発を考えた場合にＡｒｄｕｉｎｏ Ｍｅｇａボートに移行するか、あるいは他のボードに移行するのかを検討しなければなりません。
ＥＪＡＮ赤道儀制御システムの場合は、自作や赤道儀のレストアを考慮しているとは言っても全てのユーザがソフトの内容やハードボードを理解する必要がないわけですから、この際、ＡＲＭベースのＬＰＣｃａｐｐｕｃｃｉｎｏポートあたりをターゲットにしてトライしてみるのもよいのかもしれませんね。
１０．２．３ Ｙｏｃとの接続において ： 通信モニタ機能を作成してみる
Ｙｏｃ <--> Ｅ－Ｚｅｕｓ通信記録は、ＹｏｃとＥＪＡＮ赤道儀制御システム：Ｅ－ＺＥＵＳ対応版との間で行われた通信記録です。
通信はパソコン側のＹｏｃとソフトウエア・シリアルが追加されている一台目のＥ－ＺＥＵＳ１ 間で行われた通信をフックして、同じくソフトウエア・シリアルが追加されかつクロス接続された二台目のＥ－ＺＥＵＳ２に転送することで行われます。
Ｅ－ＺＥＵＳ２はＰＣ側のＵＳＢポートを介してＲＳ－２３２Ｃ通信ソフトに接続されているので、最終的にはこの通信ソフトの受信データとしてＹｏｃからのコマンドが取得できるのです。
ちなみに、このソフトウエア・シリアルは ＥＪＡＮ赤道儀制御システムのハンドコントローラ接続における通信処理ラインに応用することを念頭にこの接続テストをした訳です。
これらの通信はやや複雑なので以下に接続方法を含め若干の記述をしておくことにします。
まず、Ｅ－ＺＥＵＳシステムに NewSoftSerialライブラリを追加し、コマンド授受のためのルーチンを追加作成します。
予め送受信ポート（送信 ＰＩＮ ８，受信 ＰＩＮ ７ ピン番号は任意 ）を設定しておき、以下の手順でソフトウエア・シリアル本を接続してデータの取得を行います。
１．Ｅ－Ｚｅｕｓ１：ＹＯＣとＥ－ＺＥＵＳをシリアル（ＵＳＢ）で接続します。
◆Ｅ－Ｚｅｕｓ１の送信ピン（ＰＩＮ８）に対してＹＯＣからの送信データをそのまま出力します。
◆Ｅ－Ｚｅｕｓ２：２台目はＲＳ３２３ＣモニタソフトとＥ－ＺＥＵＳ２をシリアル（ＵＳＢ）で接続します。
◆Ｅ－Ｚｅｕｓ１の送信線（ＰＩＮ ８から）をＥ－ＺＥＵＳ２の受信ピン（ＰＩＮ ７）にクロス接続します。
◆Ｅ－Ｚｅｕｓ２の送信線（ＰＩＮ ８から）をＥ－ＺＥＵＳ１の受信ピン（ＰＩＮ ７）にクロス接続します。
◆Ｅ－Ｚｅｕｓ１からデータを受信したら、Ｅ－Ｚｅｕｓ２のシリアルにそのまま出力します。
これにより、Ｅ－ＺＥＵＳ１からのデータはＲＳ３２３Ｃモニタソフトの受信データとしてモニタリングできます。
◆Ｅ－Ｚｅｕｓ２からデータを受信したら、Ｅ－Ｚｅｕｓ１のシリアルにそのまま出力するようにすると、Ｅ－Ｚｅｕｓ２からのデータはＥ－Ｚｅｕｓ１の受信コマンドデータとしてモニタリングできます。
２．Ｅ－Ｚｅｕｓ１及びＥ－Ｚｅｕｓ２の電源をいれる
ＲＳ３２３Ｃモニタソフトを立ち上げて、ＣＯＭ（システムにより異なる）でＥ－Ｚｅｕｓ２との通信を確立させておきます。
◆ＹＯＣを立ち上げて、ＣＯＭ５（システムにより異なるがＹＯＣはＣＯＭ５が最大ｃｏｍ番号のようだ）で通信を確立します。
◆ＹＯＣが立ち上がると、Ｅ－Ｚｅｕｓ１側のＲＳ３２３Ｃソフトの受信データ欄にＹＯＣからＥ－Ｚｅｕｓ１への通信データがモニタされます。
３．稼働中の受信データはファイルに保存されます。
ファイル名は、"COM" + "ポート番号"+"日付”RS232CRcv.txt 型式である
ディレクトリ： RS232C\BACKUP\
ファイル例 ：
（前頁受信データファイル） COM8_2012_4_27_16_31_BakRS232CRcv.txt
（送信データファイル） COM8_2012_4_27_16_31_BakRS232CSnd.txt
使用したＲＳ３２３Ｃモニタソフトでは、受信データははテキスト形式でシステムの終了時にファイルに書き出されます。
４．Ｅ－ＺＥＵＳ２の送信ポートから特定なコマンドを出力すれば、
外部コントローラからの命令と して処理させることができる
ハンドコントローラのプログラムテストにシステムが使用できることになります。
上記通信モニタ機能によってＹｏｃ <--> Ｅ－Ｚｅｕｓ間の通信記録雅趣得されたので、以下に内容を提示します。
通信記録は、ＹＯＣとＥ－ＺＥＵＳ１とが接続された時点からのものです。
従って、この通信記録はＹＯＣのＥ－ＺＥＵＳに対する開始シーケンスそのものを表していることに注意することが重要です。
ここで、Ｅ－ＺＥＵＳ１はＹＯＣと接続され、Ｅ－ＺＥＵＳ２はＲＳ２３２Ｃモニタプログラムに接続されています。
次表の記述で、ＹＯＣとあるのはＹＯＣにおけるプロラム操作の内容を表し、Ｅ－ＺＥＵＳコマンドとあるのは実際に出力されたデータの内容です。
コマンド内容とあるのは、Ｅ－ＺＥＵＳコマンドの内容を分かりやすいようにコメントとして付加表記しました。
表 ＹＯＣを操作したときのＹＯＣとＥ－Ｚｅｕｓ間の通信記録
《 ＹＯＣ 》 －＞ 《 Ｅ－ＺＥＵＳ通信記録 》
〔YOC上の操作 設定〕－＞ Ｅ－ＺＥＵＳコマンド 〔コ マ ン ド 内 容〕
COM8でE-ZEUSに接続 RD#0007BB85#0007BB85 周回(1日当り)ステップ数設定
PA#00#00 到着予告ステップ数の設定
ST E-ZEUS状態の返信要求
DVRAF1 RAを恒星追尾速度で連続稼働
GP 約1秒間隔でモータステップ数要求
天体指定し同期設定 GP 約1秒間隔でモータステップ数要求
約１秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
天体指定し移動ボタン押下 DVRAF3#00001A8A RA中速"#00001A8A"連続稼働
無操作 DVDCF3#00002AAA DEC中速"#00002AAA"連続稼働
ST E-ZEUS状態の返信要求
GP モータステップ数要求
ST E-ZEUS状態要求
GP モータステップ数要求
SP1 恒星時運転に移行（スリュー停止）
GP モータステップ数要求
無操作 GP モータステップ数要求
移動:RA"中速"正回転押下 DVRAF3 RAモータを中速連続正回転
GP モータステップ数要求
移動:RA"中速"正回転解除 SP1 恒星時運転移行（スリュー停止）
GP モータステップ数要求
移動:RA"中速"逆回転押 下 DVRAR3 RAモータを中速連続的逆回転
移動:RA"中速"正回転解除 SP1 恒星時運転移行（スリュー停止）
GP モータステップ数要求
移動:DEC"中速"正回転押下 DVDCF3 DECモータを中速連続的正回転
GP モータステップ数要求
移動:DEC"中速"正回転解除 SP1 恒星時運転移行（スリュー停止）
GP モータステップ数要求
移動:DEC"中速"逆回転押下 DVDCR3 DECモータを中速連続的逆回転
移動:DEC"中速"正回転解除 SP1 恒星時運転移行（スリュー停止）
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1秒間隔でモータステップ数要求
移動:RA"高速"正回転押下 DVRAF4 RAモータ最速連続的に正回転
移動:RA"高速"正回転解除 SP1 恒星時運転に移行（スリュー停止）
無操作 GP モータステップ数要求
移動:RA"高速"逆回転押下 DVRAR4 RAモータを最速連続的に逆回転
移動:RA"高速"逆回転解除 SP1 恒星時運転に移行（スリュー停止）
無操作 GP モータステップ数要求
移動:DEC"高速"正回転押下 DVDCF4 DECモータ最速連続的に正回転
移動:DEC"高速"正回転解除 SP1 恒星時運転に移行（スリュー停止）
無操作 GP モータステップ数要求
移動:DEC"高速"逆回転押下 DVDCR4 DECモータ最速連続的に逆回転
移動:EC"高速"逆回転解除 SP1 恒星時運転に移行（スリュー停止）
無操作 GP 約1秒間隔でモータステップ数要求
無操作 GP 約1間隔でモータステップ数要求
処理終了 SP0 モータの停止要求
１０．３ ＳＵＰＥＲ ＳＴＡＲ Ⅳ対応版－苦しみの跡
ＳＵＰＥＲ ＳＴＡＲ Ⅳは、様々な望遠鏡システムのコマンド体系に対応しているソフトウエアなので、ＥＪＡＮ赤道儀制御システムの個々の機器種別で通信テストを行わなくてはなりません。ここでは、Ｅ－ＺＥＵＳコマンド体系の処理テストに関する事柄について記述していきます。
ＳＵＰＥＲ ＳＴＡＲ Ⅳで制御できるＥ－ＺＥＵＳシステムは以下に示す5種類の望遠鏡が有ります。
表 ＳＵＰＥＲ ＳＴＡＲ Ⅳで接続可能な望遠鏡
< 接続できる望遠鏡 >
Ｅ－ＺＥＵＳ（Ｆｏｒｋ Ｖｅｒ．２．００）
Ｅ－ＺＥＵＳ（Ｆｏｒｋ Ｖｅｒ．２．２１）
Ｅ－ＺＥＵＳ Ｖｅｒ．２．００
Ｅ－ＺＥＵＳ Ｖｅｒ．２．２１
ＡＧＳ Ｖｅｒ．２．２１
この望遠鏡の種別はＳＵＰＥＲ ＳＴＡＲ Ⅳ側から見たものであり、Ｅ－ＺＥＵＳではコントローラ側からは何ら相違を見出せませんのでどれを選択してもかまいません。
１０．３．１ ＳＵＰＥＲ ＳＴＡＲ ⅣにおけるＤＶコマンドの動作不良
ＳＵＰＥＲ ＳＴＡＲ Ⅳにおける動作確認は、製作中のＥＪＡＮ赤道儀コントローラがＹＯＣ上で正常に動作することを確認した後に行われました。Ａｒｄｕｉｎｏの場合はソフトシリアル機能を応用してＹＯＣのモニタリングを行いましたが、ＬＰＣｃａｐｐｕｃｃｉｎｏの場合にはこの機能がないので基板上に設置されたＬＣＤの表示機能を利用してコマンド情報の確認を行います。この場合には、送出されたコマンドをそのままＬＣＤ上に表するので、指定ステップ数の回転要求を行うＤＶコマンドの場合は、コマンド表示が表示行欄いっぱいになることと、表示時間が短いなどという欠点が有ります。
Ｅ－ＺＥＵＳにおける望遠鏡の動作は、次ページの”表 ＳＵＰＥＲ ＳＴＡＲ ⅣとＹＯＣの操作ボタンと発行コマンドの内容”で示す通り、回転動作を要求する”ＤＶ”コマンドとコントローラの状態を要求する”ＳＴ”コマンドなどで構成されています。
具体的な操作ボタンに対する出力コマンドが示されていますから、この操作ボタンの内で右ボタンに対するコマンドの内容を見てみましょう。
図 ＹＯＣの操作ボタンの形態
＜ＹＯＣの移動ボタン＞
このコマンド表で操作内容が”ボタンの押下”と表されているもの横欄は、当該ボタンを押したときにコントローラに送られるコマンドの内容が示され、”ボタンを離す”と表されているのはボタン押下後にボタンを解放したときに出されるコマンドがそれぞれ示されています。これらの発行コマンドの内容は、実際にコントローラに送出された実データのままをＬＣＤ表示デバイスで内容を表示確認して得たものです。
表 を見る限り、手動での回転動作を要求する”ＤＶ”コマンドにおいて、ＳＵＰＥＲ ＳＴＡＲ Ⅳは、要求する回転速度から恒星時運転又は停止するときに、所定時間をおいて順次低速回転に移行するように複数のコマンドを出力して減速処理をしていますが、ＹＯＣの場合にはそのような減速処理を行わず直ちに恒星時運転又は停止に移行する様なコマンドを送出していることが異なるだけです。つまり、処理内要求の内容的意味合いは同じとなりますから、望遠鏡の処理結果はほぼ同じようになります。
停止コマンドではコマンド内容そのものは全く同じものになっています。
導入コマンドにおいてはコマンド内容そのものが両者で若干異なっていることがおわかりでしょうか。この導入コマンドの仕様からするとＹＯＣが正しいのであり、ＳＵＰＥＲ ＳＴＡＲ Ⅳの方は先頭部分にゴミ（ゼロ’０’）が付加していることが分かります。このため、ＥＪＡＮ赤道儀コントローラはＹＯＣでは正常に処理を開始していましたが、ＳＵＰＥＲ ＳＴＡＲ Ⅳではコマンド不良としてレスポンスを返していました。
この場合、先頭部分にゴミ（ゼロ’０’）がなければ何も問題はないのですが、ＥＪＡＮ赤道儀コントローラとしては正しいフォーマットでコマンドが送られてくるものとして処理プログラムが書かれていました。このため、ＳＵＰＥＲ ＳＴＡＲ Ⅳでは通信異常が発生したものとしてのエラー処理を行い、コントローラ側は何の処理も行わなかったのです。
表 ＳＵＰＥＲ ＳＴＡＲ ⅣとＹＯＣの操作ボタンと発行コマンドの内容
[ 操作の内容 ] [ ＳＵＰＥＲ ＳＴＡＲ Ⅳ ] [ ＹＯＣ ]
< 発行コマンド> < コマンド処理の内容> <発行コマンド>
<ボタンの押下>
ST E-ZEUS状態要求コマンド
0VRAF4 赤経ＲＡモータ正転最速連続駆動 DVRAF4
<ボタンを離す>
DVRAF3 赤経ＲＡモータ正転中速連続駆動 SP1
DVRAF2 赤経ＲＡモータ正転低速連続駆動
DVRAF1 赤経ＲＡモータ正転恒星時連続駆動
<ボタンの押下>
ST E-ZEUS状態要求コマンド
0DVRAR4 赤経ＲＡモータ逆転最速連続駆動 DVRAR4
<ボタンを離す>
DVRAR3 赤経ＲＡモータ逆転中速連続駆動 SP1
DVRAR2 赤経ＲＡモータ逆転低速連続駆動
DVRAR1 赤経ＲＡモータ正転恒星時連続駆動
<ボタンの押下>
ST E-ZEUS状態要求コマンド
0DVDCF4 赤緯ＤＥＣモータ正転最速連続駆動 DVDCF4
<ボタンを離す>
DVDCF3 赤緯ＤＥＣモータ正転中速連続駆動 SP1
DVDCF2 赤緯ＤＥＣモータ正転低速連続駆動
DVDCF0 赤緯ＤＥＣモータ正転恒星時駆動停止
<ボタンの押下>
ST E-ZEUS状態要求コマンド
0DVDCR4 赤緯ＤＥＣモータ逆転最速連続駆動 DVDCR4
<ボタンを離す>
DVDCR3 赤緯ＤＥＣモータ逆転中速連続駆動 SP1
DVDCR2 赤緯ＤＥＣモータ逆転低速連続駆動
DVDCR0 赤緯ＤＥＣモータ正転恒星時駆動停止
[ 停止] <ボタンの押下>
SP1 恒星時運転を行う SP1
[導入 ] <ボタンの押下>
0DVRAF4#HHHHHHHH 赤経ＲＡモータ正転最速指定数駆動 DVRAF4#HHHHHHHH
0DVDCF4#HHHHHHHH 赤緯DECモータ正転低速指定数駆動 DVDCF4#HHHHHHHH
このような状況で問題となっていることは、ＳＵＰＥＲ ＳＴＡＲ Ⅳからの回転動作を要求している”ＤＶ”コマンド送出のときの先頭部分に不正な文字（’０’）が付加されていることです。
具体的にいえば、右ボタンを押したときに出される赤経ＲＡの回転コマンドは”0DVRAF4”となっており、また、導入ボタンを押下時の指定ステップ数の回転要求コマンドが”0DVRA#HHHHHHHH”となっていることです。ともにコマンドの先頭に’０’（半角ゼロ）というごみ文字が入るために、コントローラ側はコマンド不正として処理しています。このとき、正しいレスポンスとなる半角の’＃’をコントローラが返しませんから、上位アブケーション側のＳＵＰＥＲ ＳＴＡＲ Ⅳは”何らかの通信エラーが発生しています”と表示してエラーを出してこちらも処理を中止してしまいます。
ですが、この状況はハード的な通信エラーではなくて、ＳＵＰＥＲ ＳＴＡＲ Ⅳの出したコマンドエラーなのです。エラー発生当初は、上位アブケーションを信用して表示内容をそのまま受け取って信号部分のソースデバッグを行っていたのですが、どうも状況が納得いかなかったのでコマンドデータをモニタリングする事にしました。その結果が上表なのですが、このようなことが分かれば比較的簡単に修正できたので、もっと早めにコマンド表示を行えばよかったと悔いている次第です。
このような不具合はコマンド通信によるシステムでは、往々にして発生するものですが、前述のようなエラー自体は発見しずらいもののうちの一つです。というのも、コマンド仕様がしっかりと公開されている市販されたシステムにおいて、上記のような不具合を仮定しずらいからです。つまり、正しいコマンドが送付されているということが前提で処理を行おうとするからなのです。
＜ＳＵＰＥＲ ＳＴＡＲ ⅣのＥ－ＺＥＵＳコマンドエラー＞
・回転動作を要求する初めての”ＤＶ”コマンドの前に’０’（半角ゼロ）の文字列が入る
このような状態のままでは、天体の自動導入だけでなく制御そのものができないわけですから、何らかの解決策を講じなくてはなりません。
しかし、このような状況が有るにも関わらず、ネット上で実際にＥ－ＺＥＵＳが稼働しているビデオを見るにつけ、何で動作するのか理解に苦しむところではあります。
どのような場合でもソフト的には回避できるものなのでコントローラ側で回避しても良いのですが、このような修正は本来、ＳＵＰＥＲ ＳＴＡＲ Ⅳの側が行うことが最良なのです。
いずれにせよ、実際のサポートに関しては私の方からは何も言えないので、現状では単に報告のみということになります。
＜ＳＵＰＥＲ ＳＴＡＲ Ⅳのコマンドエラー回避方法＞
ＳＵＰＥＲ ＳＴＡＲ Ⅳの”ＤＶ”コマンドにこのような不具合が有ったとしても、メーカ
ーサイドでの修正を待つことはできませんので、コントローラ側で回避するしか方法はありません。
従来は、正確なコマンドフォーマットに則って制御が行われることを前提に、コントローラ側ではやや緩いコマンド処理をする様なコーディングになっていましたが、修正版ではコントローラ側がより厳しいフォーマットチェックを入れて動作するようにします。
具体的には、”ＤＶ”コマンドの”0DVRA#HHHHHHHH”のようなデータはゼロ('0')を除いた実
コマンド開始位置(“DVRA#HHHHHHHH”の“DVRA”)を検索することで行われます。
このような処理法の場合は、基本的な送られてくるコマンドフォーマット長は無意味なものになってしまうわけですから検査はしません。
従って、移動ステップ量（“DVRA#HHHHHHHH”の“HHHHHHHH”）においても、その終端も文字列終端までとします。
このコマンドの検索と取得には次のｓｔｒｓｔｒ（）ステートメントを使用して行います。この関数は、第１パラメータ（例では、コントローラ側に送られてきたコマンドがEjanCommand に入っています）の中から、第２パラメータ（"DVRA"）の文字列のある場所を検索します。関数は一致する文字列（文字ではない）がなければ'NULLヌル'を返し、文字列が有ればその先頭アドレス（この場合は’Ｄ’のアドレス）を返します。
#include <stdlib.h>
if ( (newEjanCommand=strstr(EjanCommand, "DVRA")) != NULL ) {
// コマンド文字列に"DVRA"が見つかった時の処理
if ( strchr(newEjanCommand, '#') != NULL) {
// DVRAF2#HHHHHHHH RA Motor Drive Command：赤経モーターの指定ステップ数回転
EZeusRaMotorTrackingCommand( newEjanCommand);
} else {
// DVRAF2 : RA Motor Drive Command：赤経モーターの指定ステップ数回転
EZeusRaMotorDriveCommand( newEjanCommand );
}
このようなコマンドの検査はコマンドの前に不正な文字列が入っていてもコマンド処理ができることになり、より緩やかなコマンド検査ということで本来的にはあってはならない状況なですが、実質的な処理としては仕方ないですね。これで、処理そのものは問題なしです。
＜ＳＵＰＥＲ ＳＴＡＲ ⅣのＬＸ２００コマンドエラー＞
ＬＸ２００コマンドの場合は、コマンドがデリミタ’＃’コードで区切られているので、コマンド送信の後の改行(0x0d)や復帰(0x0a)等の制御コードは要求されていません。Ｅ－ＺＥＵＳの場合は改行(0x0d)コードが終端として扱われています。 従って、ＥＪＡＮではこの仕様に則ってこれら制御コードを出力せずにコマンド処理が行われているわけです。
ＳＵＰＥＲ ＳＴＡＲ ⅣにおいてＥ－ＺＥＵＳとの通信における問題点は前述のとおりでしたが、ＬＸ２００コマンドの場合はコントローラ側とシステムの接続時に不具合が発生しました。
ＳＵＰＥＲ ＳＴＡＲ Ⅳはこのとき、望遠鏡の視野座標の取得コマンド（：ＧＲ＃， ：ＧＤ＃）を出力してコントローラからのレスポンスを待ちます。このとき、赤経ＲＡの座標は正しく表示しますが、赤緯ＤＥＣの座標が正しく表示されず、”望遠鏡からの応答が有りません”というメッセージを出力して回線を切断してしまいます。このとき、赤経ＲＡの座標は正しく表示されているので通信は良好だと思われますが、赤緯ＤＥＣの座標の取得がうまくいかないのだと思われます。
ＳＵＰＥＲ ＳＴＡＲ Ⅳの場合、赤緯ＤＥＣの座標の表示は”±ＤＤ°ＭＭ．Ｓ”ということ
になっていますが、このフォーマットはＬＸ２００コマンドにはありません。
＜ＬＸ２００コマンドとレスポンスのフォーマット＞
<LX200コマンド> < 座 標 > <高精度のフォーマット> < 低精度のフォーマット>
：ＧＲ＃ 赤経ＲＡ ＨＨ：ＭＭ：ＳＳ ＨＨ：ＭＭ．Ｔ
：ＧＤ＃ 赤緯ＤＥＣ ±ＤＤ°ＭＭ’ＳＳ ±ＤＤ°ＭＭ’
＜星図システムによる座標表示の違い＞
< システム > < 座 標 > < 高精度の表示 > < 低精度の表示 >
Caltes du Ciel 赤経ＲＡ ＨＨhＭＭmＳＳs ＨＨhＭＭ.Ｔm
赤緯DEC ±ＤＤ°ＭＭ．ＳＳ ±ＤＤ°ＭＭ
SUPER STAR 赤経ＲＡ ＨＨhＭＭ.Ｔm ＨＨhＭＭ.Ｔm
赤緯DEC ±ＤＤ°ＭＭ．Ｓ ±ＤＤ°ＭＭ．Ｓ
ＳＵＰＥＲ ＳＴＡＲ Ⅳが自らのフォーマットを優先させるとフォーマットエラーということになる訳ですが、内部処理で表示を統一しているのならば問題はないのですがどうなのでしょうか。
当然のことなのですが、 Ｃａｒｔｅｓ ｄｕ Ｃｉｅｌでは、表示精度の設定により上記の形式で各座標が表示される訳ですが、それだけでなくコントローラにも精度指定のコマンドが出力されるのでその指定に従ったレスポンスが返されているのです。
ＳＵＰＥＲ ＳＴＡＲ Ⅳの場合は、複数のコマンド体系に対応しており、それぞれのコマンド体系でのデータ表記は必ずしも同じではありませんから、自画面上の表示は固定フォーマットで統一しているのかもしれません。
いずれにせよ、このようなコマンドレスポンスでは通信が開始されないわけですが、コントローラとしてはどのような上位アプリケーションが接続されているのかを認識することができませんから根本的な解決法はないのです。つまり、レスポンスのフォーマットを変えること自体は容易なのですが、特定な上位アプリケーション毎にレスポンスを切り替えて返すということは、アプリケーションの種別が送られてこないのでできないことなのです。
0コメント