It should not, this is not C++, HMI should look for the LEN field if they want to follow Logix rules, but I recall that old FTView did the same long time ago.
But even in this case, all you need to do is to place 0 into DATA[0]
That's actually a fair point.
I've found in a few instances where the String type is used as a buffer space for comms, particularly ModbusTCP and Message paths.
My overall goal would be to prevent any mishap in those instances when simply zeroing .LEN and .DATA[0].
My go to for zeroing any structure was to keep an appropriately named zeroed copy of the structure and COPying it in to the target.
- The issue eventually faced is tracking down mismatched zero-structures when the original changes. With UDTs, not such a big deal, but Strings are evil in this regard.
-- I've almost scratched an itch lately to simply create a one-size String type from an AOI that has a variable length and fixed backing capacity of perhaps 256 bytes and bundles all the code operations you would typically perform upon it.
-- You could even use aliasing techniques to assign the contents to a Logix String type when needed.
--- How does FLL work, anyway?
--- How is it able to ascertain the number of bytes in which to populate zeros into any structure thrown at it, for example?
--- It appears to also generally accept any blob of bytes thrown at it - is there a way to pass-by-generic-reference (pointer-to-void) that I've missed all this time? Or cast the passed object as something else entirely?
---- In that vein, one curious thing is that with some UDTs and when they could be passed by reference into a Rockwell-defined AOI, a simple value of 0 can be substituted if you don't reference an instance of the type.
---- In the picture, Bus[1] is actually optional and 0 can be substituted.
---- How can we pull off the same thing with our own AOIs?