CTRIO Basics - Box Tracking on a Conveyor

[sgsims]

Looking for some basic information regarding how to use the CTRIO with an incremental encoder to track boxes on a conveyor.  I would like to create tracking windows and use the encoder in conjunction with an update photoeye in each window to verify that the box has reached the eye.

Confused about how the CTRIO counts the pulses and how I actually work with that information.  It looks like the CTRIO keeps a running total of the pulses from the encoder and places that count in a Vmem location that one specifies in the CTRIO workbench.

I guess I could work with that but eventually that running total needs to be reset to 0 again...I would think.  How does one do that without affecting the active tracking occurring with any boxes on the conveyor?

I am thinking there is something I don't understand regarding the running total concept.

[Greg]

You are correct in that the CTRIO keeps a running total of the pulses from the encoder connected to its inputs when its inputs are configured as counters (single-ended or quadrature). It automatically maps this information in V-memory where you tell it according to mapping. The total will most certainly roll over. It is a double-word 2's complement number (range -2,147,483,648 to 2,147,483,647; i.e. +/- 2.1 billion). It will roll over if not reset. You can reset the count using the Software Reset bit, or you can configure another CTRIO input to reset the count on an external pulse.

For example, you could:
- Configure CTRIO Channel 1 Input A as Counter and hook your incremental encoder to that.
- Configure CTRIO Channel 1 Input C as Reset Fn 1.
- Configure CTRIO I/O Mapping:
     Input Map: V2000-2025
     Output Map: V2030-2061

If you did this, then:
- The current encoder count would show up in V2000-2001.
- The count could be reset by a positive edge on the CTRIO Channel 1 Input C.
- The count could be reset by setting bit V2054.1

Mapping is shown in the I/O Map in CTRIO Workbench and the manual.

[sgsims]

Greg,

Okay very helpful.  At least I know I am on the right track with understanding the running total count and the reset.

I need to think a bit about how I keep track of the counts in each one of my tracking windows.  Still not sure how I can reset the running total without affecting the active windows which are depending on that running total to track the box through the window.

[ATU]

Is it a cleated conveyor?

[sgsims]

Nope just a regular belt conveyor.

[ATU]

How many boxes are on the conveyor at any given time?

[sgsims]

could be up to 12 boxes on the belt conveyor at a time needing to be tracked to one of seven divert lanes.

[ATU]

I never did that with a flat conveyor, I always had the luxury of a belt with cleats, always worried about belt slippage. Although, I would think to keep the resolution as low as absolutely necessary in order to keep your numbers small.

[sgsims]

Yes,  I agree about keeping the resolution low.  I was thinking something like 1 pulse per Inch.

[ATU]

Is the conveyor on the section you are tracking one belt?

[Controls Guy]

could be up to 12 boxes on the belt conveyor at a time needing to be tracked to one of seven divert lanes.

What I've done that was similar (not using a CTRIO but the built-in HSC on the low-numbered inputs on an 06), was when a unit entered the system and I knew where it needed to go, add the counts from the current conveyor position to the divert location in a "to-do" list.  So if the current count when a box enters at the entry point is 40,000, and the distance between the entry point and the divert lane for that box is 50,000 counts, watch the current count for a value of 90,000 and kick the corresponding diverter (or when the previous package passes, etc., depending on the mechanical design).  That way, you can have many tasks active at once.

In my case I didn't need to worry about rollover, because the parts came to me in batches of 15-20 with a pause in between, and the 32-bit counter was more than big enough to accommodate all the conveyor travel for a batch, so I just reset the count at the end of the batch.

[ATU]

I was thinking that if you had a feature on a single belt in the tracking area, then you could use it to reset your counter. Then use clock math to do your calculations.

[sgsims]

ControlsGuy,

Good information.  No that I understand the running total and reset concept I think I am going to do something similar to what you explained. 

I was thinking about setting up a series of windows at each divert point with an update (divert) PE at each window.  I'll use the current count from the encoder to track the box to the PE.  If I see a box at the PE before It should be there (some sort of +/- tolerance) I'll send it to the No-read lane.  If I don't see the box by the time I reach the upper bound of my range I'll take that box out of the queue.  I can do some math based on the fixed # of pulses I know it will take for the box to get from one end of the window to the other.

After understanding the size of the Double Word location that holds the running total from the encoder I think I will be OK resetting that RT at the end of the day.  I think I will only need to measure 1 pulse / Inch.

[Controls Guy]

One thing I found helpful on that project was "poor man's function call with returns" to do engineering unit to count conversions, IOW write a subroutine that takes the value in the accumulator (doesn't begin with an LD) and does an operation on it.  Doesn't DO anything with the result, just returns.  Then when you resume execution at the calling location, the result value is already stored in the accumulator, just as if you'd done it inline.

So, when I had to do some arithmetic based on physical locations, I LDR'ed the distance as a real in inches or feet, followed by the GTS, followed by code that was expecting to work on counts, all on the same rung.