記事の前の部分では、システム設計を開始する段階を検討しました。さて、最終的にどのようなデバイスが出てきたのかをお話ししたいと思います。
パート1
パート2
最初のパートの議論では、電圧と電流の測定の問題が提起されました。そこで、もっと詳しく説明することにしました。前に書いたように、私たちの回路の電圧と電流のセンサーは変圧器です。ミニチュアトランシックBV201 0145を使用して電圧を測定し、AC-1020電流センサーの場合：
電圧はそれらから除去され、マイクロコンピューターに組み込まれたADCによってデジタル化されます。アナログ部分を以下に示します。
電流センサーは抵抗R3の両端にロードされます。 ZenerダイオードVD3は、短い電流サージによって引き起こされる突然の電圧サージから保護します。抵抗R2、R4は1.8V付近に「ゼロ点」を設定します。変圧器についても同じことが言えます。この場合の変圧器は12Vの公称電圧を生成するため、抵抗R8とR10には分周器だけがあります。
1000Hzの周波数で200msのデジタル化を行います。得られた値に基づいて、RMSを計算します。割り込みで2乗された値の簡単な計算を行います。メインプログラムループに200個のサンプルが蓄積された後、浮動小数点数を使用して最終計算が実行されます。
RMSを測定する必要がある理由とその最善の方法については、この記事で詳しく説明しています。
私はすでに何度も書いていますが、デバイスを開発するときは、常に最も一般的な電子コンポーネントを最大限に活用して、一方ではコストを削減し、他方ではシリーズの生産中にそれらの供給に問題がないようにしています。この設計では、使用されるすべての抵抗の許容誤差は5％です。当然、このような誤差のため、製造後の製品は電圧と電流を測定する際に大きな誤差がありました。このエラーは、自動キャリブレーションベンチで解消されました。もちろん、「スタンド」は少しうるさく聞こえますが、本来の機能を果たします。スタンドは次のコンポーネントで構成されています。
- 500Wハロゲンランプ3個セット
- 上記の電流センサー
- 電気メーターEnergomeraCE102M
- USB-RS-485コンバーター
- サーキットブレーカー
ネットワーク電圧と負荷電流の例示的なメーターとしてメーターを使用します。 CE102Mモデルは、最初にUSB-RS-485コンバーター（メーター内に独自の電力コンバーターがあります）に2本のワイヤーで接続され、次にデータを読み取るためにシリアル番号を入力する必要がないため、非常に便利です。些細なことのように思えますが、カウンターを使用するのに便利です。
交換プロトコルは、製造元のマニュアルに詳しく説明されています。したがって、ソフトウェアの実装に問題はありませんでした。
ちなみに、カウンターに別の小さな記事を書くことができます。かつて私は彼らと緊密に協力しました。その結果、一部のデバイスは、Incotex-SK「Mercury206」、Energomer「CE102」、Energomer「CE102M」、IEK「STAR104 / 1」の4つの人気モデルをサポートしています。
スタンドの概観は次のようになりました。
自動化のために、メーターからデータを読み取り、コントローラーの内蔵リレーを制御し、電流メーターと電圧メーターの係数を自動的に選択する簡単なプログラムが開発されました。
通常、デバイスのシリアル番号にはバーコードを使用します。バーコードスキャナーを使用して入力すると非常に便利です。
ただし、この場合、デバイスが注文され、顧客はフロントパネルに多数の形式でシリアルを実行するように要求しました。
キャリブレーションプログラムは、すべてのデータを内部システムに保存します。誰が、いつ何をチェックしたか、および対応するパラメーターのリストを記録します。最も重要なものはシリアル番号とMACアドレスです。
ちなみに、MACアドレスについて。 Microchip社から24AA025E48-I / SNチップとして購入しています。まとめて購入すると、安価で非常に使いやすくなります。 MACアドレスはI2Cインターフェースを介して読み取られます。
次に、サーバーとの接続について説明します。開発の初期には、すでに主な機能がありました。これは、ASP.netで記述された単純なWebサービスであり、ハードウェアと通信するための別個のサーバープログラムです。各コントローラーは、1分に1回、UDPプロトコルを介して情報パケットを送信します。サーバーソフトウェアはそれを解析し、データをデータベースに保存し（「デシメーション」を使用して、最大1時間に1回）、さらにパケットの送信元の外部IPアドレスとポートを記憶します。これは、サーバーからコントローラーを制御するために必要です。
実際、デバイスの100％はNATの背後に配置されているため、いくつかの特性を考慮する必要があります。主なものは、一部のNATには、クライアントに外部ポートを割り当てるための小さなタイムアウトがあります（1分未満）。統計によると、その割合はそれほど大きくありませんが、いずれにせよ、専用ポートを「維持」するために、コントローラーからサーバーに監視データを送信する間隔を短くする必要があります。
もちろん、デバイスには両方のプロトコルが実装されていますが、TCP接続ではなくUDPを使用する理由をすぐに説明します。 UDPの選択は、コントローラーとサーバーの両方からの使いやすさと低い計算コストによってのみ正当化されます。はい、データパケットの配信を保証するものではありませんが、UDP上で実行される上位層プロトコルによってこれが簡単に実装されることを理解する必要があります。さらに、監視データを送信する場合、特にデータベースに保存するときに1時間に1回だけデータを「間引いて」保存することを考えると、1日あたり数パケットの損失はまったく重要ではありません。ただし、手動モードでリレーのオン/オフを切り替えるなど、コントローラーをリモート制御すると、「要求応答」システムが機能し、コマンドの送信が数回試行されます。
さらに、サーバーを介して、コントローラーの「ファームウェア」のリモート更新を実装しました。また、UDPでも機能します。確かに、更新は半自動モードで機能します。それでも、エンドユーザーの作業に問題が発生する可能性があるため、任意の時点でマシンで実行することは適切ではありません。昼間、イーサネットリレーが負荷を切断して再起動した場合、彼らがどれほど驚いたか想像してみてください:-)
結論として、過去2年間で、このようなデバイスは約1,000台製造されました。それらはすべてオンラインです。他の約2,000台のコントローラーも常にサーバーと通信しています。一般的に、すべてが非常に着実に機能します。もちろん、私たちは常に機能を拡張しています。たとえば、最近、暴徒をリリースしました。インターネットを介してデバイスをリモート制御するためのアプリケーション。しかし、次回はいつか彼について書いてください...