Reading tags via branches

  • Julian Smith

    Julian Smith - 2014-04-10


    We have a tag path issue where, connecting to a Siemens WinCC OPC server, 'opc -l' on the command line shows 5 branches. If we get the tags via 'opc -f' then we see all the tags, but the only tags we can get readings for via 'opc -r <tagname>' are those in the root of the branches.

    We can see tags via syntax opc -l "branch/dir1/dir2", but we can't get readings from them. After much trying, we can't find any syntax that enables us to get the data for a tag that is within a branch's path structure. Only at top level.

    Any ideas anyone?! Many thanks in advance for any enlightenment that can be provided!


  • SpinelliCreations

    I believe the delimiter is the period "." Your syntax should be TOPIC.Branch.Branch2.Branch3.......Tag

    For example, Topic = SIEMENS1, Branch = Flow, Tag = Y356, then you should read


    Depending on the server you're using, the syntax for the Topic will change. For example, Rockwell uses a [] syntax, where the hypothetical tag "FlowRate" for "MYPLC" would look like this ...


    However, for subsequent branches off the main Topic, the period is used. So for "MYPLC", branch "FlowRateReadings" and tag "Drain1" it would be...


    Last edit: SpinelliCreations 2014-04-10
  • Julian Smith

    Julian Smith - 2014-04-10

    Many thanks for the input. Alas this doesn't resolve the issue. I'm working remotely from the opc server I'm writing code for, with security that prevents outside connection, so it's easier to give a further example of the issue around the Matrikon test server...

    ...If you enter opc -l then the output is the list of two root paths:

    Simulated Items
    Configured Aliases

    If you enter opc -l "Simulation Items.Random.*" you get:


    To find the value of Random.Int1 you can then enter opc -r "Random.Int1" which gives:

    Random.Int1 100 Good 04/10/14 16:40:45

    In this case, the root path seems to be automatically assumed from the 2 (I'm not sure why...). But what if there were several Random.Int1 tags under several different root paths, say? Then I'd want to specify the root path...

    ...but if I use opc -r "Simulation Items.Random.Int1" (or other syntaxes I can think it might be) I get:

    Simulation Items.Random.Int1 None Error None

    Why is this and how do I robustly specify the entire path to the tag so that I might get its reading?

    A more practical example of our case: My colleague on site can get a list of tags from his remote client via:

    opc -s OPCServer.WinCC -l "ROOTPATH.PATH.PATH.PATH"

    But if a reading from TAG_X is required then the following does not recover the desired readings:


    Note also that for some root paths, just the tag name in the quotes is required, hence my confusion about how and why the root path seems to be assumed in some cases. But other root paths don't play ball, as above.

    Any advice much appreciated!!

    Kind regards,

    P.S. OpenOPC is otherwise fantastic, thanks! I'm sure we're missing something here...

    Last edit: Julian Smith 2014-04-10
  • SpinelliCreations


    That's just not supposed to happen. (( I'm befuddled ))

    Rockwell's RSLinx has a similar misbehavior though also. It has 'online' and 'offline' (one is real data, the other is some legacy garbage which the server supports for other purposes).

    server name = RSLinx Classic
    branch 1 = online
    branch 2 = offline
    tags = all variables in any given PLC are shown (when browsing) in both the online and offline branches
    ... but only the 'online' branch will return any data when drying to do a read, and you can't specify 'online' or it will respond with an error that the path can't be found, etc.

    So MYPLC INT5 might be (when browsed with the -l (list) command) "[MYPLC].online.INT5", but the working call is "[MYPLC]INT5", the call that it should be ("[MYPLC].online.INT5") won't work, and "[MYPLC].offline.INT5" simply acts like it does not exist.

    Your Matrikon test setup seems to be pushing the 'Simulation Items' path by default. Much like the Rockwell flavor pushes the 'online' path by default (and will not allow reading from the other branches, even though they can be browsed). Try eliminating the first branch level in your Siemens OPC Server and see what happens. Perhaps this is the same illogical (but functional) behavior?

    • Vince.
    Last edit: SpinelliCreations 2014-04-10
  • Julian Smith

    Julian Smith - 2014-04-11

    Thanks for the ideas Vince! We had the same problem as you describe, that only an aparent 'online' branch would provide tag data. No other branch could be specified.

    However, we came across the solution for our case, which was to use the syntax:


    Does this perhaps work for you? I suspect there are various variations out there...

    It was quite a "Eureka" moment, as you can imagine!

    Solving the riddles tortures me in this game...but it's the reaching the solutions for them that keep me coming back for more!!

    Many thanks for your time and effort to consider our case Vince, and any others who looked over our issue.

    Best wishes,

    Last edit: Julian Smith 2014-04-11
  • SpinelliCreations


    Very impressive solution, and glad that you were able to come to it. I'm definately writing that down in my little black book of things to remember.

    The " :: " deliminator I have only used inside an area where I wasn't supposed to use it (go figure). In Rockwell's Factory Talk Studio (PC based and hardware based HMI), the backend is something called RSLinx Enterprise (not to be confused with RSLinx Classic, which is an OPC Server). Anyway, Enterprise is not an OPC Server, but it serves as a backend to push tags between an HMI and a PLC. Well, in doing so, it offers the tags in a format that is somewhat comparable to the format used by Rockwell's OPC server...

    Linx Classic OPC Server Tag --> [MYPLC]N7:15
    Linx Enterprise 'sort of OPC' Tag --> {[MYPLC]}::N7:15

    ... in the above, it is used to delimit the tag source from the tag name. The reason I'm not supposed to use it is that FT Studio is designed such that you create an Alias Name (let's say "Water Temperature") and then associate a Source Device and Tag Name (let's say "MYPLC" and "N7:15"). These are little boxes you fill in. But I despise little boxes, and can develop much faster (and with easier editability) by directly shoving the tag into the object I'm working on. Somehow along the way I figure out that was the structure that the software uses.

    I have a feeling that much of this is common between vendors behind the scenes, and we're only seeing it as Chinese Calculus because we're sitting in that gray area between 'End User' and 'Developer'.

    Glad you're up and running.

    • Vince.
    Last edit: SpinelliCreations 2014-04-11

Log in to post a comment.