CTRIO2

[johnofeasttex]

I was wondering how the development on the CTRIO2 was coming? Earlier last year it was "coming nicely".

[BobO]

It got basically completed, after which the heavy development load of the new PLC pushed it basically into the ditch. In truth, all we really needed was to get it UL approved, and then to move it into ADC's launch queue. As of last week, we were in the process of packaging a batch of modules to go through UL...CTRIO2 among them. Once we get UL's blessing, we will be launching.

Sad, I know. Make stuff folks want to buy, and we're too dang busy to pick it up and take it to the front door.

[Eric Nelson]

OK, it's been a few months. Any info on a release date?

-Eric

[BobO]

Currently in the queue at UL. I heard something about a commit date of June 9th, after which ADC will begin the launch process. Their launch process takes several months, so I would think sometime in Q3 it should be on the shelf.

[WRT]

If the design is fixed, then is an advance version of the specification / documentation available yet?  I want to start making plans...

[WRT]

I sure hope I can program it to count X pulses and then give me the Usecond time of the Xth pulse, then update the clock time X pulses later (free-running time measurements).

Among other things this is used on rotary encoders to filter out wobble during frequency measurements.

Bill Thomson

[BobO]

CTRIO2 is largely a drop in replacement for the CTRIO, but much higher performance. We did add a couple of new pulse profile types, but the changes have been relatively minor.

Can you not use a rate or interval scale with smoothing to do what you need?

[WRT]

I had added my comments to the RFC on the new CTRIO a couple of years back.

When doing accurate frequency measurements from a rotary encoder, you can usually expect some wobble (lack of concentricity).  The only good thing is that the inaccuracy repeats every revolution.  So if updating frequency once per revolution is fast enough, then all you have to do is count the period between X pulses, where X pulses is the PPR.  That's hitting the Easy Button!

If that update rate is not fast enough, then the algorithm gets more complex but can still be done by subdividing the revolution into more parts, for instance X is now =  PPR / 10.  Keep track of the last 10 readings and do a delta compare and you can have fast AND accurate, and still correct for mechanical wobble.

This is just one example of a range of uses for a good timer counter card, in addition to the current focus of the CTRIO design.

Bill

[BobO]

The problem is that this really requires 2 channels, a counting channel and a timing channel. There is really no good way to do that in the existing design.

As part of the new PLC design that we are doing, we will be doing a new high speed counting module that will be much more flexible. It would be reasonably easy to do what you are asking in that context.

[WRT]

Probably my problem is that I don't understand the internal architecture of the CTRIO.  I assumed that a free running Usec clock was used for calculation of all interval and frequency outputs.  So all I needed was raw output from the clock instead of the massaged values.  A single channel would simply count pulses, then output raw clock data.

Less CTRIO processing, not more, was my hope and expectation.

[BobO]

There is a free running microsecond clock yes, but for timing requiring accuracy...which I think is the point...we use capture registers. The scan time of the CTRIO can be as high as 2ms, which would be a great deal of jitter for software timers. If you can't do it right, don't do it at all.

You could potentially time the Z pulse and accomplish exactly what you are describing.

[WRT]

I am thinking of the 6522 timing chip from the 70's.  A wonderful chip for doing this sort of thing.

Doesn't the capture register grab the current clock value?  In which case I would have what I need?

[WRT]

Most encoders I deal with are single channel units without the Z.  I am not doing position control, this is strictly speed control applications.

Also since typically a single pulse per revolution doesn't give me fast enough updates,
I do the multiple calculations per rotation as I described previously.

Think big wind turbine rotors with multi-second rotational periods.

Actually, I may have misled you talking about encoders.  Typically I have a proximity switch mounted to pick up a machined gear wheel or bolt pattern, so it is really important to be able to cancel out repeating once per revolution errors.  So I also don't get to pick the best number of pulses per revolution, that's why I would like to count X pulses.

[BobO]

Doesn't the capture register grab the current clock value?  In which case I would have what I need?

In counter mode, the capture register stashes the count when the D input fires. In edge timer mode, we store the accrued time in the second register and then update the main accumulator with the result when we have it.

[BobO]

Think big wind turbine rotors with multi-second rotational periods.

We use 2 different mechanisms to scale to rate. For fast moving signals, we recommend the Rate scale on a counter. For slow moving signals, we recommend an Interval scale on a timer. In most cases one of the two modes will produce a good result. For yours, I would expect that the Interval scale on a Timer would be the way to go...but apparently not.

I said fast moving and slow moving...but meant fast occurring or slow occurring.