Further Understanding AOI RSLogix

showshocka · Nov 16, 2015

I'm looking online in a Project trying to catch a Jam instant. I'm looking at the Logic of this AOI where I found the only instant of a Jam Photo eye in in Rung 5 on the actively working AOI. Out in the Add-On Instruction's folder in the Controller Organizer's section the "JAM_VFD" AOI says to move a time/value of 6000 into PEJ_TMR.pre. Understood up to there. My questions is it how can that J_TM go up pass the time value of 6000 from which the AOI is set, also what's driving the value of J_TM that's in the Mov instruction to go up? As you can see here the time now a J_TM is 8143. Every now and then we're getting a Jam fault here and there is no jam, or maybe it is. May Sound confusing but I tried my best to ask this.

Basti504 · Nov 16, 2015

These questions may lead to the cause of your issue

* Is the J_TM destructive in the AOI? (Cross-Reference)
* Is the J_TM a local/input/output/inout?

If it is nowhere destuctive and declared local, its value is kinda floating. As in, nothing really determines its value aside from the initial 6000 from the AOI definition. Along the way something may have changed it, manually, external device (HMI), etc...

You can change is then by typing something in it via the tag monitor window, the value should then stay what you just typed.

showshocka · Nov 17, 2015

Basti504 said:
Along the way something may have changed it, manually, external device (HMI), etc...

It changes constantly from 6000 to 6xxx, 7xxx and up to 8xxx as the Conveyer runs. I Screenshot it while it was well over the AOI definition of 6000

rdrast · Nov 17, 2015

Where are the rungs calling the AOI?

showshocka · Nov 17, 2015

Basti504 said:
* Is the J_TM a local/input/output/inout?

16 or 32 bit input from the VFD maybe??

showshocka · Nov 17, 2015

rdrast said:
Where are the rungs calling the AOI?

In the "Motor Run" Main routine for that section of Conveyor

Basti504 · Nov 17, 2015

Can you post a image of the place where the AOI is called from your main ladder routine?

As the J_TM is an input for the AOI, the place where the block is called provides the value for the J_TM.

showshocka · Nov 18, 2015

Basti504 said:
Can you post a image of the place where the AOI is called from your main ladder routine?
As the J_TM is an input for the AOI, the place where the block is called provides the value for the J_TM.

Sure. Hope this is good enough

rdrast · Nov 18, 2015

So J_TM is being passed into each instance of the AOI as an input parameter. What is the mystery again?

Tharon · Nov 18, 2015

Are you having an issue with the J_TM being different outside and inside the AOI instance?

In your first image, you show the AOI with the J_TM set to 6172, and in your second image you show the current logic (I assume it's the same AOI, but it is censored in the images) of the AOI with the J_TM set to 8143.

But your first image, the program is offline, so I don't think you can trust the data table values.

Also, you could see if the J_TM variable is being set or modified somewhere in the actual program. Would be a tag something like YYY.J_TM Each J_TM would be a unique variable of the AOI tag group. Even though they may both be J_TM, each instance is really a separate tag. Edit: I do see the second J_TM is actually referenced to the first one YYY.J_TM Was hard to see originally.

showshocka · Nov 18, 2015

rdrast said:
So J_TM is being passed into each instance of the AOI as an input parameter. What is the mystery again?

The Mystery is how is J_TM is moving while the conveyor is running the only other thing that I can think of is that the variations are coming from a VFD output. I see in the definition of the AOI that the set time is 6000 and it goes up or down from there. The Motor does not have an encoder on it so it must be a value coming from a VDF. Maybe, it has to be. My confusion now is whats the difference between and input/output vs an in/out in the AOI?

showshocka · Nov 18, 2015

Tharon said:
Are you having an issue with the J_TM being different outside and inside the AOI instance?

yes to an extent, I was wondering how the set value of 6000 was varying up and down in the mov instruction

Tharon said:
In your first image, you show the AOI with the J_TM set to 6172, and in your second image you show the current logic (I assume it's the same AOI, but it is censored in the images) of the AOI with the J_TM set to 8143.

But your first image, the program is offline, so I don't think you can trust the data table values.

how it varies so much, If I was to take a screenshot 2 separate times, it still could have been 6172 or 8143 if on line both times

Tharon said:
Also, you could see if the J_TM variable is being set or modified somewhere in the actual program. Would be a tag something like YYY.J_TM Each J_TM would be a unique variable of the AOI tag group. Even though they may both be J_TM, each instance is really a separate tag. Edit: I do see the second J_TM is actually referenced to the first one YYY.J_TM Was hard to see originally.

All I did with the Editing is that everywhere where the same exact characters appeared, I used "xxx" or "yyyy" or etc..

Tharon · Nov 18, 2015

showshocka said:
yes to an extent, I was wondering how the set value of 6000 was varying up and down in the mov instruction

how it varies so much, If I was to take a screenshot 2 separate times, it still could have been 6172 or 8143 if on line both times

The J_TM value is being modified somewhere. It's being moved into a timer preset value inside the AOI. But there is nothing saying that the J_TM value cannot be changed directly.

Cross reference the YYY.J_TM tag and see where it is used. It can be set to any value at any time in the program depending on what the logic dictates.

Eriond · Nov 18, 2015

I have noticed that a TON's ACC value increases as long as the input is TRUE. When it reaches the .PRE value, the .DN bit goes true but the .ACC continues to increase. However, a RTO's .ACC value stops increasing once the .DN bit goes TRUE, regardless of the input's state.

showshocka · Nov 18, 2015

Eriond said:
I have noticed that a TON's ACC value increases as long as the input is TRUE. When it reaches the .PRE value, the .DN bit goes true but the .ACC continues to increase. However, a RTO's .ACC value stops increasing once the .DN bit goes TRUE, regardless of the input's state.

yes...the Tmr.acc is waiting for the PE to be blocked. The preset is always working at various values being moved into the Tmr.pre

Further Understanding AOI RSLogix

showshocka

Member

Basti504

Member

showshocka

Member

rdrast

Lifetime Supporting Member

showshocka

Member

showshocka

Member

Basti504

Member

showshocka

Member

rdrast

Lifetime Supporting Member

Tharon

Member

showshocka

Member

showshocka

Member

Tharon

Member

Eriond

Member

showshocka

Member

Similar Topics