Hello,

I'm having problems with HSC not reading correct values. I made a simple example showing the problem.

The problem is that I have two HSC configured the same, just counting upwards with no interrupt OB's or anything. The counters are feed with the same signal, 15kHz. I want to read the counter values in my cyclic OB and take the difference. As the HSC are feed with the same signal, one would assume that reading the values with :P would result in the same counter values, give or take 1 LSB. And normally, the diff is 0 or 1, but sometimes, the diff jumps to 9 or 10 (sometimes in between), and in the next cycle, back to 0-1. See the attached image for main program block and a trace with diff over time.

Will post program and a zoom-in on a problem area soon. 

Here is the zoom-in of a jump from 0 to 10 for the diff. Red trace is Counter1 value, blue is Counter2, the pink trace is the diff between those two counters. 

At the first cursor, the counters are the same and diff=0.

At second cursor, counter values are different by 10 and hence diff=10.

And in the next program cycle, the diff is back at 0 again.

Good test and presentation!

Did you notice that the values are always negative?

Maybe there is a time gap
between reading ID1004 and then again ID1000?

I think the result has something to do
with the PLC's updating communications.

Maybe you'll see something different
if your PC does not communicate with the PLC.

w

And here is the project, unzip and make a Project/Retreive to open it.

Any idea what could be the problem?
This kind of scenario can not be that obscure? 
15kHz for HSC is far from the specification limit. At 4kHz, I get diff up to 3.

Hello and sorry for a late reply. Thanks for your answers.

William_B - Yes, I noticed that and in fact, if I change the order of the reading, I get positive spikes. And yes, it looks like there are a time delay between readings.

huggy_d1 - As always, you can not measure something without interact with it... But my philosophy is that if it "can" happen, it will happen. And this is kind of critical behavior for out application. Maybe I need to back of my expectations, but I'm almost there now, see below :)  If it's impossible i can filter the signal some, but that is not perfect.

By making a cyclic interrupt at 2mS, maximum priority(24), disable all other interrupts in this OB(DIS_AIRT/EN_AIRT), )and reading the values there, I now have only have like +-1 counter value difference to much. 

Communication interrupt should be handled in main cyclic OB, so that "should" not cause delays in my cyclic OB. Putting a runtime meter for the read of the values, and looking att the diff and the runtime meter, I can tell that for each "glitch" the runtime is higher than normal. This must be some internal CPU interrupt that is not disabled bu DIS_AIRT.

I also have tried the POKE_BLK command in SCL, but that was much worse.

If one could use the UMOVE_BLK it could work, but I do not get how to address the HSC values directly into an array?

Is there any solution to disable ALL internal interrupts in CPU in my cyclic OB?

Any other instruction for a complete non-interruptable block move?

See attachment for the cyclic OB code and a trace (red=diff, green=runtime for the move instructions). One can clearly see that the processing of the move instructions is interrupted by something, and HSC_counterLoad move instruction is delayed.