Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on March 29, 2016, 03:17:00 PM
-
Documentation fields, that is. Is 32 enough? Do we need more? No...unlimited is not an option. ;)
Sound off!
-
After learning to live with 16; I believe that 32 will be enough.
-
Wait, I'm confused. We can already have descriptions longer than 32 characters, can't we? It's got to be like 4x12 or 5x12 or something, seems like. Or are you talking about nicknames specifically?
-
Just to throw this out there, C-more has a 40 character limit.
-
Wait, I'm confused. We can already have descriptions longer than 32 characters, can't we? It's got to be like 4x12 or 5x12 or something, seems like. Or are you talking about nicknames specifically?
We're talking about increasing nicknames and wiring info to 32, and descriptions would grow to 6x32 (they are currently 6x16).
-
Just to throw this out there, C-more has a 40 character limit.
That was another number we've kicked around. Any insight into how they arrived at that?
-
It seems I always need one more character than what's available, so whatever you decide on, make it +1 ;)
32 characters would work for me.
Since you brought it this up, it would be nice to be able to use other non-alphanumeric characters other than the underscore.
-
Since you brought it this up, it would be nice to be able to use other non-alphanumeric characters other than the underscore.
We really can't. Since nicknames are actual symbols that can be used anywhere as a replacement for element names, they have to follow a restricted format that works within the grammar of the places they are used. The most common characters you might use are already part of the math expression grammar, and we still have plans to expand the math grammar to a full ST type language. With that in mind, we chose what is essentially a C style symbol definition.
-
Just to throw this out there, C-more has a 40 character limit.
That was another number we've kicked around. Any insight into how they arrived at that?
IIRC it was the minimum number of characters to support AB tag names for Ethernet IP in order to make them unique.
-
What about a decimal point in the name? It would be nice to have some pseudo name space. I think if you are going to use 40 characters, you should just go ahead make it 64. Maybe down the road, you might need it?
-
What about a decimal point in the name? It would be nice to have some pseudo name space. I think if you are going to use 40 characters, you should just go ahead make it 64. Maybe down the road, you might need it?
I think the number will be 32, but we will look at making it easier to change in the future.
I'm sure we could do about anything we want as far as embedding stuff, the question is simply how painful the parsing becomes and how patient our users are when the never ending stream of side effects show up. When you can mix all of the valid elements and nicknames, and in some cases even combinations of both (for instance, T[MyIndexNN].Acc), in with full expressions with nested function calls, tossing in random punctuation isn't conducive to simplicity.
But seriously, I've been coding with C symbol rules for my entire professional career and I haven't once been frustrated that I couldn't embed a pound side or dollar or ampersand or whatever. I camel case for clarity, and might add an underscore when I need an additional level of division. "MyObject_Field" isn't meaningfully different in practice than "MyObject.Field", is it?
And remember that you will be able to create your own data types. Rather than creating pretend structs with dots in nicknames, you will be able to create real structs.
-
we will look at making it easier to change in the future.
Future proofing is good.
And remember that you will be able to create your own data types. Rather than creating pretend structs with dots in nicknames, you will be able to create real structs.
I'll be saying to the young engineers," Why back in my day, all we had was 16 characters for a tag name ...."
-
I'll be saying to the young engineers," Why back in my day, all we had was 16 characters for a tag name ...."
Nah...worse: "Back in my day all we had were 1s and 0s, and some of us even had to use pointy sticks for 1s."
-
And one other thing...
In our discussions about adding a documentation grouping mechanism, we did discus the possibility of treating the group name act like a class name, hence "Group.Item" might become a reality, not as an adornment of a nickname, but as a legitimate object concept. I'm also thinking that if a documentation group could be flagged as belonging to a program or task block, scoping might fall out of that. But I don't want to overly complicate it from the onset, preferring to get the basic group thing working and see where it leads.
-
And one other thing...
In our discussions about adding a documentation grouping mechanism, we did discus the possibility of treating the group name act like a class name, hence "Group.Item" might become a reality, not as an adornment of a nickname, but as a legitimate object concept. I'm also thinking that if a documentation group could be flagged as belonging to a program or task block, scoping might fall out of that. But I don't want to overly complicate it from the onset, preferring to get the basic group thing working and see where it leads.
I have been in C#.NET land for the past 2 months, so this is music to my ears (Where is the jumping up and down with excitement emoticon?). ;D
And I personally have no use for anything more than Alphanumerics and underscores in a nickname.
-
Since we are talking about documentation, one of the things I liked about DirectSOFT, that's not in Do-More, is when you open the documentation editor all the elements are shown. This makes it nice when entering documentation, you can see what you have entered and what elements you haven't used. It also makes it nice to see that all your data points are blocked together, that you didn't skip a variable by mistake. It would be nice to have an option to display all memory locations available or to display only the memory locations for which nicknames have been assigned.
It would also be nice if the Documentation Editor contained a dropdown list or tabs for displaying only the selected memory types. Having to scroll through the entire memory list of memory to get to the Modbus Holding Registers elements isn't ideal, to be able to display only the MHR or R or combinations of memory types would be more user friendly.
And this might just be something that annoys me but, when using the Add Documentation Record window, when adding documentation for a bit of word, say MHR105:0, when you enter that record the window increments to the bit of the next word, so it would go to MHR106:0 when I would hope it would go to MHR105:1. When entering documentation for bits of a word I usually enter all the bits of the word before moving on to the next word.
-
Since we are talking about documentation, one of the things I liked about DirectSOFT, that's not in Do-More, is when you open the documentation editor all the elements are shown. This makes it nice when entering documentation, you can see what you have entered and what elements you haven't used. It also makes it nice to see that all your data points are blocked together, that you didn't skip a variable by mistake. It would be nice to have an option to display all memory locations available or to display only the memory locations for which nicknames have been assigned.
DL's memory maps were tiny compared to Do-more. Plus, with the ability to document a cast, a single D location has over 40 possible variants. It gets ugly fast. The list could easily contain over 2M items in a facility that was originally designed to handle 1000s. Our best attempt at giving you what you want is the ranged record mode in the Add Record dialog. Not optimal, but with very minimal extra effort you can get full ranges of elements.
We are kicking around the idea of automatically adding records for all installed I/O.
It would also be nice if the Documentation Editor contained a dropdown list or tabs for displaying only the selected memory types. Having to scroll through the entire memory list of memory to get to the Modbus Holding Registers elements isn't ideal, to be able to display only the MHR or R or combinations of memory types would be more user friendly.
I like the idea of filters.
And this might just be something that annoys me but, when using the Add Documentation Record window, when adding documentation for a bit of word, say MHR105:0, when you enter that record the window increments to the bit of the next word, so it would go to MHR106:0 when I would hope it would go to MHR105:1. When entering documentation for bits of a word I usually enter all the bits of the word before moving on to the next word.
It's doable, just gotta get the new hardware done first. When that was originally written, I don't think were were documenting casts.
-
Fill Documentation Records -
Element Nickname Description
C10 Josy01 Josie 01
It will give
C11 Josy2 Josie 01
What happened to the leading 0 in Josy01 carrying to Josy02? Josy_01 is also Josy_2
Same happens in "Add" in Doc Editor when "Keep Record Content..." is checked.
(I just had a weird one happen in Fill, it gave me a bunch of C2 - #Josy-# or something entries, but I can not duplicate it, so I don't know what I did.)
(Fred gets tired of being my test nickname.)
-
(Fred gets tired of being my test nickname.)
Try Bob. (Or BobO if that doesn't work) ;D
-
Had a short time to implement Fill in response to a customer request just before shipping 1.4. Simple rule set was the only way to get it done in the time available. Choice was "you can have it awesome and get it next year" or "have it good enough and get it now".
-
(Fred gets tired of being my test nickname.)
Try Bob. (Or BobO if that doesn't work) ;D
Flintstones. Fred, Wilma, Barney, Betty, Pebbles, Bam Bam, Dino, and on rare occasions even Mr. Slate.
-
Had a short time to implement Fill in response to a customer request just before shipping 1.4. Simple rule set was the only way to get it done in the time available. Choice was "you can have it awesome and get it next year" or "have it good enough and get it now".
I just thought I had better ask. I seem to miss the obvious on occasion. Then again, doing things a little different than other folks means I get to find lots of hidden "features". I've got quite a list started this past couple of weeks on C-more unfortunately.
-
By all means...ask when in doubt. That's why we have this forum.
-
And one other thing...
In our discussions about adding a documentation grouping mechanism, we did discus the possibility of treating the group name act like a class name, hence "Group.Item" might become a reality, not as an adornment of a nickname, but as a legitimate object concept. I'm also thinking that if a documentation group could be flagged as belonging to a program or task block, scoping might fall out of that. But I don't want to overly complicate it from the onset, preferring to get the basic group thing working and see where it leads.
:) :) :) :)
-
Glad you guys are doing this. I never seem to have enough.
Sometimes I feel like I'm writing a book but with my memory, I need all the help I can get. ;D
-
The original vision for groups in documentation was simply organization. You create a group, you assign a doc record to a group, you sort the order of groups or records in a group, and the group could be hidden or shown independently.
But now we are seeing how this could blossom into something a bit more useful, where groups become scopes, and in essence define an object. A couple of questions that come out of that:
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. Would it bother anyone if we required groups to be created as organizational vs 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?
3. And lastly, does the #2 makes things complicated to the point that folks get confused?
I very much like where this is going, but I fear that like so many things in Do-more, we'll offer too many ways to solve the same problem and users will get confused.
-
After more internal discussion, we are trending toward eliminating the organizational concept and consolidating everything under a single namespace concept. If you use a namespace, the namespace.record name must be globally unique. Records outside a namespace must be globally unique, which really just means that they must be unique to the implied global namespace.
The other thing we like is the ability to create a copy of a namespace. Click the namespace, select create new from selected, and then we give you a dialog with all of the source namespace's records stubbed. You then enter the new namespace name, target memory addresses for each field, and we create the new namespace that matches the source.
Old-school users can continue to use the global namespace with shiny new 32 character nicknames, but the cool kids can go full OO. Win/win.
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. And since a structure could be included in a namespace, we're kinda nesting structures too. ;)
-
Global scope is fine with me. Having the ability to copy an entire group of variables will be a big time saver. Many times you are working on systems that have similar, if not identical parts, which would make it easy to copy data sets and not have to do the export/import thing from Excel.
-
Once we have a facility for cloning a namespace, I'm sure it could easily adapt to cloning a selected range of records, one being a subset of the other.
-
Since we are talking about documentation, one of the things I liked about DirectSOFT, that's not in Do-More, is when you open the documentation editor all the elements are shown. This makes it nice when entering documentation, you can see what you have entered and what elements you haven't used. It also makes it nice to see that all your data points are blocked together, that you didn't skip a variable by mistake. It would be nice to have an option to display all memory locations available or to display only the memory locations for which nicknames have been assigned.
DL's memory maps were tiny compared to Do-more. Plus, with the ability to document a cast, a single D location has over 40 possible variants. It gets ugly fast. The list could easily contain over 2M items in a facility that was originally designed to handle 1000s. Our best attempt at giving you what you want is the ranged record mode in the Add Record dialog. Not optimal, but with very minimal extra effort you can get full ranges of elements.
We are kicking around the idea of automatically adding records for all installed I/O.
It would also be nice if the Documentation Editor contained a dropdown list or tabs for displaying only the selected memory types. Having to scroll through the entire memory list of memory to get to the Modbus Holding Registers elements isn't ideal, to be able to display only the MHR or R or combinations of memory types would be more user friendly.
I like the idea of filters.
And this might just be something that annoys me but, when using the Add Documentation Record window, when adding documentation for a bit of word, say MHR105:0, when you enter that record the window increments to the bit of the next word, so it would go to MHR106:0 when I would hope it would go to MHR105:1. When entering documentation for bits of a word I usually enter all the bits of the word before moving on to the next word.
It's doable, just gotta get the new hardware done first. When that was originally written, I don't think were were documenting casts.
Just today I was trying to get the bits of words added for documentation in v2.0.3 and I found it still doesn't seem possible to add N100:0 thru N100:15. I know the BRX priority thing took precendence, but hopefully you can find some time to help us out with this soonish. I have been documenting literally thousands of memory locations today due to Modbus stuff. Excel works, but sometimes it feels like it really wants to mess with me when it comes to retaining double quotes or searching and replacing without hosing other things.
Also, is it possible to export a program, pull out just the logic mnemonics, edit them and import back just the rungs I want into the existing program? So far I have only succeeded with the import as a new program and that means lots of things cause it to fail if they are not there yet (setting up the SERIO-4s for example.)
-
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! ;D 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.
-
Also, is it possible to export a program, pull out just the logic mnemonics, edit them and import back just the rungs I want into the existing program? So far I have only succeeded with the import as a new program and that means lots of things cause it to fail if they are not there yet (setting up the SERIO-4s for example.)
I didn't look hard enough! Select rungs in DmD and <Ctrl> + C. Open Wordpad and <Ctrl> + V. Make edits. Delete all the gobbledegook above the rungs I want and save file. Then in DmD, Select the location I want to insert in ladder. Tools > Insert Instructions From File...
I am guessing the gobbledegook needs to be there for something, but all attempts this morning to use it have been fruitless.
I can't get past the Insert Code Block errors. What does the (16) in the output window mean when it says:
[Error] JoeBob.txt(16) Invalid element type
Looking at the file I need to know where to look.
-
You are referencing a data type that hasn't been defined.
If you had the following logic:
STR X0
MATH N0 "D0+D1"
...and edited it to:
STR X0
MATH MyNewBlock0 "D0+D1"
And MyNewBlock was not already part of the configuration, you need to add it to the MEM_CONFIG definition.
It were an unsigned byte block you would add something like:
MyNewBlock UBYTE 1024 -1
Recommend you create a block like you want in the MemConfig and export it to see the proper syntax for what you need.
I'm sure Franj can elaborate more on the nuances of import/export/insert code/etc.
-
Considering I had copied a functioning block of code out to Notepad then tried to do the Insert Instructions (Code Block) I figured it would already have the needed memory blocks. I just looked and this was in it:
PLC DM-SIM
#BEGIN MEM_CONFIG
MRXFailedVFD BIT decimal 64 -1
MWXFailedVFD BIT decimal 64 -1
DeadJimVFD BIT decimal 64 -1
#END
So what if anything does the (16) mean in:
[Error] JoeBob.txt(16) Invalid element type
I obviously need to start with something simpler to figure this out.
-
Considering I had copied a functioning block of code out to Notepad then tried to do the Insert Instructions (Code Block) I figured it would already have the needed memory blocks. I just looked and this was in it:
PLC DM-SIM
#BEGIN MEM_CONFIG
MRXFailedVFD BIT decimal 64 -1
MWXFailedVFD BIT decimal 64 -1
DeadJimVFD BIT decimal 64 -1
#END
So what if anything does the (16) mean in:
[Error] JoeBob.txt(16) Invalid element type
I obviously need to start with something simpler to figure this out.
Please post JoeBob.txt, or the code at line 16 in that file.
-
So what if anything does the (16) mean in:
[Error] JoeBob.txt(16) Invalid element type
Sorry...it's the line number.
-
Please post JoeBob.txt, or the code at line 16 in that file.
I was trying not to do that :-[ as it didn't like a second code block named Main so I changed it. It was late! And Spring Forward to boot.
Line 15: // Beginning of Code Block $Main
Line 16: $PRGRM $DangitBob
I had to use Notepad++ to even see the line numbers. I thought either Notepad or Wordpad had a status line but it seems not.
-
Program blocks are structures and must exist in memory as either a heap item or a block.
Add this line to the MEM_CONFIG section: DangitBob PROGRAM 0 -1
And drop the leading '$'. That's for system generated stuff.
-
Ahh, OK and thanks.
It's frustrating to know the answers are right there if I could just "see" them the right way.