Using FSC to inspect BOOL element of UDT array

[ASF]

I received the following message via PM, and am posting here publicly to help others.
============================================

I had a question about this Instruction. I am trying to use this instruction to search through an array of a UDT i created but i cannot search through the status of a bool.

UDT_Source[20]
Ratio REAL
ID STRING
Select BOOL
Product ID STRING

basically customer has to select which tank he is wanting to use from an HMI and i have to Set the path for equipment to use based on the source.

I have 20 tanks to choose from. So basically if a tank is selected. I was wanting to do a FSC for that "Select" bit. Copy the "Ratio, ID, ProductID" to another UDT that adds the sources up and shows all the tanks selected. "Source 1, Source 2" ETC...

Do you know of anyway i can utilize the FSC to do this??

 

[ASF]

I've not ever tried to do what you're describing using an FSC. I'm not sure if it's possible, but it's certainly possible using general logic.

If it were to work with an FSC instruction, your expression would need to be something along the lines of:

My_Array_Of_Tanks[My_FSC_Control_Tag.POS] = 1

Then, if you get a .FD (found) bit turn on, you copy My_Array_Of_Tanks[My_FSC_Control_Tag.POS] to Some_Other_Array, and clear the relevant control bits to resume the search to check if any more tanks are also selected.

Assuming that doesn't work, you can use a simple loop to achieve the same thing. Set a pointer tag to zero, then do a simple XIC to check if My_Array_Of_Tanks[Pointer_Tag] is true, and if so, do your copy the same way. Following the check and/or copy, increment your pointer, and use a JMP/LBL pair to check the next array instance.

Couple of caveats:
1. CHECK YOUR LIMITS. I strongly recommend using a SIZE instruction to check the size of your array before doing any indirect addressing, and remember that if the rung your indirectly addressed XIC is on is scanned with a pointer value higher than the last array element, your PLC will hard fault, even if the rung conditions before that XIC are false.
2. If it's possible to have more than one tank selected, you'll need to get a little more elegant than just "copy the selected tanks to a new UDT". If you have an array of 20 tank UDT's, you will also need an array of 20 tank UDT's for the "selected tanks" data. Your best approach for populating it is probably to use an FFL instruction rather than a straight copy, and you will need to find a way of clearing it out as well.
3. Tasks like this are much simpler with a short structured text routine, if that's an option for you.

 

[ASF]

Now I'm off to make a coffee and see how long it takes drbitboy to show up and comprehensively solve this problem five different ways (with screenshots) and point out at least one error in my initial response.

 

[Aardwizz]

The file instructions (FAL, FSC, etc) do no work on BOOL arrays.

He'd do much better if his Selected Tank were a DINT instead of a BOOL[Array], and if selecting Tank 6, were to set the 6th bit (with the usual caution of the "6th" bit is technically DINT.5).

Some simple bit twiddling would determine which bit is set, and that value could be used to Indirectly COP a UDT[Array] tag into another UDT tag.

 

[Jeev]

1. CHECK YOUR LIMITS. I strongly recommend using a SIZE instruction to check the size of your array before doing any indirect addressing, and remember that if the rung your indirectly addressed XIC is on is scanned with a pointer value higher than the last array element, your PLC will hard fault, even if the rung conditions before that XIC are false.

And don't forget that it's SIZE-1 elements in the array, because Array[SIZE] will definitely do what you are trying to avoid doing.

 

[ASF]

And don't forget that it's SIZE-1 elements in the array, because Array[SIZE] will definitely do what you are trying to avoid doing.

Yeah, my usual approach is "increment pointer; if incremented pointer still less than array size then loop".

But I guarantee I haven't faulted a PLC by incrementing my index one too many places for the last time in my career just yet

 

[drbitboy]

Now I'm off to make a coffee and see how long it takes drbitboy to show up and comprehensively solve this problem five different ways (with screenshots) and point out at least one error in my initial response.

LOL. I would think ASF is right and the FSC should do it; see here; the description of expression format start here.

Is it possible that the expression could be only My_Array_Of_Tanks[My_FSC_Control_Tag.POS], since it's an array of booleans, and the "= 1" is superfluous?

 

[Corsair]

The Drs responses are always appreciated - but I must also respond in my predictable way with my usual broad generalization.

I don't believe either in doing loops in ladder code - or in using PLC brand-specific instructions that loop internally in my ladder code. Do all your looping in ST where it belongs using code that doesn't force somebody to pour through the instruction set reference material to understand it.

Judging from the questions on FSC and it's relatives on this website it appears that others disagree. Such is life. It's why you can't have two cooks in the same kitchen or two programmers in the same CPU.

 

[ASF]

Is it possible that the expression could be only My_Array_Of_Tanks[My_FSC_Control_Tag.POS], since it's an array of booleans, and the "= 1" is superfluous?

Quite possibly, I did wonder that myself. If I get a chance to fire up my Rockwell VM today and have a play around I'll test it.

I must also respond in my predictable way with my usual broad generalization.

I don't believe either in doing loops in ladder code - or in using PLC brand-specific instructions that loop internally in my ladder code.

In (broad general) terms I agree with you - stuff like this belongs in an ST routine. But, some folk may not have access to ST (or the expertise to develop it), and some customers refuse to entertain ST even when it might be the better solution. There are lots of ways to achieve a task like this, all of them with pros and cons, many of those pros and cons subjective or environmental rather than absolute. I've heard it said "the only WRONG way to skin a cat, is if the cat is still alive when you start". I would extrapolate that to say "the only wrong way to solve this problem is to make it more complicated than it needs to be given your specific constraints, or if you don't add clear and comprehensive documentation to whatever solution you choose".

 

[chelton]

I don't believe either in doing loops in ladder code - or in using PLC brand-specific instructions that loop internally in my ladder code. Do all your looping in ST where it belongs using code that doesn't force somebody to pour through the instruction set reference material to understand it.

I would agree, however in AB the FSC is magnitudes faster than an ST loop. Even on a 500 iteration loop FSC is much faster.

 

[Jeev]

Somewhat arbitrary, but if you are curious - I tested this on an old L6x we had laying around for a project we worked on last year. The test was how long it took to search a 32000 element UDT array with the data I was searching for in the last array element.


Scan times:
6ms – LD For Loop
1.5ms – ST For Loop
2.2ms – LD FSC Instruction