「なでしこv1」開発掲示板

【症状】どのような症状、現象か？
RS232C通信で、マイコン等より連続したHEXデータの中に「0x00」データがあると、(定義した)受信バッファに取り込んだ受信のデータ全てがクリアされる。
連続したHEXデータの中に、「0x00」が無ければ、全てのデータは正常に取り込むことができる。
【再現方法】サンプルソース、再現手順など
使用した、プログラムは以下の通り。

#-----ここから-----
!「rs232c.nako」を取り込む
受信バッファとは文字列
テストRS232CとはRS232C 　　　　# RS232C部品を作る
テストRS232Cについて
　　ポートは「COM1」
    BPSは9600
テストRS232Cが受信した時は～
　　受信バッファに「{受信データ}」を追加
　　「全文字数＝{受信バッファの文字数}」を表示
　　「全バイト数＝{受信バッファのバイト数}」を表示
　　受信バッファは空

結果ラベルとはラベル。 
結果ラベルは「」
中止ボタンとはボタン。 
中止ボタンのクリックした時は～結果表示
●結果表示 
　　イベント部品→テキストで条件分岐。 
　　　　「中止」ならば結果ラベルは「中止」 

テストRS232Cを開く

必要の間　　
　　もし、結果ラベルが「中止」なら
　　　　抜ける
　　0秒待つ
テストRS232Cの閉じる
終わる
#------ここまで-------

【要望】どのような解決が望ましいか？
　マイコンからのHEXデータをパソコンで受信するプログラムを作成しているのですが、この部分で自分のしたいことが止まっています。
是非とも、0x00～0xffまでのデータが受信できるよう、お願いいたします。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
もしかしたら、「0x00」のデータは、内部でコントロール・コードとして使用されているのでしょうか？

【バージョン】確認したバージョン
なでしこバージョン：1.53353
OS:WinXPSP3

【その他】
添付ファイルに、その時の実験方法と、実験結果（パソコンの画面の写真と、RS232Cのモニターとして使用したオシロスコープの画面の写真）を記した画像をいれてあります。汚いですがご確認いただくとうれしいです。
写真の中の送信データは、「0x01,0x02,0x03,0x04,0x05,0x06」と、
　　　　　　　　　　　　「0x01,0x02,0x03,0x04,0x00,0x06」の2種類です。
                                             ~~~~~~
ご迷惑をおかけいたします。
プログラムの作り方が悪い為におこる現象でしたら、申し訳ございません。

　ざっと、内部を調べてみました。開発者向けの情報です。

　内部でのデータ設定を、代入文をeval相当で行ってますが、evalは0x00を含むとうまく動かないようです。

　もともと、今のevalで代入文を実行する方法では、受信データの「』」によって、エラーになったり、別のコマンドを流し込まれて実行させらてしまったりするので、根本的に実装方法を変えるか、evalへ渡すコマンドの生成をevalが処理可能な形になるよう変更する必要があるようです。
（おそらく、TCPやUDPの受信も同様。）


なお、「文字数」の命令は、0x00の前までを文字数として数えるようですので、ご注意ください。他にも、データとしての0x00をうまく扱えない(処理がその前までで終了してしまう)機能があるかもしれません。
（「バイト数」は正しく動くようです）

蛇足。
　動作検証をする場合、RS-232Cはどうしよう・・・

「うぇいく」さん、早速の返信ありがとうございます。発信者eva1000です。

>内部でのデータ設定を、代入文をeval相当で行ってますが、evalは0x00を含むとうまく動かないようです。

そうだったんですか．．．．．（残念）

今、マイコンからのデータをRS232C経由で取り込めることを前提にして、SQLiteにデータを入れるプログラムを、せっせと、作っています。ので、

何方か、ソースの変更をお願いできませんでしょうか？(m_!_m)

開発者向けの情報です。

おそらく、evalで受信データの設定しいる箇所（３か所）を、以下の方法に変更すると動くような気はします(以前、UDPSocketの問題の際に書いた方法の適用)

----
// 受信データをセット
p := nako_getGroupMember(PAnsiChar(self.instanceName),PAnsiChar('受信データ'));
if p <> nil then nako_bin2var(PAnsiChar(s),Length(s),p);
----
※変数eが不要になるので、宣言ぶから削除可能。

置き換える内容を含む関数は、hi_unit\dll_rs232c_function.pasの、
procedure Trs232cN.FFOnPACKET(Sender: TObject);
procedure Trs232cN.FFOnRXCHAR(Sender: TObject);
procedure Trs232cN.FFOnRXFLAG(Sender: TObject);
の、それぞれの該当箇所です。

ただ、UDPSocketのほうもリリースファイルは以前のままのようなので、evalでの方法に比べてデメリットがあるのではとも思うのですが、なぜそのままなのかなどの説明もないので実際のところはわかりません（データ中に「』」というのは普通にありえるため、しょうがないので、当方ではnakonet.dllは自身にコンパイルしたバージョン(TCPClientの受信部分が該当)を使用しています。）。

発信者eva1000です。
うぇいくさん、早速の情報ありがとうございます。

うぇいくさんの返信は、「開発者様向け」の発信の様ですね。
残念ながら発信者の私は素人のため、何かのファイルの中身を置き換えれば対応出来る位しかわかりません。

そこで、うぇいくさんにお願いですが、変更したファイルを、頂戴することはできないでしょうか？

無理は承知でお願いをしております。
どうか、よろしくお願いいたします。

とりあえず、コンパイルしてdllの形にしたものを自サイトに置きました。
http://weyk.la.coocan.jp/weyk/nadesiko/

動作は未確認です(PCにCOMポートがなかった・・・)

よろしければ、うまく動作するのかどうか確認いただければと思います。
うまく動作した場合には、次のバージョンアップの際に何らかの形で取り込んでもらおうかと思います。

eva1000です。
早速、dllファイルを作成して頂き、ありがとうございます。
この連休に、職場からRS232Cケーブルを持って帰るのを忘れてしまい、確認が取れないため、あす以降に動作確認をさせてください。
結果を、この掲示板でご報告いたします。

先ずは、うぇいくさんに、お礼を申し上げます。

発信者eva1000です。
うぇいくさんのHPよりダウンロードさせて頂きました、ファイルで動作致しました。
・0x00～0xffまで受信確認しました。
・「全バイト数」命令で、0x00も1バイトとしてカウントしました。

これで、RS232CによるHEXデータの取り込みが行えるようになり、マイコンとの送受信ができるようになり、また一つ「なでしこ」との付き合いが深くなりそうです。

うぇいくさんには、大変感謝しております。
心より、お礼申し上げます。