Counting Populated Elements In An Array

[plvlce]

or, to do it in one step, assuming .LEN can only be either 0 or 16, though less efficiently:

(EM005_STATION5_Robot1OutPuckRFID_FIFO[FAL_L1.POS].LEN/16) + FAL_L1_Total
​

Not sure why I didn't think of that... I'd take dropping it to a single step over a slight efficiency increase almost any time.

 

[Mispeld]

This is a special case, search for zero, of a previous post to use a FAL for searching an array for an arbitrary value. The same advice applies: just because you can does not mean you should.

 

[wirelessliquid]

Try the expression in the FSC
stringarray[ctl.pos].len > 1

Tried this to no success unless I missed something, there is definitely more than 8 active positions in the array at this time.

 

[wirelessliquid]

Not sure why I didn't think of that... I'd take dropping it to a single step over a slight efficiency increase almost any time.

Thanks plvlce & drbitboy, this seems to do the trick

 

[wirelessliquid]

Is this a more efficient piece of code? little harder to read?
Is good though

 

[drbitboy]

Is this a more efficient piece of code? little harder to read?
Is good though

I strongly advise a comment explaining the code e.g. "Count number of non-empty strings in FIFO [RFIDs/products tracked on conveyor?]; FAL Expression assumes all FIFO string lengths are either 0 or 16"

I don't think that FAL Expression can get any cleaner; I would have code elsewhere (e.g. near the FFL) to enforce the 0-or-16 assumption.

The FAL and TON could be connected to a single XIO.

TL;DR

There are probably a dozen different ways to handle the trigger/timing logic, but I think what you have is pretty easy to understand and read. That said ...

You could perhaps get away without a timer if you used the .EN and .EU bits of the FFL and FFU, respectively, to trigger the FAL.

I suppose the entire process could be on a single rung with one [XIO FAL_Pulse_Timer.DN]: the RES and CLR would be on a branch above the FAL and triggered by an [XIO FAL_L1.EN] in front of them i.e. see untested image below, but that is no more efficient and probably less easy to read than what you have

 

[drbitboy]

OT: Agile

Not sure why I didn't think of that...

Interesting statement, and I think the answer to "why" is that this forum often models the agile mindset*:

1. @drbitboy suggested FAL (only because I got there first) with an expression that did not work;
2. @plvlce asked the key question (constant non-zero length?)
3. @plvlce got the expression and basic algorithm/math right;
4. @drbitboy tweaked it a bit from there.

Each step added value, and made the next bit of value easier to see; classic agile.

Others went down the FSC path; it didn't pan out, but that doesn't matter: they felt free to think; and for all we know someone still could yet find more value there.

Agile is a mindset, not a process.

* when it's not modeling an ego war.

 

[drbitboy]

This might work, with seven instructions, untested:

FLL 0 counters2 2
LBL counter_loop LES pos 60 BST GRT RFID_ARRAY[pos].len 0 ADD count 1 count NXB ADD pos 1 pos JMP counter_loop BND
​

• counters2 is an INT[2]
• pos is an index into the FIFO, and also an alias for counters2[0]
• count is the number of non-empty RFITs, and also an alias for counters2[1]

 

[Peter Nachtwey]

It is much simpler and faster to test if a string is "null" than to computer a string length.
Isn't there an easy test to check if a string is null?

 

[JesperMP]

If the strings in AB work anything like standard IEC STRINGs, then the 1st byte contain the max declared length, and the 2nd byte contains the actual length.
So 2nd byte = 0 means the string is empty.

 

[drbitboy]

It is much simpler and faster to test if a string is "null" than to computer a string length.
Isn't there an easy test to check if a string is null?

I suppose

EQU RFID_ARRAY[pos] ''
NEQ RFID_ARRAY[pos] ''​

would do it, if strings can be compared, but comparing .len to 0 may be faster, who knows how they implement this stuff.

 

[plvlce]

I suppose

EQU RFID_ARRAY[pos] ''
NEQ RFID_ARRAY[pos] ''​

would do it, if strings can be compared, but comparing .len to 0 may be faster, who knows how they implement this stuff.

Strings can be compared. Since OP specified v21 string literals aren't available however, you'd need to compare to a string tag storing a null.

 

[Peter Nachtwey]

Strings can be compared. Since OP specified v21 string literals aren't available however, you'd need to compare to a string tag storing a null.

This would be faster as it takes only one compare. Counting characters takes many.

 

[plvlce]

This would be faster as it takes only one compare. Counting characters takes many.

The length of the string is stored as an element of the string data type. If that length is zero, the string is a null -- one comparison.

 

[drbitboy]

This would be faster as it takes only one compare. Counting characters takes many.

.LEN does not count characters; .LEN is an object property; it is not a function like C's strlen.