Can't make Digital Scope work

[CoastalMaineBird]

 How loaded is Core 2? 

--- I don't know why you're choosing Core #2.  But the processor is doing nothing but watching one digital line go up and down, and counting how many times it does it (plus whatever superivsory stuff is going on).

My real program has 12-15 TCP connnections, 200 channels of DAQ at 10 Hz going on, plus PID control of an engine. There's plenty of CPU hosrespower. All that is suspended for this little test.

What are the properties for action on late iterations? 

--- I tried the SKIP option both ways - no effect.

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)

--- The jitter is not the issue. The jitter is tiny and irrelevant to my needs.  It is 99.9% consistent.  Out of 300 samples, 270 of them are 10000 uSec exactly, another 20 are 1 or 2 uSec off and another 5 are 3 uSec.  That troubles me not at all.

--- It's very consistent.  The trouble is, it's consistently WRONG. By 12-15%.

[Norbert_B]

Steve,

i reprogrammed your VI running on a Windows PXI. Using a 6602, everything works as expected.

Since you are using a 1MHz baseclock for the timed loop, i would expect you to run on a real time target. Correct?

My test (1Hz, 1kHz loop rate software timed reading of DIO) shows something like:

1946-970 = 976, which would be about 2% off from your expectation.

1951-974 = 977

Question:

How old is the 6602 you are using? Is it calibrated?

Norbert

[CoastalMaineBird]

 i would expect you to run on a real time target. Correct?

--- Yes, I'm on a PXIi-8196 running PharLap.

How old is the 6602 you are using? Is it calibrated?

--- It's 4-5 years old and hasn't been calibrated since the factory.  But it's hard to believe that it could be off 15%.

However, today, there is news:

The same program that failed yesterday, and the day before, works perfectly today.

It's the first thing I ran after killing the boot program (my software is set to auto-run on boot).

And it gets a perfect answer every time.!

1Hz gets me 500, 2.5 Hz gets me 200 (I'm measuring half-periods).

Hmmm...  It's cold (60 degF) in my office at night.

[CoastalMaineBird]

Should have kept my mouth shut, it seems.

After 10 minutes, I ran it again:  It's down to 193 or so.

[CoastalMaineBird]

... and after another few minutes, it's down to 187.

Either the generator is speeding up with temperature, or the CPU is slowing down.

[Norbert_B · Accepted solution]

It seems that you have (as you indicated somewhere in the thread already) some kind of thermal dependency. This could indicate an issue with calibration.

Sure, 15% off sounds like exaggeration for "calibration", but you have an old device (recommended interval of calibration is every year for the 6602!) and you have thermal influenced.

Sadly, the 6602 does not provide a "self calibrate" routine to counter thermal influences. The easiest way to get a grip on if the issue is calibration based or not is to test the whole approach using another 6602 in another PXI.

Which reminds me: Is it possible that the PXI system has a defective fan or the outlets are blocked?

Norbert

[CoastalMaineBird]

I powered the PXI off for about 15 minutes and tried again.

Yes - it's back to reading perfectly correct.

The fans are not defective, but I'll clean the filters and see what happens.

[CoastalMaineBird]

 The easiest way to get a grip on if the issue is calibration based or not is to test the whole approach using another 6602 in another PXI.

Well, I don't have an extra one, but you said you tried my program in your system and it works.  So, that's a clue.

The filters were indeed very dirty.  I have cleaned them and reinstalled them.  The first run was almost perfect:

We'll see after a while.

My guess is the 6602 is not influenced so much by temperature: a crystal doesn't care much (15%) about 20 degrees temp difference.

But the CPU might very well have a "defense mechanism", where if it gets too hot, it slows down to generate less heat internally.

That would account for what I've seen here.

[CoastalMaineBird]

Well, after 15 minutes of running, it's still perfect.  

Looks like the filters being dirty did mess up the works.

As a software guy, it's good to be able to blame it on the hardware

Norbert, thanks for your persistence and prodding me to keep chasing it.

[Norbert_B]

I think both effects could take place with different impact. Looking into a sample curve for temperature influence on oscillators:

So drift is really depending a lot on temperature and, if presented as percentage, can exceed more than 100% additional temperature error.

E.g. rising the temperature from 20 degrees to 30 degrees changes the error 2ppm to -2ppm...this would be a change of -200%!

Well, nevertheless, it seems that you are on the right track to solve the issue. I hope you can now persui your original task.

Norbert

PS: figure copied from here.