Feature input wanted!!

[b_carlton]

I haven't had too much trouble in using an external differential-single ended buffer. It would add a lot of board real estate to provide that for the few using differential. Regarding keeping the position a supercap (with the understanding that this would be short term memory only) might help.

[BobO]

The big issue with holding RAM state is that it requires a low-power static. Those parts work great, but tend to be slow, and when you have only one memory on board, it can be an unacceptable compromise to slow down the CPU's memory access rate to match the memory.

An interesting aside...the CTRIO's clock rate is 16Mhz, even though the CPU could handle 20Mhz. Why? Because by slowing down the CPU to the point that instruction access was 1 clock instead of 2, the overall system performance was increased by 30 or 40%. Sometimes you gotta go down to go up. Reminds me of a few life lessons.

The new CTRIO2 has only one memory...a high speed dynamic RAM. But never fear...I think we can make this happen transparently, and accumulator retention becomes a simple checkbox in the configuration.

[JohnB]

I would like to see a dual channel (or more) CTRIO card that could do a rate calculation as well as return a raw or scaled count on each channel. I have tried tying both channels together and trying to drive them using an Automation Direct encoder (TRD-N100-RZWD) using a 24 VDC supply, with one channel set to do a rate calculation and the other channel set to return the pulse count, but the encoder apparently had problems driving both channels simultaneously.

[BobO]

With some of what we are kicking around, that should be simple. The current limitation is memory map...it's already pretty big. A big part of what we want to do with the CTRIO2 is to improve the CPU integration. Meaning, the PLC will have an intimate knowledge of the CTRIO2, and will be much better at exchanging data between the two. The previous discussion about accumulator retentiveness is actually similar. Stuff that has been very difficult to do previously, becomes almost simple when the PLC knows the CTRIO2 and has a cleaner way of expressing data from modules.

Without saying more...yes, another teaser...think dynamically generated structure representing the memory map of the module as configured. That's a mouthful, but it means that we can express the module's data directly in the PLC in the appropriate format. Having a counter's scaled data, raw data, captured data, etc., all present at the same time becomes simple. I think that would solve your problem nicely.

[PLCGuy]

Reading all these posts, I remember what I would like to see. I remember doing a project and I wanted to see positioning. It has to be there. It seemed too much to map and get the data if it can be done already. If it can be done, make it simplier. I was trying to see what the counter was at and could not. I forget exactly what I was trying to do, but I think it was trying to get the position and counter data and read them.

[BobO]

That's a little ambiguous, but I get the "make it simpler" part.

If you are trying to get the position from an encoder, it is already pretty easy. Configure the quad input channel, and tell me where in the PLC's memory you'd like it to go. Doesn't get much easier than that.

On the other hand, the pulse output functions are somewhat more involved. The IBox functions introduced in DSP 5 dramatically reduced the complexity...but it is still harder than we'd like it to be. Stuff like that will definitely get improved.

Even the basic quad input should get a tiny bit easier with the CTRIO2. I think that all you'll have to do is tell me you want a quad input and tell me which of the CTRIO2's physical inputs you'd like assigned to the function and <poof> it'll just show up in the PLC's memory. We'll work on the psychic mind reading configuration tool for CTRIO3.

[jondecker76]

I would like better access of internal registers (using RD and WRT on a DL05 PLC for example).
Mainly, the scaling parameters.. It would be nice if I could create a solution, then have a setup page on my HMI screen where the user could enter the encoder PPR, smoothing, etc. parameters. This way, an end user of my solution would not neet to use CTRIO Workbench to adjust these settings, rather, it would be fully integrated in the HMI.

[WRT]

Please remember us guys that do things with the CTRIO that you never imagined.  My need is very basic.  I need to be able to have the CTRIO record its clock time for edge detections on two input channels.  Don't process the signal, just let me get access to the CTRIO clock time and I'll do the rest, including missed events and counter overflow.

So the idea is to not think applications, but provide very fundamental access to the internal clock on the CTRIO.

Requests:

1. Be able to read the current clock time on demand.  If Useconds, then even 16 bits will overflow only 15 times a second, the PLC can scan fast enough to deal with that.

2. Record the clock time when an edge event takes place, either positive, negative, or both. 

3. Allow either free-running or PLC reset modes for item 2

4. Do item 2 for at least two inputs simultaneously independently, all four would be fantastic!

Bill Thomson

[WRT]

Please provide some simple elementary functionality for those of us with esoteric timing needs.

I simply need PLC access to the CTRIO current clock count, and to be able to access the edge detection time (using the same clock base) for any or all of the inputs individually.  It would be desirable to be able to chose positive, negative or both transitions as is done currently.

I realize that the PLC and CTRIO will only communicate once per scan, but this functionality will still work for me.  The PLC can do the rest of the processing I need.  For this purpose I don't need any  status flags, as the time stamp itself will supply enough information. 

[gjones]

I would love a Ziplink connection if I could use line driver encoders

[ERokc]

It would be nice to import discrete preset table data into Designer.  The same for Memory Blocks would help too when ROM tables are needed.

[Bill_1000]

I'm no Ctrio expert but on this project with 16 encoders & Do More PLC; I set up all the Ctrio stuff as retentive. But that didn't work ! After I lost all the data several times I had to add logic to save the position data to D mem and reload it on boot.

Seems to me the retentive alt to work, nice a simple.

bbass

[BobO]

I'm no Ctrio expert but on this project with 16 encoders & Do More PLC; I set up all the Ctrio stuff as retentive. But that didn't work ! After I lost all the data several times I had to add logic to save the position data to D mem and reload it on boot.

Seems to me the retentive alt to work, nice a simple.

bbass

What you marked as retentive was the Do-more structure, not the underlying hardware register. I realize that from the user's perspective the difference is semantics and it should just work, but the CTRIOx wasn't designed for Do-more, so sometimes we are a bit limited in what we can do.

The good news is that yes, we agree with you, and in BRX (new design!) we added retentive counter accumulators. So while it may or may not get fixed in CTRIOx, it is already fixed in BRX.

Since BRX currently doesn't have a counter expansion module (coming early next year), BRX can't yet replace 205 for apps like this, but that is coming...and better actually. The BRX replacement for the CTRIOx is still only 8 in/4 out, but will support 4 quadrature inputs per card...so your 16 encoders can be done in 4 modules (if you don't need Z pulse or other inputs).