「三菱電機PLCでDBアクセス」

パラメータ設定の前に、まずはファームウェアをアップデートしました。
MES IFユニット「RD81MES96N」は、発売開始(2019年10月)してからまだ日が経っておりませんので、重要度の高いファームウェアアップデートが頻繁に行われています。

DBアクセストリガ条件として、「値変化」「定周期」「定刻」等の設定が用意されています。
その中から「値変化」を採用しました。
高速化のため、装置から製造実績を受け取ったタイミングで、ラダープログラムでトリガデバイスをインクリメントし、すぐにMES IFユニットから登録SQLコマンドを発行するようにしました。

図2.  トリガ条件

トリガデバイスの読出しタイミングの設定です。
「高速アクセス(毎スキャン)」「高速アクセス(間隔指定)」「汎用アクセス(間隔指定)」が用意されています。
その中から「高速アクセス(毎スキャン)」を採用しました。
高速化のため、毎スキャントリガデバイスを読出して判定させるようにしました。

図3.  トリガ判定時データ読出し

トリガ条件成立後のDBアクセス処理の設定です。
「挿入(INSERT)」「抽出(SELECT)」「更新(UPDATE)」「削除(DELETE)」「複数挿入(Multi-INSERT)」「複数抽出(Multi-SELECT)」「処理実行(STORED PROCEDURE)」といったDBアクセス処理、および内部タグの演算処理、を最大20個まで登録できます。
当該案件では「挿入(INSERT)」1つのみ登録しました。
DBテーブル管理のため別のアクションを加えることも考えましたが、高速性を重視し、PLCの役割をシンプルにしました。

図4.  メイン処理

※なお、接続先がPostgreSQLの場合、MES IFユニットはストアドプロシージャでのDBアクセスに対応していません。
接続先がOracle、SQL Serverの場合のみ対応しています。

トリガ実行中に、同一トリガが成立した場合、そのトリガ(SQLコマンド)を破棄せずに、MES IFユニット内部メモリにバッファリングする機能です。
「有効」としました。
動作検証で常時500ms周期トリガ成立させたときに、稀にトリガバッファリングすることが確認されたため、有効としました。

図5.  トリガバッファリング

ネットワーク切断やDBサーバーがダウンしたとき、トリガ成立したが送信できないSQLコマンドをSDメモリカードにバッファリングする機能です。
「使用する」と設定しました。

再送方法は「自動で再送する」のチェックを外しました。
動作検証で、プライマリーキー違反が発生するSQLコマンドをバッファリングさせたとき、通信復旧しても自動再送されなかったためです。
そのため、手動(ラダープログラム)で再送リクエストタグをONして再送する方法にしました。

復旧時の動作は「即時送信(バッファリング済みのデータに追加しない)」「バッファリング済みのデータに追加」が用意されており、その中から「即時送信(バッファリング済みのデータに追加しない)」を採用しました。
動作検証で常時500ms周期トリガ成立させたときに、DB登録抜けが発生したためです。
その原因は、以下の青字であると推測しています。
「バッファリング済みのデータに追加」設定では、通信復旧後に成立したトリガ(SQLコマンド)は、(前項で説明した)トリガバッファにバッファリングされ、そのあとトリガバッファからDBバッファに移動される。
500ms周期でトリガ成立だと、『トリガバッファに溜まっていく速度 ＞トリガバッファからDBバッファに移動する速度』となり、トリガバッファがオーバーフローを起こしてSQL文が破棄されてしまったため。

図6.  DBバッファリング