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
