Controllogix count using event

[pauly]

We are looking to use an event driven task to count meters of material on a machine from a proximity switch. Every pulse of the switch initiates the event driven task which will add a value of meters to itself. The maximum frequency of the pulses will be around 70hz so the event will (hopefully) trigger every 14 milli-seconds. My question is will this have a detrimental effect on the rest of the scan for the other code? Also has any one else done a similar thing without using a counter card?
The processor is an L72S. I am debating the use of a dedicated 1756-HSC counter card for the application

 

[widelto]

I have done it with no problem. You have to setup your digital input to trigger your event task.

 

[daba]

We are looking to use an event driven task to count meters of material on a machine from a proximity switch. Every pulse of the switch initiates the event driven task which will add a value of meters to itself. The maximum frequency of the pulses will be around 70hz so the event will (hopefully) trigger every 14 milli-seconds. My question is will this have a detrimental effect on the rest of the scan for the other code? Also has any one else done a similar thing without using a counter card?
The processor is an L72S. I am debating the use of a dedicated 1756-HSC counter card for the application

Of course it will !. The Logix5000 processors are single-cored and single-threaded, and can only do one thing at once. Executing an Event Task will always have priority over the Continuous Task, which always has the lowest priority and cannot be changed.

Now the discussion opens up to what you mean by "detrimental". Your event task is only going to count pulses, so the code in it will be minimal, and I would expect that the event task can be completed in less than 100 microseconds - is this going to be detrimental to the rest of the logic ? I very much doubt it....

Just remember to change the default Input Module configuration of "change-of-state" notification, which is both Off to On, AND On to Off

 

[gmferg]

Event tied to module, not single input.

As I recall an event task assigns an entire module. You can't assign a single input point. This means that a change of state on any of the inputs on the module will trigger the event task.

I have used this feature with an event task that only cared about 2 inputs on the module and the other 14 were used, triggered the event and the logic ignored it. The logic within the event is kept as short as possible so as not to tie up the processor. There was no noticeable difference in scan time.

 

[Anirban Hazra]

Actually,one can set up the event task to be triggered by the change of state of either one point or multiple points.However, using the change of states of multiple points is not suggested because that may lead to overlapped triggering of the event task.

Also, although the event task can be triggered through a single point's change of state the module multicasts the data for all its points at the instance the designated point changes to a specified state or states.

 

[gmferg]

Ah yes, you're right. At the module level select which inputs should report change of state.

 

[dskplc]

Hi, this thread has been helpful in setting up events but I am still wondering how I can prioritize 3 different events (a fire, evacuation, and gas leak) that may occur at one time in a factory. I know the order I want but do I set these up as Event Tasks? If so is there any sample code (5000) I could see? Otherwise I was given the hint to use MOV to set up my event priority. Thank you for any help.

 

[daba]

@dskplc

Each task has a "Priority" setting, the lower the number, the higher the priority.

If, during execution of an event task, another task is triggered which has a higher priority, then the controller switches execution to the higher priority task immediately, returning to finish the lower priority task once the higher priority task has completed.

The task with the highest priority can not be interrupted, and will complete. Any lower priority tasks that might have been triggered during execution of the higher priority task will then be executed.

The priority setting levels (1-15) are not important, it is the relative magnitude of the priority levels that are.

If two tasks with the same priority are triggered, then the controller will "time-slice" between them, giving the tasks equal priority execution status.

So the answer to your question is yes, you can "prioritise" handling your 3 events, using separate event tasks m for each event.

BUT.... you may be doing too much thinking on this. Reading between the lines, I get the impression you just want a tag to contain a value based on 3 different inputs, but you want the tag to always show the value corresponding to the input with the highest priority.

If that is the case, then it is simply a case of arranging 3 rungs with XIC x MOV s d on each rung. The latest rung in the controller scan will be the input with the highest priority... something like this may be all you need ...

 

[dskplc]

@Daba

Thank you very much. I think you may be right-I am thinking to hard about this and this is what I had come up with but your train of thought may work better. I attached a possibility.

 

[dskplc]

addendum

I was told evacuation was first priority, fire second and gas third. Thanks for your help.

 

[daba]

Thank you very much. I think you may be right-I am thinking to hard about this and this is what I had come up with but your train of thought may work better. I attached a possibility.

OK, just remember that the value tag can change as often as you like, but it will be the lowest "true" branch that will set the value that the rest of the logic sees.

However, we need to be aware of something else.... If a HMI, SCADA, or another controller, is reading your "Events" tag, then it is entirely possible for it to be read during the execution of the rung, and therefore the HMI or SCADA will receive "bad" information briefly. This might not be desirable.

Way round this is to use a temporary buffer tag in all the MOV instructions, and add a single MOV of the buffer tag to the Events tag as a new bottom branch.

 

[daba]

I was told evacuation was first priority, fire second and gas third. Thanks for your help.

The way you have your rungs, you have to have Evacuation trip in order for the others to generate an Events value.

I would simply put...

CLR temp
XIC gas MOV xx temp
XIC fire MOV yy temp
XIC evac MOV zz temp
MOV temp Events

Evac has highest priority, since it will be the last branch scanned. Gas has the lowest priority, since it can be changed by either of the other, higher priority, conditions.

Priority is therefore determined by the order of execution.

 

[dskplc]

Great!

Thank you very much! I am still learning programming as you can see.

 

[dskplc]

One more time

Is this what you mean? Not sure why I need the clear instruction and temp tag though.

 

[daba]

That's exactly what I mean.

1. You need the CLR because Temp will remain at the last value when all the XIC conditions are false. The final MOV will keep writing the last event type into Events.

2. You need the Temp tag because communications with other devices (eg. HMI/SCADA/Other PLCs), occurs during what is called the "System Overhead Time-Slice".

While the processor is scanning the user logic, it periodically goes away to handle "system stuff". Part of that system stuff is to deal with communications. The System Overhead Time-Slice is asynchronous to the program scan, so can occur anywhere, anytime.

Imagine the scenario where you have more than one of your events true, and you are writing directly to the Events tag.... it is possible for your HMI/SCADA/PLC to come in and read the value of the Events tag before it is finally settled at its correct, highest priority, value. Having a single MOV of the prioritised event value means that the external device can't be fooled by values that may be overwritten.

Of course if "Event" is not being read externally, you can dispense with Temp, and have the other MOVs setting its value directly. You'll still need the CLR though...