timer documentation

[PLCGuy]

Maybe this was discussed before. It is concerning Timers. Let's say I enter Timer 1 and label it "On Timer". Set it to 2 secs.
Now go to next run and enter T1.Done. The label is not there. Can you make it carry over the label "On Timer" or give option to re-label it?
AB gives that option, but it you ignore the pop up to give it a label, it keeps the Original Title.

[Mike Nash]

Ha ha. I know that one has been brought up and desired it again myself this week. What I can't recall is what the response was.

There are quite a few questions I have had this past couple of weeks I know have been answered but I can't seem to locate the messages.

[BobO]

I'm not sure what you are wanting it to do. I add a TMR and name the associated structure, and it does show up in the list...

[Mike Nash]

This gets back to the nicknames vs descriptions thingy.*

Choosing to use descriptions means going to the doc editor** which won't even list the chosen timer until the rung has been accepted. If you do have it, you don't have Tx.Done because you haven't used it yet. So when you do use it, by adding a contact say and typing Tx.Done (because you know Tx is what you want - x being some actual number) it doesn't have the description from the TMR, it has no description. Back to doc editor again to fix this.

We would like to see the .Done inherit the TMR description, maintaining the ability to edit the .Done description later if we choose.

I would like the associated structure sub-elements to automatically be added to the doc editor when any part of the structure is accepted.

** Element Picker doesn't have the ability to comment the picked element.
     Element Browser does, but doesn't help with the .Done.

*  Nicknames are still too restrictive at this point.
     ->16 characters and limitations on those.
     ->They are all global so look-alike routines can't be the same.

Between those 2 limitations alone on nicknames I keep going back to elements only as I waste too much time trying to get nicknames to fit, or not be so alike (but different) that I get confused.

[PLCGuy]

I see what I did. Only the NickName or Extra Info shows up as a label to Tx. I filled in Description and that does not show up in the element.

[BobO]

Nicknames are actual symbols and get special love. I could probably have other doc fields inherited like them. That somewhat misses the point though: you guys are forced to use descriptions due to limitations on nicknames. The better answer is to fix nicknames. And we will. DmD 2.0 will increase nicknames to 32 characters. I can't imagine programming without auto complete, and yet you work that way all the time by using descriptions. Yuk.

As for adding all fields, I'm torn. Makes good sense for stuff like timers or counters, but some (like programs) have a large number of fields. Makes for a mess. I guess we could make it optional.

I was kicking around automatically adding all I/O associated with installed modules. We can look at other stuff at the same time.

And by the way...Christ is Risen indeed!

[PLCGuy]

Thanks Bobo. Yea, I think because of how limited nick-names is, I tend to us descriptions.
When is the release of 2.0 scheduled?

[BobO]

Thanks Bobo. Yea, I think because of how limited nick-names is, I tend to us descriptions.
When is the release of 2.0 scheduled?

DmD 2.0 will ship concurrently to the launch of the new hardware platform. Specific date is yet to be determined. We still feel that late this year is the target, with a possibility of it slipping into early next year.

[BobO]

I will also mention that we had a discussion today about increasing nicknames to 32 characters, and how that will affect description display. Here's what we decided:
1. All fields will be increased to 32 characters...NNs (1x32), wiring info (1x32), and descriptions (6x32).
2. Hard carriage returns can still be used to format descriptions and will take precedence over soft formatting.
3. Descriptions will use a new optimized width, which will work as follows:
  a. Minimum width of 16 characters, maximum of 32.
  b. We will optimize the description to the width of the widest field in a rung column, within the boundary of 'a' above.
  c. If the optimized minimum width per 'b' produces greater than 6 rows, we will widen the description until it fits within 6 rows, thus establishing a new width for the rung column.

If we pull this off as expected, descriptions will take the fewest number of rows possible, while not forcing the width to 32 characters everywhere. It should make the display efficient, and still allow you to use the full (2x as large) description where you want, overriding the optimized behavior with hard CRs as desired.

[Mike Nash]

I was just wondering today which way would work best, trading row height for column width or vice versa. I had one rung too tall to fit on the screen, and the next too wide. So obviously nothing is going to be perfect all the time.

And I am not really fond of Rockwell's rung wrapping as it can get pretty confusing, especially with variable column width between wrapped rows mixed in.* But I truly hate fixed width and nicknam... style ladder others have. Especially when the missing letter is less than the ellipse...**


*Yes you can turn it off.
**Yes you can make all columns wider (so none fit on screen).

[BobO]

I was just wondering today which way would work best, trading row height for column width or vice versa. I had one rung too tall to fit on the screen, and the next too wide. So obviously nothing is going to be perfect all the time.

And I am not really fond of Rockwell's rung wrapping as it can get pretty confusing, especially with variable column width between wrapped rows mixed in.* But I truly hate fixed width and nicknam... style ladder others have. Especially when the missing letter is less than the ellipse...**


*Yes you can turn it off.
**Yes you can make all columns wider (so none fit on screen).

One of the primary reasons we have resisted increasing the width is due to concerns about display efficiency. We kinda ran over that one in a rather backhanded fashion when we added indexed struct blocks, such that "123456789012345[123456789012345+12].123456789012345" is a valid size for an element field. Meaning...we're already dealing with it at the element level, but haven't yet jumped into it on the description. If there was an element that was as wide as the previous example, we want the description to take advantage of it, but we still want it to be friendly if everything else in the column is well behaved. I trust that y'all will let us know how we did.

Our general bias about width vs height is that monitors are generally getting wider, not taller, so we prefer burning width over height. As you mentioned, that'll always be wrong for somebody some percentage of the time, but we are aiming for the most useful display, the majority of the time.

[Controls Guy]

This is a HUGE beef I have with the Control/Compact Logix tag based family.  If you use the paradigm to it's potential, you end up with VERY long tag names, AND THEY DON'T WRAP THEM!! So you get like two contacts in the screen width.  There desperately (for most tag-based systems, but especially if you implement user types) needs to be some default and/or user-controllable wrap for tag name display.  If that long, the tag names are probably descriptive enough that you don't need descriptions, so you can use some of that height.  Two contacts per screen width is just unacceptably absurd.

[Controls Guy]

That somewhat misses the point though: you guys are forced to use descriptions due to limitations on nicknames.

Eh....not necessarily!  I do like the description partly because it's more verbose and not subject to rules like no spaces (therefore possible to write in people-speak), but I also like seeing the address (and typically use that for entry)    [ducks and runs]

I'm with Mike or whoever said we need scoped nicknames (and possibly constants).  I use them a fair amount now, but then I'd use them more.

[BobO]

Eh....not necessarily!  I do like the description partly because it's more verbose and not subject to rules like no spaces (therefore possible to write in people-speak), but I also like seeing the address (and typically use that for entry)    [ducks and runs]

I'm not a PLC programmer per se, but I have written a few lines of code in my day, probably a touch more than the rest of you rookies , and there is *zero* chance that I would give up symbolic programming with autocomplete. Zero. To choose to enter silly little letter-number combinations...on purpose...when there is a nice drop-list of available names, is difficult for me to wrap my head around. But feel free to do so if it makes you happy, because despite the obvious joy that I get by mocking your 70s-eqsue ways, I really do want you to be happy.

I'm with Mike or whoever said we need scoped nicknames (and possibly constants).  I use them a fair amount now, but then I'd use them more.

Scoped seems hard, although the documentation grouping facilities we are adding for 2.0 will certainly help, and might even end up being a stepping stone to scopes.

[Controls Guy]

And don't forget to at least look at wrapping.  Long, deeply hierarchical tag names need it, because now the symbol is its own description, and I really really really hate not seeing the whole rung all on screen at once, except obviously for extremely complex ones.  Especially when it seems like there's no reason for it.