GRV-IDCIFQ-12 Timer resolution and accuracy

I am looking at a flow computer project that will be used on a flow prover.

The API spec for doing this claims to require 100 nano second timer clock resolution.

What is the period measurement clock speed for theGRV-IDCIFQ-12?

What is the maximum timer duration?

Here is the problem:

  1. Need to start a period measurement on one channel using a single long duration pulse based on 2 high speed photo eye switches, one is a start switch, the other the stop switch, and connected together to create the ON pulse.
  2. Need another 2 channels connected together to provide pulse train duration time and a square wave count from the same source.
  3. The total pulse train duration time and the counts need to be triggered and stopped or captured from item one.

If I use Pac Control in Epic to trigger the start and stop of item 2, there will be significant and variable error introduced into the reading.

In Epic, unlike Pac controllers, there is no events and reactions where there was a predictable time value that could be associated with making that happen in the rack brain that could be compensated for. In the Epic even if I devote a chart to it with a 1ms delay, it really will not be a static delay.

I just happen to be looking some of this up.

Pulse measurement is limited to 100μs because that is the way it is stored in the memory map:

Counting is limited to 200kHz (5μs period) on the IDCIFQ. Period measurement has the same 100μs resolution as pulse measurement in the memory map.

100 ns timer clock- it won’t work on EPIC. You will need a quick PLC.

Yah, i was seeing various issues also such as how to accurately start and stop…
I think maybe a modus timer counter hardware is needed.
Something that has pretty high res and high clock speeds.
Too bad they did not use a timer in the module itself.

I assume that the quad module has a counter register on the module itself, otherwise the accuracy and repeatability would be limited to the scan rate of an epic chart, not all that good.

If the module can count at 200khz, then it is capable of capturing a 2.5 usec half wave pulse. That means the clock speed on the module is maybe 10 times higher than that, right? Therefore possibly a 4 mhz clock speed or maybe much higher.

It seems to me that Opto would not have used a lower or same speed chipset as in Pac, so my guess is that the limitations in Pac Control may have nothing to do with the limitations of the module itself, they just haven’t gotten around to or don’t want to upgrade that aspect of Pac because they are hoping everyone will end up using Code Sys…I certainly hope that isn’t the case.

I see that Ben hasn’t jumped in here, but I’d like to here what actually is the case.

I also have found a module (MCC USB-QUAD08) by Diligent and it at up to 10 mhz in 16, 32, 48 bit and has 8 input counters (single or diff) and 8 IO channels. It is programmable (or configurable) and it is USB with Linux and Windows API’s for C and Python.

Yes - I assume this is the case as well.

IO and memory map operations are independent of the charts - there is a separate process on the epic that handles IO (OptoMMP operations). The limitation may likely be the storage location in the memory map wasn’t setup to handle anything finer than 100μs. It may be possible for a new memory map location to be created for finer readings on these modules if Opto wanted to do that. I think the focus was on counting and not interval timing so this wasn’t done.

In your use case, I’m not sure if it would gain you any benefit since it looks like you want to respond to this event in a high speed manner which means bringing into PAC Control which of course will be much higher latency.

For analog waveforms the Nyquist sampling rate is 2 times the frequency so it doesn’t have to be 10 times higher. Though on a digital module such as this, the circuitry is likely responding to “edges” and there is no sampling.

Are you desiring to get this data into the EPIC? Looks like you will need to use shell and compile the libraries with no guarantee that you can get it to work.

Well actually if the quadrature input can be used to stop and start the pulse count and the period measurement, then no, it can be sampled very slowly. In other words, if one input can be used as start and stop trigger. I am not sure that is the case, but the MCC device has that capability.

There in lies the issue with the MCC module, otherwise it is about as close as I have come other than a UK module that is probably perfect, but then costs much more. Talks MB, TCP and RTU.