MODBUS(モドバス)は所謂通信プロトコルの一種である。
すでに十分枯れた 歴史のある通信プロトコルであるし、ちょっとググると沢山引っかかるので、詳細の解説は他の方にお任せするとして、本ブログではより実践的にシーケンサを使用してFAのフィールドネットワークに寄せる方向で実験を行いたいと思う。1)
実験に使用するシーケンサはキーエンス社のKV-Nanoシリーズを予定している。
このモデルはオプションの増設シリアル通信カセット(形:KV-N11L)で、RS422,RS485(4線式)、RS485(2線式)が増設出来、しかもMODBUS マスター/スレーブプロトコルがいずれも標準で実装されていて、設定以外ユーザーはほぼ何もしなくていいという超お手軽仕様。
これに市販のMODBUS対応デバイスをぶら下げればあっという間に通信網の完成である。
で、あるが、このブログ的にはMODBUS通信が実際どのように成り立っているかを知ることが目的なので、あえて遠回りをして、CPUユニット内蔵RS232Cポートを経由したMODBUS通信でArduino等をリモート制御することをゴールにしたい。
まずはハードウェアを一歩づつ検証してみよう。
市販のMODBUS対応機器の多くにはRS485半二重(2線式)が採用されている。
うち、5V系で最もポピュラーなのはSN75176(TI)やMAX485(MI)を使ったものではないだろうか。
そこで、MAX485を使って信号の状態をモニタしてみた。
実験に使用した回路。
電線のコネクタ処理の(ただそれだけの)ために、MAX485を一個づつ載せた基盤を2つ(も)作成。
電源はセルフパワーUSB HUBからの5Vを取り、MAX485×2個を同一の電源から取得して、USBポートの電流をモニタしつつ、クリスタルオシレーターからTTL信号を入力する。
通信の配線には仕事で手配ミスやらかしてデッドストックになってしまっていた ミスミの形:SS300SB-22-2P-50 AWG22,2Pツイストシールド,50mを使用した。
発信源のモニタをCH1で行いつつ、レシーバー側でRS485の信号レベルとROを確認する。
実験に使用したMAX485(HTC)のデータシートからICの周波数上限は5Mbpsとのことだが、製造元によっては2.5Mbpsとの記述もあるので、まずはそこから。
こういう時に周波数の切替がスイッチ一発で出来るオシレータは便利じゃのう。
左が485の差動信号のモニタ、右がTTL出力(RO)。
ケーブルのリアクタンスとキャパシタンスの影響を受けて波形が随分と鈍ってしまっているが、一応EIAの仕様を満たしているし、まぁまぁいい感じ。
次に5Mbps。
2.5Mbpsの時よりさらに485の波形が鈍ってしまっている。
が、なんとか伝わっているようで、TTLの出力は出ている。
おまけで10Mbps。
485の波が更に減衰。なおかつ、レシーバーが信号を拾えていないのでTTL出力はフラットなままだ。
ケーブル長を10cmにした結果。
ケーブルのキャパに食われる分が減って電圧は上昇し、波形も改善している。
レシーバも何とかそれを拾ってる状態ではあるのだけれど、今度はICの出力側が追いついてない。
ICの生の入出力ではやはり5Mbpsが限界のようだ。
続いて、終端抵抗の影響を調べてみた。2)
入力を2.5Mbpsに戻して50mケーブルの送信側の終端抵抗のみ外した結果。
送信側の抵抗に食われていた電圧が乗って、若干電圧が上がっているものの、両端に終端抵抗がある場合に比べてほぼ変化がないことが解る。
同じく、受信側の終端抵抗のみ外してみた結果。
反射波が重畳して尖った波形になった。
P-Pの電圧が2倍近くに上っていることが解る。
終端抵抗を両方外してみた結果。
さらに電圧が上がってP-Pが11Vに!
慣性電流恐るべし。
ケーブルのリアクタンスやキャパシタンス次第ではICの絶対定格を超えて破壊してしまう可能性もあるので、絶対にこういった運用は避けるべし。
視点を変えて、市販のRS485デバイスを10cmの配線で5連にして測定した。
この変換器はサージ対策回路としてすべてのデバイスに120Ωの抵抗とA/B相にプルアップ/プルダウンがされている。
こんなかんじで。
(リバースエンジニアリングしましたが、発表は自粛します)
結果、5連にするとA/B間の抵抗は120/5=24Ωと低くなる。
あんまり沢山のノードをぶら下げると、信号レベルが下がりすぎて±0.2Vを割り込んでしまうだろうけど、プルアップ・ダウンが結構いい感じに効いていて、生ICの状態より485の波形が安定している。
このデバイスはTTLのほうにもプルアップとパスコンが仕込んであり、リプルが乗ってるのはその影響かと。
この後、入力を10Mbpsに上げても目立った乱れは見られなかった。
実験中の模様。
消費電流はこの状態でオシレータ込で0.18Aといったところ。
これなら、シーケンサに繋いでも壊れることは無いだろう。
つづく。
最初からこれ買ってれば余計な基盤を作らずに済んだのかも。
だが後悔はしていない。
続きを読む
実験に使用するシーケンサはキーエンス社のKV-Nanoシリーズを予定している。
このモデルはオプションの増設シリアル通信カセット(形:KV-N11L)で、RS422,RS485(4線式)、RS485(2線式)が増設出来、しかもMODBUS マスター/スレーブプロトコルがいずれも標準で実装されていて、設定以外ユーザーはほぼ何もしなくていいという超お手軽仕様。
これに市販のMODBUS対応デバイスをぶら下げればあっという間に通信網の完成である。
で、あるが、このブログ的にはMODBUS通信が実際どのように成り立っているかを知ることが目的なので、あえて遠回りをして、CPUユニット内蔵RS232Cポートを経由したMODBUS通信でArduino等をリモート制御することをゴールにしたい。
まずはハードウェアを一歩づつ検証してみよう。
市販のMODBUS対応機器の多くにはRS485半二重(2線式)が採用されている。
うち、5V系で最もポピュラーなのはSN75176(TI)やMAX485(MI)を使ったものではないだろうか。
そこで、MAX485を使って信号の状態をモニタしてみた。
実験に使用した回路。
電線のコネクタ処理の(ただそれだけの)ために、MAX485を一個づつ載せた基盤を2つ(も)作成。
電源はセルフパワーUSB HUBからの5Vを取り、MAX485×2個を同一の電源から取得して、USBポートの電流をモニタしつつ、クリスタルオシレーターからTTL信号を入力する。
通信の配線には
発信源のモニタをCH1で行いつつ、レシーバー側でRS485の信号レベルとROを確認する。
実験に使用したMAX485(HTC)のデータシートからICの周波数上限は5Mbpsとのことだが、製造元によっては2.5Mbpsとの記述もあるので、まずはそこから。
こういう時に周波数の切替がスイッチ一発で出来るオシレータは便利じゃのう。
左が485の差動信号のモニタ、右がTTL出力(RO)。
ケーブルのリアクタンスとキャパシタンスの影響を受けて波形が随分と鈍ってしまっているが、一応EIAの仕様を満たしているし、まぁまぁいい感じ。
次に5Mbps。
2.5Mbpsの時よりさらに485の波形が鈍ってしまっている。
が、なんとか伝わっているようで、TTLの出力は出ている。
おまけで10Mbps。
485の波が更に減衰。なおかつ、レシーバーが信号を拾えていないのでTTL出力はフラットなままだ。
ケーブル長を10cmにした結果。
ケーブルのキャパに食われる分が減って電圧は上昇し、波形も改善している。
レシーバも何とかそれを拾ってる状態ではあるのだけれど、今度はICの出力側が追いついてない。
ICの生の入出力ではやはり5Mbpsが限界のようだ。
続いて、終端抵抗の影響を調べてみた。2)
入力を2.5Mbpsに戻して50mケーブルの送信側の終端抵抗のみ外した結果。
送信側の抵抗に食われていた電圧が乗って、若干電圧が上がっているものの、両端に終端抵抗がある場合に比べてほぼ変化がないことが解る。
同じく、受信側の終端抵抗のみ外してみた結果。
反射波が重畳して尖った波形になった。
P-Pの電圧が2倍近くに上っていることが解る。
終端抵抗を両方外してみた結果。
さらに電圧が上がってP-Pが11Vに!
慣性電流恐るべし。
ケーブルのリアクタンスやキャパシタンス次第ではICの絶対定格を超えて破壊してしまう可能性もあるので、絶対にこういった運用は避けるべし。
視点を変えて、市販のRS485デバイスを10cmの配線で5連にして測定した。
この変換器はサージ対策回路としてすべてのデバイスに120Ωの抵抗とA/B相にプルアップ/プルダウンがされている。
こんなかんじで。
(リバースエンジニアリングしましたが、発表は自粛します)
結果、5連にするとA/B間の抵抗は120/5=24Ωと低くなる。
あんまり沢山のノードをぶら下げると、信号レベルが下がりすぎて±0.2Vを割り込んでしまうだろうけど、プルアップ・ダウンが結構いい感じに効いていて、生ICの状態より485の波形が安定している。
このデバイスはTTLのほうにもプルアップとパスコンが仕込んであり、リプルが乗ってるのはその影響かと。
この後、入力を10Mbpsに上げても目立った乱れは見られなかった。
実験中の模様。
消費電流はこの状態でオシレータ込で0.18Aといったところ。
これなら、シーケンサに繋いでも壊れることは無いだろう。
つづく。
最初からこれ買ってれば余計な基盤を作らずに済んだのかも。
だが後悔はしていない。
続きを読む