Periodically timed pulse counting

[MWijnen]

Hi all,

For my research project I'm working on a tabletop fusion device. The main goal is to investigate the neutron production. At the moment I'm automising as much as possible. 

I have 3 analog input signals for voltage, pressure and current and 1 analog output signal to control the voltage and I have a USB camera continously filming the inside of the reactor. Furthermore the neutron counter puts out TTL pulses usually at 25-100Hz.

The aim of my program is to continuously measure the analog signals so I can see the pressure, current and voltage and video in real time. Furthermore I'd like to periodically (when I press a button) measure the neutrons for a set period of time and during this time I'd like to record a movie. After such a measurement I'd like to plot the pressure, voltage and current vs. time (for the duration of the measurement) in one plot and total counts, and counts per second vs. time in a second plot.

I've done this with a different ADC/DAC device and it worked allthough the aquisition rate was low. I used to measure pressure through serial communication with the pressure meter (which made the loop time very long) but now I've figured out a way to measure the pressure directly with an analog signal. Since the other adc/dac device had only 2 adc channels I switched to the PCIe-6361 and now I'm  trying to replicate my program.

I've made two timed loops, one running on its own doing all the analog and video aquisition, and another timed loop inside a case structure inside a while loop. When I press a button the case with the timed loop is selected and this loop starts the aquiring the counter data and outputting that together with the data from the other (continuous) loop. In my old program I used a local variable of the cluster with my data, in my new program I'm trying notifiers. After the set time is up the timed loop should end and all data should be put in an array to be made into a waveform and plotted. I also would like to see the remaining time of a counting period and perhaps the total counts in real time during counting.

At the moment I'm stuck configuring the DAQ counter to do the same thing I did with my old program. I read some stuff about pause triggers, and using a second counter to generate a clocksignal for the first but that only confused me more, escpecially what clock times to pick . Furthermore I'm worried about the timed loops running in parallel, I assume they're not synchronized, is that a problem?

Is it an option to put the counter in the continous loop, and use the second (occassional) loop purely for data logging, resetting the counter when I start a measurement? 

Are there any other bottlenecks I'm not aware of? 

I added both VI files, FusorDiag and FusorDiag2. The first, allthough some VI's in it are not visible, works and is instructive of what I'd like to achieve. The second is very similar, but not yet finished, (I haven't put the data in an array, or attempted to make the waveforms and plots). Any advice is more than welcome.  

Kind regards, 

Mick Wijnen

[ThiCop]

Hello Mick,

Before going into details I want to make sure I understand your specifications correctly.

Specifications:
- Acquire 3 Analog Inputs (Voltage, Pressure and Current)
- Generate Analog Output (to control a voltage)
- Acquire USB Video

Goal 1s
- Monitoring of Voltage, Pressure, Current and Video Stream.
-  While pressing a “record” button I want to:
a) Record the video for a set/fixed period of time. (let us call this the ”video record”)
b) During this same period you want to record voltage, pressure and current vs. time. (“analog record”)
c) During this same period you also want to record “counts per second” vs. time (“count record”)

- Both the "analog record" and the "count record" should be plotted.

General feedback:

- For continuous acquisitions I would generally not advise to use timed loops.

  The DAQmx read functions possess inherent timing capabilities that you should take advantage of in this case.

- Notifiers are also not the best solution in this case.

  I suspect that you want to avoid any loss of data, so you should better use queues to transfer your data sets.

- Reading out notifiers in your timed loop is also not something I would (in general) advise to people.

- I think an adaption of the producer consumer design pattern might be a good starting point for your project.

Open Questions:

- What sample rates would you like to have for your 3 Analog Acquisitions and your Counter input?

- How accurately do you need to now the "neutron count"?
If you want to use edge count, then you can do this, but then I would suggest that you take a running average over a certain amount of values.

Otherwise sampling at 1 kHz will either show you "1 edge" or "0 edge", because 1 kHz is still 10 times faste than your maximum pulse rate (100 Hz).

There are other approaches we can take, but these depend on what you actually require in your application.

[MWijnen]

Hello Thierry,

You are mostly right about the specifications:

-3 analog inputs, 1 analog output, USB video stream continuously at 5-10 samples per second There are no fast processes involved.

-1 TTL input about 25-100 pulses per second, occasionally for a set amount of time. I would like to able to verify the amount of time, usually around 30-60 seconds.

The target variable I'm looking for is neutrons per second, in my old program I calculated the mean NPS as the total count divided by the run-time in realtime and instantaneous NPS by calculating the derivative afterwards.

I want to record all the analog input, videostream and counts for that period of time, plot the analog and counting data separately as a function of time afterwards and save the data in a spreadsheat file and an avi file.

The counting needs to be as precise as possible, neutron counting is a very insensitive process, every pulse represents about 43285 neutrons, so missing a count is not an option. 

How do I use the DAQmx read functions inherent timing capability? And what do you mean by producer consumer design pattern? The biggest problem for me at the moment is how set up the counter.

Thank you for your help,

Kind regards,

Mick Wijnen 

[ThiCop]

Hello Mick,

The producer/consumer design pattern is quite elaborately explained over here: http://www.ni.com/white-paper/3023/en/

If you have questions about this, then don't hesitate to ask.

Some follow-up questions:

- Do you want to have the ability to monitor the 3 AIs, the video stream and the Counter lines when you are not "recording" (so before you press the record button)?

- A rate of sample 1000 kHz for the AI and the counter lines should then be (more than) enough?

- Should your analog output be set software-timed (by manually changing the value in the UI) or should it follow a certain predefined pattern?

Can you provide me with a bit more information about your experience level with LabVIEW programming?

- How long have you been using NI LabVIEW?

- How many projects have you already done?
  Is this (one of) your first one(s)?

- Did you follow any official NI courses?

  If not, how did you train yourself?
- Which Design Patterns do you already know? (state machine, Master Slave, ...)

These questions will allow me to do a preliminate evaluation of your current LabVIEW experience/skill level.

PS: Which version of LabVIEW are you using?

The later versions include some nice examples about continuous monitoring.

Thanks in advance!

[MWijnen]

Hey Thierry,

I'll study the design pattern information tonight, so I can apply it tomorrow and ask you some questions if needed. 
Yes I'd like to monitor all the analog input and video stream all the time, even when I'm not recording. That's why I tried two loops in parallel in the first place.

I figured the 1000Hz sample rate is more than enough.

Today I cleaned the program up a bit, by making (multichannel) tasks configured for on-demand samples. 

But I still kept the loop rate at 200ms as I think updating the indicators at more than 5-10 Hz will make them not readable, and more than 10 datapoints per second i.e. 300-600 datapoints total is sufficiënt for the speed of the processes involved. I was wondering if you meant the time-out input of the DAQmx as the inherent timing mechanism?

The analog signal should be indeed be set software-timed, and I'd like to be able to change the value at any time.

This project is my only labview experience. I've had no training at all. I'm a physics student at the Eindhoven University of Technology. When I started my project I found the set up consisting of the reactor, a high voltage supply, several multimeters and a pressure meter which all were to be read out manually. Since this was in my opinion a ridiculous situation I got a ADC/DAC device our university produces (TUeDACs) and hooked up the voltage and current input, and voltage output to this device. I started with labwindows, but since I only had very basic training in programming this was an unsurmountable task. One of the computer engineers responsible for automatisation of our department (who also programmed the VI's for the TUeDACs) pointed me to LabView and gave me some minor instructions. From there on I expanded the program bit by bit, starting over a couple of times and adding features along

the way. I mostly worked by trial and error and some advice from our computer engineer.

The pressure was read through serial communication with the pressure meter and as soon as I found out how VISA worked I implemented it. After a while the neutron counter arrived, I had make a small electronic circuit converting the output pulses to proper TTL and hooked that up to the TUeDACs as well. That is what FusorDiag.VI was. Recently I found out the pressure meter also shunts the analog signal to one of its outputs and decided to hook that up to the ADC as well. Unfortunately the TUeDACs has only two ADC inputs. I found out we had a NI PXIe-1082 with a PXIe-6361 collecting dust in another lab so I confiscated it and hooked up my setup to it. Since monday I've been trying to modify my program for the DAQmx VI's. 

Long story short I have no prior experience, all I learned was by trial and error on this project. I have no notion of design patterns or other jargon. I do however learn quickly so don't be affraid to try new or complicated approaches with me. I use LabView 2013. I added the most recent version of the project. It has only DAQmx VI's and no other external VI's so you should be able to view everything. Thank you again for your help. 

Kind regards,

Mick Wijnen 

[ThiCop]

Hello Mick,

Thanks for your elaborate feedback!

Have you been able to test a bit with the producer consumer Design Pattern?

Based on your post it seems like you would do one test  based on this and then get back to me with a first try.

If I misunderstood this, then please let me know.

In the latter case I will put together a simple example.

Otherwise I would just start from your first "producer consumer" try.

[MWijnen]

Hi Thierry,

I played around a bit with the producer consumer pattern in your link and tried to use the queueing VI's. I think I understand the basics, but I got stuck. I attached the .vi file to this email.

In which loop should I put the read counter VI? And how do I make sure the counter only runs for the specified amount of time and that it resets afterwards? I put the add to queue in a case-structure so that it only queues data when the count button is switched on, and a notifier to link that to the second loop. Perhaps events are better for this but I'm not really familiar with those.

The FusorDiag2.vi I attached to the previous mail works right now but I assume it is not programmed very well based on your comments so I'd like to improve it or completely overhaul it with your help. 

Kind regards, 

Mick

[ThiCop]

Hello Mick,

Friday I wasn't able to do any forum replies, so my apologies for that.

Before doing that can you tell me what the code circled in attachment is supposed to do?

These contain non-standard VIs and do not seem to be in a while loop.

Therefore, I don not understand what these are supposed to do.

If you can tell me what these are supposed to do, then I'll better understand what you're trying to do.

I think you should split up your different tasks to be able to manage them correctly and understand them fully.
1) Let us focus first on the synchronization of your analog Inputs with your counter inputs.

One example that illustrates how this can be done in a continuous way is over here:
https://decibel.ni.com/content/docs/DOC-14817

Do you fully understand what is happening over here?

2) Your generation of your analog output can be in a totally seperate loop, since it seems like it does not have to be synchronized with the other tasks.

Can you first try these 2 things and let me know if they work correctly? (please also share when you've tested this)
From there on we can build the final application up.

[MWijnen]

Hi Thierry,

I started from fusordiag2.vi and tried to implement the normal while loops with queueing etc. At some point I got stuck and didn't know how to connect several of the VI's and variable, but as a I didn't want to lose them I put them outside the loop. So I could place them inside the loop again when I figured out what would be the best approach. So fusordiag3.vi was a (failed) attempt at implementing the producer/consumer pattern you recommended. When I tried to implement it, it raised a lot of questions and that's when I got stuck.  

Kind regards,

Mick Wijnen 

[ThiCop]

Hell Mick,

I have made small example to illustrate what I had in mind.

Please note that:

1) I did not implement your whole set of requested feature set (I only focused on a simple architecture).
2) This example is not the best approach. It is an approach that leans quite closely to what you're currently trying to do.
You should however get more acquainted with how a state machine works.

3) The best approach would be to follow the principles explained in the "Continuous Measurement & Logging Sample Project".

This Sample Project can be found in LabVIEW 2012, when you have installed the DAQmx driver.

If you have questions, then you can of course always ask.

The attached Code is provided As Is.  It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments.  You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense.