Logix 5000 instruction or method to clear / 0 out an array of bits

Its a perfectly good answer - wish I could get the messages across with so few words
 
Can you give me an example on when to use a Bool[32]. For stuff like process_ready, I will use single Bools, but for oneshots, test bits, and alarm bits it has always been easier to use DINT's. DINT's work real well in alarming.

Thanks for the responses!
 
I would kindly suggest reading the following Tech support article on the AB website

answer ID> 41378 - ControlLogix data always align to 32 Bit boundary
 
Kev77

If using DINTS works for you for oneshot storage bits then keep doing it that way.

For alarms I've developed an affinity for ALMD and ALMA - they are just too handy to not use.

For test bits and the like we define a UDT and call the type PROGRAMMER. It contains a set of Bools called AlwaysON, AlwaysOFF, TOGGLE, a general purpose bool[32] array, a DINT array, a REAL array, a TIMER array, a COUNTER array, and a CONTROL ARRAY. Then tags are created of the PROGRAMMER data type for each of our programmers. This lets us all automatically see which programmer is troubleshooting, debugging, or testing changes to a program. If someone else sees XIC CONNOLLY.AlwaysOFF on a rung then they know it is me who has temporarily disabled something as opposed to an AFI that carries no information with it.

If I want to group bits then I frequently use bit overlays. I hesitate to get too deep into overlays as it is an advanced programming topic, but here goes anyways. An overlay is a special kind of a UDT.

For example, I might have a DINT tag named State. However I want each bit in STATE to have a name, not just a bit position number. I might want something where
State.0 = Reset State
State.1 = Pick up Part
State.2 = Move Part to Fixture
State.3 = Clamp Part
State.4 = Apply glue,
etc.
But rather than remember what each state number is I would like to be able to name each bit, much like a timer has a .DN or .TT bit that has a name as well as a number.
State.Reset
State.Pickup
State.MovePart
State.ClampPart
State.Glue
The overlay lets me reference bits by name and at the same time do something like
MOV 2 STATE (sets state to pickup state)
or
CLR STATE (clear all state bits)
or
State:=State*2 (to advance to the next state, set the next bit up, and clear all others)

This requires that the bits be from a DINT in the UDT. They cannot be bools.

Overlays can offer some significant advantages but they also come with some big disadvantages. You cannot create them in RSLogix5000. You have to create an external XML file to define the overlay and once you import it into your Logix5000 project you cannot change it or edit it. This requires some careful planning. If you want to know more then search the AB KB for the tech notes on bit overlays and I've posted a couple of threads with overlay examples in them that you can find with a forum search.
 
It makes sense to do it that way. I will check out the AB technotes on overlays and see if I can wrap my head around it some more. It looks like it would work well in sequencing.

As for alarming DINT's work well when working with Panelviews. I agree about using the ALMD and ALMA.

Thanks for the class, tell me where to send the check...
 
Kev77

If using DINTS works for you for oneshot storage bits then keep doing it that way.

For alarms I've developed an affinity for ALMD and ALMA - they are just too handy to not use.

For test bits and the like we define a UDT and call the type PROGRAMMER. It contains a set of Bools called AlwaysON, AlwaysOFF, TOGGLE, a general purpose bool[32] array, a DINT array, a REAL array, a TIMER array, a COUNTER array, and a CONTROL ARRAY. Then tags are created of the PROGRAMMER data type for each of our programmers. This lets us all automatically see which programmer is troubleshooting, debugging, or testing changes to a program. If someone else sees XIC CONNOLLY.AlwaysOFF on a rung then they know it is me who has temporarily disabled something as opposed to an AFI that carries no information with it.

If I want to group bits then I frequently use bit overlays. I hesitate to get too deep into overlays as it is an advanced programming topic, but here goes anyways. An overlay is a special kind of a UDT.

For example, I might have a DINT tag named State. However I want each bit in STATE to have a name, not just a bit position number. I might want something where
State.0 = Reset State
State.1 = Pick up Part
State.2 = Move Part to Fixture
State.3 = Clamp Part
State.4 = Apply glue,
etc.
But rather than remember what each state number is I would like to be able to name each bit, much like a timer has a .DN or .TT bit that has a name as well as a number.
State.Reset
State.Pickup
State.MovePart
State.ClampPart
State.Glue
The overlay lets me reference bits by name and at the same time do something like
MOV 2 STATE (sets state to pickup state)
or
CLR STATE (clear all state bits)
or
State:=State*2 (to advance to the next state, set the next bit up, and clear all others)

This requires that the bits be from a DINT in the UDT. They cannot be bools.

Overlays can offer some significant advantages but they also come with some big disadvantages. You cannot create them in RSLogix5000. You have to create an external XML file to define the overlay and once you import it into your Logix5000 project you cannot change it or edit it. This requires some careful planning. If you want to know more then search the AB KB for the tech notes on bit overlays and I've posted a couple of threads with overlay examples in them that you can find with a forum search.
Unfortunately, Rockwell has recommended not going much over 200 ALMA & ALMD instructions in a controler due to overhead required to process them. I suspect the Version 21 changes will lessen the impact of that restrition but only for the 557X series of ControlLogix processors.
 
For the ControlLogix Boolean memory is allocated differently by the compiler and word instructions don't work on it. The compiler allocates a full 32 bit word for a stand alone boolean but it still may contain only boolean information and so word level instructions are not allowed. When you create an array the memory allocation is word optimized but the data type remains the same, meaning you may not use word level instruction on it.
Thanks. I learned something today. (I'm still in PLC-5 land)
 
.... I prefer to use stand alone tags. I've never had a memory limitation problem from doing that and a boolean tag named Process_Ready is a lot more clear than B[19].

Have you never thought of making a "Process" tag a UDT of type "Process" that you can define.

Then you can make an array of "Process" tags, so your code will ultimately address Process[5].Ready

Make it even easier to read the ladder, make your "Reingestinate_Lacquick_Comspotle" Process tag as an Alias to Process[5], and the ladder reads clean. e.g Reingestinate_Lacquick_Comspotle.Ready

HMI access to your process data is simplified, because it only needs to interface to Process[5] - think "faceplates" for your process control screens.

Life can be simpler, just needs a bit of thought


Added : Note to self - check posting dates before adding replies, lol
 
Last edited:
Second cwal61's suggestion. In logic you can do indirect, using '[]' to make it kind of like an array. If you don't alias the bit then you'll have to type in the bit number yourself from Factorytalk for a display reference.

Sorry for resurrecting an old thread, but this one appeared in my google search: To be more explicit, you can use indirect addressing on a word, and have it act like a bit array by using:

WordTagName.[ArrayElementNumber]
 
Sorry for resurrecting an old thread, but this one appeared in my google search: To be more explicit, you can use indirect addressing on a word, and have it act like a bit array by using:

WordTagName.[ArrayElementNumber]

Apology accepted, but your post is not relevant to the OP's problem. He wanted to know methods to clear a BOOL[nn] array.

Your example cites an indirection to the BOOL element number of a "word", and I assume you mean a DINT tag, correct me if I am mistaken.

All well and good, in context, until you need more than 32 BOOLean "flags".

PS. Welcome to the forum, make your stay here useful, to yourself and others. :)
 
Little bit of a thread revival but I get excited when I can answer some of these questions rather than just always coming here for help.
Create a counter and make the PRE the same size as your bool array which we will say is called Mydata[256]

Than put the XIO of counter.ctu in front of the counter and the RES for the counter with the Counter.DN

Than put this on the rung below it all. As the counter cycles though it will unlatch each bool until it get to the end where it resets it and starts again
Mydata[counter.acc]
---------------(U)----

Now back to looking for the answer to my question.
 
A few things need to be clearfied
when you say an array of bits
is it a bit array
an INT tag and aDINT tag are both arrays of bits
and for that matter a string tag is stores as anarray od bits
but the easisest way is to use for next loop
in a ladder program use the lable function to form the loop
one line of code
 

Similar Topics

In studio 5000, is there a way to write a force mask into a rung? Long story short, I would like to create a test routine for a FAT test. In...
Replies
7
Views
1,238
Hey guys, thanks for taking the time to look into my question. I'm building a system to monitor several other systems for faults and one of the...
Replies
17
Views
4,608
I"m trying to average an array of DINT's called FIFO_ARRAY. It has 1000 elements in it. Here is what I have entered into the AVE instruction...
Replies
11
Views
4,646
I have a RS Logix 5000 program that i feel was poorly structured and I'm trying to make the best of it. There is a series of approx 40 tags with...
Replies
8
Views
1,777
Good morning everyone. I am apparently confused on the COP instruction. What I am trying to do is copy a DINT to a DINT in a User Defined Data...
Replies
16
Views
6,785
Back
Top Bottom