Miscellaneous Do-More Questions

[Controls Guy]

1) I assume MEMCLEAR/COPY is significantly more efficient than MOVE when applicable?

2) Is there a way to reorder user data blocks in the list if they'll be accessed with REFx functions?

[BobO]

1) I assume MEMCLEAR/COPY is significantly more efficient than MOVE when applicable?

Yes.

2) Is there a way to reorder user data blocks in the list if they'll be accessed with REFx functions?

No.

[Controls Guy]

Need them 2D arrays then.  Can't store the memory block numbers in an array and nest the array refs I don't think.

[BobO]

The array reference can be a full expression in MATH. Is that not enough?

[franji1]

Need them 2D arrays then.  Can't store the memory block numbers in an array and nest the array refs I don't think.

Not really 2D arrays, you just need a slightly smarter calculation for the extra level of indirection utilized by your REF/REFWRITE instructions.

Say you were using D100 as your "Reference Type" value (aka Block #) in your REFWRITE/REF instructions.

You were probably doing something like a FOR loop for your D100 value, hoping you had a "contiguous" range of block #'s.

Say you had 5 blocks 40..44 nice and neat for your D100 values
FOR D100 40 to 44
// use D100 in REF/REFWRITE instructions
NEXT

But now you need 10 ADDITIONAL blocks, but those are now 50..59.

All you need to do now is store these block #'s in a range of V, or even better, a new block called MyRefType.

Define MyRefType to be 15 words long (for the 15 now non-contiguous block #'s 40..44, and 50..59).
Initialize that to
MyRefType0 = 40
MyRefType1 = 41
...
MyRefType4 = 44  // last of 1st contiguous block
MyRefType5 = 50  // first of next contiguous block
MyRefType6 = 51
...
MyRefType14 = 59

So each MyRefType ID now stores the unique block # value.

Now your FOR loop iterates through the simple 0..14 indexes of MyRefType:

FOR V0 0 TO 14
  MOVE MyRefType[V0] D100  // D100 now contains the V0th block # in your "non-contiguous" set of blocks!
  // use D100 just like you did before in your REFWRITE/REF instructions!
NEXT

Sure, it's a little extra overhead compared to what you were probably doing, but it's just as powerful!

[Controls Guy]

I know -- I was just hoping to do MyBigArray[BlockList[V101]]

I'm lazy plus I like it clean.  Whatever, it works.

[BobO]

I know -- I was just hoping to do MyBigArray[BlockList[V101]]

I'm lazy plus I like it clean.  Whatever, it works.

I'm confused. That's legal.

[Controls Guy]

I guess I should have tried it.   I thought nesting array refs was taboo.

Part of the issue is that I haven't used REFx very much so I don't know when I'm pushing the envelope.

Now is that nomenclature valid for assignment as well as use in an expression?  That would be part of the task.

[BobO]

Now is that nomenclature valid for assignment as well as use in an expression?  That would be part of the task.

No, sorry. Only as part of the expression itself, so it would require a two-part computation.

[Controls Guy]

I guess if you were really intent on reordering the user data blocks, and if you had a reasonable number, say 20 or so, you could start a new empty program, recreate all the blocks in the order you want them, then cut and paste the logic from the program with the blocks in the undesirable order into the new one.  A lot of effort, but it's something you'd hardly ever do.

[plcnut]

I really despise that extra MATH instruction to get the deeper nesting for indexes. I know we had an older thread about it in the past... What was the issue that makes the deeper nesting 'non-doable'?

I guess one thing I don't like about the extra step, is the readability/documentation. I have not figured out how to use meaningful names for the large number of indexes that I use in my programs using only 15 characters. Especially when many of my indexes require two v-mem's per index because of nesting. One thing that would help, is instruction level comments. Or maybe even a new instruction that would allow deeper nesting for inputs and outputs (a supercharged MATH box!).
What would the chances be of adding a new instruction that would allow expressions in the Destination field of 'MATHREF'?

[BobO]

I really despise that extra MATH instruction to get the deeper nesting for indexes. I know we had an older thread about it in the past... What was the issue that makes the deeper nesting 'non-doable'?

Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.

I have not figured out how to use meaningful names for the large number of indexes that I use in my programs using only 15 characters.

An unfortunate decision on our part to stick with 16 character nicknames. That decision was made early in the development, when we thought it was going to be a quick-n-dirty effort. We are planning to increase that in a future rev, maybe 2.0.

Or maybe even a new instruction that would allow deeper nesting for inputs and outputs (a supercharged MATH box!). What would the chances be of adding a new instruction that would allow expressions in the Destination field of 'MATHREF'?

Right side of the equal should be effectively unlimited now, at least in MATH. I'm pretty sure we could do an expression in a simple output reference. Meaning "D[V0 + V1*10 + V2*100] = Expression" would be legal.

[Controls Guy]

So would the enhanced ability on assignment include array references in the expressions?  Even array-less expressions would be very powerful and address many of the cases.

[Controls Guy]

Everything is do-able, the question is ROI. I have spent a bit of time thinking about this though, and I know how to do it pretty easily in the PLC. Whether I can talk Franj into the the Designer side work remains to be seen.

If you can, Do-More would be industry-leading in this respect.  This (lack of nested array refs) has been a thorn in my side with Control Logix since the inception.  Such a cool vision, and then they leave out critical parts.

[BobO]

So would the enhanced ability on assignment include array references in the expressions?  Even array-less expressions would be very powerful and address many of the cases.

Like this: "D[D[V0] + D[V1]] = Expression"? Yes.