RSLogix AOI and timers

[garciaortiz]

I have a problem and can't find an answer anywhere. I have a ladder logic aoi to control motors. In the routine there is an alarm for failure to start. If the motor is told to start but the auxiliary does not come in then after 3 seconds alarm.

I have three motors. Each one is using a UDT structure of data to pass the parameters to the AOI(start command, contactor status, etc.). When I use a local timer tag, if only one or two motors fail I don't get an alarm.

If I create an individual alarm and pass it with the structure the logic works fine.

Does anyone have an idea how this could happen? I thought each AOI was contained to itself.

Here are some clips from my logic.

 

[widelto]

what you mean is that you need to use three timers one for each udt ?

 

[daba]

Your top rung works just fine, I have programmed it into an AOI and used it for 8 motors, all "ftr" after the required time individually.

can you post your code so we can see what is wrong ? (zip it first, forum rule)

 

[garciaortiz]

Here is a copy of my logic.


View attachment MotorLogic (2).zip

 

[garciaortiz]

@widelto

The AOI uses one timer. I have to add a timer type member to the UDT structure that is passed to the AOI so that each instance has a unique timer.

The only thing that I can figure is that all three motor AOI's are collected into another single AOI that is used in the main logic. Could this be the reason they are sharing tags somehow?

 

[iant]

Am I right in saying you are using the same fault output multiple times?
That is a no no.

 

[iant]

Waiting on reply

 

[garciaortiz]

Thanks iant. The alarm bit is also passed to the AOI as part of the structure. Once I added the timer to the UDT structure, so that it becomes an INOUT parameter instead of a local tag, I get individual alarms properly.

 

[bernie_carlton]

Just as a note, the Allen Bradley publication on AOIs (1756-PM010A-EN-P) shows a motor fault detect implementation with timers within the AOI. I think something else must have been going on.

 

[daba]

@widelto

The AOI uses one timer. I have to add a timer type member to the UDT structure that is passed to the AOI so that each instance has a unique timer.

The only thing that I can figure is that all three motor AOI's are collected into another single AOI that is used in the main logic. Could this be the reason they are sharing tags somehow?

The timer should be a local tag, it will be unique for each instance call because it is stored in the AOI tag. I am assuming you have created a unique tag for each instance call of the AOI - if you haven't, and are re-using the same tag, that will cause what you are observing.

 

[bernie_carlton]

The only thing that I can figure is that all three motor AOI's are collected into another single AOI that is used in the main logic. Could this be the reason they are sharing tags somehow?

I am assuming you have created a unique tag for each instance call of the AOI - if you haven't, and are re-using the same tag, that will cause what you are observing.

You both nailed the problem, as far as I can see. The 3 instances of CM_Motor_VFD_AOI contained within EM_Fans_AOI need to have unique AOI tags. But the same one (Motor_Control) is used for all three.

 

[garciaortiz]

You guys are awesome. That Motor_Control should be an array of 3 . Thank you so much. I have been pulling my hairs out for weeks.

 

[bernie_carlton]

On the side it gets me thinking. If an AOI had NO LOCAL Variables or structures of any type, just IN, OUT and IN/OUT, could you get away with just one instance name used over and over?

But I guess thaat would do away with the advantage over subroutines which have parameter passing in that you can look into the individual instance at runtime to see that individual logic executing.

 

[devo.xx]

... That Motor_Control should be an array of 3 ...

Personally, I have found that when I create a program with Arrays and do what you are doing, it leads to greater headaches.
Because:
A year later, they want me to add something, or change something, I go to site, open the code. Then I look and see Pumps_Array[0], Pumps_Array[2]... etc.
Then I walk around the plant, and all my pumps are labeled P111, P112, P221... "Oh no... Which one was Array[1] and which was Array[8]?"

I'd recommend just making individual tags for each pump, and carry the Real World name.
It makes your Tag viewer really long, but makes future work easier.

Food for thought.

 

[daba]

Personally, I have found that when I create a program with Arrays and do what you are doing, it leads to greater headaches.
Because:
A year later, they want me to add something, or change something, I go to site, open the code. Then I look and see Pumps_Array[0], Pumps_Array[2]... etc.
Then I walk around the plant, and all my pumps are labeled P111, P112, P221... "Oh no... Which one was Array[1] and which was Array[8]?"

I'd recommend just making individual tags for each pump, and carry the Real World name.
It makes your Tag viewer really long, but makes future work easier.

Food for thought.

Well yes, so would I, but here we are talking about the AOI control tags, the tags that hold the data used by the AOI code, not by the pumps or valves. It doesn't matter if the AOI tags are in an array, and not related to the pump/valve number, they are simply there to hold the instance data for the execution of the AOI code. You will be parameterising the pump/valve as an in/out, so if the AOI handling code needs 15 timers, then that is all that is needed. If you put 15 timers into the UDT for the plant item, and you have 1000 plant items, you end up with 15,000 timers instead of 15.

Simplify.... A "debounce" AOI for level probes etc. may need 2 timers. I make them local timers in the AOI, and all I have to specify in the AOI "box" are the "on time", and "off time" for that level probe. The AOI code moves those values into the local timer presets.