Using all 8 counters on the 6602.

[Kevin_Price]

---

 What I can do is...  send my Z, so that all of the counters start on the Z and therefore start at the exact same time.  Then connect the test encoders A to any PFI and B to any PFI. 

1. Yes, you could use the Z index signal as a shared digital "arm start" trigger.

2. I would also recommend wiring the Z-index to the 4 counters' Gate pins and enabling the Z-index feature with a reload value of 0 (the default). 

---

 Speaking of, I have future application where I will want to measure not only A and B signals from my test encoder, but also 3 commutator outputs.  That means I need to record both high and low for 3 outputs, meaning I need 6 additional counters.  If I started with a 6602, could I later add in a 6601 card for an extra 4 channels, or would it be better to get another 6602  (6602 uses a 20MHz timebase and the 6601 uses a 10MHz)?

---

1. The 6602 gives you 3 more DMA channels, the 6601 only offers 1.  Also the timebases are 80 MHz and 20 MHz respectively.  I'd definitely suggest the 6602, or possibly 2 of them (so all 6 measurements can come via DMA).

2. Better yet, if you're needing to buy new hardware anyway, consider a board that can do hw-clocked DIO.  The M-series boards are a good place to start.

3. General unsolicited advice: this sounds like a testing system that's likely to be quite important / valuable to your company.  Don't be penny wise and pound foolish by using the absolute bare minimum of data acq hardware.  It's easy to burn up the $1000 you "saved" with all the extra debug & maintenance needed to manage lots of interrupt-driven channels.  Personally, I'd make a goal of having ALL data collection operate via DMA and purchase the hardware needed to accomodate that.

   Here's an M-series based option.  Buy 2 M-series boards, 1 for timestamping the test encoder and 1 for timestamping the commutators.  Each can be configured to sample based on "change detection", i.e., everytime one of the specified bits has a transition.  Additionally, the task will generate a change detection event/pulse which can be used as a sampling clock to capture the reference encoder position.

-Kevin P.

[Garrett K]

Thank you again Kevin for your reply.

Ah, you are right, the 6601 is only 20MHz.  The 6602 is capable of 80MHz, but will be limited to 20MHz becuase of the encoding.

I believe by hw-clocked DIO, you mean reading digital IO with using an external clock, which would be my refrence encoder.  Is this correct?  I have personally used external clocking before, but with IOtech DAQ cards, and have had horrible results.  Thats not to say the NI cards will suffer the same problem, but my first thought in fixing this problem was to avoid having to have that similar setup, which lead me to the counter cards.  The bigger problem is leaves me with, for this application, is in data collection.  Perhaps the NI software is different, and if so this could be an option, but other DAQ software I have seen will make a recording of of the DIO at each clock pulse.  To record one relvolution, I would have 67 million state recordings for each DIO.  That would be way too much to process.  Does the NI software offer some other method of recording the data?  Also, if I were to go this route, could I go with something like the PCI-6503 or the usb 6501?  The M series look very nice, but I have no need for the analog inputs.

I am sorry if I am asking a lot of simple questions.  I am not new to DAQs, but new to the NI products, software, and termonolgy.  Thanks for your help.

Message Edited by Garrett K on 06-15-2006 09:16 AM

[Kevin_Price]

I believe by hw-clocked DIO, you mean reading digital IO with using an external clock, which would be my refrence encoder.  Is this correct? 

Not exactly.  The "change detection" I mentioned would be set up to detect transitions on your TEST encoder (or your commutator signals).  So you'd get 1 sample exactly at the instants that the test encoder had an A or B transition.  You'd collect exactly the data that's necessary and sufficient -- no waste!

I have personally used external clocking before, but with IOtech DAQ cards, and have had horrible results...  Perhaps the NI software is different, and if so this could be an option, but other DAQ software I have seen will make a recording of of the DIO at each clock pulse.  To record one relvolution, I would have 67 million state recordings for each DIO.  That would be way too much to process.  Does the NI software offer some other method of recording the data?  Also, if I were to go this route, could I go with something like the PCI-6503 or the usb 6501?  The M series look very nice, but I have no need for the analog inputs.

If your test encoder is 1024 cycles/rev, you'll produce 4096 samples/rev each for the ref and test encoders.  Each ref encoder sample is its count value at the instant that one of your test encoder channels had a transition.  Each test encoder sample can be a simple bit pattern showing the test encoder's A,B states.  You'll get at least 6 additional bit values for free, so you could expand to capture some other digital data there with absolutely no real-time performance penalty, just some extra post-processing.

I don't know the 6503 or 6501, but at a quick glance I don't think they'll do the trick.  The M-series boards are indeed very nice.  I've got an app going that generates 8 output DIO bits while capturing 24 input DIO bits.  Both operate at 10 kHz, and I'm performing on-the-fly logical operations to verify that the outputs and inputs correlate properly.  Any failure to correlate is flagged within 10's of msec.  All this without bogging down the PC.

Before committing actual $$ to boards, talk with NI.  Talk through the future anticipated uses as well as the current ones.  And a little friendly wager -- if you have a boss or project leader, within 1 year of getting this test system going you'll be asked to add analog.

-Kevin P.

[Garrett K]

Kevin, thanks again for the very prompt replies.

The M series board looks like it will do just what I need, also.  By using only 1 counter, recorded off of many DIO, I avoid having to get a board with multiple counters which were just being fed the exact same signal anyways.

I just got off the phone with NI discussing the multi-counter boards or a DIO board with a counter.

The general consensus seems to be that either would work, however, neither will do the trick with VI Logger Lite, as it allows only 1 task to run at a time.  For the 6602 counter board, this would mean I could only operate one counter at a time, and for the M series board it would mean I could look at DIO or a counter, but not both at the same time.  Hopefully today my software CD will show up and I can take a better look at everything.

[Ryan_V[DE]]

Garrett,

I agree completely with Kevin's suggestion to use M Series instead of the counter boards. The combination of change detection and counters can be a very powerful one. A few considerations:

1.) With such a high resolution encoder, you'll have to worry about the counter rolling over at the terminal count, 2^32 - 1.
2.) The change detection event signal is correlated to the 80MHz timebase of the board, so any encoder pulses that occur within 12.5ns of each other could be registered as the same event. Just be aware that it is possible for 2 changes to occur at the same "positionstamp"
3.) The M Series (and counter boards as well) have a limited counter FIFO buffer. If your shafts are creating pulses too quickly (and thus the change detection event is firing too fast), you will get a buffer overrun for your "positionstamps". At what rate are your shafts rotating? Note that this will not be a problem for the digital input as it has a much larger buffer.
4.) VI Logger, aside from not having the resource management you desire, does not allow for the intricate routing and configuration that this application will certainly require. Some programming will be involved, either LabVIEW, C, C++, etc. I doubt many will argue that it is easier to use NI hardware in anything other than LabVIEW, however. Save yourself the time and catch up with the graphical programming revolution!!!

It sounds like you have a really interesting application planned. Let us know if you have any more questions.

Regards,

[Garrett K]

Ryan, thank you for your input.

You are right, with a 26 bit encoder and a 32 bit counter, I am limited to 64 revolutions, so I do need to be careful with it, however, I will be able to obtain all the data I need in 1 revolution. 

I will be running very slow.  The motor and gear configuration I am running right now puts me at about 3 rpm.  Hopefully I can step it up a little.  I orgionally was running that slow so my IOtech DAQ would keep up, but that card can go in the trash can as far as I am concerned, maybe now I will be able to run a bit faster.  I should stay well under 80MHz and do not think with a counter that fast I will have problems. 

It is really too bad that it looks like VI Logger Lite wont work for me.  I am already pushing the budget as is.  As questioned before, yes this is an important tool for our facility, but its like pulling teeth to get money.  I will have to see what I can do to get a copy of labview.

I am starting to lean toward the M series card.  If I have low resolution (8-12 bit) encoders on the DIO and the 26 bit on the counter, then I need the counter to be very fast, but the DIO can be much slower.  The PCI-6220 has an 80MHz counter, and 1MHz digital.  I believe this should be okay for me.  What I am imagining is if I were to use the 6220, I could wire my refrence encoder to the counter, and my test encoders signals (A, B, Index, and commutators) to DIO ports.  Then, I could configure it to record the counter value and all DIO states, at any state change on any of the DIO pins.  Does this sound like the right approach?

Thanks all! 

[Kevin_Price]

Furthering Ryan V's comments...

1.  The issue of terminal count can be avoided if you enable z-indexing for the counter task measuring reference encoder position.  That will restrict the count range to +/- 67 million, preventing you from getting a "rollover" artifact.  Even without the z-index, you could avoid the problem by being careful.  It'd take something like 60-70 revs at 67million counts each before rollover.

If you use z-indexing, you may want to trigger off the z signal.  Alternately, ignore all data collected before the 1st time your count values get reset to 0.

2 & 3.   I wasn't aware that the change detection event correlated to the internal timebase.  In a practical sense, the counter FIFO will overrun at much lower speeds than the 12.5 nanosecond resolution Ryan mentioned.  I don't have a hard number, but I wouldn't want to rely on a counter acquisition task with a sampling rate of even a few hundred kHz.   I'd set a goal of 100 kHz or lower.  What kind of resolution do your test encoders have?  What speed will your test fixture run at?  Can you keep (test encoder cycles/rev * 4 changes/cycle * revs/sec) below 100 kHz or so?

A different change detection problem may happen at standstill conditions.  If your test encoder is sitting right on the threshold of a transition, vibration may cause bursts of high-freq change detection events, possibly fast enough to generate FIFO overrun errors.  If this were my test fixture, I'd make sure the drive motor & test encoder were moving at a smooth constant speed before starting the data acq tasks.  Then your change detection events will happen at a much more steady and manageable rate.

It also might (?) be possible to avoid such troubles if you can configure the input pins for digital filtering.  But I'm not so sure that you can perform both digital filtering and change detection on a given pin simultaneously. 

-Kevin P.

[Garrett K]

My test encoders are 8-12 bit, and I am running, right now, around 3 rpm, but will likely run a bit higher, as I know I can and still be well under the speed of the DAQ.

[Ryan_V[DE]]

To address the 12.5ns comment, I was merely suggesting that it is possible for two encoders to pulse "at the same time," meaning less than 12.5ns apart. It is not guaranteed that every single change will regsiter an edge on the change detection event. As for buffering the counter at that rate... if only we could. On that note, for M Series devices, I start to get occasional buffer overwrites around 400kHz, and that is with a PCI video card. The suggestion to use Z-indexing is also a good one. For the digital filtering suggestion, you can only perform change detection on port 0, and unfortunately, no lines on port 0 are shared with PFI lines. This means that you cannot even use the digital line filter workaround outlined in this KB.

Hope this helps,

[Kevin_Price]

To: Garrett,  Re: 12.5 nanoseconds. 

As a non-NI guy in this thread, I've got no vested interest in selling you hardware.  But Ryan's point about the 12.5 nanosecond resolution has an implication that might not be immediately obvious.

Earlier, I suggested ways to avoid FIFO overruns from high frequency change detect events coming from a single test encoder.  Because there's a physical distance separation between the transitions, being careful about rotational speed will be enough to limit the transition rate. 

The OTHER implication about the 12.5 nanoseconds comes if you also want to perform change detection on your commutation signals.  If you were to try to do it in the SAME task using a single M-series board with a 32-bit hw-clocked port, you'd risk having an encoder transition and a commutation transition within a 12.5 nanosecond period.  You'd only end up sampling on 1 of those 2 transitions, corrupting your data.

The solution would be to buy 2 M-series boards, one for the test encoder task and one for the commutation signal task.  They could each be a somewhat cheaper version with an 8-bit hw-clocked port.

-Kevin P.