counter pxi-6221 - some elemtary qestions

[Moschdschlotzer]

Hello,

i have some questions:

I want to measure two periodtimes of two TTL signals. The TTL signals come from two Heidenhain rotary measuring devices

which have 18000 periods. I use about 50rpm. So its about 6,6E-5 seconds per period and 15000 periods per second (frequency=15kHz).

I connected the two signals to the PXI-6221 (M-Series) - card. I used PIN 3 and PIN 41 (CTR Gate).

It works but the results aren't good, so:

Do i need an external timer? How big is the sampling rate? 20Mhz or 100kHz?

Ho exact is the value of the periodtime? How many digits can i use?

I get things like that: 0.0000666625 (see the file in the attachement. Column 1 is the first signal, Column 2 is the second signal.)

But this is not very exact!!! Is there a way to become better values?

How exact is the card?

I want to sum up all values of signal 1. So i have the whole time of mesarument.

Then i want to subtract all values of signal 2 from all values of signal 1.

sum(signal1)-sum(signal2)=delay

So you see it is important to have exact values.

Is there a difference between the 6221 (M-Series) and the 6123 (S-Series)?

It would be great if someone could help me.

regards

Jens Bihr

[Kevin_Price]

Several thoughts in no particular order:

1. The M-series is a better choice because the internal timebase is 80 MHz rather than the 20 MHz for the S-series.  The counters are also 32-bit rather than 24-bit, though this particular app probably wouldn't care either way.

2. What do you mean by "exact" exactly?  What I see in the data are periods measured to the nearest 80 MHz timebase cycle, i.e., 12.5 nanosecond resolution.  I would consider that to be pretty exact.  However, because of the speed of the incoming pulses, you're still getting a quantization error of about 1 part in 5000 or 0.02%.

3. If your only concern is to measure the delay between your A and B encoder channel, there's a measurement mode known as "two-signal separation measurement" that will do this more directly.  This mode is available for M-series counters, but might not be (?) for S-series.  You'll still be subject to the same kind of quantization error of ~0.02%.

4. Personally I prefer going native, setting up my counter configurations with units=Ticks and my counter Reads as 1D U32's.  Then the periods come back as integer counts, and it becomes a little more intuitive to understand what the limits of "exact-ness" are. 

5.  Apart from the details you've described, what's the purpose of the overall app?  What are you trying to learn or assess from this measurement?  What decision(s) do you need to make based on this data?

-Kevin P.

[Moschdschlotzer]

Hi Kevin,

thank you very much for your fast response!

1. Okay, so i will use the M series card.

2. If i use 50rpm and measure 18000 signals, i will have a maximum error of 18000*12,5E-9=2,25E-4.

The quanization error is 18000*(measuring space/2^32)=18000*(9E-4/4,29E9)=18000*2,1E-13=3,78E-9.

Is that correct?

3. Hey this is a good hint! I tried it. But the "Measurement and Automation Explorer" wants me to connect the cables to a port, which

i don't have. It says for example: First signal to PFI11, second signal to PFI4. But i have only PFI 0 ... 9. What shall i do now?

4. ?

5. Okay, i will try to describe everything.

The whole issue is a test station for gears. The gear box runs under a high torque. As a matter of fact sometimes only one tooth touches the other tooth and sometimes there are two toothes touching two others. So because of the high torque the tooth will bend. When only one tooth touches another tooths the bending will be much bigger. The gear ratio isn't constant. We want to measure these differences.

So we have a rotary measuring device at the drive shaft and one at the output shaft. If the gear would be perfectly exact and if there would be no bending the period times of signal 1 should be the same as the period time of signal 2.

At the instantenous configuration there is one reference mark on each measeruing device. We call it trigger signal. We start to measure when we get such a trigger signal. The trigger signal of signal 1 comes to a different time then the trigger signal of signal 2. So the measuring of signal 1 and signal 2 starts at different times. This is our delay.

We use this triggering only because we whant to have a assignement to the 18000 strokes on the measuring device. In the future we could correct the errors of the measuring device.

But maybe we will try it without the triggering thing. So we won't need the delay.

After measuring we use Matlab for doing calculations on the signals.

Today i tested it with a very very high torque and i saw the different tooth on the diagramm. So we can't be so bad. But not good enough.

Hope you can help me.

Thanks

Jens

[Kevin_Price]

2. The quantization error I referred to doesn't accumulate, so you don't need to multiple by the 18000 cycles per rev.  I'm not sure I follow the other parts of your calculation.  The essence of the quantization effect is that the timebase can only count integer multiples of 12.5 nanoseconds (1/80 MHz).  So all the time measurements you make will be quantized to a neighboring multiple of 12.5 nanosec.  If your nominal measurement is going to be about 66 microsec, then the non-cumulative quantization error is (12.5 nanosec / 66 microsec) ~= 2 parts in 10000 per measurement. 

3. I'm going to take a guess here that you have an SCB-68 terminal block with a pinout sticker for E-series devices.  If so, you're going to want to print and tape an M-series label on it.  Then you'll see that you do indeed have a PFI-11 pin.  However, now that I understand your overall app better, this 2-signal separation mode may result in too many quirks to deal with.

4. Nevermind, not really crucial.

5. Ok, your app really isn't easy to get right.   The details you described are very helpful, but I'd think there'd actually be quite a bit more involved as well (maybe you already know this?).  Off the top of my head, here are some of the complicating factors:

A. Synchronize the two measurements in a repeatable way.  Repeatable may (?) need to depend on the exact tooth mesh state.  If you have a 37:24 ratio, the mesh state only repeats once every 37 revs of the faster gear.  You'll also need to make sure your two measurement tasks are sync'ed to start together using an "Arm Start" trigger.

B. Are you at a simple 1:1 gearing?  In general I'd expect your gears' tooth quantities to be mutually prime to help spread out tooth wear if you have defects.  If so, then your nominal gear ratio is no longer an integer and your two input signal frequencies will be different.  Then you can't do simple delay measurements.

C. Thought experiment.  Replace gears with a solid shaft from input encoder to output encoder.  Run with 0 torque.  Your input and output signals will still have a nominal phase offset because they aren't perfectly mechanically aligned.  Until you build the system, you don't know what this nominal offset will be.  And after you build the system with gears between, it'll be non-trivial to characterize this nominal offset.

D. Encoder error due to manufacturing tolerances.  This one you know about because you mentioned the possibility of one day correcting for them.  There will also be some 1-per-rev error due to shaft misalignements during installation.

E. Maybe you don't need a full 18000 measurements per rev?  You'll improve your quantization % error if you can reduce your effective sampling rate.  I'd think that if you got about 20 measurements per tooth mesh you'd have a good picture of what's going on.  That probably means <1000 measurements per rev.  There's a function available that'll decimate and average your data.

Perhaps there's an entirely different approach that could work?  If for example you just did some FFT analysis on the encoder variation, you could find the amplitude of variation at the tooth mesh frequency.  A trial run at low torque would tell you how much is due to the ever-present movement of the point of contact between meshed teeth.  The rest you could suppose is due to tooth deflection.

-Kevin P.

[Moschdschlotzer]

Hey Kevin,

you're really good. It's a SCB-68 terminal block. Thank's.

The other problems you mentioned are far far away from me till now. I am still working at the basics.

I am not so involved in these things till now.

Now i have another problem. Maybe you can help me there too:

For triggering the two signals we use a box which lets the signals only pass through if the trigger signals are at the ports.

So measuring signal 1 starts when trigger 1 is at the port of the black box. Measuring signal 2 starts when trigger 2 is at the port of the black box. (Measuring means measure the period time with counters crt0 and ctr1). A third counter on a second card is used for measuring the delay between the two signals. (cable from the black box to the card)

So it's a hardwaretriggering.

I want to realize this function with a LabView programm. But this isn't so easy.

How can i arm a digital signal with another digital signal? It doesn't work.

I tried it another way but still doesn't work.

regards

Jens

[Moschdschlotzer]

Look at the program in the attachement. This would be my new solution. But it doesn't work proper.

[Kevin_Price]

After your latest description, I no longer think I understand your app.  I don't understand what purpose is served by the "black box".  It seems counter-productive to me that you would use different triggers for your 2 signals because you lose the ability to correlate them with respect to time.

Or are you saying that the present-day setup uses this black box, and you're looking to replace it with a new LV program?  Sorry, I thought I understood before but this black box stuff has got me confused.  If it's something you still plan to use, can you describe exactly what it does for you and why you think you need it?  Also, what "second card" do you have available for measuring delay?

-Kevin P.

P.S.  You must have posted again while I was writing.  I'll try to take a look at the code you just posted when I get a chance.

Message Edited by Kevin Price on 11-21-2006 10:33 AM

[Moschdschlotzer]

I have to NI cards. (M-series and S-series) Each of them has two counters.

Today we need three. Because we measure the Period time of signal 1, the period time of signal 2 and the delay between the two signals.

For the both signals we get a trigger signal from the rotary measurement device. (the reference mark)

We want to start measuring at the reference mark.

The "black box" outputs zero untill the reference mark was at the port. But beside this function the black box generates a "one" signal with the delay time till the second signal trigger comes.

I hope you will understand this.

My problem now is doing the black box shit with LabView.

[Kevin_Price]

I think I have a fairly good understanding of "what" you are doing, but I definitely don't understand the reason.  Again, it sounds like your approach guarantees that your 2 counter period measurements cannot be properly correlated in time or in position to one another.   If I understand where you're headed, there are approaches that are both better and simpler.  It sounds like you don't really need to correlate variations to specific gear teeth, you just want to characterize the velocity variation caused by the gear mesh without regard to the position where it occurs.

A. Don't try to trigger your 2 period measurements off two different signals!  Trigger them both off the same signal so that their t=0 start time is identical.

B. Then when you take your 2 period measurements, you can also sum up your cumulative time totals and easily calculate the difference as your delay.  There's no need for the 3rd counter or the black box as far as I can see, unless the black box conditions the encoder signals into TTL-compatibility.

I did get a chance to look at the code you posted.  Honestly, I would recommend starting over from one of the examples.  It appears you're pretty new to LV and there's nothing wrong with that, but you've put together code that is presently more trouble than it's worth.  I don't have free time to go through all the details, but among the problems I remember:

• Trying to use the same counter for multiple measurement tasks simultaneously.
• Using software polling to handle triggering.
• Not keeping track of error clusters coming out of DAQmx calls
• Wiring that's quite difficult to follow (hidden behind case structures, etc.)
• Very large multi-screen diagram that requires scrolling

Take a step back and just try to measure periods on 1 signal by adapting a shipping example.  Then add an "Arm Start" trigger to start it from the reference mark.  Rotate the gears by hand to verify that the triggering and measurement is working properly.  When you've got 1 counter channel working well, *then* add the 2nd channel.

-Kevin P.

[Moschdschlotzer]

Hi Kevin,

yes i am a bloody LabView beginner.

A. But i want to trigger my two period measurements with two different signals. So that they don't start at the same time. The difference is the delay.

I am trying the ArmTrigger examples all the time. But they won't work. I can't even do a simple triggering. Why?

In the attachement you will find a very simple vi with only the basic functions. I wrote the error message into it. Maybe you can tell me what the problem is.

I am very grateful to you helping me so much! Thanks!

Jens