expand/collespe visible operand in rslogix5000

[md.abdullah]

hello every body
i have made a AOI which is got very big as in the picture.
i want expand/collespe visible so that it can be look small
as i have putted MAJ(for example)in the program.in the MAj there is <<less or <<more tab which can epand or collespe.
so i want this feature to my AOI.so it is possible to do AOI like MAJ..
thank you

 

[md.abdullah]

sorry i forgot...
i can not disvisible in the parameter tag show
becuase all element int he AOI must be there in the AOi
no one can be disvisible. evry element in the AOI reqiured..
thank u

 

[md.abdullah]

i think it does not have any solution
??????

 

[jkerekes]

I don't think it's possible either. If the AOI is in function block, then you can determine which elements are shown. I don't know how it was done on the built in insruction that you showed.

 

[md.abdullah]

yes i search many document from rockwell but possibly here it is not so to biuld so....perhaps any one know....
that is possible to make the required or visible in the definition of AOI of any tag....

 

[rdrast]

yes i search many document from rockwell but possibly here it is not so to biuld so....perhaps any one know....
that is possible to make the required or visible in the definition of AOI of any tag....

Right click the AOI.
Select "Open Definition".
Go to the Parameters tab.
Set your visibility and required attributes as necessary.

Seriously, once again, ALL of this is the manuals, and in the included online PDF's. Try reading through some of them for once.

 

[md.abdullah]

thank you rd
but agian here i reqiured all tag so it become big
i cant remove any tag in the AOI...
i just want <<less tab in my AOI as in the MAJ of rockwell inbiult instructions...

 

[lostcontrol]

As well as reading manuals, simple right clicking & exploring is also worth doing, after all that is how a lot of things are done these days

 

[md.abdullah]

i know expand/collaspe visible operands propert is available in the rslogix5000 v18 but how it does used still i am in search...

 

[daba]

In the AOI Parameters definitions, you have the choices...

Required
Visible

If you select "Required", the parameter automatically becomes "Visible" in the AOI instruction that appears on the ladder, and you have to supply an operand for that parameter when programming the instruction.

If you don't select "Required", you can leave the "Visible" attribute cleared, and the parameter will not appear in the instruction.

Each parameter can have a "Default" value, so that whenever you program a new instance of the AOI, the default values are automatically set in the parameters. This is a one-time only setting.

This means that you can write code to set parameter values for each AOI tag instance, to override the default values.

If you made this code execute on "First Scan" (XIC S:FS), then it will not affect your normal processing scan time.

Or, you can monitor each instance tag for an AOI, and write the relevant values into the parameters using the tag monitor. Of course, you will have to save tag values each time you exit the software if you have changed them, otherwise they will revert to original if you do a download.

I prefer the first method, i.e. to have initialisation code, which sets my parameter values.

Of course, having the parameters displayed in the AOI gives you quick and easy access to the parameter values, but it is just the same as going to the tag and changing values in the database.

 

[MichaelG]

Personally in your AOI I would have a visible ER bit and a UDT for all the Error information - that would reduce the clutter

+1 for daba hiding initialization stuff eg EUMax, EUMin, RawMin, RawMax

If I want that visible in the Ladder I use the AOI_Tag.EuMin in the rung before

 

[rdrast]

thank you rd
but agian here i reqiured all tag so it become big
i cant remove any tag in the AOI...
i just want <<less tab in my AOI as in the MAJ of rockwell inbiult instructions...

You can't do that.
End of story.
That behavior is programmed into RSLogix for those instructions.

 

[md.abdullah]

yes rd
but sad very sad
for only this reason my company has terminated me..
now finding other job....
i have done their all engineering calculation and made the AOI
but just for the small sizing i was terminated today
but no matter i have extensive knowledge of plc,,,,
like
AB
ABB
Schneider
Mitsubishi
modicon
Siemens
Delta
etc...

 

[daba]

Personally in your AOI I would have a visible ER bit and a UDT for all the Error information - that would reduce the clutter

+1 for daba hiding initialization stuff eg EUMax, EUMin, RawMin, RawMax

If I want that visible in the Ladder I use the AOI_Tag.EuMin in the rung before

Then you will be adding instructions to the code which increases the scan time. If you do want them visible, then visibility inside the AOI instruction is the best place for them, the execution time of the AOI is not affected by having parameters "Visible".

It is worth noting that the Logix5000 platforms were designed to provide high performance, and having the processor execute unnecessary instructions every scan undermines that ethos. One day you will need that little bit "extra" performance in an application, so it is a good habit to think about it now.

Also, the good thing about having parameters that are essential to the operation of the AOI in the instruction box, is that it positively forces you to enter values when you program a new instance call of the AOI. This is something you may forget when you add a new instance after some time has elapsed. Also it is good for anyone else who has to add an instance call - they may not know about the semi-hidden initialisation code.

An example - suppose I had an AOI for valves.
Required parameters would be the Valve tag itself, the type (N/O or N/C), the I/O references (output and feedbacks), etc.

I would not include the opening and closing watchdog times as required or visible parameters, but I would add a default value (say 5 secs), to the parameters. Each and every time a new instance call of the AOI is made, it will automatically use the default value, and that value would probably be satisfactory for most of my valves. On commissioning, I could add initialisation code to move other values if a valve needs it, but I wouldn't bother with any other valve.

Doing it in this way, I am assured that each new instance call will receive at least default parameters if it doesn't require me to specify one in the AOI box.