Hmmm … ok, So, I count two people for using Tag and sort of Two for using Field. Am I correct with this?
At least my LinkedIn question seems to be clear that most people would be expecting “Tag”. And I mean … I think we don’t need to work on having PLC4X accepted on the IT side, but on the OT side. Making it more aligned with what the OT folks expect seems to be a better path for me. But I would really appreciate a bit more clear outcome of this discussion… so anyone who’s not posted his opinion yet is highly encouraged to do so. I’d just hate to rename something like that after a 1.0.0. Chris From: jl hong <[email protected]> Date: Tuesday, 8. November 2022 at 02:56 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Rename Fields -> Tags? Hello Chris, I had the same confusion with Łukasz about what "Tag" meant when I first met it in using Rockwell PLCs.Maybe it is more difficult to understand than "Field".Also, I think "Field" is not accurate enough too. Finally, I think either "Tag" or "Field" is acceptable, and people should both be able to understand it from the document or context. By the way, we call it "Point Position" in Chinese, I translated directly. Christofer Dutz <[email protected]> 於 2022年11月8日 週二 凌晨4:49寫道： > Probably should rename „fieldQuery“ to „fieldAddress” (or tagAddress) as I > split Fields and Queries as a query usually targets more than one element > and an address normaly doesn’t. > > Chris > > From: Christofer Dutz <[email protected]> > Date: Monday, 7. November 2022 at 21:40 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Rename Fields -> Tags? > And regarding your points, Lukasz, > > The output from the Browse API is that it is a BrowseItem. This contains a > Field (or Tag if we rename it) and loads of metadata. > Is the Field readable, writable, subscribable, loads of protocol dependent > options. > > The Field itself now should be able to produce an address string that > should be able to re-produce it. The APIs all support “addFieldQuery” which > takes this string representation or “addField” which directly receives the > field object. > > Chris > > > From: Łukasz Dywicki <[email protected]> > Date: Monday, 7. November 2022 at 13:48 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Rename Fields -> Tags? > Hey Chris, > I do not insist on any side. Knowing how hard it is to get a "common > understanding" on certain things I think it is easier if we stick with > project specific concept. > > Other point, we do not need to re-use a PlcField and field notion > everywhere. For example output from browse api might be a descriptor > which can be used to construct a field address. After all, a browsing > functionality might provide more information than needed to fetch data - > ie. human readable name, description or other elements which are > irrelevant for driver to get data. > > As a side note, I do acknowledge that best time to do naming and larger > API alignments is prior 1.x release. > > Best, > Łukasz > > On 6.11.2022 13:32, Christofer Dutz wrote: > > Hi Lukasz, > > > > even in protocols like ADS and EIP at Rivian everyone is referring to > any data point as a “Tag”. > > So far, I haven’t come across a single person saying something else on > LinkedIn. > > https://www.linkedin.com/feed/update/urn:li:activity:6994584721582088192 > > > > And keep in mind: PLC4X is meant to be the bridge between IT and OT, and > we chose a lot of stuff (Like the address patterns, etc.) to match the OT > expectations. After all, I will most probably be an IT person asking the OT > person: Please give me the address for Field/Tag XYZ. So, I think naming it > “Tag” would be better. > > > > I would like to name it to match the most used term: I know that this > isn’t always a perfect match in all protocols, but I guess that’s the > difference between providing a “shared API” or building individual drivers > for each protocol. > > > > And currently we name it “Query” in Go … so you currently say: > “AddQuery” instead of “AddField”. > > > > Chris > > > > > > From: Łukasz Dywicki <[email protected]> > > Date: Sunday, 6. November 2022 at 11:45 > > To: [email protected] <[email protected]>, Christofer Dutz < > [email protected]> > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > Hey Chris, > > I am not certain if "tag" is standardized or not. Earlier, knowing only > > modbus registers and bacnet objects, I been confused multiple times what > > the tag is. For regular IT tag is rather a marker placed on something to > > categorize elements. Our field currently specifies rather a unique data > > point than a tag. > > If tag meaning comes from IEC standard then I'd opt in for a change. If > > its not standardized then I'd advice staying with a field. Our use is > > mixed IT/OT (with probably still more IT?), if we stick too much to > > automation industry terminology then we will need to bake definition of > > a tag, fight situations where we miss a "common understanding" cause we > > can't beg others for unification of their meaning. > > > > I've seen tag used in context of ethernet/ip (more precisely Rockwell > > PLCs), but haven't done a research of why. Keep in mind we have also > > object oriented protocols such as BACnet (with `device.object.property`) > > and CANopen (with `device.sdo` or `device.tpdo..`) thus in their context > > tag is far less meaningful than field. > > > > Cheers, > > Łukasz > > > > On 5.11.2022 12:23, Christofer Dutz wrote: > >> Hi all, > >> > >> I’m currently working on harmonizing our different API variants a bit > and hopefully finalizing our Browse API (Which sort of wen’t through > multiple levels of change between Java and Go, back to Java and now back to > Go. > >> > >> One thing I learned at Rivian is, that everyone seems to be talking > about “Tags” on PLCs. So I asked on LinkedIn and it seems pretty obvious > that “Tag” seems to be the term mostly used in the automation industry. > >> > >> So, I would like to consequently rename “Field” to “Tag”. > >> > >> What do you folks think? > >> > >> Chris > >> > > >
