■■■20レス以内で済むF-BASICの質問はこちらへ■■■ - 1071834531

631：名無しさん：2015/10/28(水) 12:02:26: >>630 　まずは原因の方から。
最初に推定するための情報を列挙します。
通信条件設定の表示テスト結果 >624-625 >626 から違いを見ると、
[fDtrControl]
0=DTR_CONTROL_DISABLE (DTRは常にOFF)←[GW-BASIC]
1=DTR_CONTROL_ENEBLE (DTRは常にON)　←[F-BASIC]
[fRtsControl]
0=RTS_CONTROL_DISABLE (RTSは常にOFF)←[GW-BASIC]
1=RTS_CONTROL_ENABLE (RTSは常にON)　←[F-BASIC]
そして >611 のデジタルマルチメータのデータ通信資料、(コネクタに無い信号線がある)
そして >621 のRS-232Cの関連情報、QuickBasicの通信条件オプション(,rs)

　次に通信条件設定の内容とテストの状況から、要因を探ります。

・F-BASICで受信時に「[27]システムに異常があります」原因不明エラーで受信不能。
ただ、ヌル(00h)が受信されていた。とりあえず受信不可能ではないらしい。
・ケーブルは普通にストレート。問題なし。
・ポートはマザーボードのものでUSB変換ではないし、GW-BASICで使えている。
・デジタルマルチメータ側端子には無い信号線がある。
・ハードウェアフロー制御はなし。→(通信量的に必要ないし無用な製品製造コスト)
・DSRの状態はPC側で無視している。
・CTSは？。PC側でCTS監視による送信フローはしない設定。→たぶんPC側ですべて無視。
・DTRはON/OFFどちらでも反応(受信)はする。→たぶん無視している。
・GW-BASICの通信条件オプション(,rs)→PC側でRTS関連のなにかを無視して通信している。
・RTSが常時OFFでもGW-BASICで正常通信できる。→無視しているのか？
・RTSが常時ONのF-BASICではデータ受信できない。→なぜ？。では完全無視ではない！。

可能性１－コマンド送信ができないまたは送信したが無視される。
＄Ａ－送信ができない。→DSRは無視、CTSは見ない。だから送信できないことはないだろう。
＄Ｂ－送信したコマンドが無視される。→なぜ？。print# は変更しても変わらなかった。
＄→それでは別の要因でＡＢいずれかの問題が発生か？→要因は何か？設定違いはRTS、DTR。
可能性２－データ受信ができないまたは送って来ない。
＄Ａ－受信ができない。→RTS常時ONだから？。そもそも受信できないはずがない・・。
＄Ｂ－データを送って来ない。→RTS常時ONだから？。なぜ？。
＄Ｃ－送って来たデータをPC側が無視した？。→DSRは無視しているはずだし、Ａに同じ。
＄→要因は何か？設定違いはRTS、DTR。

　これらから原因を推測すると、
DTRの可能性は低そう。DTR常時OFFで動くし、フロー制御なし設定なのだから。
ただしDTRをONにしていると(PC側の機種の判断材料)動作が変更されるのなら話は別だが…。
RTSの可能性が濃厚。それにF-BASICには",rs"オプションに当てはまりそうなものは無い。

RTSの違いが原因だと仮定して、とりあえずRTSをGW-BASICと同じく常時OFFに設定すればよい。
RTSがONだと送信または受信に支障が出るとすると、
　送受
OFF○ ○(これは成功)
ON × －送信で失敗と仮定だと→コマンド送信失敗ではデータが来ない…。
ON ○ × 受信で失敗と仮定だと→ONでも送信できるが、受信は失敗。
ON × × 両方失敗と仮定→常時OFFでなければ失敗。

ただ、送信時と受信時でON／OFFが異なれば受信成功するという可能性もまだある。
そのような場合のRTS(Request To Send)の動きは半二重通信方式の場合が考えられる。
半二重通信では送信と受信を同時には行えず、送信する時にはONにする。
これに該当しそうな設定は、次のものらしい。
3=RTS_CONTROL_TOGGLE (トグル)
(有効な送信用Bytes(データ)があればRTSをONにする。バッファのデータを
すべて送信した後、RTSをOFFにする。)

　とりあえずの結論としては、RTS_CONTROL_TOGGLEに設定してみるか、
RTS_CONTROL_DISABLE (RTSは常にOFF)にできれば通信はできると予想。