kitam

A moderate Sysmac Studio user.
レイモンド・M・スマリヤンを好む。
『記号論理学: 一般化と記号化』が平易なのでおススメ。

[kitam @kmu2030]

IEC61131-3の正確な資料が手元に無いのが何とも。
STのASTのS式出力を得られるようになれば、私が傍観者ではなくなるかもしれない。

[kitam @kmu2030]

@ilwli 変数の型は明らかで、s式のastがあるならWasm化はBinaryenとか。挙動も追いやすいかも。
https://t.co/Z9KcocUnIa
https://t.co/vYyvXgUtOU

外挿する関数を定義できるので、JSを経るコードとも同じ状態に持っていけます。
初期BASICをWasm化する例として以下のようなものも。
https://t.co/Ux3wnQYNTL

[kitam @kmu2030]

Sysmac Studioの構造体アライメント調整をKSで表現するとこれだけ。
seq:
- type: align(x)
# fields with align.
- type: align(x)
types:
align:
params:
- id: n
type: u1
seq:
- type: u1
repeat: expr
repeat-expr: (n - (_io.pos % n)) % n

[kitam @kmu2030]

@ilwli アプローチと課題は色々だと思いますが、原コードのスコープが再現されていれば、まずは振る舞いとして同じになるかと。STの型システム的な側面を使用したコードは少数でしょう。
JSを経るのは、Wasmランタイム外から機能を注入しやすいというのもあります。
Wasmだけでは私もさっぱり分かりません。

[kitam @kmu2030]

@ilwli もし素朴なJSトランスパイラがあれば、ESP-IDFのWasmランタイムとM5のようなデバイスでIOもどきを備えたPLCっぽい何かに化かして実際に動かしてしまうとか多分できるかと。
私がやってみたいだけですが、かなり遠くまで行ける気がします。

[kitam @kmu2030]

@ilwli データ交換であれば、静的コード生成を活用しているのでFlatBuffersを使うというのもありかもしれません。
vtable参照、リトルエンディアン、IEEE-754なので構造体変換のフットプリントが小さいと思います。
IecGeneratorがそれのコード生成コードのように見える。
ProtocolBuffersならSparkplugに。

[kitam @kmu2030]

@ilwli 素晴らしい。その通りです。KSのビット処理ではビットストリームのポジション調整のために特別にパックしてやる必要があります。そして、以下が諸々を反映させた玩具です。

https://t.co/ytNOKgVIip

[kitam @kmu2030]

タマムシ。
私が生息する地域はのどかとは言い難いが、生息数か接点が増えたかで出会う頻度が増している。
状態が良いので軟化に問題が無ければ展足。触角が脆い。
採集地、採集日、採集者を記したラベルを残しておくと意味のあるデータになる。
おまけでRFIDタグ。

[kitam @kmu2030]

軽く定義セットを作るつもりがそこそこになった。
NX/NJの構造体アライメントの説明がイマイチ分からんという状況でも、それっぽく定義するだけで読み書きできる。
共用体も共用体のように参照できる。
任意の定義を表現可能なので、全てのバイナリを扱える。
もう少しテストしたら出す。

[kitam @kmu2030]

Sysmac StudioのNJメモリレイアウトの構造体と共用体バイナリを読む疑似DSLをKaitai Structで構築する。
C言語のアライメントに類似なので、満足な見た目の表現とはならないけれど読み出せる。
受信側はパーサを生成できるので、構造体をそのまま投げられる。
SDに保存したバイナリも読める。

[kitam @kmu2030]

どうしたものか。JSONを扱いたい人がいることは知っていたが、人ならざるものが広まってから参照が増えたような。
必要なのにベンダーの提供が無いから探しているのだろうに。
パースは気を付けたけれど、格納と参照が力技でメモリ食いなのでやたらには使えないが、やたらに使う理由は無いはず。

[kitam @kmu2030]

「奇跡的なプロトコルの合致」、「ガラパゴス不条理システム」、「儀式によるシステムの安定化」という文言を不意に提示されコーヒーをぶちまける。
その様相を苦労なく想像できた瞬間の不意打ちに耐えられなかった。

[kitam @kmu2030]

難しいとのことなので。
スイッチと手動要素だけの装置改修に付加価値を追加するとか。
電装品置換はそこそこのシステムとし、耐環境I/O配置でバスを整備、手動要素を計測する。
整備良否の評価、手動調整支援をする動的マニュアルとしてのローカル用モデル。
使い込むほど慣れを不要にできるかも。

[kitam @kmu2030]

始めから全てのデータを使う必要もなければ、難しいことを目指す必要もない。
データの一部で仮想センサもどきや、複合不調をそこそこの確率で予測するとか。
振る舞いの探索と理解を目的にわいわいするなら、言い合いよりまとも。
必要なのは自分の頭と高性能なLLMサービスのアカウント、そして端末。

[kitam @kmu2030]

装置の振る舞いやオペレーションを観測して知見を得ることが目的であれば、よくある稼働データやアラート収集では効果が見込めないかもしれない。
振る舞いを再現できる解像度でないと。
もう少し未来、そこそこのモデルのローカル運用が普通となった時、それが蓄積されていないと厳しいかもしれない。

[kitam @kmu2030]

NXから極高頻度に大部分の値をサイクルに対する一貫性を担保してパック、UDPで飛ばして集めると買い物をしなくても事後的にも価値のある、大量の時系列データが手に入る。
そして、そうでもない端末で訓練が可能なそうでもない何かを作るとたぶん何かが起こる。運転操作プロファイリングとか色々。

[kitam @kmu2030]

パーソナライズするのは気にしないが、しばしば偏執的な仕様マニア、変態（いい意味で）と形容される。
かなり前からなので気にしていなかったが、こんなものなのだろうか。

[kitam @kmu2030]

Unit ChainBusの回路図と内容を確認してて、何故か数年前のEtherCAT障害の原因切り分けの追加検証を思いつく。その結果があっても対処が変わらないのは良いが、虫の知らせとかは嫌。