So, I’m definitely +1 for renaming the “Fields” to “Tags”. And it seems my LinkedIn thread also seemed to solidify that willingness to change.
A good argument for renaming was, that in Historians, which store data of all sorts of automation products, the term is “Tag”. 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 >> >
