1. When using groups strictly for organization, and while keeping the field name globally unique, it wouldn't be necessary or advantageous to require the full name (group.element.field) to be entered or displayed, while for true objects, the group name would be required for uniqueness.
Tres S7! Over there you can create a Data Block, and put heap items inside, either singletons or n-D arrays (up to 4D I think?), and name them whatever you want. It gives you data organization namespace as well as storage-location-wise, and readable code. For example, in one app I have a Burner DB, that has a bool element Permissive inside, referred in ladder as Burner.Permissive. I do this a lot. Very helpful. (Though you can do user defined types as well, but I typically only do that for something repetitive, that you think of more as an object).
2. Since we are also adding user defined structure elements, there is clearly some overlap here. Do you construct your structure concept as true structures contiguous in memory and able to be added as memory blocks, but with the limitation of containing simple types only, or do you construct your structures as documentation objects, with the advantage of being able to contain any valid element...even strings and other structures...but only as random heterogeneous memory?
Don't necessarily see a conflict there. Even with complex member types, the maximum size is known, so if you do an array in contiguous memory, you know how far apart to put them. Maybe allow for default values and some sort of constructor mechanism because if you do anything that increases the struct size, they're all getting rewritten.
And yes Steve, you will be able to have symbolic constants in a namespace...so MaxFlow, Pump1.MaxFlow, Pump2.MaxFlow could be three different constants.
Yup, that's something I definitely want, but namespaces in general is even bigger. Really, really want that.
And since a structure could be included in a namespace, we're kinda nesting structures too.
Yeah, but only two deep though!
Actually, two deep covers 80-90% of the use cases.
Final word -- whatever you do with namespaces,
PLEASE ALLOW NAME WRAPPING IN LADDER DISPLAY! Control Logix shot themselves in the foot here, bad. They have a for the most part very good memory architecture, with user types, and so on, but if you really exploit it and use it to it's full potential, you end up with LONG variable names, like Tank[38].Heater.Safety.Overtemp, and THEY DON'T WRAP THE VARIABLE NAMES. D'oh! So if you are zoomed to where the text is readable, you might get two or three element across a screen display.
