Options for multiple encoder driven events

Hello,
First off I want to thank the users of the forum for helping over the years answering many questions!


Here the my dilemma...I would appreciate any thoughts on it.


In the past, I have used Counter Cards with their Channel Outputs tied to a DC Input module with Change-Of-State enabled to create event based tasks for encoders operating a bitshift. I've had success with 2 active encoders. FYI its a ControlLogix system (L71)


The situation I am faced with now, would require 4 active encoders generating their respective events.

Each task would have 2 COP instructions operating on a large array (230 words) and a smaller one (120 words).


Encoders are driven by conveyors going roughly 450fpm, and would generate interrupts every 2" of belt travel (45 triggers per second).


Is 4 too many? Will the tasks overlap and causes errors? Setting the priorities, would it be possible that #4 might not run/miss if #1 triggers before it? Not sure if there is a scheduler involved to "queue" the tasks...


The continuous task is fairly simple, some MEQ's, OTE's and some basic photocell logic.



Any thoughts?
I figured I could build and try it but figured someone might have experienced something similar before


Thanks again!

I personally have not done that, but looking at your numbers I would hesitate.


45 events times 8 COP's would be 360 events per second on a PLC that probably at best will scan 150 times per second, and the larger the program the less scans per second.


My first though would be to increase the conveyor travel per event, at 450FPM an event every 24" would give you the data you need with much less processing



Unless the product on the conveyor must be tracked in 2" increments? If so maybe a single encoder for 2" and the other 3 for 24"?

There are 4 sorting lines so 4 encoders are a must.
Basically, logs are being scanned and sorted.
So the 2" steps are required in the process as its scanning their diameter. The COP on the larger array would be every 6"(so every 3 events).

The processor has not been selected yet. The L71 was the one I had used for 2 encoders with much success.

That is indeed why I posted, I am very hesitant to go down this route for scan time reasons...


Thanks for the reply and confirming my suspicions!
Now, back to the drawing board


One other option might be to have multiple lower-end processors in same rack sharing inputs, and produce/consumed tags...

What are the COPs doing? Are they shifting the array data relative to itself (FIFO?), or are they actually copying hundreds of elements of new data dozens of times per second?

Shifting data

Data do not have to be shifted to implement a FIFO, the data can be static and the indices of the start and end of the data can "move" (be manipulated) instead, so the array becomes a circular buffer, which will reduce the CPU load per shift by at least an order of magnitude and a half, maybe two, so managing FIFOs might be well within the capability of one PLC.

If it is 4 separate lines what about 3 lines having its own CompactLogix doing the computation for that line, the 4th line have the ControlLogix doing its work and reading the other 3 as a master?

Also, as stated above a FIFO would be better than a lot of COPs.

I don't think a CompactLogix would have any problem keeping up with that rate of events if the FIFO is implemented as a static circular buffer with moving indices. Cf. this link for a MicroLogix 1100 doing something similar i.e. maintaining a FIFO with events arriving at 300Hz+.

P.S. I knocked this together quickly this morning; I'll add comments later.

drbitboy said:

I don't think a CompactLogix would have any problem keeping up with that rate of events if the FIFO is implemented as a static circular buffer with moving indices. Cf. this link for a MicroLogix 1100 doing something similar i.e. maintaining a FIFO with events arriving at 300Hz+.

P.S. I knocked this together quickly this morning; I'll add comments later.

Click to expand...

Comments are done.