BOOL to INT CLX5000

Is there an easier way to move a BOOL array to INT in CLX5000 Ladder program.
Thanks

Easier than what? Having 16 rungs (or branches) with bits from the bool array going to OTE for the INT?

This may not be satisfactory but I created a UDT with one member, a bool array of the appropriate size. Then I created a tag of that defined type. A COP command likes that. But I can't test it. And it also buries the array one level deeper.

Yes bernie, I need to move 128 long Bool array to a 4 long DINT array. I thought there may be an easier way to do it. Rather than having 128 individual lines.
Thanks

If you alias your bools to ints (or dints) they become contiguous bits that can be moved as words or compared, etc.

My example is for alarm bits in words. I have two words declared as data type INT: ALM_WORD_01 and ALM_WORD_02. Then I have boolean tags for the alarms. The first bit alarm is ALM_PLC_LOBATT and it is aliased to ALM_WORD_01.0. And so on...

"Easier way" is a definition we all like. We all want an easier way, and there might be one you can use. HOWEVER - I've found that the old "hard way" of moving bits like this, using individual rungs, is easier, and quicker, than trying to manipulate words of bits around to get them where you want them. You might find, even with 128 individual rungs, that the program runs better, cleaner, and is easier to maintain when you can see the individual bits.

I've worked with systems that use indirects within indirects, and pointers within pointers, and trust me... it's easier to do it the "hard way" because a year from now you won't be scratching your head trying to remember what magic you used to make something happen in your "old" program.

tomalbright said:

........I've worked with systems that use indirects within indirects, and pointers within pointers, and trust me... it's easier to do it the "hard way" because a year from now you won't be scratching your head trying to remember what magic you used to make something happen in your "old" program.

Click to expand...

How very true.....well said.

Originally posted by tomalbright:

I've worked with systems that use indirects within indirects, and pointers within pointers, and trust me... it's easier to do it the "hard way" because a year from now you won't be scratching your head trying to remember what magic you used to make something happen in your "old" program.

Click to expand...

That's just the result of bad documentation. The same can happen on a grander scale with the logic development behind a section of code, the evolution of a physical design or the genesis of an equation. You must absolutely hate logic developed using Karnaugh maps.

If you define "easier" as smallest amount of program entry by the developer it will be hard to beat an indirect address solution given the tools you have to work with in the PLC. I like Pauls B's solution. It involves no user code to accomplish this and you can 'develop' it using Excel and import the resulting tags. You can do this very quickly. But it is obscure. You will have to carefully document this somewhere, although it will become pretty obvious in the code when you see the alias relationship on the screen.

If you need to execute this in one scan and scan time is an issue the alias solution will provide the least scan time impact. Aliasing does have an effect on scan time but not as much as explicit instructions will. If you can wait 128 scans for all your alarms to be updated the indirect address method will have the least affect on the per-scan scan time, although it is the least processor efficient. The thing that helps the scan time is you are only performing one relationship per scan.

So what you do is based on your criteria. If you have no criteria just do what you feel most comfortable with.

Keith

Yes, documentation is the key. Also, naming your tags appropriately is a very strong suggestion of mine. I'm working with a program now, where subroutines are run after every analog input, solenoid input, and even to the motors, where the setup is done, then a subroutine is done to take care of it. I did a little programming... where the subroutine to start or stop a motor is about 30 rungs long, I did it directly in the main program in about 10 rungs.

In the subroutines, you ARE NOT able to troubleshoot. I use them for stuff like alarms, but in the main program, you want to be able to track your logic. Also, here I am faced with the beginner's guide to UDTs; analog inputs start at "Analog[1]" and contain every alarm, timer, and whatnot. Motors start at "Motor[1]", and it just gets worse.

Labelling? You have to know where everything is in this program to find it. Tag names are used in the descriptions only. Lose those, and your goose is cooked. There is no organization of the control system. The major program revisions are "Analog", "Annunciator", "Motors", "Solenoids", and so forth. The sheer overhead that is unneeded in this program would make you cry.

Personally, with RSL5000, I like to label a section as to what it's for, such as "Sump Pump", "Dry Oil Tank" or "SAFE CHARTS" (that one is needed, but alas, I don't have it! Scattered throughout). There might be only one or two rungs in each section, but you will always, immediately, see what you need to see. I'm glad the PLC I have runs fast, but boy oh boy they could have hired someone like... me! when they did this job. There's a little documentation in the program, but it was done by a company that got fired during the middle of construction, and the fixes were done by someone else working with this system. I'm the programmer/maintainer now.

Yes, document it like crazy. If your PLC allows it, make your program tags mean something to someone else, as well.

In the real-world, control systems are built by egotistic SI's, but are maintained by under-trained plant tech's.

K.I.S.S

tomalbright said:

In the subroutines, you ARE NOT able to troubleshoot.

Click to expand...

If many plant items are handled in a common subroutine (i.e. function code), then a single problem with one plant item isn't in the PLC code, leave the programming terminal in its case and get a multimeter out

tomalbright said:

Also, naming your tags appropriately is a very strong suggestion of mine.

Click to expand...

Even more strongly agree - FFS programmers, you have 40 characters to play with, and NO OVERHEAD for using meaningful names - just do it !

no more rants for tonight

Keith, thanks for the agreement. It was taught to me by other engineers in my company. Along with providing a means of contiguous data there are other uses. One of the great benefits is it eliminates typos. I'm sure you have noticed in Logix5000 if you type something wrong the program still compiles and downloads. The logic just won't work since you typed the wrong tag. If I alias bools to bits in words I always see the alias, unless I type it wrong. Also I can sort by alias in the tag editor and "see" stuff the way I assigned it, like an old school addressing way of doing things.

Unfortunately you can not do that with a copy, but you could do something like the following.

I do not have a processor handy to test on, but if you have structured text available something like this should work:
===================================
FOR i:=0 to 127 DO
WordOffset := TRUNC(i/16.0);
BitOffset := i MOD 16;
TestDints[WordOffset].[BitOffset] := TestBools;
END_FOR;
===================================
Then if this is something you need common use of you could create a user defined add-in instruction.

Darren