Host Engineering Forum
General Category => General Discussion => Topic started by: tmoulder on April 18, 2013, 10:08:40 AM
-
Okay, I've been using the do-more designer software long enough now to start rendering some constructive criticisms about it. Most of this falls under the heading of "let me just get on with it".
1. If I add an unused bit to the ladder, and nothing is defined (tag, comment, etc), it should automatically open the data entry pop-up. Wasted mouse clicks double-clicking an element I just added to give it a name.
2. If I change a description or tag in the data-entry pop-up, I should not have to hit enter 3 times to implement the change and close the window. On a related note, having to hit ctrl-enter to add another line is so last-century. Give me an instruction comment line-wrap parameter I set once, and parse accordingly so I can just get on with typing.
3. When assigning addresses to ladder objects, I don't need to know there are 2048 X bits in the memory configuration - I need to browse them and choose the one I want. My programming style uses memory ranges - C1000 to C1200 reserved for alarm bits, etc, and the current scheme offers little practical support for this. As it stands, I assign X32 to "Start Button" and if I want to assign it to a bit elsewhere, I need to look it up in my hand written notes.
4. Yes, I know - tags. I've never met a tag I didn't hate instantly. Simple example - Tag says "MotorOn" with no indication of whether this is an X, Y, or C bit. Sure, you can make a naming convention, but people being people, it gets forgotten, alot. The more programmers involved in a project the more messed up it becomes - exponentially.
Prefix the tag automatically with the data type. And allow spaces in Tag names. Most of us are neither young nor computer science majors, and reading these makes for eye-strain and migraines.
5. When I open the tool pallet, it covers a third of the screen, and the first thing I do in edit mode is close it again. Nevertheless, I use it alot. A true love-hate relationship. Restructure it to a tool bar with drop-down and fly-out menus. Show me a list of categories and I can figure out what I need from there.
The software is pretty good so far, but I'd ask you to consider and adhere to an ancient, hoary principle of HMI design - 2 button presses is one too many.
Thanks!
TM
-
Regarding the tool-tip pop-ups for the instruction pallet, I appreciate the amount of work that went into these, but honestly - overkill. A simple definition of what the element is would be sufficient to let me know if it's the item I want to use in a given spot. You already let me click on the tool-tip to go directly to the help page, and that is a VERY GOOD THING ;D But it's not nescessary to provide every scrap of info up-front, particularly since it hides most of the pallet whenever it pops.
-
Possible bug - whenever I switch ladder sort order to "by execution order", the system tasks, used and unused, disappear from the ladder tree,
-
I like all your comments...
1. Definitely like this as an option.
2. The first ENTER "Writes Detail" then second "Exits" (not sure of the third). Possibly make an option for the Element Browser to "Always Exit on Write Detail"?
You don't need to use Ctrl+Enter, it does word-wrap. Ctrl+Enter is there to let you format precisely where YOU want the CR to be instead of the word-wrap algorithm. Just type, and the words will wrap, up to 6 lines worth.
3. Are wanting some kind of tree/cascaded menus grouped by type then on 10 point boundaries for ID? Please provide details.
4. Cool idea. Possibly color or subscript/superscript, or ?
5. Agreed. Cascading menu on toolbar and right click context menu would be nice.
FYI, if you know the first couple characters of a box mnemomnic, just type it in the output column on top of a NOP or empty output cell - no need to browse (this has auto complete, so just hit the first 1 or 2 characters to see choices). For OUT coil, just start typing the element in the output column on a blank cell or NOP (ignore box auto complete, "Y0" will bring up editor for the OUT coil w/Y0). For NO contacts, just start typing the element, for NC contact, hit forward slash "/" then the element.
For any existing instruction, just hit space bar to initiate editing, or if you need to change the first parameter, just start typing and it will start the editor on the first field with that first key stroke.
-
Regarding the tool-tip pop-ups for the instruction pallet, I appreciate the amount of work that went into these, but honestly - overkill. A simple definition of what the element is would be sufficient to let me know if it's the item I want to use in a given spot. You already let me click on the tool-tip to go directly to the help page, and that is a VERY GOOD THING ;D But it's not nescessary to provide every scrap of info up-front, particularly since it hides most of the pallet whenever it pops.
Yes, it's big. It's not for everybody (or every computer monitor). One big decision in the development of Do-more was that it was NOT JUST a big 260 that could store documentation in the PLC. The instruction set and programming capabilities are quite extensive. Hence, there is a need to educate users on the breadth/depth of the tool set. The Ladder Palette is meant to be similar to CAD or graphic tool palettes. It's meant for larger or multiple monitors. It's definitely NOT for every user/system. Note that you can turn off tooltips in the Ladder Palette under the Options... button.
The Instruction Browser is a modal dialog is a different "instruction selection" tool that helps a little (only because its modal, not because it has a small foot print ;D). Also, the mnemonic entry (mentioned in my other post) is what many "experts" use, those who are pretty familiar with the instruction set and corresponding mnemonics.
However, I do like the cascading menu idea for the "intermediate" user.
-
Possible bug - whenever I switch ladder sort order to "by execution order", the system tasks, used and unused, disappear from the ladder tree,
Yes, we know about that one. It's just the Unused System Tasks, and the "$tFirstScan" and "$tLastScan" code-blocks. All of the other "used" system tasks should be shown - let us know if this is not the case. We need to fix this, regardless.
-
1. If I add an unused bit to the ladder, and nothing is defined (tag, comment, etc), it should automatically open the data entry pop-up. Wasted mouse clicks double-clicking an element I just added to give it a name.
I'm sure that could be added as an optional behavior and might even be a great way to encourage proper documentation. There is already a way to do what you want...kinda. Rather than entering the element name, enter the new nickname you want to create. We then pop up a box that lets you assign it to the desired element. It doesn't allow you to create a description at that point, so that may not fly.
It also gives you the option of DmD assigning the first free element of a specified type. Since you pointed out that certain things in the PLC world are stuck in the last century, I'm gonna flip that back on you. I personally could not care less where my internal variables are located. I see the need to know or care as being similarly last century.
This one is gonna fly in some faces, but I also wouldn't use physical I/O directly in the program...in fact...I wouldn't even document physical I/O at all. I would use the MAPIO instruction to move physical I/O into and out of internals (randomly assigned <shudder>), and would write my entire program to be abstract of X, Y, WX and WY. By doing so, changing where a physical point is only requires editing the MAPIO table, and doesn't require any edits to documentation or program.
2. If I change a description or tag in the data-entry pop-up, I should not have to hit enter 3 times to implement the change and close the window. On a related note, having to hit ctrl-enter to add another line is so last-century. Give me an instruction comment line-wrap parameter I set once, and parse accordingly so I can just get on with typing.
I assume you are referring to the Element Browser. It is not the primary nor intended place to edit documentation. It is intended as a browser to see what is valid/available for the current field. We added the ability to edit documentation there as a courtesy. The Doc view is the primary doc editing facility...Ctrl+D. No 'enter' required there, just tab to the next field.
3. When assigning addresses to ladder objects, I don't need to know there are 2048 X bits in the memory configuration - I need to browse them and choose the one I want. My programming style uses memory ranges - C1000 to C1200 reserved for alarm bits, etc, and the current scheme offers little practical support for this. As it stands, I assign X32 to "Start Button" and if I want to assign it to a bit elsewhere, I need to look it up in my hand written notes.
Not sure exactly what the expectation is, but I think this ties into my comments for #1.
4. Yes, I know - tags. I've never met a tag I didn't hate instantly. Simple example - Tag says "MotorOn" with no indication of whether this is an X, Y, or C bit. Sure, you can make a naming convention, but people being people, it gets forgotten, alot. The more programmers involved in a project the more messed up it becomes - exponentially.
Prefix the tag automatically with the data type. And allow spaces in Tag names. Most of us are neither young nor computer science majors, and reading these makes for eye-strain and migraines.
Again...#1.
On spaces...can't. Nicknames are actual symbols which can be used in MATH expressions.
5. When I open the tool pallet, it covers a third of the screen, and the first thing I do in edit mode is close it again. Nevertheless, I use it alot. A true love-hate relationship. Restructure it to a tool bar with drop-down and fly-out menus. Show me a list of categories and I can figure out what I need from there.
I actually played with a concept like this when we first developed DSP in 1992-94. I'm sure the browser could be improved, and as we have time we will revisit much of this.
Do-more is the future of Host Engineering, and we are just getting started on it.
-
1. If I add an unused bit to the ladder, and nothing is defined (tag, comment, etc), it should automatically open the data entry pop-up. Wasted mouse clicks double-clicking an element I just added to give it a name.
That's like the worst idea I ever heard. Say there's a bit you don't intend to document for whatever reason -- do you want to interrupt your code entry flow and use part of your finger's finite supply of clicks to close the nannying box EVERY single time you use the element??
-
1. If I add an unused bit to the ladder, and nothing is defined (tag, comment, etc), it should automatically open the data entry pop-up. Wasted mouse clicks double-clicking an element I just added to give it a name.
That's like the worst idea I ever heard. Say there's a bit you don't intend to document for whatever reason -- do you want to interrupt your code entry flow and use part of your finger's finite supply of clicks to close the nannying box EVERY single time you use the element??
That's what 'options' are for. If he wants it that way, cool...it may fit nicely in his way of doing things. But we would make it optional, so we won't unnecessarily deplete you of your daily click quota. ;)
-
That's what 'options' are for. If he wants it that way, cool...it may fit nicely in his way of doing things. But we would make it optional, so we won't unnecessarily deplete you of your daily click quota. ;)
Sure, more options can never be bad. But....he seemed to think it should just work that way, period, and I wanted to get a quick word in lest anyone think that was the universal user outlook on the issue.
-
Sure, more options can never be bad.
But....he seemed to think it should just work that way, period, and I wanted to get a quick word in lest anyone think that was the universal user outlook on the issue.
We still use many of the same keystrokes that we used in TISoft. Rest assured that we won't substantively mess with the status quo.
-
1. If I add an unused bit to the ladder, and nothing is defined (tag, comment, etc), it should automatically open the data entry pop-up. Wasted mouse clicks double-clicking an element I just added to give it a name.
That's like the worst idea I ever heard. Say there's a bit you don't intend to document for whatever reason -- do you want to interrupt your code entry flow and use part of your finger's finite supply of clicks to close the nannying box EVERY single time you use the element??
That's what 'options' are for. If he wants it that way, cool...it may fit nicely in his way of doing things. But we would make it optional, so we won't unnecessarily deplete you of your daily click quota. ;)
No, it should not pop up every time you enter a bit - only an undocumented bit. I'm sure there is capability within the software to detect if a bit has a nick or desc and pop the box if not. Leave the box closed if so.
I personally cannot conceive of any circumstance in which you would place an object of any sort in a program - and not document it. In fact, I've been known to swear loud, long, and in front of witnesses for undocumented code.
:P
-
So it becomes a 'to make this box stop popping up DOCUMENT THIS BIT!!!' prompt.
-
Thanks to everyone who responded, I think it's great to see such a swift and vigorous response :)
With regards to the items I brought up, I mentioned the element browser a moment ago for pop-up on placing an unused element, I see no issue with making this an option you can turn off or on. I wouldn't want Darth Ladder to get too excited :)
Regarding the three enters, as follows:
I place bit C2040, then click it again to bring up the little gray highlight box, then click the magnifying glass to see the browser so I can enter a description.
I enter said description - taking note that the word wrap is in fact there, although wide for my taste - fair enough.
Enter - pop window for unsaved changes
Enter - saves change and clears the brower window away
Enter - confirms all of this and clears away the little gray highlight box around C2040
***
Within the element browser,
1. Make the "Nicknames" box into a table that also displays the address. It should display if the bit is used in the program. That would cover it perfectly.
2. Color code or subscript for the element type in nicks would be fantastic. I'm flexible, I just want some indication.
Thanks for the tip about the box names, I'm actually doing that already. Having a tool menu instead of the palette does sound like a great one for options.
Bob, you're in good company on the memory mask approach. First time I ever heard that one was from Terry Woods. I think it's situational - some people might have a reason to manipulate their IO table with frequency, whereas I don't. Once assigned they stay there unless one burns out.
That said, yes yes yes the ability to choose the first unused bit would be terrific. And while I don't give a hoot about my timers (unless I double coil, then I care a great deal) I do care a great deal about internal memory. To re-iterate, I want to assign all my alarms to a consecutive bank of addresses, and while I could do that with elaborate nicknames, addresses are so much tidier.
I got it on the spaces, well, it was worth a try.
More later
-
So it becomes a 'to make this box stop popping up DOCUMENT THIS BIT!!!' prompt.
Amen to that!
-
The other good thing about packing alarm bits is the ability to look at bits as a BYTE or WORD or DWORD using casts. This makes it VERY easy to see when there are ANY alarms or if ANY ALARM state changed (via the delta contact)
Say you have 16 alarm bits. Start them at some multiple of 16 (WORD casts of BITs must be WORD aligned), e.g. C1600 (or C0 or C16 or C32 or C64 or ...).
C1600:UW 0
-----] != [-----
to see if ANY alarm is ON
C1600:UW
-] DELTA [-
to see if ANY alarm state has CHANGED (ANY bit either INTO or OUT OF alarm)
(the contact actually has a little triangle in the middle, i.e. the Greek letter Delta, like Delta airlines. Delta means "change")
-
No, it should not pop up every time you enter a bit - only an undocumented bit. I'm sure there is capability within the software to detect if a bit has a nick or desc and pop the box if not. Leave the box closed if so.
Yup, that's what I thought you meant, hence my response.
I personally cannot conceive of any circumstance in which you would place an object of any sort in a program - and not document it. In fact, I've been known to swear loud, long, and in front of witnesses for undocumented code.
:P
Oh, well, I won't do it any more then. ;D How about a temp bit, say, that you're not planning on leaving in? Besides, it's almost more the very PRINCIPLE that the software would try to mold my practices instead of the other way around that I find offensive. We have Obama for that, we don't need it in our software.
-
That said, yes yes yes the ability to choose the first unused bit would be terrific. And while I don't give a hoot about my timers (unless I double coil, then I care a great deal) I do care a great deal about internal memory. To re-iterate, I want to assign all my alarms to a consecutive bank of addresses, and while I could do that with elaborate nicknames, addresses are so much tidier.
If it wasn't clear, the facility to automatically assign new nicknames to the first unused element of a particular type is already there. The same facility allows you to assign a new nickname to a specific element as well. To use this facility, just type the new name into an instruction. When you accept the instruction, we will pop up the "Create Nickname" dialog for every parameter that you entered a name that isn't assigned to an existing documentation record. You can also create a symbolic constant or leave the nickname unassigned. This is pretty much the only way that I create new symbols...I rarely use either the Element Browser or the Doc View. Your mileage my vary.
-
On the software friendliness: It's not a big deal, but, when an instruction is open for editing, when I double click a field, I expect it to select all the contents; but instead it opens up the element browser. Could the element browser be changed to open on a triple-click? An option for that maybe? It is not that your way of doing it is bad, but, it is different than any other software that I have. So every time I go from one Programming software to another I have to switch my thinking mode.
-
The other good thing about packing alarm bits is the ability to look at bits as a BYTE or WORD or DWORD using casts. This makes it VERY easy to see when there are ANY alarms or if ANY ALARM state changed (via the delta contact)
Say you have 16 alarm bits. Start them at some multiple of 16 (WORD casts of BITs must be WORD aligned), e.g. C1600 (or C0 or C16 or C32 or C64 or ...).
C1600:UW 0
-----] != [-----
to see if ANY alarm is ON
C1600:UW
-] DELTA [-
to see if ANY alarm state has CHANGED (ANY bit either INTO or OUT OF alarm)
(the contact actually has a little triangle in the middle, i.e. the Greek letter Delta, like Delta airlines. Delta means "change")
Precisely. I've got a whole bag of tricks for using vectors of various sorts that depend on sequential memory locations. But keeping track of them in the current layout is a bear.
-
No, it should not pop up every time you enter a bit - only an undocumented bit. I'm sure there is capability within the software to detect if a bit has a nick or desc and pop the box if not. Leave the box closed if so.
Yup, that's what I thought you meant, hence my response.
I personally cannot conceive of any circumstance in which you would place an object of any sort in a program - and not document it. In fact, I've been known to swear loud, long, and in front of witnesses for undocumented code.
:P
Oh, well, I won't do it any more then. ;D How about a temp bit, say, that you're not planning on leaving in? Besides, it's almost more the very PRINCIPLE that the software would try to mold my practices instead of the other way around that I find offensive. We have Obama for that, we don't need it in our software.
Anything that drives best practices in software is a good thing. How much effort does it take to add a nick or desc to a bit? (Okay, I take that one back. IMO currently it takes way too much).
But as to your point about a temp bit - no, it SHOULD be documented. Because when you finish, that "bit-from-nowhere" that you forgot to clean up (admit it, we all do it) will have the next guy trying to figure out what the heck that bit is doing there, where the heck it came from, and if that one is the reason his machine won't run.
He'll xref or search for it and not find it anywhere else. Then he'll check the HMI software for a reference, not there either. Then he'll dig through the IO logic, (remote, or physical if it's mapped out like BobO's) and not find it there either.
When he finally works out that the mystery bit is a temporary bit that you accidentally left behind, and had it simply been labelled he would not have lost hours trying to solve the mystery, he will call you on the phone and get all "Yoda" on you. :o
I've been on both ends of that stick at different points.
Comment everything. And if the power of Do-More compels you, that's less time I would have to spend harping about it. Think of it as a management tool - Cheney would have loved it. ;D
-
TempBit and BitBucket
TempBit - one to use as the output of previous rung, driving logic in the next few rungs, but never need to know the status, although this is becoming more rare 'cuz when I have to DEBUG those rungs, I care ::). Hence, I've been shying away from this practice.
BitBucket - when I must provide a bit output parameter, but I don't care, but it's required.
Note that BitBucket IS different than TempBit. I've actually used TempBit in rungs that also used multiple BitBucket bits. Yet even BitBucket is not good when DEBUGin' those rungs :o. (I'm seeing a pattern here, and with so many C-bits, and bit-o-word, they're not as important any more. But then, I need to document them ;D).
-
How much effort does it take to add a nick or desc to a bit? (Okay, I take that one back. IMO currently it takes way too much).
Typing the nickname first, then assigning the element in the automatically popped up dialog, is basically doing exactly what you asked for initially, and yet you still feel that it takes way too much. I'm puzzled. ???
-
TempBit and BitBucket
For me (when doc'd, TM), TempBit == "Scratch" (also used for registers) and BitBucket == "Dummy". One place that one will get used is on the output when I do one of those "poor man's HMI" rungs that displays a lot of key values but doesn't do anything.
Additionally, when I put in the temporary manual switches I was talking about, the first one or two actually do have descriptions ("EngrBit" usually). It's just that when I end up needing like 10 different ones simultaneously, I end up not bothering to doc the last few. Also note that if you're temporarily turning something hard on or off with no manual control while the bit is in place, that's typically a parallel NO SP1 or a series NC SP1, so the intent is obvious with no docs.
-
How much effort does it take to add a nick or desc to a bit? (Okay, I take that one back. IMO currently it takes way too much).
Typing the nickname first, then assigning the element in the automatically popped up dialog, is basically doing exactly what you asked for initially, and yet you still feel that it takes way too much. I'm puzzled. ???
It works nicely if you are used to a nickname-based scheme, but as stated previously, I'm an address-based programmer.
As we've been having this discussion and I've been checking out the things you mention, it's quite clear the software is geared entirely towards nicknames (tags, labels, what-have-you). If I simply fell into line using nicknames, I might find the software much easier to work with.
In the interest of fairness, I'll examine this further and see if I can wrap my head around it, but right now, it's taking me far longer to accomplish anything than it would under a traditional address-comment system.
TM
-
Precisely. I've got a whole bag of tricks for using vectors of various sorts that depend on sequential memory locations. But keeping track of them in the current layout is a bear.
If you have tables that are relying on being contiguous and laid out in a known order, Do-More's most compatible option if you don't like the lack of doc-prompting might be to create your own array in heap (think equivalent of a tag in CLX). So Do-More has both flat memory and structs (actually the only structs for now are single-type arrays, with UDT's or true structs on the way), use each where it works the best. 8)
-
right now, it's taking me far longer to accomplish anything than it would under a traditional address-comment system.
But I still don't see the problem. When you start to write a program, create a memory architecture that's clean and not infested with spaghetti, leaving some spare after each block. Enter (or import) those addresses in the docs editor all at the same time (Much more efficient that doing them one at a time on a popup on the ladder window. You can even cut and paste 50 sets of docs at a time where you have recurring analogous blocks of data.) As you enter your code and think of new elements not in the original plan, either document them each instantly, or take a break from coding and testing every couple hours and catch the docs up to the code.
To me coding and doccing focus is entirely different, so that's what I like to do. Keep coding and testing till I'm ready for a break or till I need to let the machine run without messing with it, then put on my doc hat and catch the docs up to the code. It's one of those maintenance tasks you sometimes can do when you can't do other tasks.
-
It works nicely if you are used to a nickname-based scheme, but as stated previously, I'm an address-based programmer.
It sounds like you are both, meaning that whenever you use a new element, you want to document it immediately. Hence, the CreateNickname mechanism can work just as well as what you are doing.
When you come up with a new alarm bit, you know you need it to go to C1673, and that it is the "Mach123OverTemp" alarm. Instead of entering
C1673 in the instruction parameter field
then hitting F9 for the Element Browser,
then entering Mach123OverTemp for the nickname,
enter Mach123OverTemp in the instruction parameter field
finish editing any of the other parameters (including new undefined nicknames), hit Enter to enter the instruction,
the Create Nickname dialog will automagically come up for each and every "new" nickname, then just select the 3rd option "...assign to specified element" and assign it to C1673; the Create Nickname dialog will continue to pop-up for each and every "new" nickname (but the radio button will default to the last choice, so you won't even have to select "...assign to specified element").
-
...(actually the only structs for now are single-type arrays, with UDT's or true structs on the way)...
Not sure what you mean by 'true structs'. We currently have 25 built-in types that are as true a structure as I know how to create. The only thing that isn't there yet is the ability for the user to create his own types.
-
It works nicely if you are used to a nickname-based scheme, but as stated previously, I'm an address-based programmer.
As we've been having this discussion and I've been checking out the things you mention, it's quite clear the software is geared entirely towards nicknames (tags, labels, what-have-you). If I simply fell into line using nicknames, I might find the software much easier to work with.
Entirely? That's a pretty strong statement. You can type an element into any field anywhere and it works just fine. Depending on what your settings are, we don't even display nicknames. I don't understand that characterization.
In the interest of fairness, I'll examine this further and see if I can wrap my head around it, but right now, it's taking me far longer to accomplish anything than it would under a traditional address-comment system.
It takes me 5 seconds to enter a contact, create a nickname, and accept the new instruction. The keystrokes are "C,0,<F9>,<Tab>,F,r,e,d,<Enter>,<Enter>,<Enter>". Not trying to be a pain, but I find it hard to understand how anything could be so much faster than that for DmD to be considered slow.
-
Not sure what you mean by 'true structs'. We currently have 25 built-in types that are as true a structure as I know how to create. The only thing that isn't there yet is the ability for the user to create his own types.
Well, and I'm not much of a PC programmer, but my understanding of a "struct" is that it IS a user defined type. You know, two integers for such-and-such with the following names within the struct (which itself becomes a type that can be freely instantiated), two strings for this, 20 bits for that, and so on. I say "struct" rather than "class" because it's just a data type and you can't add member functions.
-
Well, and I'm not much of a PC programmer, but my understanding of a "struct" is that it IS a user defined type. You know, two integers for such-and-such with the following names within the struct (which itself becomes a type that can be freely instantiated), two strings for this, 20 bits for that, and so on. I say "struct" rather than "class" because it's just a data type and you can't add member functions.
A 'structure' is a heterogeneous collection of fields, regardless of whether it is user defined or not. Timers, counters, or PID loop in Do-more are all structures...and can even be created by the user as either arrays (blocks) or as singletons on the heap. The user cannot yet declare his own, but I would not characterize that as not supporting structures.
-
Well, I think I said they were partially supported, plus that was the reason I said "struct" rather than "structure". IIRC, "struct" is the keyword used in C to create a user-defined structure type, so that was specifically the issue I was intending to speak to.
I definitely didn't mean to imply that Do-More was incompatible with structures per se, and apologize if I sounded that way.
-
Obviously this is an issue of semantics and I was pretty sure that was the case going in. ;)
In the interest of better understanding terminology, what would you call something like Do-more's PID thingy that contains a collection of fields like Loop.SP, Loop.PV, or Loop.Output, or our Timer thingy that has Timer.Acc or Timer.Done?
-
You HAD to ask, didn't you? ;D I mean, I do realize that they're structures, but I just don't think about them enough to need a word for them. I don't believe I've ever used the word "struct" to refer to anything but UDT's (and actually was using it to make the concept easier for PC guys! -- I should stick to automation terms!). See, I look at internal code like you look at nicknames. It's a black box. It works, it's got an accumulator & setpoint, a enable bit, a done bit, and a timing bit. Beyond that, don't care unless and until I get into some arcane situation where it doesn't do what I expect and I have to go find out.
-
It's totally ok. I'm not remotely offended and I hope you aren't either. I'm just trying to wrap my head around several user perspective things now between you and TM. The thing is, you guys use these products...I don't. So in the end my opinion is really irrelevant. Now I do know the product pretty darn well and there are probably some tricks I know that you don't, but in the end, how effective you are with the product is the only relevant point. I push back because I know things you might not, but I hope that you guys will also continue to push back about how you see things from a practical perspective. Engineering is a full contact sport. ;)
Franj and I were just talking earlier about what it would take to add roll-your-own structs. Don't think it would be too hard actually...even the UI would be pretty straightforward.
-
I don't believe I've ever used the word "struct" to refer to anything but UDT's...
Believe it or not 'UDT' throws me every time you use it. We have a built-in block of time/date structures called 'UDT'...User Date/Time. I gotta keep reminding myself that you mean 'User Data Type'...
-
Franj and I were just talking earlier about what it would take to add roll-your-own structs. Don't think it would be too hard actually...even the UI would be pretty straightforward.
I know you've said that it wasn't possible, but I think the real power in UDT's are implementing them in arrays. In fact, I'll bet that if I looked back on all the UDT's I've used, I can just about guess that all of the data types were used in an array, with arrays defined in the UDT . Sometimes its only way to store data efficiently.
-
You can most certainly create arrays of structures, user defined included. But no, a structure cannot contain anything but simple types, and that is not likely to change any time soon. Personally, I think it is far more important to create arrays of structures than arrays within structures, but I can certainly see the benefits of both.
-
What about a string? I don't suppose that's a simple data type?
-
Unfortunately not. That's the one I would miss the most. It's not terrible to work around by creating arrays of strings in parallel to your array of structs, but I would love to have strings as struct fields. Sadly, it will take some major refactoring to make it work. Same issue as multidimensional arrays. But give us time... :)
-
Unfortunately not. That's the one I would miss the most. It's not terrible to work around by creating arrays of strings in parallel to your array of structs,
This actually works quite well.
but I would love to have strings as struct fields. Sadly, it will take some major refactoring to make it work. Same issue as multidimensional arrays. But give us time... :)
This would be awesome though! ;D
-
Maybe it would be better to approach this issue when you think about adding file/database/external storage in the future?
-
It's totally ok. I'm not remotely offended and I hope you aren't either.
Not even close! :) Frustrated sometimes that I'm not making myself clear, but even that's not with you or Host.
I'm just trying to wrap my head around several user perspective things now between you and TM. The thing is, you guys use these products...I don't. So in the end my opinion is really irrelevant
Well, sorta. It's relevant to doing YOUR job. We're spoiled in that we can trust you to do your job and not have to think about it.
Franj and I were just talking earlier about what it would take to add roll-your-own structs. Don't think it would be too hard actually...even the UI would be pretty straightforward.
PLEASE do this at your earliest opportunity. It adds a lot of power and subtracts a lot of complexity from our work.
-
Believe it or not 'UDT' throws me every time you use it. We have a built-in block of time/date structures called 'UDT'...User Date/Time. I gotta keep reminding myself that you mean 'User Data Type'...
It's an AB thing! :D
No, it doesn't surprise me at all. I've never heard it anywhere else than AB, so that's why I was using "struct" (as distinguished from "structure"), both so as to be brand-agnostic and also because I'm talking to guys who program on PC's a lot.
-
You can most certainly create arrays of structures, user defined included. But no, a structure cannot contain anything but simple types, and that is not likely to change any time soon. Personally, I think it is far more important to create arrays of structures than arrays within structures, but I can certainly see the benefits of both.
That's exactly what I was going to say. I want both of course, but arrays of structures is far more important to me than arrays IN structures. The workaround for the one is infinitely easier than for the other.
Oh, alarm bells going off now. You said structs may only contain simple types, and I'm assuming a struct is not a simple type. Structs in structs is something I do quite a bit, and that IS pretty important. Maybe not quite as important as arrays of structs, but up there. (Certainly more important than arrays IN structs, for example)
Same deal with strings as arrays in structs. It would be the cleanest, but no big deal until you do or even if you never do.
-
Oh, alarm bells going off now. You said structs may only contain simple types, and I'm assuming a struct is not a simple type. Structs in structs is something I do quite a bit, and that IS pretty important. Maybe not quite as important as arrays of structs, but up there. (Certainly more important than arrays IN structs, for example)
If a struct consists entirely of simple types, then nesting a struct within a struct doesn't add anything but additional layers of naming. If Struct A contains an instance of Struct B, and Struct B has Field1, then you would reference B's field as 'A.B.Field1'. Is that so much better than adding B_Field1 to A, which would be referenced 'A.B_Field1'? In an OO context where Struct B has significance beyond the fields it contains, embedding a struct has significant merit, but I'm not sure that our mostly flat memory model gains such advantage through nesting.
-
Yeah, I guess it's not all that significant (especially if difficult), and doing what you say is indeed the workaround. I guess it's just the OO mindset advantage, that it your brain just automagically views the nested structs by their OOPish significance.
-
Yeah, I guess it's not all that significant (especially if difficult), and doing what you say is indeed the workaround. I guess it's just the OO mindset advantage, that it your brain just automagically views the nested structs by their OOPish significance.
The advantages are huge if the complex type has meaning beyond being an aggregate of simple types, and your mindset is spot on in that context. Sadly, as capable as Do-more is, structures really have no purpose beyond that at this point.