Request for User Data Type Editor

[BobO]

Actually, I like having both predefined memory locations and tag generation. It saves time not having to define tags for the simplest of things and simplified communications with other devices. Tags are great when working with data. Why throw the baby out with the bathwater? I knew they would come around someday.

At the least there will be two modes, conventional and tag, but I suspect that our tag-based implementation will be more of a hybrid. You will lose nothing.

[Controls Guy]

At the least there will be two modes, conventional and tag, but I suspect that our tag-based implementation will be more of a hybrid. You will lose nothing.

I'm with ATU on this one.  Both is best, and memory architecture matters a lot to me.  This is the way Siemens S7 works, and this is a part of why S7 and Do-More are my go-to controllers right now.  Some preallocated table memory (though not expandable or shrinkable like Do-More), but most memory free for user defined "Data Blocks".  It's kind of like a one-off UDT.  The Data Block gets a name, and then you can put tags/heap items of internally defined typed or UDTs in it, even in arrays.  So you create a DB called "Burner", and you might have a bit inside called "Enabled", which is then "Burner.Enabled" in logic.  So they're better than AB tags, because you can get layers of hierarchy in the naming.  AB is better on scoping.  The only way with Siemens to scope a variable is to put it in a "Function" or "Function Block", which then must be called from logic.  A regular logic file is called an OB or "Organization Block", and if it has the right number, will get called automagically without having to clutter up the ladder with calling it explicitly.

Oh, and S7 is smart enough to know that a 25-character tag name needs to be wrapped to a normal column width.  Who knew?  Control Logix, even after 20 years, still thinks it needs to be written out horizontally on one VERRRRRY long line.

One place S7 stinks is all the byte-based addressing (only on the predefined memory) and the goofy-butt endianness.

[ADC Product Engineer]

Good lord, man, we aren't savages!

In truth we are starting to recognize the importance of terminology to intuitiveness. If 50% of the market know a certain thing by a certain name, it's kinda dumb to try to retrain them. There is a distinct possibility that someday DmD might even support tags. 

Gee Brain.  If we change everyone's name, won't they get confused about who they are?

[ATU]

Another suggestion is to provide default descriptions for the User Defined Data fields. When the Heap items are created, then the description fields are preloaded by those specified in the definition, but can be changed for individual instances.

[BobO]

Gee Brain.  If we change everyone's name, won't they get confused about who they are?

Yes, Pinky. But that is a key part of my plan to take over the world.

[Controls Guy]

Good lord, man, we aren't savages!

In truth we are starting to recognize the importance of terminology to intuitiveness. If 50% of the market know a certain thing by a certain name, it's kinda dumb to try to retrain them. There is a distinct possibility that someday DmD might even support tags. 

Yeah, I know what you mean.  Interestingly, the effect varies varies from term to term.  UDT seems to be burned into my lexicon, even though "Struct" would make just as much sense, whereas tags vs. heap I don't much care (though tags is more likely to work without explanation when the conversation has to include someone of undetermined background).

I kinda went off on a tangent with that post above.  The basic intent was to concur with ATU that controllers with both classic table memory (presumably at least partially predefined), as well as tag/heap capability are the best of both worlds and make our lives easier, and to give kudos to Do-More and Siemens as the only two controllers I know of that have that.  Then of course instead I go off into a long winded comparison of the merits of the memory structure of every PLC known to man! 

[ATU]

Concerning the use of UDT's.  I tried to do a memcopy from the Standard V memory area to a UDT. Is this possible? If so what are the rules?

[franji1]

Concerning the use of UDT's.  I tried to do a memcopy from the Standard V memory area to a UDT. Is this possible? If so what are the rules?

MEMCOPY size MUST be in terms of the # of UDT elements (NOT the # of V elements).  If it is a Heap Item, the count (obviously) must be 1.

MEMCOPY Definitely useful for mapping MHR to/from a "Device" that are actually mapped to a bunch of "struct fields" (bits, floats, etc.).

[franji1]

For some reason, I keep wanting to right click to get a menu to insert a line. Probably decades of Excel use. Could that be something easily added?  Have Insert, Delete on a right click menu? If its a lot of trouble, I would not mess with it.

Take 2 - this will be in the next release...

Added a context menu for the Edit UDT Definition dialog to Add/Insert/Edit/Delete... fields
(see UDTFieldEditContext2.png attachment)

Added a context menu for the SysConfig/MemConfig/UDT sub-dialog to Add/Edit/Delete... UDTs
(see StructListContext1.png attachment)