Can you get value of BOOLs only within UDT?

is it possible to just look at the value of the BOOLs within a UDT? In RS500 i would create a B3 word then i could use an EQU to look at that word and see if anything was 'active' to allow for other things within the program to happen. Being new to the Compactlogix system i thought i was being smart by creating a UDT with the tag names that i would normally use in the method described above but it seems as if there is really no way to look at the UDT and use an EQU instruction to see what BOOL tags within it are active or not. Or am i missing something?

No, you are not missing anything, BOOL tags in Logix5000 are very unfriendly, and you have to think again about your data structuring.

Logix500 and Logix5 used Binary Files for boolean (bit) data, but stored them in "worded" data structures, exactly the same as N files. You could use N File bits, or you could use B File words, there really wasn't much difference in them, other than the type letter, B or N.

About the only thing that might make sense of the Logix5000 environment is if you create BOOL arrays, and you will find that they "snap" to multiples of 32 bits. But then those BOOL arrays are pretty useless, you really can't do very much with them, at all, just think of them as dumb storage.

If you really must have BOOL data (and not go for individual bits of DINTs, for example), then the best place for them is inside a UDT tag, which opens up the possibilities of some manipulation. From a UDT you can COP or CPS them to DINT tags, do whatever you want on the DINT copies, then COP or CPS them back. It's all a bit messy, and has dangers, because if you get you length specifications wrong on the COPs CPSs, and FLLs you will trample over other data in your UDT without any errors being flagged.

thanks for the response!

So im better off just creating a DINT and using that, which is fine. I just liked the UDT idea because i could then name them in an easier fashion i assumed. As apposed to a DINT in which i will have to add the description to each bit i use within the DINT so it makes sense to whomever is looking at the code and not just seeing example.1, example.12, etc.

There is the option of bit overlays in a UDT, but that is not necessarily for the faint of heart.

Keith

Just to try to finish this off for JZerp, Logix5 and 500 did not have any "boolean" data at all, it was just that you could "drill-down" to the individual bits of 16-bit memory words.

As I said before, B files and N files were largely interchangeable. B files had to be used for some instructions (Bit-Shifts and the like), but for general-purpose storage of bit data you could use either.

Along comes Logix5000 with its "proper" tag database, and a BOOL tag is just like any other tag, it has its own place in the database, unlike bits of memory words in the legacy platforms.

There is absolutely no way you can group BOOL tags together and look at the value of that group, like you could in 5/500. This is why you would need to use tags declared as arrays of data-type BOOL, and use COP or CPS to get the data structure into tags that you can perform some comparison, arithmetic and logical operations on.

COP and CPS (and FLL) are pretty dumb instructions, they take your declared operands, source and destination, and do a sequential byte to byte copy in controller memory, the number of bytes copied is calculated by the Length specified, multiplied by the size of the destination data-type.

That is why they can look so odd to the untrained eye.

Copying 256 BOOLs from an array of BOOLs, into an 8 element DINT array for example, you would specify the length of the copy as 8, and the number of bytes copied would be 8 x the destination data-type size of 32-bits, or 4 bytes, so 32 bytes are copied.

Going the other way, the destination data-type size is 1, which is 1/8 of a byte, so you would need to specify the length as 256, and the number of bytes copied would calculate out as 256/8, or 32 bytes.

Now the fun part : you can't perform COP, CPS or FLL, on Base BOOL Arrays, but you can when they are named members of a structure, or UDTag. Normally the controller will protect you from data corruption by specifying a length parameter wrongly, by preventing writing past the end of the tag memory space. But that is not the case when the destination is part of a UDTag, the intended destination may not be the last element of the tag, but could be in the middle of that tag's memory space.

A COP, CPS or FLL will go blindly on, overwriting whatever is in the destination tag, because those instructions were designed to be fast and efficient, they therefore have no error checking - get it done as fast as possible. Only when a COP, CPS or FLL reaches the end of the tag space, will it stop, possibly prematurely, having not completed its number of bytes to copy, with no warnings given whatsoever.

In summary, getting the length specification correct is paramount.

I worked many years ago on one project where 5 ControlLogix PLCs were seen "as one" by the control system, so each PLC shared its alarm arrays with the other 4. Each had 2048 alarms, all in BOOL arrays so that they could be indexed, so the "global" alarm array was 5 x 2048 bits long. Each PLC had to declare the "First-Up" alarm, so the detection had to be done with FBC type instructions (I forget the detail, so long ago), but I do remember the huge number of COP instructions needed to get the BOOL alarms into DINT arrays for processing. In the end it all worked perfectly, but a nightmare to program because of the length specifications, one instruction wrong, and it would have all come crashing down like a house of cards....

In retrospect, I would not have done it that way, but "company standards" overruled.