Host Engineering Forum
General Category => General Discussion => Topic started by: PLCGuy on March 26, 2016, 04:57:14 PM
-
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.
-
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.
-
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...
-
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.
-
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.
-
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!
-
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?
-
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.
-
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.
-
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).
-
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.
-
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.
-
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) ;D [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.
-
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) ;D [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.
-
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.
-
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.
Temporarily zooming out and in using Ctrl+Mouse Wheel is great for graphics that are too big to fit on the screen. 11 zoom levels makes this quite useful.
-
Temporarily zooming out and in using Ctrl+Mouse Wheel is great for graphics that are too big to fit on the screen. 11 zoom levels makes this quite useful.
"Great", no. Marginally acceptable till it gets fixed, yes. "Great" would be finishing it (though I'm still waiting on Rockwell for this self-evident change after 16 years so I ain't holding my breath for them at least).
Take AutoCAD as an analogy. In the early days, screen size and resolution were such that your view was either broad or deep. You could zoom out to see an entire schematic page, but you couldn't read the text. If you were tight enough to read the text, you could only see about a third of the page, so sometimes your context was limited; you were zooming in and out all the time (which with the PCs of the day was a time-killer in and of itself). There will admittedly always be a tradeoff between depth and breadth, but to get useful information bandwidth, you have to be able to get a minimum level of both depth and breadth simultaneously. Display size and resolution eventually reached the point where AutoCAD had a tipping point for this issue, where you could get adequate breadth and depth simultaneously so that working digitally carried no penalty to have to balance with the obvious advantages. Now, we're WAY past that tipping point. My current screen is about the size of a paper drawing with resolution approaching that of paper, so I can see an entire drawing at once and still read the text just fine.
The same principle is applicable in PLC commissioning, but even more so. You're not viewing a static drawing, but a rung or three where you need to see all the status in real time, preferably while still being able to see what each token represents. As a practical number, I'd say you need to be able to show 8 or ten contact across with maximum length tag names in a readable font. THAT'S why tag name wrapping is a must-have.
-
We have no plans to wrap nicknames, so I guess you'll be stuck with descriptions after all. Good thing you like those letter/number thingies.
-
No, even with nicknames at 32 characters max, I think you can probably get an adequate number across the screen without wrapping; I'm talking about tag names, particularly once you implement structs. Then I think you're going to HAVE to look at wrapping to keep DMD as functional as possible.
Assume that in a process plant, I create a TempCtrl struct, which might include a BOOL member named HeaterEnabled. Now I create a struct to represent a process tank, one member of which is a TempCtrl struct that we'll call "Temp". Now I might instantiate those tank structs one at a time by name, but lets say there are several similar (plus I might want to iterate through them), so instead I create an array, say "MixTank"[0..19].
So then a typical tag would be "MixTank[13].Temp.HeaterEnabled" -- I could easily see those type tags exceeding a length that would let you display rungs with a good combination of breadth and depth, and if you keep your tag names short and non-hierarchical, then you're letting the power of the concept go to waste (for a lot of applications). RS5000 has never done anything to address this and it DOES seriously impact productivity.
-
It will be a while before we nest structs, but yes, I can see how that would get painful pretty quickly.
-
It will be a while before we nest structs, but yes, I can see how that would get painful pretty quickly.
I know, but I trust we'll get there eventually! ;D
RS5000 doesn't even wrap on the paper printouts, and it makes those a lot less usable for the same reason. Even if they just defaulted to wrapping on every dot, that would put each level of hierarchy on its own line, which would be very intuitive and easy to read. You could explicitly override the default wrapping if for whatever reason you needed to.