1ms bit shift for tracking

[LWright]

Hi All. I have a very specific question about tracking using an encoder and bitshift register. We would like to use a Compact or Control Logix PLC but when we tried a few years ago (>5) I found that we couldn't get it to work as well as the ML1400. It was limited by the I/O scan time. On the ML1400 we track multiple objects (>300) at up to 1000 increments a second with 20480 bits (5 x 4096). We also have numerous devices attached where we check the time and distance between events. I would like to keep the 1ms cycle time and if possible shift more bits. Is this something anyone else has done? I don't know how to overcome the I/O limitation and mostly just want to know if it is possible but pointers on how to do it in a Compact or Control Logix are appreciated. Thanks, Larry

 

[Peter Nachtwey]

I did it differently. I changed an index instead of shifting bits. If you shift bits one bit at a time, it will be slow. Shifting DWORD one bit is much faster than shift each bit individually but why shift all these bits? It requires a lot of reads and writes to memory whereas indexing a pointer is much faster because the data doesn't move. Now all the stations are offsets from the index.

If the bits simply tell if something is on or off there are other methods. If you want to shift real data there are tricks.

 

[drbitboy]

I am curious to see that ML1400 code; PDF would be best.

If the increments run at 1kHz then the scan cycle has to be below have a millisecond I would think (unless it is using the HSC?).

 

[drbitboy]

I am curious to see that ML1400 code; PDF would be best.

If the increments run at 1kHz then the scan cycle has to be below have half a millisecond I would think (unless it is using the HSC?).

[Corrected typo above]

 

[lfe]

I agree with @drbitboy, the scan time has to be much less than 1ms, otherwise you will lose some counts

 

[robertmee]

He's using an encoder, so likely the high speed counter inputs which are 100Khz. Would need a better explanation of his process to understand how he's using the counter to track. I think the scan time on an ML1400 is 1ms per 1K roughly, so whatever the OP is doing, I doubt the scan time is less than 1ms. But I'm just guessing on limited information.

 

[LWright]

Hi everyone! I'll go a little more in-depth. This is very much like the basic tracking of a part on a conveyor example. Except fast. I use a HSC for the encoder input which increments a value. I use an STI set to 1 ms to handle all of the tracking logic. (normal stuff is in the main loop and I/O modules) I can have one or more bit shifts to track presence, pass, fail, etc. In the 1ms timed interrupt I capture the inputs via an immediate input, I read the sensors (optic, pass, fail, etc.), I latch on bits at locations in the bit shift files using indirect offsets, and if the encoder has shown movement I do bit shifts, calculate output states at locations, set output, and perform immediate outputs. I have to limit the bit shift events to 1000 per minute(plc limitation). There are several tricks I have to do to keep this loop under 1 ms. I hope this helps with understanding. I don't know how to replicate this in the Compact or Control lines. The first major issue was that the I/O is through a bus and the HSC is a device on the bus so there was no sub-millisecond HSC event that can occur and no immediate I/O. I hope I'm missing something because I love some of the 5000 functionality.

 

[mad4x4]

Hi everyone! I'll go a little more in-depth. This is very much like the basic tracking of a part on a conveyor example. Except fast. I use a HSC for the encoder input which increments a value. I use an STI set to 1 ms to handle all of the tracking logic. (normal stuff is in the main loop and I/O modules) I can have one or more bit shifts to track presence, pass, fail, etc. In the 1ms timed interrupt I capture the inputs via an immediate input, I read the sensors (optic, pass, fail, etc.), I latch on bits at locations in the bit shift files using indirect offsets, and if the encoder has shown movement I do bit shifts, calculate output states at locations, set output, and perform immediate outputs. I have to limit the bit shift events to 1000 per minute(plc limitation). There are several tricks I have to do to keep this loop under 1 ms. I hope this helps with understanding. I don't know how to replicate this in the Compact or Control lines. The first major issue was that the I/O is through a bus and the HSC is a device on the bus so there was no sub-millisecond HSC event that can occur and no immediate I/O. I hope I'm missing something because I love some of the 5000 functionality.

I think the choice of PLC may be limiting you, there are PLCs on the market that can handle 1ms control loops with very fast scan times of IO. May look at these and then you won't have to use "tricks" to keep the scan under 1ms.

 

[drbitboy]

It makes sense to use the HSC as the input pacing events are faster than the PLC.

I don't see why an analogous approach would not work in CompactLogix/ControlLogix, unless those PLCs cannot drive a 1ms STI. Certainly updating an index, which models the conveyor belt being stationary and the conveyor frame moving, would minimize the amount of code in the high-frequency interrupt routine.

There may be an issue with the Logix PLCs' I/O being asynchronous with the continuous program scan, so input value updates will interrupt, and change the values during, the middle of a program scan, but that can be dealt with via buffering. And you probably already deal with something similar with the STI routines in the MicroLogix.

An alternate approach, to the STI (timed interrupt), would be to have the HSC trigger an interrupt routine each time the accumulator reaches the preset, which preset I assume could be small (2 or 3), and which interrupt routine would reset the counter value to 0.

There is also the Event Interrupt (EII), which could trigger calling an interrupt routin on the rising edge of a high-speed input (equivalent to using the HSC Interrupt with a preset of 1).

 

[robertmee]

ControlLogix and CompactLogix would be limited in some respects.

CompactLogix supports only Instruction Event Interrupts.

ControlLogix supports Motion, Consumed and Data Change on an Input.

You can set up Periodic tasks to run at .1ms if you want, but you have to be careful with task overrun. In essence, whatever logic you execute in the Periodic task must have a shorter scan time than the periodic value. So if you set a .1ms periodic, the execution of the logic in that task must be less that .1ms worst case.

However with all that said, I don't know how you get around the RPI limitation of the CLX/CPLX backplane. Even the 1756-HSC card has a minimum 2ms RPI. Meaning the controller only polls the HSC card for data every 2ms.

 

[LWright]

drbitboy:
I'm not sure I understand how updating an index would work. Can you point me to a resource that I can follow up with?
Previously when I tried using the HSC interrupt directly I had an issue where occasionally the encoder would move too fast and cause the PLC to fault. With the STI, it's limited to 1000 IPS which prevents faults.
Maybe the Compact/Control Logix have faster I/O scan times now. I need to research that aspect.
Thanks so much for your input. Please let me know about using the index and if there is anything else.
Larry

 

[LWright]

Thanks robertmee:
This is very specific to my concerns. Previously we asked our Allen Bradly/Rockwell representative for direction and I think you are far more clear.
I was hoping they would have a faster version of the 1400 and include implicit EIP (dreaming!) but everyone keeps saying that they are getting ready to phase them out for the 800 series. Only the 800 series doesn't do several of the functions I need.
Larry

 

[robertmee]

Thanks robertmee:
This is very specific to my concerns. Previously we asked our Allen Bradly/Rockwell representative for direction and I think you are far more clear.
I was hoping they would have a faster version of the 1400 and include implicit EIP (dreaming!) but everyone keeps saying that they are getting ready to phase them out for the 800 series. Only the 800 series doesn't do several of the functions I need.
Larry

Reading your description it comes down to how much do the encoder counts move in a 2ms window and would that be a problem? In otherwords, if the encoder count is 2ms old (instead of 1ms) is there enough of a deadband to deal with? You can still run a periodic task every 1ms, but the data from the HSC would only update at half that rate. The HSC has four immediate outputs (for something like cam control) that are faster than the 2ms limitation, but I'm not sure if that would be of any value in your application. You could wire them to an Input module and configure those inputs of COS (change of state) which would immediately update in memory instead of waiting for the RPI.

There's probably some tricks that could be done with a combination of settings and modules, but nothing likely as straightforward as the ML1400.

 

[drbitboy]

drbitboy:
I'm not sure I understand how updating an index would work. Can you point me to a resource that I can follow up with?

Here is an old thread: https://plctalk.net/qanda/showthread.php?t=129424

That may or may not be clear so I will try to describe the process.

Background of what I assume you do now:

• We are modeling products on a conveyor with an array of 20480 bits (5 consecutive x 4086-bit B data files on a MicroLogix).
• The 20479th bit location in the model represents the upstream end of the conveyor
• The 0th bit location in the model represents the downstream end of the conveyor
• All bits in between those two end bits in the model represent discrete positions between the upstream and downstream ends of the conveyor e.g. the 10240th bit represents a position midway between the conveyor ends.
• The value of each location's bit represents (models) something about the state of whatever product (or empty space) is at that bit location's corresponding position on the conveyor e.g. a bit value of 1 could mean a broken bottle was detected and is now at that conveyor position; a bit value of 0 could mean either a non-broken bottle, or no bottle at all, is at that conveyor position.
• Every time the conveyor moves by some fixed amount, all of the bits' values are shifted one bit position left (BSL) i.e. towards the 0th bit in the array.
  • This models every product on the conveyor belt moving one position relative to the conveyor frame
• There are stations along the conveyor with position that are fixed relative to the conveyor frame
  • the belt moves the products past these stations
  • e.g.
    • there could be a bottle inspection station near the start of the conveyor, and
      • that inspection station position corresponds to the location of the model bit array at index 20000 (word 1250, bit 0), and
      • there is a camera or other device that looks at the bottle at that inspection station.
      • That camera is connected to a discrete input on the PLC:
        • a value of 1 for that input's bit models a broken bottle is detected;
        • a value of 0 for that input's bit models a non-broken bottle, or nothing, is detected
        • The PLC logic latches (OTLs) a value of 1 into the bit at index 20000 any time the camera's discrete input is 1.
          • N.B. we assume the BSL/shift operation writes values of 0 to the bit at index 20479 at each shift, indicating and unbroken, or no, bottle.
        • The PLC logic shifts those 1-valued bits (broken bottles) down to lower indices; it does the same with the 0-valued bits, of course; this models the movement of bottles along the conveyor.
    • there could be a reject/divert station near the end of the conveyor, and
      • that reject/divert position corresponds to the location of the model bit array at index 1000 (word 62, bit 0).
      • When the PLC detects a 1-valued bit at index 1000, that models a broken bottle at the reject/divert station on the conveyor,
      • so it activates the diverter output to push that bottle off the line.

It's long winded, and probably takes less time to code than to describe, but that is probably something like what you do now. The key point is that any given index (1000, 20000, 9876) of a bit in the array models a fixed position relative to the conveyor frame, so the bit at array index 1000 always models the bottle state at the reject/diverter station, and the bit at index 20000 always represents the bottle state at the inspection station.

Alternate approach using variable indices to represent conveyor positions that are fixed relative to the conveyor frame.

Assume a similar initial setup to that described above.

• Initialize an integer, call it END_INDEX, to 0
• The steps are similar for the first few scan cycles, until the shift event:
  • a 0 value is written to the bit at index 20479, modeling an assumed unbroken bottle, or no bottle, arriving at the upstream end of the conveyor,
  • the bit at index 20000 is OTLed to a value of 1 if the camera detects a broken bottle, and
  • the diverter is activated if the bit at index 1000 is 1
• What is different is what happens at each shift event:
  • The bit values are not shifted along the array, and
  • instead the value of END_INDEX is incremented by 1, from 0 to 1
    • This models the conveyor frame moving upstream relative to the conveyor belt and the products on that belt.
    • the absolute indices of the array model position relative to the belt.
• So the fixed-frame positions (upstream end, inspection station, reject/diverter station) are modeled by indices that are at fixed offsets from the value of END_INDEX.
• i.e. when END_INDEX is 1,
  • the absolute index of the reject/diverter station is 1001 (= 1 + 1000),
    • and activate the diverter if the value of the bit at that index 1001 is 1.
  • the absolute index of the inspection station is 20001 (= 1 + 20000),
    • and OTL a value of 1 into the bit at that index 20001 if the camera's discrete input value is 1
  • The absolute index of the start end of the conveyor is 0 (= (1 + 20479) MODULO 20480)
    • and write a 0 as the value of the bit at that index 0,
    • N.B. 1 + 20479 = 2480, but that index of 20480 is off the end of the array, so it "wraps around" to the beginning of the array i.e. index 0
      • This "wrap around" is why we call the bit array a "circular array."

So instead of shifting the bits of all 20,479 bits (1,280 words) at each shift event, the code has to only

• increment the value of END_INDEX by 1, and
• calculate a few absolute index values at fixed relative offsets from END_INDEX, with wraparound.

 

[OkiePC]

Instead of shifting bits or shuffling numbers, just build a memory map for each of the conveyors and use the encoder to drive a pointer that moves around that map.

I did this with a complicated tire sorting system in a PLC-5 many years ago and it worked very well.

I had multiple locations along that conveyor where tires got dropped in so they each had an offset from the main pointer for that conveyor section, so I could plop new data into my "map" as each machine dropped in a new tire. I had a photocell at the ends of each section so that I could find the data for that tire and move it to the right location in the next map.

Since there was no tire smaller than 1 foot in length (diameter), I used 1 foot as the resolution for my map. Each element in the integer file represented 1 foot of conveyor space. When a tire entered the system, I added its drop offset to the encoder driven pointer rounded to the nearest foot. When a tire left the section, I found the nearest value with the 3 nearest element in that data file and copied it to the next section and cleared it. When the pointer rolled past the length of the section, I wrapped it back around to the beginning.

It's harder to describe than it is to visualize if I still had that code and a way to animate it.

It's a whole lot less moving parts and should work the same way even for a higher speed system with a higher resolution map. My