バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
CANapeで自作MDFの読み込み確認中
前回はtabular with rangeの物理変換をCANapeで確認した。
残りは文字列変換タイプだが、CANapeのグラフィックウィンドウで文字列表示させるにはある程度設定が必要。
そこらへんの設定方法を解説した。
今回はその文字列表示の方法も利用して文字列変換タイプの物理変換の確認を行う。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
value to text
じゃー今回は前回の文字列表示方法を生かして
t10ms_value_to_textを表示してみよう。
特定の値を特定の文字列に変換するタイプの物理変換だったはず。
その通り。
早速見てみよう。
あれ？
AsamMdf付属Viewerで確認した時って、
特定数値だけ文字列変換されて、それ以外はdefault Keyになった気がしたんだけど？
ここでやったと思うけど？
まぁここらへんはViewer依存なところが強いからねー。
tabular with interpolationなんかも自動で範囲判定をしていたと思うけど、
value to textもViewerによって自動判定をするタイプ、しないタイプに分かれるのかもしれない。
AsamMdf付属Viewerは自動判定しない。
CANapeは自動判定する。
みたいな感じ。
MDF仕様的にどうなってる？
表現の話だから違ってくるのはわかるけど、
MDF仕様としては決まってないの？
決まってないな。
MDF仕様はあくまでファイルフォーマット仕様であって、
それをどう表現するかまでは指定してない。
なるほど・・・。
ここらへんにASAM仕様の緩い標準化の性質が出てくるのか・・・。
といってもそれほど使うタイプの物理変換ではないから、
誰も困ってないってのが実状なんだろうね。
Viewerの仕様を考える人は大変だろうけど、
ユーザサイドとしては割とどうでも良かったりはするね。
確かにViewerを設計する人はこの仕様の緩さには苦しめされそうだ。
しかもユーザに聞いても、
使ってない機能だから答えが出ない。
最終的には決めの問題だから誰かが決めれば良いだろうけど、
その決める人も決定根拠がないから決められないだろうね。
欧州文化の推測
この手の問題って、
ASAM本国のドイツとかどうしてるんだろう？
推測になるけど、
仕様スタートじゃなくて、
できてるツールスタートなんだと思う。
ツールスタート？
すでに動いている物が正しい。
なんかアカンやつやーー！！
これは仕方ないと思うよ。
存在する似たような機能やフォーマットをASAMとして標準化させたわけだから。
標準化されたものが先に存在するわけじゃないんだよね。
なんとなく状況はわかったかも。
というわけで、仕様が完全に固まっているとは思わずに、
基本的な使い方だけでおおよそのことをやって、
どうしても特殊な仕様を使いたい場合は、ダメ元で使う。
程度の認識が良いと思うよ。
そうね。
特殊なのはダメ元って発想は大事そうだね。
まとめ
まとめだよ。
- value to textの物理変換をCANapeで確認。
- value to textの表現がAsamMdf付属Viewerと異なることが発覚。
- MDF仕様としてはファイルフォーマットの規定だけなので表現方法の標準仕様は存在しない。
- 欧州ではツールが先に存在し、それらの共通項をASAM仕様にまとめただけと推測される。
バックナンバーはこちら。
コメント