Parameterized network master instructions

[CReese]

It works just like any other memory block, other than security considerations, which may well not be an issue. I name pretty much every variable anyway, so whether the block is called 'V' or 'MHR' or 'Beauregard' I don't much care. I know some here are pretty adamant about using block names rather than symbols, but other than awareness of where they are located for comm purposes, I prefer to treat Do-more as a tag-based system. Of course YMMV...

I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name. This was especially annoying in data view, because once you type in a memory address it is converted to a name and you can't click on it and have it convert to the memory address (as it does in the RLL screen). This problem has for the most part been mitigated by autocomplete and that you can in fact write variable names into the logic block fields. You may then effectively forget about where they are until you need to edit your memory blocks.

The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.

[franji1]

I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name. This was especially annoying in data view, because once you type in a memory address it is converted to a name and you can't click on it and have it convert to the memory address (as it does in the RLL screen). This problem has for the most part been mitigated by autocomplete and that you can in fact write variable names into the logic block fields. You may then effectively forget about where they are until you need to edit your memory blocks.

In DS and in Designer, you can enable any/all documentation/element fields, but they cost you screen realestate, so the default in Data View is "nickname only" (which will display "element only" if NN does not exist), but you can check BOTH "nickname" and "element" or whatever to see EVERYTHING (right click on Data View, Options..., check the desired combination of Documentation fields you want, check the New Views checkbox in the Apply To group at the top so that your changes will be applied to any NEW data view instances that come up).

The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.

You are correct.  The element is stored in the instruction, not the nickname.  However, there is a Replace utility in both DS and Designer below the Search-> menu that can be helpful when needing to "move" a "tag" across ALL ladder logic.

[BobO]

I have mixed feelings on it. In DS, I found it quite annoying that the memory address locations were replaced by the aliases, since when writing code you could not enter by name.

Unless something is broken, nicknames can be typed into any element entry field in DS. Of course without auto-complete, that is a bit more of a chore, but for a tag-centric developer, you shouldn't need to use element names in DS or DM.

The one functional difference between this system and a solely tag-based one is that if I change the memory location in the memory editor, I assume that my code blocks will not automatically update with the new address, but instead will revert to either a raw memory address or whatever new alias the memory location has.

Correct. The key distinction between true tag-based systems and conventional memory-based systems is that we store a memory location rather than a tag handle. As was previously mentioned though, there is a powerful replace facility for dealing with those issues. Personally, I don't find it to be an issue because I shy away from elements except for comms where I must know. I would think you wouldn't need to change addresses very often, except in the case you are refining a public comms interface where the order and placement is important. Of course PUBLISH and SUBSCRIB is a great way to handle that...but requires a copy...and our merry chase has just looped back on itself!!

Again...there's always trade-offs. If engineering was easy, it wouldn't pay quite so well.

[CReese]

I just got a DoMore in the mail today. What does the time-frame look like implementation of this feature?

thanks.
C

[BobO]

We opted to go ahead and implement variable IP for all remaining network instructions as well as a DNS lookup instruction. It will be a week or two, although probably two once we get it all tested.

[CReese]

Excellent. Please keep us posted.