Counting Problem: How to avoid data overwritten?

[Kevin_Price]

Part 2 of 2 (due to 5000 char limit)

2.  Buffered Pulse Train Generation.  Analog signals and Digital bit patterns can be acquired as inputs and then "played back" as outputs.  Variable-frequency pulsetrains can be acquired by counters but CANNOT be played back as outputs.   The high-speed digital boards are very inefficient for defining a high-precision long-duration pulse train (unlike the efficient PCI DIO64 product offered by one of NI's Alliance partners here).   Here's how it should work.  Ultimately the pulse train specs would be interleaved arrays of low times and high times.  The interface would be polymorphic, allowing the programmer to feed in either a scalar value or an array for both low times and high times.  The interface would also support definitions in terms of pairs such as Freq/Duty Cycle, High Time/Low Time, Freq/Pulse Width, etc.  A bigger onboard FIFO should go along with this feature.   Paired with a high-speed digital board, this feature would make digital pattern generation much more RAM efficient.

3. Polarity = Either.   Maybe it would be troublesome if ALL edge-driven functions supported "either" rising or falling polarity.  But I'm sure it would come in handy for triggers and probably several other cases I can't think of right now.

4. Query Signal State.  Perhaps there's already a way to do this with DAQmx property nodes?  (My LV system is tied up and I can't check).  If so, I think it can sometimes be a little clunky, requiring a query to a specific PFI hardware pin that is identified by #.  It could be handy to identify by task / function such as "Counter Input-->Edge Counting-->UpDn state"

5. Stop Trigger (in addition to presently-supported Start trigger): maybe this could be implemented similarly to AI pre-triggering?  The idea is to support a mode that means "count until a {Rising, Falling, Either} edge on signal {PFI pin #, RTSI pin #, etc.)."

-Kevin P.

[gus]

Kevin-

These suggestions are awesome.  Seriously awesome.  Believe me we're taking them into consideration as we're designing next generation counter products. I have some questions that I'll ask in a second post (char limit)

First I wanted to make a quick note about duplicate count prevention.  This has been an ongoing issue for quite some time (even pre-DAQmx when it was called "synchronous counting").  In DAQmx 7.4 though, we made some changes to the DAQmx driver to (hopefully) minimize the need to use the duplicate count prevention properties.  The new behavior will automatically turn duplicate count prevention on as long as the following conditions are met:

1. The duplicate count prevention attribute/property has not been explicitly set.
2. The selected counter timebase source is not set to an internal timebase.
3. The prescaler attribute/property has not been set.
4. The counter output event has not been configured.

With this change in behavior, you should generally not have to modify the duplicate count prevention property.  If you are seeing different behavior or you still find that you need to manually modify the duplicate count prevention property with NI-DAQmx, please respond to this post.

gus....

[falkpl]

I hope this means that we might be getting a new ctr board in the future.  With all these addition the product will live up the the 660x series precedence of excellence.  I have used the 6602 for so many applications since the multifunction boards just dont have enough counters to be useful, often single operations require two counters.  It would be nice to see a multifunction daq which focuses on counting as well, ie 4-8 counters with limited analog I/O

Paul

[gus]

Sorry, I got distracted yesterday and never got to finish this post:

1 A & B:

1 C: You are correct, A, B, and Z are hardwired to the default AUX, SOURCE, and GATE pins on 660x devices.  On M Series devices all three of these are selectable and can come from most any source (PFI, RTSI, etc).

1 😧 I can't find it now, but I remember looking into the behavior of Z index a long time ago and I found something on the web that seemed to indicate that level-based was the appropriate behavior for quadrature encoders.  Is there a situation when actually using encoders that this behavior is necessary, or is this a problem that would be alleviated if 1 A & B were addressed?

2: This one is something I've given a bit of thought to and there are some behavior issues that I haven't worked out. Such as, what should happen if the output FIFO is empty?  Should the counter output the last set of points again? stop generating? A bigger FIFO would definitely be necessary to accomodate this behavior.  Otherwise any short pulse would cause this underflow situation.

3: I've never heard of this being requested before.  Can you think of any situations where this would be useful to you?  Anyone else have situations where this would come in handy?

4: The only signal state that you can retrieve in the DAQmx API is the output state.  For input signals, we generally go with the philosophy that you should create a digital task (since on almost all counter devices you can create digital input tasks on PFI lines).

5: Stop trigger is another interesting one.  I had thought about it previously, but didn't have a scenario where I thought it would be necessary.  Incidentally, you can currently get this behavior by configuring a buffered period measurement task.  The first point (generally the throw away point) is the number of source ticks that occurred between when the counter was started and the first rising edge.  It's not pretty, but it's possible.  If this behavior were separately available, what would the buffered behavior be? or would there even need to be one?

gus....

[Kevin_Price]

gus -- thanks for the opportunity to discuss a wishlist!  So without further ado...

[bulk of post placed in attachment to avoid dealing with 5000-char-limit post-splitting]

Thanks again for engaging the topic!  I've long been a big fan of the 6602 as is probably obvious by my activity in this forum.  I remember that there have been a couple other little wishlist-like things that have come up here but don't remember right now.   Probably related to pulse-on-TC mostly, especially when combined with encoder position measurement, and even more especially when z-index reload is enabled.  I think.

-Kevin P.

[falkpl]

While we are making a wish list here is one more.  This might be too much to ask for but I have been looking for the ability to do some simple generic hardware based reconfiguring of counter operations.  Such operations can easily be done with a fpgs but some overlap could be nice, where a programable logic is incorporated in the design and could be set with labview and enhance the operation of the card.  Here is an example I have been asked to put out a single retrigable pulse with a width based on a formula and the measurement of the time between two other pulses the formula is a simple mathematical operation, and there is not enough time to reprogram the task, if simple functions and a set of registers could be downloaded to a card, this would be simple.  Tasks could be set to compensate for changing conditions without any software overhead.  This might be stepping on the toes of the FPGA but it would be way cool to have some overlap in the future.

[glo]

I am also seeing ".. data overwritten before it could be read" problem and it also seem random for me.

Legacy DAQ driver seems ok. But when I try to use DAQmx the data overwritten issue appears.

So, is there something wrong with DAQmx? Is there any difference between legacy DAQ driver and DAQmx driver in terms of how DAQ driver access the on-board buffer on PCI 6602?

Thanks,

Geoff

[Ima U]

Hi Geoff,

I would like you to reset the device then try an example program and see if you experience the same result.  To reset your driver open MAX (Measurement & Automation Explorer) and expand Devices and Interfaces >> Traditional (NI-DAQ) legacy.  Right click on Traditional NI-DAQ and choose "Reset Driver for Traditional NI-DAQ".  Next choose an example program to test this device in DAQmx (Open LabVIEW, Help >> Find Examples >> Hardware Input and Output >> DAQmx >> Counter Measurements.  Choose a program similar to the application you are doing to see if you receive the error.

[glo]

Thanks. That seem to work 🙂

Also, is there a way to detect using DAQmx function to check what driver NIDAQ driver version is installed on a system?  Or how I can find it some other way ( e.g. through windows registry? )

Geoff

x8590

[Ima U]

Hi Geoff,

You use Measurement & Automation Explorer (MAX) to find out the versions of all of your NI software including driver versions.  Open MAX, go to Configuration >> My System >> Software >> NI-DAQmx.  If you look to the right, you will see the driver version.  You can click on anything in the list of software and see the version. 

I hope this helps!