左右上下方向の検索処理シーケンスの目途が立ったので、全面検索とリバース処理を実行させます。
全面の検査とリバース処理
やりたいことが明確になってきたので、やることに変更しました。
手探り状態の部分もあり、設計書→コーディングをめざしていましたが、プログラムデバッグしながらとなりそうです。
今回は、全面の検査とリバース処理をします。
リバース処理は方向検索処理の中で実行し、その作業を検索作業とリバース作業と分けます。
リバース実行は、手動(人が実行)の場合のほかに、PLC(自動演算)が実行することを想定します。
そこでまずは、手動でのリバース処理の確認。
全盤面を連続して検索し、石を置けるかどうか何個リバースできるかカウントした結果をM6000-とD6000-に記録します。
リバース処理
方向検索処理の回路を流用してリバースフラグを立てて、実行するようにしましたが、この回路だめでした。
リバース処理を実行すると次のステップで色が一緒と判別してそこで処理が停止します。
そこで、結果的にリバースは専用で処理を実行するように変更しました。
1個ずつ処理をしましたが、デバッグでは、修正が発生すると8方向処理全部変更となるので、CALL分にFD要素をつけて処理部分はまとまるようにしました。
CALL P211 FD0 FD1 ・・となるので、右処理はFD0=+1 左の処理はFD0=-1としてリバース処理を実行することで集約しました。
処理のイメージは下記の通りです。(方向検索処理でのイメージですがリバース処理も同様です)
全盤面の検査処理
全盤面を検査するのに、処理を簡素化するようにとSET、RSTの連続処理+CALL方向検索をしましたが、何度やってもうまくいきません。
同じスキャンでコールして演算結果から判断して、M6000-に判定結果 D6000-にリバース個数を記録することがうまくいかないようです。
そこでステッパーの出番です。処理のフロー図です。
ラダーでの処理は、下記のようになります。
ここでのポイントは、ENCO命令となります。
この命令処理でステップラダーの記述が数段楽になり、また、確実に1スキャン回るので、誤動作がないです。
デメリット(メリット?)は、シミュレーターの場合100msec固定のスキャンタイムなので、この処理の場合かなり時間がかかります。
まとめ
今回は、だいぶ説明が進みましたがお伝えできているか不安ですね。
次回は、先に進む前に今回分で不具合がたくさんでたので、デバッグ機能を紹介します。
コメント