LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

retriggerable buffered event counting

I have been programming with Labview for the last 3 years, but know i have a problem:

Anybody know if is possible to do a retriggerable buffered event counting?

Thanks for your time.
0 Kudos
Message 1 of 12
(4,049 Views)
Can you clarify exactly what you are trying to acheive - describe the sequence of triggers/event pulses, the number of input signals.
0 Kudos
Message 2 of 12
(4,034 Views)
Thansk for the interest.

I have attached a diagram of what I need to do. I am not a 100% sure if it is possible, but there is far more in Labview than what you can find in their manuals (which are not great...)

I would appreciate if anybody could give a hand.

Thanks,
Jofre.
0 Kudos
Message 3 of 12
(4,028 Views)
Jofre,

Depending on your DAQ board and the duration of the trigger pulse, there may be a solution.

First, to the best of my knowledge, there is only one way to get a counter's value to be reset by a hardware trigger signal. It requires setting up the counter to measure an encoder position and will also require some screwdriver work to wire signals to specific locations. This type of measurement is supported by the 660x family of counter/timer boards and the M-series multifunction boards. It is *not* supported by E-series boards.

(Editorial: there really *ought* to be ways to reset a count value on an external trigger edge when in other counting modes, such as edge counting or even pulse generation. This has been on my wishlist for several years...)

The procedure is a little bit involved and I don't have enough minutes right now to get it right. Do you have (or can you get) the needed DAQ hardware? If so, post back and I'll describe the details soon.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 12
(4,014 Views)
Hi Kevin,

So, if i understand well is not possible out of the box... I am a confident(-ish) labview programmer but hardware is another matter. I work at the university so there are some technicians than can give me a hand. We have several cards, but the one that I use for this is a 6602DAQ. The pulses that should trigger the reset of the counter buffer are periodic, so i have been already working by triggering (just) the start of the "Buffered Event Counting" and, by knowing the period of the signal labeled in the diagram as "Trigger", i could figure out the correct timing position respect the "Trigger" of my signal at the "Gate". But nothing is never perfect, and after a while i have problems of synchronization, and the the signal at "gate" is shifted. So i thought that by just re-triggering each time, i will solve this problem.

I hope the message is not to messy. Anyway, briefly: I have a 6602DAQ and the resources to do changes on the board, so now (please...) what i need to do?


Thanks again,
Jofre.
0 Kudos
Message 5 of 12
(4,005 Views)
I believe Kevin is suggesting that you might be able to use the "counter reload on index pulse(channel Z)" function of the counter board's "quadrature encoder" mode (6601/6602 manual page 3-18).

I think this would be very tricky indeed, because you would need to generate an approximately 90 degrees phase shifted (delayed) source signal to input into "Ch B" (the main source into "Ch A") in order for the counter to continually count up. Note, I don't think the "reload on Z" function works in the "two pulse encoder" mode.

How about this alternative idea...

Set up two counters, each doing buffered event counting on the same source. Connect one counter's gate input as per your original configuration, and connect the second counters's gate to your "Trigger/Reset" signal. Now you will have two data buffers, one with the cummulative count at each "gate/event", and the second with the count value at the point you wanted a count reset. You should be able to read from these two seperate buffers and process the data in such a way that you can recreate the reseting effect you are after - (subtracting the values at the "reset" points logged in the second data buffer from the subsequent points in the first data buffer).

Mark H.
Message 6 of 12
(4,001 Views)
That's a great idea!!!
I will start working on it now. I will let you know if it works (I don't see why should not work, but just as a confirmation).

Thanks!
Jofre.
0 Kudos
Message 7 of 12
(3,995 Views)
Just in case you haven't encountered this before...

Note: When configuring multiple counter tasks using the "Counter Group Config.vi" (traditional DAQ) - as well as specifying different counter numbers, you also need to give each of the configuration VI instances a different "group" number input, otherwise the second configuration will overwrite the first. This is not at all obvious, and has almost certainly thrown quite a lot of people over the years.

I've no idea whether the same has to be done in DAQmx. I don't like the idea of DAQmx much at all - but I dare say I'll be forced to use it before very long.

Mark.
0 Kudos
Message 8 of 12
(3,989 Views)
Jofre,

Mark's suggestion is definitely a simpler and cleaner solution. I've done a pretty similar thing in the past with a 6602 and traditional NI-DAQ. I'd just add two more thoughts to go with his method:

1. You'll want to configure both the counters to be started by the same digital trigger signal so that their time information is synchronized, i.e., they both have the same "0" time.

2. You may need to watch for counter rollover, which occurs in less than a minute at 80 MHz. Not a real big deal, just a little thing to watch for when processing the data.

It could get a little trickier if your trigger signal is relatively rare (once or twice a minute or less). In such cases, you stand the risk of not knowing whether the counter rolled over between triggers or how many times. To help this problem, you could use a slower timebase (probably the 100 kHz) as a source for timestamping the triggers. There are other possibilties requiring the use of additional counters.

Other comments:

- Heed Mark's tip about group # if using Counter Config under traditional NI-DAQ.

- If you aren't heavily committed to traditional NI-DAQ, I'd suggest doing this with DAQmx. I admit that I struggled a while when making the switch but half of the effort was unlearning old ways. I've been using only DAQmx for all new development and I'd venture that for about 80-90% of the functions and features, I prefer it.

- (for academic interest only). It actually *is* possible to use the Z-index reload feature when configuring a counter for position/encoder measurement with a "two-pulse" encoder. You would simply hardwire one of the two inputs to digital ground, and configure the Z-index reload phase to "A LOW B LOW." There would still be two problems for the app in question here.

1. In encoder mode, the up pulse and down pulse must be signals wired to the counter's default SOURCE and AUX/UPDN pins respectively. You would need to somehow bring the internal 80 MHz timebase clock out to your terminal block pins. (I *think* but am not 100% sure that this can be done, but possibly only with DAQmx). Also, the reset signal must likewise be hardwired to the counter's default GATE pin.

2. The Z-index reload pulse seems to operate in a level-sensitive mode rather than edge-sensitive. As I recall from testing, if the trigger pulse remains in a HIGH state during several encoder pulses, the count keeps resetting after each one. One the other hand if it pulses briefly within the time that the A input is HIGH, no reset will occur. (Many industrial measurement encoders are designed to meet these Z-index requirements right out of the box.)

The more I think about it, the more I REALLY REALLY think there should be a setting that lets you reset a counter to a specific reload value on an EDGE of a software-defined GATE/TRIGGER signal.

Anyway, good luck with things.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 9 of 12
(3,982 Views)
Good point Kevin - I'd overlooked the need to start the two counters simultaneously - that crucial.

I've never had to start a buffered event count using a hardware trigger, so I can't offer help there - but one alternative option though, would be to use a further counter as the clock/timing source (continuous pulse train generator), which can be started after the two buffered event counter tasks are started, thereby obviating the need to start the two event counters simultaneously. Generating your own clock/timing source also adds the flexibility of controlling the clock rate, slowing it down if needs be, to reduce the rate of counter rollover.

Lucky the 6602 card has 8 counters really. 🙂
0 Kudos
Message 10 of 12
(3,966 Views)