Software friendliness

[franji1]

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")

[Controls Guy]

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.

 

Oh, well, I won't do it any more then.  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.

[BobO]

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.

[plcnut]

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.

[tmoulder]

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.

[tmoulder]

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.

 

Oh, well, I won't do it any more then.  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.   

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.   

[franji1]

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  .  (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 ).

[BobO]

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.

[Controls Guy]

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.

[tmoulder]

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

[Controls Guy]

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.  

[Controls Guy]

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.

[franji1]

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").

[BobO]

...(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.

[BobO]

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.