zero/null/no delay pulse generation on PCI 6602?

[metamero]

Hi!

I need to configure a pulse generator to mantain a high output for N pulses sourced by a flow meter. (So that I can use another counter to measure this time.)

Is it possible to generate such a pulse without any delay ticks (null/zero delay)??

So that I could arm this measurement and I wouldn't need to wait this dull pulse before the N pulses I want to measure their time duration.

Thanks!

[CaioCanheiro]

Hi,

Are you working with real time system?

Why do you need to generate a pulse without ane delay?

Regards

[metamero]

I'm working with PC+Windows, but my timing requiriments are strict (for metrology).

The motivation of this pulse is not to give a pulse of time T, but to have a signal that stays high for N pulses (of a flow meter). Then I need to measure this time (for N pulses) with another counter. Then I can syncronize the measurements of two such meters (double chronometry).

My point is that with this non-null initial delay, I have to wait one "dull" input pulse of this flow meter so just then this 'N-pulses-high-signal' can begin (and then I can measure it's time duration). I am missing something?

Thanks for your response, @CaioCanheiro! If my explanation is still not clear, feel free to ask and point anything. Valeu!

[Kevin_Price]

Just so we're clear.  You'd like the output to transition "instantly" when you get the 1st flow meter pulse and, hold state until the Nth pulse, then "instantly" go low.  Meanwhile, another counter will measure the pulsewidth of the resulting output.

Does the flow meter pulse have a constant width but variable frequency?  What's the board's default state for your output pin?

-Kevin P

[metamero]

---

Kevin_Price escreveu:

You'd like the output to transition "instantly" when you get the 1st flow meter pulse

---

Yes, that's the ideia. I want to arm this task by software and then on the first rising edge of the input this output N-ticks-pulse goes hight...

---

Kevin_Price escreveu:

and, hold state until the Nth pulse, then "instantly" go low.  Meanwhile, another counter will measure the pulsewidth of the resulting output.

---

yeah (on the Nth rising edge)

---

Kevin_Price escreveu:

Does the flow meter pulse have a constant width but variable frequency?  What's the board's default state for your output pin?

I think both pulse width and frequency (frequency for sure) can vary, since they're mechanically generated by physical magnets on a flow meter (typically). I'm working with 'slow frequencies'.

Thanks, Kevin!

[Kevin_Price]

Is your output pulse there solely to give you the opportunity to measure time?  Or does it serve some other function to sync other equipment?

If solely to measure time, you don't even need it.  Let the second counter perform finite buffered period measurement on the flow meter pulses with a buffer size of N.  Sum the periods for total time.

-Kevin P

[metamero]

---

Kevin_Price escreveu:

If solely to measure time, you don't even need it.  Let the second counter perform finite buffered period measurement on the flow meter pulses with a buffer size of N.  Sum the periods for total time.

---

Yes, that would be fine/sufficient for the simple chronometry of the N pulses time...

---

Kevin_Price escreveu:

Is your output pulse there solely to give you the opportunity to measure time?  Or does it serve some other function to sync other equipment? 

---

But on some applications I need to synchronize another chronometry (of a stantard or test instrument (flow meter)). This N-pulses-intermediate-signal would be the source of the time measurement and the trigger/arm to another such N-pulses-timing-measurement ("faster", this second one is of higher frequency).

[metamero]

---

Kevin_Price escreveu:

If solely to measure time, you don't even need it.  Let the second counter perform finite buffered period measurement on the flow meter pulses with a buffer size of N.  Sum the periods for total time.

---

But... as I can remember by reading about buffered measurements, the first value is to be ignored. So how could I know if this first rise happened or not, if I use this method?

[Kevin_Price]

But... as I can remember by reading about buffered measurements, the first value is to be ignored. So how could I know if this first rise happened or not, if I use this method?

You're right, you'd need a buffer of size N+1 and ignore the first reading.  I've started getting used to the newer X series boards that never buffer the first "meaningless" reading.  I much prefer the older behavior of the 6602, M-series, and other boards.  The first reading isn't *always* meaningless, having it lets me make the choice.

Back to your problem of syncing 2 different readings.  The older behavior of the 6602 may be able to *help* us here.  However I'm not quite following your exact needs.  You said: 

---

---

on some applications I need to synchronize another chronometry (of a stantard or test instrument (flow meter)). This N-pulses-intermediate-signal would be the source of the time measurement and the trigger/arm to another such N-pulses-timing-measurement ("faster", this second one is of higher frequency)

---

 Let's say you use triggering to start both measurements at once.  If the 2 N's are the same, they will count their respective N's over different time intervals.  So you don't have complete time correspondence between the measurements anyway despite all the gyrations over 0-delay triggering, etc.

Even if the N's are different to try to reflect similar *nominal* time intervals, the reality will vary from nominal at least a *little* bit.  To me, that calls into question the value of the 0-delay triggering you're after.

I'm going to suppose that the flow meters are emitting pulses pretty much continuously and you need to start your data acq in the presence of these signals.  The phase of both pulse trains are pretty much random relative to your task starts and you can't control them.

Your goal (as I understand it) is to characterize the two flow rate measurements over the same nominal time interval.  It seems to me that you need a precise measure of the two flow meters' pulse frequencies.  Thus far, you've opted to do that by counting a specific number of intervals and measuring the total time.  At best, that would only give you an average flow meter frequency.  

*I* think you'd do better by setting up 2 buffered period measurement tasks, both set to arm-start trigger off some common signal, possibly one you generate yourself.  Once a sufficient measurement time has passed, read all the data from both tasks. The first reading is not a full interval but it's still helpful because a cumulative sum of the periods now gives you timestamps for each flow meter edge.  All of them represent "time since trigger."  You can use this info to help decide which portion of the 2 buffers lines up best in time.  Otherwise, all but the first interval can be used to do analysis on the flow meters' pulse frequencies.  Now you can compute not only the average frequency, but also median, standard deviation, and more.

The intermediate counter used to generate a pulse of duration N1 or N2 cycles is still not needed.

-Kevin P

[metamero]

Hello again!

Sorry for this delay, the lab of this job was off some days for an important inspection.

Kevin, thank you very much for your time and attention! I talked to the team and we agreed that this really points to a better solution, more clean and adequate to this problem. I already cogitated this aproach, but your message helped to clarify this. We are gonna try it and validate (against the old system that I'm remaking/upgrading), as soon we can do this I'll post the results.

But... when I tried to configure a buffered measurement to trigger on a digital signal, it wasn't able to configure this. (I'm using LabVIEW, it says this is option is not available for this kind of task.)

*I* think you'd do better by setting up 2 buffered period measurement tasks, both set to arm-start trigger off some common signal, possibly one you generate yourself.  Once a sufficient measurement time has passed, read all the data from both tasks. The first reading is not a full interval but it's still helpful because a cumulative sum of the periods now gives you timestamps for each flow meter edge.  All of them represent "time since trigger."  You can use this info to help decide which portion of the 2 buffers lines up best in time.  Otherwise, all but the first interval can be used to do analysis on the flow meters' pulse frequencies.  Now you can compute not only the average frequency, but also median, standard deviation, and more.

This method seems the right one, but it depends on exact synchronization between the two tasks. Do you have any idea how can this can be obtained (or what I am missing)?

~

Some other comments:

You're right, you'd need a buffer of size N+1 and ignore the first reading.  I've started getting used to the newer X series boards that never buffer the first "meaningless" reading.  I much prefer the older behavior of the 6602, M-series, and other boards.  The first reading isn't *always* meaningless, having it lets me make the choice.

That is very well observed. This value almost never would represent a whole period, but it is the exact count between task arm and first active edge. I also (always) prefer the behaviour that lets me the choice.

---

---

 Let's say you use triggering to start both measurements at once.  If the 2 N's are the same, they will count their respective N's over different time intervals.  So you don't have complete time correspondence between the measurements anyway despite all the gyrations over 0-delay triggering, etc.

Even if the N's are different to try to reflect similar *nominal* time intervals, the reality will vary from nominal at least a *little* bit.  To me, that calls into question the value of the 0-delay triggering you're after.

---

Yes. In this case, one signal is much faster than other. They will "never" have same synch/phase so we have to chose the most similar (and close to each other) time intervals, to count respective pulses within these intervals. So, the slower one determines the measurement: we want to count N "slow" pulses (choosed a priori by operator), then as soon as the task is armed and the first "slow" rise happens, we need to start do count time and pulses of the other meter too. I also understand this could be acomplished by the two buffers/series that stamps all rises after arm.

---

I'm going to suppose that the flow meters are emitting pulses pretty much continuously and you need to start your data acq in the presence of these signals.  The phase of both pulse trains are pretty much random relative to your task starts and you can't control them.

---

Yes, the measurement will start when flow is stable - and we can't control phases.

---

The intermediate counter used to generate a pulse of duration N1 or N2 cycles is still not needed.

---

This would greatly reduce system complexity. =]

And I have some more concerns. About the advanced features "pad synchronitazion" and "duplicate count prevention", I wasn't sure if they have or not to do with this case.

Thanks a lot!