Sum part of an array starting at element 70

chelton said:

I agree with Mispeld, Length should be 30




Expression would be something like:
Total+Array[x.Pos+70]

Click to expand...

Much better than my example.

edit: Just have to make sure you reset "Total" prior to running it, otherwise will keep adding sum on top of sum.

drbitboy said:

You could always do two FALs: one with .LEN=70 and .MODE=ALL; one with .LEN=100 and .MODE=ALL.
Your answer (sum[70 to 99]) is the difference.
But you do need to ensure they both have ALL as the .MODE.

Click to expand...

Yea... I guess I could...

The length must be 100
from the manual the length is the end .POS
in the rung just before the FAL MOV 70 to .POS
the scan will start at 70 and run until .POS = 100
the size of the array is not relevant as long as there are more elements then the length
just make sure that the .POS never exceeds the highest index number of the array
if the index (.POS) exceeds the size of the array it will trip a major processor fault and crash the program

GaryS said:

The length must be 100
from the manual the length is the end .POS
in the rung just before the FAL MOV 70 to .POS
the scan will start at 70 and run until .POS = 100

Click to expand...

I thought you were onto something but the same thing happens. The scan is still starting at 0 so its capturing the beginning of the array not the end. Using (FAL.POS + 70) in the expression did point the FAL to the right place but thats a workaround.

I gotta be missing something really obvious and I'm gonna myself when I figure it out.

I would have thought setting the length to anything more than the number of iterations you require is a workaround.

chelton said:

I would have thought setting the length to anything more than the number of iterations you require is a workaround.

Click to expand...

If .LEN means iterations, which is the theory I have been going on, yes. But if he was right that .LEN is an explicit comparitor to .POS that also could make sense.
Alas neither one works for me atm.
I'm reading every word of the manual on this instruction now.... AND I'm locked down for the rest of the week so this will wait.

it looks like the FAL is placing 0 in the .POS when the rung goes true
the in your expression if .POS > 69 Total = Total + array[.pos].value
or something that
I have found that the file handlers in RSLogix don't always work as expected some times you have to get creative
I would use the for next loop in ladder code use a JMP LBL to form a loop
I have done this many times

GaryS said:

it looks like the FAL is placing 0 in the .POS when the rung goes true

Click to expand...

Docs say that happens when the .DN bit or the .EN Bit goes False depending on the state of the rung.

I see that on the rung just before the FAL clear the .DN bit and the .EN bit
then move 70 into the .POS
if the .EN bit is false nothing in the FAL should change
the FAL will run when the .EN bit is true and stop when the .EN bit is false
when the .DN bit goes from false to true it sets the .EN bit to false but the .DN bit will remain true until the next time the .EN bit goes true
as long as the .DN bit is true it will clear the .POS to 0 so you need to reset the .DN bit before you move 70 onto the .POS clearing both the .EN and the .DN before you move 70 to .POS should solve the problem
I just had an FSC I had to do that to with to get it to work
let us know how you make out

GaryS said:

The length must be 100
from the manual the length is the end .POS
in the rung just before the FAL MOV 70 to .POS
the scan will start at 70 and run until .POS = 100
the size of the array is not relevant as long as there are more elements then the length
just make sure that the .POS never exceeds the highest index number of the array
if the index (.POS) exceeds the size of the array it will trip a major processor fault and crash the program

Click to expand...

From the instruction help.
.LEN The length specifies the number of elements in the array on which the FAL instruction operates.

And from the flow chart I take it that length = Iterations

You missed an important part of the information
when .POS = .LEN (length ) the .DN bit is set and the FAL stops
it also states the when the .EN is true and the .DN bit is set it sets the .POS to 0
.EN is FAL enabled ( rung is True)
so on the false to true transition if the .DN bit is set the .POS is cleared / Set to 0
that's why the FAL starts at element / index 0
you could have an array of 200 and set the FAL to start at element 70 and scan to element 100
the elements below 70 and above 100 are not included in the FAL function
you could have multiple FAL calls for the same array doing different things and they all would work without problems

GaryS said:

You missed an important part of the information
when .POS = .LEN (length ) the .DN bit is set and the FAL stops
it also states the when the .EN is true and the .DN bit is set it sets the .POS to 0
.EN is FAL enabled ( rung is True)
so on the false to true transition if the .DN bit is set the .POS is cleared / Set to 0
that's why the FAL starts at element / index 0
you could have an array of 200 and set the FAL to start at element 70 and scan to element 100
the elements below 70 and above 100 are not included in the FAL function
you could have multiple FAL calls for the same array doing different things and they all would work without problems

Click to expand...

I'm not saying it wouldn't work. But to give another example. I have 2 Arrays
Array1 DINT[10000]
Array2 DINT[20]

I want to add the last 20 elements of Array1 to Array2 and get the result.
My FAL lenght would be 20
My expression would be along the lines of: Result + (Array1[x.Pos+9980] + Array2[x.Pos])

Denied ! but resolved.

OK... well I have resolution which is what GaryS was trying to say and I didn't get it only because it didn't make sense to build the instruction like this.

The flowchart clearly says that if .LEN => .POS the instruction ends and sets its bits.
But in this case .LEN>.POS is how I have in initially set up and is how I needed it to work.

It would make sense to have this instruction be capable of reading .LEN elements from any start position in an array, leaving the out of bounds errors to the programmer.

But this instruction is literal with it's numbers and so in this case the instruction ends as soon as it starts.

So of a 100 (or one million) element array I wanted to start at position 70 and read 30 elements... and the reason I can't is only because 70 is greater than 30 regardless of the construct it's reading from. I would consider that to be a flaw, not a bug, but a flaw in the instructions design.

So I have to put this offset in the expression which I knew was an option, and now I know its the ONLY option.

Thanks for the assist folks.

Okay, I just spent five minutes reading and re-reading that.


You meant that when .POS >= .LEN, the instruction completes, and not the other way 'round, right? Because you typed '.LEN => .POS'


And you're right: it's a flaw, not a bug; oh if only these machines did was we wanted them to do instead of what we tell them to do!


Wait a minute, what happens if you set .LEN to 100? Doesn't .POS then run from 70 to 99, just like you want it to?


The definition of .LEN needs a few additional words: "The length specifies the MAXIMUM number of UNIQUE elements in the array on which the FAL instructionoperates"

Works like a charme