バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はPyXCPによるDAQ起動を実施。
(SET_DAQ_LIST_MODE、START_STOP_DAQ_LIST、START_STOP_SYNCHのコマンドを投げた。)
CAN回線上にDAQパケットが流れていたのでDAQ起動は成功した。
しかし、CAN回線モニタしてDAQパケットが分かっただけであり、
PyXCP経由で取得ものではない。
DAQパケットの取得は、いままでのコマンド形式の手法とは異なるようで、
そこらへんの話をしていく。
登場人物
博識フクロウのフクさん
イラスト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
DAQパケットの取得方法概要
DAQ起動はできたけど、PyXCP経由でのDAQパケット取得手段がわかってない状態だったねー。
そうだね。
取得方法は今までのやり方は雰囲気が変わるね。
仕組みが違うってこと？
うん。
コマンドは投げれば何かしらレスポンスが有る想定のメソッドだったが、
DAQパケットはXCPスレーブ側から能動的に送信されてくる。
よって、Python側で何もしていなくても受信できなければならない。
まぁそうだよね。
Python側で別の処理しててもDAQパケットは送出され続けられるわけだし。
というわけで、PyXCPでは内部でdaqQueueというQueueにDAQパケットを貯め続ける仕組みが組み込まれている。
これにより、DAQパケットを常に受けつけられる状態を作ってる。
ほー。
ということはPython側で多少読み出しができない期間があっても、
そのdaqQueueが貯めておいてくれるから、取りこぼししないってことか。
そうだね。
まぁdaqQueueが無くてもCANインターフェース等がバッファリングしてたりするんで、
PyXCPでバッファリングしなくても辻褄合うことは多いだろうが、
それでも早々にPyXCP側で貯め込んでおいた方が良いのだろうね。
DAQパケット取得の具体的なコード
なんとなく仕組みっぽいのはわかってきたから、
そろそろ具体的なコードを希望。
こんな感じだな。
ちなみに0.2秒後に抜けてくるwhileループになってる。
import time
start = time.time()
while True:
queue_len = len(xm.transport.daqQueue)
for _ in range(queue_len):
daq = xm.transport.daqQueue.popleft()
print( '%.6f, %s' % ( daq[3],daq[0].hex() ) )
if time.time() > start + 0.2:
break結果
1637554273.380365, 007b0d00000000
1637554273.390367, 00df0d00000000
1637554273.400484, 00430e00000000
1637554273.410388, 00a70e00000000
1637554273.420251, 000a0f00000000
1637554273.430279, 006e0f00000000
1637554273.441190, 00db0f00000000
1637554273.451152, 003f1000000000
1637554273.461138, 00a31000000000
1637554273.471091, 00061100000000
1637554273.481069, 006a1100000000
1637554273.491047, 00ce1100000000
1637554273.501016, 00311200000000
1637554273.510994, 00951200000000
1637554273.520964, 00f91200000000
1637554273.530966, 005d1300000000
1637554273.540911, 00c01300000000
1637554273.550922, 00241400000000
1637554273.560900, 00881400000000
1637554273.570861, 00ec1400000000
1637554273.580823, 004f1500000000
1637554273.590817, 00b31500000000
1637554273.600787, 00171600000000結果解説
xm.transportにさっき言ってたdaqQueueが定義されてるのね。
そして、len(xm.transport.daqQueue)で現在の格納されてるDAQパケット数を特定して、
そのパケット数分をxm.transport.daqQueue.popleft()で一気に引き抜いてるわけか。
そうだね。
これはJSON記述のコンフィグレーションパラメータにある、
CAN_USE_DEFAULT_LISTENERをtrueに設定していると使える機能だ。
あの時のパラメータがここで効いてくるのか。
JSONのコンフィグレーションはここらへんでやったね。
まとめ
まとめだよ。
- DAQパケットの取得方法の概要説明。
- transport層に相当するクラスでdaqQueueが定義されている。
- このdaqQueueに自動的にDAQパケットがキューイングされる仕組み。
- 上記仕組みはJSONコンフィグレーションのCAN_USE_DEFAULT_LISTENER
- trueでないと使えない点に注意。
バックナンバーはこちら。
コメント