nuritelecom
2020年8月3日 11時00分
Armadillo-IoT ゲートウェイ G3(M1-Dモデル) の絶縁RS485アドオンモジュール RS02を用いてModbus通信を行うプログラムを作成しています。
RS02の設定は、１，２，４をON。
RS-485は、ボーレート９６００、データビット8ビット、ストップビット１、パリティなし。
カーネルのバージョンをv4.9-at15に上げたところ、それまで動いていたプログラム(java)でread_input_registersがCRCエラーを返すようになりました。
そこでArmadillo-400シリーズでModbusの通信をする
https://armadillo.atmark-techno.com/howto/armadillo-400-modbus
を参考にさせていただきlibmodbusを使用したプログラムでも試してみたところ、同様にread_input_registers関数がCRCエラーとなります。
エラーはCRCエラーですが、受信データは送信データと同じように見受けられます。
また、存在しないスレーブに対しても同様にCRCエラーが発生します。
このエラーの発生原因について、ご教示いただけますと幸いです。
[動作していたバージョン]
カーネル:uImage-x1-v4.9-at14
DTB:armadillo_iotg_g3_m1-v4.9-at14.dtb
[動作しなくなったバージョン]
カーネル:uImage-x1-v4.9-at15
DTB:armadillo_iotg_g3_m1-v4.9-at15.dtb
カーネルのバージョンアップはマニュアルの「11.2. 特定のイメージファイルだけを書き換える」に従いuImage,armadillo_iotg_g3_m1.dtbのコピーを行う方法で実施しました。（同様の方法でカーネル、DTBをat14に戻すと正常に動作します。）
[プログラム]
添付の modbus_master.c
「Armadillo-400シリーズでModbusの通信をする」
modbus_master.cのSLAVE_ID、REGISTER_ADDRESS、SERIAL_SPEED等を弊社の環境に合わせて変更したものです。
コンパイル環境
Armadillo-IoT ゲートウェイ G3(プログラム実行マシン)
apt-get install libmodbus-devで以下のライブラリを追加した上でgccでコンパイル
libmodbus-dev/oldstable,now 3.0.6-2 armhf [installed] libmodbus5/oldstable,now 3.0.6-2 armhf [installed,automatic]
[at14で正常動作していた際の実行結果]
root@armadillo:/home/emsjp/work/modbus_master# ./modbus_master /dev/ttymxc1 Opening /dev/ttymxc1 at 9600 bauds (N, 8, 1) [06][04][00][01][00][01][61][BD] Waiting for a confirmation...
<06><04><02><0F><89><70>
Fri Jul 31 14:24:49 2020
Temperature:4030
[at15でエラーになった際の実行結果]
root@armadillo:/home/emsjp/work/modbus_master# sudo ./modbus_master
/dev/ttymxc1
Opening /dev/ttymxc1 at 9600 bauds (N, 8, 1) [06][04][00][01][00][01][61][BD] Waiting for a confirmation...
<06><04><00><01><00>
ERROR CRC received 100 != CRC calculated 9301
faild: Invalid CRC
modbus error
存在しないスレーブ(5)に対して実行した場合でもタイムアウトにならずCRCエラーになります。
./modbus_master /dev/ttymxc1
Opening /dev/ttymxc1 at 9600 bauds (N, 8, 1) [05][04][00][01][00][01][61][8E] Waiting for a confirmation...
<05><04><00><01><00>
ERROR CRC received 100 != CRC calculated 6301
faild: Invalid CRC
modbus error
| ファイル | ファイルの説明 |
|---|---|
| modbus_master.c | Armadillo-400シリーズでModbusの通信をするを使って確認しました。 |
コメント
nuritelecom
nuritelecom
at_keita.mogaki
nuritelecom
at_do.phanngoc
連絡が遅れて、大変申し訳ありません、
本件の不具合の原因は次の通りです。
RS485の半二重通信を行う場合は、RX DMAが常時有効化されています。この状態でRX
FIFOにデータが残ったままRXをdisableからenableに設定すると、次回のRX
DMAに失敗します。
添付したパッチが暫定対策となりますので、ご確認ください。
こちらで確認した限りではmodbus通信で不具合は発生しませんでしたが、恐らく不具合の再現頻度が低下したことによるものです。
今後、恒久対策となるパッチを作成する予定です。
何卒よろしくお願い致します。
https://armadillo.atmark-techno.com/sites/armadillo.atmark-techno.com/f…
| ファイル | ファイルの説明 |
|---|---|
| rs485-at15.patch |
nuritelecom
ご回答ありがとうございます。
「恐らく不具合の再現頻度が低下したことによるもの」とありますので、現状の暫定パッチですと問題が発生する可能性があるということでよろしいでしょうか？
現在、at14を使用し、1分間隔で10台前後の機器に対して、ModbusRTUにてデータ収集を行っています。
上記でも記載しましたCRCエラーの事象後再起動が必要となるケースが1日1回発生している状況です。
at15+パッチによって、事象や頻度が改善されるのであれば適用を検討したいのですが、at14と比較して改善されていると考えてよいでしょうか？次の恒久策を待つべきでしょうか？
また恒久対策に関しまして、今後の提供時期に関してもお知らせいただけると幸いです。
at_do.phanngoc
ドです。
> 現状の暫定パッチですと問題が発生する可能性があるということでよろしいでしょうか？
その通りです。こちらでテストした限りでは問題が発生しませんでしたが、競合状態を完全に除去できていない為、問題が発生する可能性は残ります。
> at14と比較して改善されていると考えてよいでしょうか？次の恒久策を待つべきでしょうか？
少なくとも問題の発生頻度は低下しているので、その点については改善されると考えます。
問題の発生頻度の低下が有益である場合は、パッチの適用をお勧めいたします。
> また恒久対策に関しまして、今後の提供時期に関してもお知らせいただけると幸いです。
現在のところ、今月(2020年10月)末を予定しています。対策に時間がかかり、大変申し訳ございません。
以上です。
nuritelecom
nuritelecom
at_do.phanngoc
ドです。
ご迷惑をおかけし、申し訳ございませんでした。
昨日（2020/10/19）、本問題の恒久対策を施した
Linux カーネル (v4.9-at16) をリリースしました。
Armadillo 製品アップデートのお知らせ (2020年10月/Armadillo-IoT G3L対象)
https://armadillo.atmark-techno.com/news/20201019/software-update-aiotg…
お手数ですが、 at16 にアップデートお願いいたします。
以上です。
at_keita.mogaki
2020年8月3日 15時17分
ご迷惑をおかけして申し訳ありません。
at15 にて RS-485 の不具合に関する対処を行いましたが、
対処内容に不備がありまして、
正常に動作しなくなるパターンが発生しております。
現在原因解析を行っております。
お手数ですが、現状は at14 をご利用頂けますでしょうか？
原因が判明し次第、再度ご連絡致しますので、
何卒よろしくお願い致します。