KiNOKO-DAQ 関連情報 掲示板

このスレッドに記事を投稿する
前のスレッド | 次のスレッド | 掲示版ホーム

割り込み設定のテストにおける現象
2016 年 8 月 23 日 17 時 43 分
投稿者: 戸澤

福井大学の戸澤です。

先日助言していただいたとおり、とりあえずIの振る舞いを無視し、次の割り込み設定のテストに移りました。
LAMを発生させるモジュールとして、豊伸電子製 16ch PH-ADC(C008)を使用し、クレート(東陽テクニカ製 PS-6000)に差しました。
ファンクションジェネレータを用いて1Hz(0〜-700mV)の方形波を発生させ、ADCのGATEに入れました。

% ./lam_test
を実行したところ、ファンクションジェネレータの出力信号をONにしたとき、OFFにしたときのどちらも、約0.5秒ほどの間に
Waiting LAM ...OK.
という表示が16行出てきて、終了します。

私の解釈では、出力信号をOFFにしたとき(LAMを発生していない)、
Waiting LAM ...timed out.
と表示されると思ったのですが、現状の場合、常にLAMが発生しているということでしょうか。(クレートには、使用しているADC、クレートコントローラの他には差していません)

また、使用しているクレートコントローラ(豊伸電子製 C001)には、IのLEDの左隣にDEMと書かれたLEDがあり(過去スレッドによると、いずれかのモジュールがLAMを出しているときに点灯するとありました)、これについて見てみたところ、
DEM消えた状態で出力信号ON → DEM点灯
DEM点灯状態で出力信号OFF → DEM点灯したまま
DEM点灯状態(出力信号ON)で ./lam_test 実行 → 上記の現象(約0.5秒の間にWaiting LAM ...OK.が16行出てくる)の間だけ消え、その後再び点灯
DEM点灯状態(出力信号OFF)で ./lam_test 実行 → 上記の現象が起き(このとき消える)、その後も消えたまま
という結果になりました。

どのようなことが考えられるでしょうか。



2016 年 8 月 27 日 16 時 44 分
投稿者: 榎本三四郎

C008 について詳しく知らないのではっきりとは言えませんが、症状からはドライバとデバイスのやり取りはそれなりにできているけれど、LAM がクリアされていないように見えます。camdrv の方の問題かもしれませんが、もし C008 の機能として LAM をクリアするファンクションがあれば、それを呼ぶコードを lam_test_c に加えたら何か変わるかもしれません。また、若干乱暴ですが、CGENC() を CGENZ() に置き換えて振る舞いを見てみるのもデバッグに役立つと思います。

ファンクションジェネレータからの矩形波信号が長すぎたりしていないでしょうか?



2016 年 8 月 30 日 18 時 0 分
投稿者: 戸澤

C008について、豊伸電子のホームページを見ると、
CAMACファンクションの欄に、F(10)・S2 : LAMクリア
という記載がありましたが(このことでしょうか?)、これを呼ぶコードを lam_test.c に加えるにはどのようにすればよいのでしょうか。詳しくないため、どの場所にどのような記述を追加すればよいか教えていただけると幸いです。

また、C008をクレートから取り出し、クレートコントローラのみ差した状態にして、
% ./lam_test
を実行したのですが、同じように約0.5秒ほどの間に
Waiting LAM ...OK.
という表示が16行出てきました。
さらに、一度PCを再起動して、ドライバをインストールし、今度はクレートの電源を切った状態で実行してみましたが、やはり同じような現象が起こりました。
クレートの電源自体入っていないにもかかわらず、
Waiting LAM ...OK.
と表示されるのはおかしいと感じました。



2016 年 8 月 31 日 7 時 55 分
投稿者: 榎本三四郎

C の代わりに F10 を発行するようにした lam_test.c を添付しましたので参考にしてください.ファイル中で,変数 n に C008 を入れているステーション番号を設定するように書き換える必要があります.

クレートの電源が入っていない状態では,ハードウェアがどのような値を返してきても不思議ではないので,そのときにどのような振る舞いをしても,それがおかしいかどうかは判断できない気がします.

ファンクションジェネレータからの矩形信号が長すぎないかは確認してみたでしょうか?

この後3週間ほど不在になるので,返信が遅くなるかもしれません.申し訳ありませんが,ご了承ください.


添付ファイル: lam_test.c (704 byte)



2016 年 9 月 2 日 18 時 41 分
投稿者: 戸澤

添付ファイルいただき、ありがとうございます。

C008 をステーション 3 に入れていたため、ファイル中の n = 3 のままで使用しました。
実行したところ、これまでと同じように、ファンクションジェネレータからの信号が ON のときも OFF のときも、
Waiting LAM ...OK.
Q=0, X=1
という表示が16回繰り返されて終了しました。
変わったのは、 Q=0, X=1 という表示が追加された点のみです。

矩形信号が長すぎるというのは、矩形信号の周期のことでしょうか?それとも出力時間のことでしょうか?
波形は、このスレッドの最初にも書いた通り、周波数 1Hz(周期 1s)、振幅 0〜700mV
の方形波を発生させて行っております。
周期をある程度小さく、あるいは大きくすると、クレートコントローラの DEM のLEDは消えますが、実行した際の表示は変わりません。
出力については、OFFにした状態で実行しても、
Waiting LAM ...OK.
Q=0, X=1
という表示になります。

確認ですが、ファンクションジェネレータからの信号が OFF (→ LAM が立っていない状態)であれば、3秒ごとに
Waiting LAM ...timed out.
と表示される
という解釈でよろしいですかね?



2016 年 9 月 7 日 17 時 51 分
投稿者: 戸澤

矩形信号の長さは、パルス幅のことですね。
確かに、最初に入れていたものは周期の半分(=0.5s)がパルス幅になっていました。

そこでパルス幅をADCで認識されるであろう1μs程度にしてGATEに入れてみたのですが、やはり同じ現象が起こります。
そもそも、 C008 をクレートから取り出し、クレートにクレートコントローラのみが挿さった状態(クレートの電源は入っている)で実行しても、ずっとOKが表示されます。
(ステーション3に C008 を挿したとき、「Q=0,X=1」であったのが、 C008 を取り出したとき、「Q=0,X=0」となる変化は見られた。)

また、クレートを正常に動作している別のものに代え、 C008 とクレートコントローラを挿して実行しても、現象は変わりませんでした。



2016 年 9 月 12 日 16 時 48 分
投稿者: 戸澤

現状を報告します。

一度、DAQ-Middlewareでのデータ取得が確認できているクレート(東陽テクニカ製 PS-6000)およびクレートコントローラ(東陽テクニカ製 CC/7700)で lam_test を実行し、正常に動作する(LAMが立ったときにOKと表示される)ことを確認しました。
その後、そのクレートとADCはそのまま使用し、クレートコントローラおよびPCを最初からテストしているものに入れ替えて実行すると、正常に動作しませんでした。
以上より、クレートとADCは問題なく、クレートコントローラもしくはPCとつないでいるCCP-USBがおかしい可能性があると考えました。



2016 年 9 月 20 日 8 時 14 分
投稿者: 榎本三四郎

ADCを入れた状態で X=1 が返ってきて、外すと X=0 となるというこは、CAMAC とのコミュニケーションはある程度できているということになります。問題は LAM を読むところに限られているという印象を受けます。

CCP のフロントパネルの設定やケーブル接続などは問題ないでしょうか? もし可能なら Windows コンピュータを用意して、USB ケーブルまで同じハードウェアで豊伸のソフトウェアを試してみれば、ソフトウェアの問題なのかハードウェアまたは設定の問題なのかを分離できると思います。

全てが問題ない場合の lam_test の振る舞いは、LAM が立ってなければ、3秒ごとに Waiting LAM... timed out. と表示されるということで合っています。



2016 年 9 月 21 日 15 時 2 分
投稿者: 戸澤

CCP のフロントパネルの設定およびケーブル接続については、確認しましたが問題ありません。
一度 Windows コンピュータで、豊伸のソフトウェアを試してみます。



2016 年 9 月 27 日 14 時 56 分
投稿者: 戸澤

お世話になっております。

ご助言いただいたとおり、USB ケーブルまで同じハードウェアを使用し、Windows コンピュータで豊伸の製品付属 Windows 用ソフトウェアを試してみたところ、正常に動作することが確認できました。
そのため、Linux 用ソフトウェアが問題なのではないかと考えました。

使用した Windows 用ソフトウェアをお送りした方がよろしいでしょうか?
他に何か試すべきこと等ありましたらよろしくお願いします。



2016 年 9 月 28 日 17 時 3 分
投稿者: 戸澤

もう一度、Linux PC につないで様子を見ています。

Windows 用ソフトウェアでテストした際、ドライバソフトのマニュアルに、クレートナンバーの値の範囲は 1 〜 7 であると書かれていたため(実際には 0 〜 9 まで変更できる)、これまでクレートナンバーを 0 としてテストしてきましたが、CSETCR()内の数字を 1 にした上で、クレートナンバーを 1 にして行ってみました。
しかし、依然として
Waiting LAM ...OK.
Q=0, X=1
という表示が続けて16回繰り返されます。

CSETCR()内の数字とクレートナンバーが異なる場合、表示が16回繰り返されるという現象は変わりませんでしたが、その際 X=0 となることが確認できました。
(CSETCR()内の数字を8,9としたとき、クレートナンバーをそれぞれ0,1としたときに X=1 となった。クレートナンバー0のときは、CSETCR()内の数字0で問題なかった。)

クレートコントローラ C001 のマニュアルによると、 DEM の LED はデマンド信号の状態を表示する LED で、
点灯 → 割り込み要求あり
消灯 → 割り込み要求なし
と記されていました。
何度もテスト実行していますが、 DEM が消灯(= LAM が立っていない)状態で実行しても、ソフトウェアの方では LAM が立ち続けているという動作を示します。



2016 年 10 月 1 日 18 時 33 分
投稿者: 榎本三四郎

症状からして、問題は LAM の取得だけで、CAMAC との通信自体はできているのではないかと思います。これを確認するために、とりあえず lam_test は置いておいて、camaction_test の方を試してみてもらえないでしょうか?

豊伸の Windows 用ソフトウェアは正常に動作したとのことですが、これには LAM 状態の取得も含まれているのでしょうか?



2016 年 10 月 4 日 20 時 1 分
投稿者: 戸澤

いろいろ試したところ、DAQ-Middleware でデータ取得できることが確認できました。
以下に、行ったことについて記載します。

まず、camaction_testについて。
前回と同様に、camaction_test.c において setcn() 内の数字を 1 にした上で、クレートコントローラフロントパネル上のクレートナンバーを 1 にして行ってみました。実行したところ、LAM が発生するたびに、
LAM BITS:0002
[00:02:00] 3863
[00:02:01] 3589
[00:02:02] 3693
  ……
[00:02:15] 0589
NXQ:0003
のようなものが表示されました(5回まで繰り返された)。
このとき、モジュールや信号の値も正しく読まれていることが確認できました。

ここで、CAMAC との通信自体はできているととらえ、以前申し上げた、すでに他のクレートコントローラでデータ取得が確認できている DAQ-Middleware を試してみたところ、正常にデータ取得できました。( DEM の LED は LAM 発生時の一瞬だけ点灯)
データ取得の途中で、クレートナンバーを 1 以外にすると、DEM の LED が点灯し続けた状態になり、この瞬間は PC にデータを送っていませんでした。
さらにその状態から、クレートナンバーを 1 に戻すと、 DEM の LED が消灯し、この瞬間に PC にデータが送られました。

以上のことから、setcn() を使用していた DAQ-Middleware のデータ読み込み部分に追加し、番号を与えたところ、コントローラのクレートナンバーをその値に合わせたときだけ正常に PC にデータを送る動作をするということが確認できました。

lam_test での動作は不明ですが、camaction_test は問題なく動作したと思います。

豊伸の Windows 用ソフトウェアに関して、LAM 状態の取得は DEM が 0 か 1 かで判断するという形で含まれていました。



2016 年 10 月 6 日 21 時 17 分
投稿者: 榎本三四郎

CAMAC Action はちゃんと動くとのことなので、とりあえずはこれを使ってデータ収集を行うことができるでしょうか? Q レスポンスを見ることにより、LAM を見るのと同等のことができると思います。

CCP-USB では、LAM 割り込みが使えないので、LAM を出すモジュールが決まっているなら、LAM を見ても Q レスポンスを見ても同じです。というか、Q レスポンスの場合は最初から有効データを取得できることもあるので、CCP-USB に限っては、むしろこの方が性能が良くなると思います。

CAMAC Action がちゃんと動くということは、ドライバの設定などの基本的な部分には問題がないと思っていいいと思います。CCP-USB では、割り込みが使えないので、LAM 状態取得も CAMAC Action も大して変わらないはずなのですが、今回 LAM 取得だけができないのは不思議です。もしかしたら CCP にまだ私が知らない差異があるのかもしれません。現状でできることはあまりありませんが、今後機会をみて調べてみたいと思います。



2016 年 10 月 19 日 12 時 34 分
投稿者: 戸澤

はい、問題なくデータ収集を行うことができる状態にすることができました。
いろいろとご指摘くださりありがとうございました。
以前にデータ収集ができなかったのは、クレートナンバーの設定をしていなかったことが問題であったと思われます。


このスレッドに記事を投稿する