Can't make Digital Scope work

[CoastalMaineBird]

LV 2010, RT, PXI 6602 

All I want is a simple digital scope to look at a digital signal coming out of a COUNTER and judge whether another part of my software is working.

I wrestled all day with trying to make connections and finally gave up - LabVIEW just won't do it.

So, I managed to find a cable and make the connection myself via hardware (oh - the horror!).

I start a counter going.

I direct the output to a particular terminal.

I hardwired (with physical wire) that terminal to a DIGITAL INPUT port.

I made a task to read that digital input port.

I used a timed loop to read that input port a bunch of times.

I then plot the results.

No matter what I do, I read a different frequency than what I'm asking for.

It's always 85-90% of the period that I expect.

For example, I'm sampling the port here at 1000 uSec or 1 mSec intervals.

A check of the END TIMES, or the FINISHED LATE status shows absolutely no error.

But look at the plot one transition is at sample 429, the next is at 1298. That's a difference of 869 samples, or 869 mSec.

If I sample at 10 mSec, instead of 1 mSec, I get 134-45 = 89, or 890 mSec

If I generate 10 Hz and sample at 1 mSec, I get 138 - 48 = 90, or 900 mSec

So, which one is lying to me?

Is it really generating 10 Hz and I'm measuring it wrong?

Or am I measuring it right and it's really generating 11.1 Hz when I ask for 10 ?

For example

[CoastalMaineBird]

Changing the timebase from 80 MHz to 20 MHz changes nothing.  

So it's not like 1 Hz is on the end of resolution...

[JÞB]

Steve,

Try subtracting expected end i-1 from actual end i-1 and sum the array outside the loop.  I think that would help explain what you see

[CoastalMaineBird]

Try subtracting expected end i-1 from actual end i-1 and sum the array outside the loop.  I think that would help explain what you see

Well, here it is, but I'm not sure what it means.  I'm a rookie with timed loops.

That's the actual end time - the expected end time.

I suppose a positive number would mean it ends early. 

so... a negative number means it ends late?

But the FINISHED LATE never comes on.

If I change the LOOP dT to 10000, the SUM number is 10x or so.  But the waveform is the same: about 90% of what I expect.

If it's late with a 1000 uSec loop wouldn't it have a lot better chance of keeping up with a 10000 uSec loop?

Can you explain what you mean?

[Norbert_B]

Steve,

i think you are getting caught by this too much 🙂

You have to step back a little and watch the sign of the "sum". It is negative!

So the Expected End [i-1] is (at least in most times) BIGGER than Actual End [i-1]. Since Finished Late [i-1] never occurs (as you say) it is save to say that this is true for every iteration. So each iteration finishes BEFORE it has to in order to keep up your 1kHz clocking.

I think you have some other issues here:

A millisecond is not a millisecond.

This sounds odd, doesn't it?

But go search an answer to the question first: What is a millisecond?

Second question: How do you clock your acquisition? How your generation? Are you SURE that they share exactly the same timebase? I would say: NO!

Another point: Reading the DIO line will take some time. It is possible (most depending on system load) that this includes quite some jitter. You can see the jitter if looking into the delta times you use for "sum". If they differ much, you have a big jitter in the Read of the DIO line. But since you have no Finished Late, you don't violate your overall timing requirement.....

hope this helps,

Norbert

[CoastalMaineBird]

i think you are getting caught by this too much

--- Yeah, yesterday was frustrating. At every turn.

You have to step back a little and watch the sign of the "sum". It is negative!

OK. I'm a rookie at TIMED structures.  

That's the END of my code minus the end of the period in which I'm allowed to do it (and stay on time).

A negative result means I'm done EARLY.

I did look at the FINISHED LATE status and there were never any TRUE values.

So each iteration finishes BEFORE it has to in order to keep up your 1kHz clocking.

so... I don't understand what I was supposed to gain by looking at this.  The suggestion to do this subtraction was cryptic, as if it would be obvious once the number was known.

I could have guessed that there was no timing problem, reading one single bit from one single port at 1000 Hz on a PXI with nothing else running is not a big burden.

Second question: How do you clock your acquisition? How your generation? Are you SURE that they share exactly the same timebase? I would say: NO!

--- Fair enough question: the generation is clocked by hardware, the acquisition is clocked by whatever runs the timed loop.  I am sure that they DO NOT share the same timebase.

But I was expecting a difference a WHOLE LOT LESS than 15% .  That's awful. That's pathetic.  Is that really the best I can expect?

Another point: Reading the DIO line will take some time. It is possible (most depending on system load) that this includes quite some jitter.

--- Understood. But, this is a PXI 8196 controller (2 GHz Pentium M) doing nothing but sitting here watching one digital line go up and down (plus whatever supervisory overhead there is).

You can see the jitter if looking into the delta times you use for "sum". If they differ much, you have a big jitter in the Read of the DIO line.

--- I did exactly that yesterday.  Except for the first 2 samples, that delta T is 10000 uSec, with 2 or 3 spikes (out of 300 samples) of 10 uSec deviation from that, and everything else less than 3 uSec deviation.  At least 99% of the loops are within 1 uSec.

I find that to be pretty good.  But the value of consistency is lessened if it's consistently WRONG, in absolute terms.

But since you have no Finished Late, you don't violate your overall timing requirement.....

--- Which leaves me with the same question:  is the TIMED LOOP really that bad at timing things, or is my hardware generation somehow mucked up?

[Norbert_B]

I am stumbling about something else in your screenshot. CTR is the 6602, correct?

Looking into the pinout, PFI37 has no connection whatsoever to P0.0:

So i am wondering: Do you have an external connection there?

Norbert

[CoastalMaineBird]

Looking into the pinout, PFI37 has no connection whatsoever to P0.0

So i am wondering: Do you have an external connection there?

Yes. Well, the client does. This code is copied from the real program, where that output is redirected to PFI37 in the real world.

I don't think it affects this scope test, but I put it there just to copy the real code.

[CoastalMaineBird]

Well, on top of everything else, it's a thermometer, too.

I ran this test right after powering up.

At dT = 10000 uSec, I got consistent 44 samples per half-period.

At dT = 1000 uSec, I got 439 +/- 2

At dT = 100 uSec, I got 4380 +/-10

After some time, I got 4330 +/- 7  (1st pic below)

After 30 more minutes, I get 4318 +/- 6.

[JÞB]

Sorry, I'm being a bit obtuse.

The basic problem is you are trying to use the system clock as a deterministic timing source.  It just isn't so!

If I change the LOOP dT to 10000, the SUM number is 10x or so. But the waveform is the same: about 90% of what I expect.

If it's late with a 1000 uSec loop wouldn't it have a lot better chance of keeping up with a 10000 uSec loop?

Actual end is probably not the best meteric.  We probably should have used expected and actual start to see how often the OS interrupted our execution system.  How loaded is Core 2?  What are the properties for action on late iterations?  the default is to just plain skip it and wait for the next maintaining phase.  I am assuming that is what you are seeing since the actual frequency is shifted by the assumption time in the loop is constant.  It will not be and the jitter will be as bad as your OS timer (Sorry)

Edit: Somehow this went to draft rather than the thread.  Steve.  I wasnt intentionally trying to be cryptic, Just rushed.