Sysmac Studio

タスク設定でプログラムの初期状態を変更し、リビルドしてもシミュレータに反映されないことがある。強制的な変更を発生(周期を変える等)させ、リビルドして反映されるか試す。
Sysmac Studioを再起動する。
タスクマネージャでシミュレータだけ落とすのはやめたほうがよい。

kitam

STのインデントがガタガタ。デフォルトフォントではなく、等幅フォントを使用する。
ツール>オプション>STエディタ>フォント設定

kitam

MemCopyのInにコンスタント属性の変数を渡せない。

マニュアルの不備かどうかは知らないが、入出力らしい。内容からして入出力である方が妥当だから、それならそれでいい。諦めてAryMoveを使う。

kitam

可変長配列を読み取り専用と宣言する。

コンスタント属性を有効にする。ただし、POU内でMemCopyは使えない。

kitam

StringMD5以外のハッシュ関数が欲しいオーソドックスなのは以下にある。OpenSSLのようなInit-Update-Finalではない。そのようなバージョンもあったほうが良いのは分かる。
SHA-1https://github.com/kmu2030/SHA1Lib
SHA-2https://github.com/kmu2030/SHA2Lib
SHA-3https://github.com/kmu2030/SHA3Lib
MD5https://github.com/kmu2030/MD5Lib

kitam

シミュレータで乱数生成器がリセットしない

Randのヘルプに"電源をONするたびに"とあるように、シミュレータをOFFする必要がある。そして、その安全な方法はSysmac Studioの再起動しかない。

kitam

UUIDが欲しいバージョン7ならある。乱数生成器は、今のところ組み込みのRand命令なので不安ではある。それを留意した用途であれば使える。rand_aはPLCらしくマイクロ秒を使えるようにしてある。

https://github.com/kmu2030/UUIDv7Lib
バージョン4もあった。乱数生成器は、同じく組み込みのRand命令なので、それを留意した用途であれば使える。

https://github.com/kmu2030/UUIDv4Lib

kitam

ULIDが欲しい乱数生成器は、今のところ組み込みのRand命令なので、それを留意して使用するなら。
https://github.com/kmu2030/ULIDLib

kitam

BOOL型の基本サイズは2 byteだけれど配列にするとメモリを上手く使ってくれる。BOOL型配列は、I/Oマップの変数割り当てに使うと具合がよい。I/Oのビットに、個別に変数を割り当てると煩雑になるが、BOOL型配列を割り当てておくとまとまる。これは、同社のモジュールに限らない。例えば、IO-Linkマスタを使用していてもDI/DOだけの使用であれば、あるビット値だけが必要なので同じように使える。

kitam

65kB以上の連続したメモリ領域を確保する配列の要素数は、65535個までという制約があるので、単一のBYTE型配列では約65kBの領域しか確保できない。また、多次元配列は、要素へのアクセス手段を提供するだけなので領域を広げる手段としては使えない。しかし、65kB以上のメモリ領域確保にはいくつかの手段がある。
任意長のBYTE型配列だけがメンバーの構造体を定義し、その構造体の配列を定義する
BYTE型より大きいビット列型(WORD、DWORD、LWORD)の配列を定義し、BYTE列として操作するための共用体を定義する。
どちらも向き不向きがあり、用途に合わせて選択する必要がある。

kitam

予期せぬエラー(b0100400)

何らかのライブラリを使用していて、このエラーに出くわしたらライブラリ内の何かとプロジェクト内の何かの名前衝突が生じている可能性が高い。Sysmac Studioの識別子の扱いはかなり厄介で、何らかの識別子である文字列は、全て単一のテーブルで管理していると考えておくとよい。例えば、名前空間のある階層で使用した文字列は、FUNの引数名に使用すると衝突するという具合。ひょっとすると、このコンテクストお構いなしな仕様は、IEC内にあるのかもしれない。

kitam

立ち上げてもウィンドウが表示されないそれは、ウィンドウがあらぬ位置にあるからかもしれない。OSの表示スケール設定を100%より大きくしている場合、画面外のあらぬ位置で立ち上がることがある。その疑いがある場合、次のように確認する。
タスクマネージャーを立ち上げ、Sysmac Studioのプロセスがあることを確認
OSの表示スケール設定を100%にしてウィンドウの有無を確認
そもそもプロセスが無いようであれば、何らかの障害が発生している。その場合、OSのログを確認して対処する。ウィンドウが頻繁に行方不明になるようであれば、PowerShellを使った起動スクリプトを準備するのが良いかもしれない。他のことも含め、もう少し安定したものにして欲しいが、どことなく不吉な臭いを感じる。

kitam

任意の名前空間とルートに同名の型があるとき、誤って指定するとメッセージとして"式の構文エラー"が出力される

"式の構文エラー"を便利に使い過ぎな気がする。メッセージは通知の為だけではなく、それをもって適切なアクションに繋がるものであって欲しい。紛らわしいので型が違うというメッセージにして欲しい。

kitam

メモリ使用状況を確認するとクラッシュする最悪の事態を考える必要がある。プロジェクトファイルの致命的な破損により回復不能になっている可能性がある。諦めて問題が無かった時点から始めるのがよい。破損したファイルからの破損しているかもしれない要素のコピーはコピー先のプロジェクトを破損させるので行わないほうがよい。以下が教訓。
定期的にリビルドをかけてメモリ使用状況に異常がないか確認する
自動ビルドを無効にしておく
名前空間の大規模な変更は本質的に危険である
OSのApplicationログを確認すれば、.NET Runtimeのエラーを確認できるのでその内容にガッカリするはず。名前空間が問題含みであるのは分かっていたのに迂闊だった。

kitam

名前空間持ちPOU内で同一名前空間のPOUを使用する場合も名前空間を含めて指定する

名前空間はもう少し仕事をして欲しい。名前空間持ちのFUNを、同一名前空間のPOU内で名前空間を指定しないで使用し、ルート名前空間に同一名称のPOUがあると参照を解決できずビルドに失敗する。ライブラリでこれが発生するとライブラリの修正が必要になる。FBはインスタンス化で必然的に名前空間を含むので生じることはない。ライブラリ内のFUNは、必ず名前空間を指定して実行する必要がある。

iLockKey := Context.LockKey;
iHead := Head;
Lock(iLockKey);
    Size := MIN(Context.Size, TO_UINT(SizeOfAry(Out) - Head));
    // 完全限定名で実行する.
    \\stfreakjp\logging\RingMemCopy(In:=Context.Buffer,
                                    Out:=Out,
                                    InHead:=Context.Tail,
                                    OutHead:=iHead,
                                    Size:=Size);
    Context.Size := Context.Size - Size;
Unlock(iLockKey);

kitam

シミュレータがブレークポイントで停止しないPOU/プログラムの一部を変更し、リビルドしても解消しないならプロジェクトが破損している可能性がある。ライブラリ参照を更新したら壊れたらしい。クリーンビルドの手段は無いのだろうか。諦めて問題の無かったコミットから開始する。ライブラリ操作は、プロジェクトが破損する可能性があるので、必ずコミットを分ける。
ライブラリ参照の更新
ライブラリ設定の変更

kitam

ループ内で実行するFUNが実行されない

FUNの引数としていた値のインデックスが範囲外になっていた。インデックスの異常は、クラッシュもしなければエラーログを残すことも無い。沈黙する。自身の誤りであることは確かなので、容赦なくクラッシュして欲しい。P_PRGERフラグでしのぐしかない。

kitam

シミュレータのブレークポイント設定はPOU定義数が450以内でなければ機能しない (ver.1.62)

マニュアルに記載がないので仕様なのかバグなのか分からないが、ver.1.62ではそうなっている。仮想コントローラがNX1P2扱いなのか、実行時間予測モードで動作させても同じ。POU定義数の上限はNX1が3000、NX5に至っては6000なので改善しないとマズいのではないかな。

kitam

メモリ使用状況の実行モジュールファイル数がPOU定義数かな

たぶん。