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!
Cheers,
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
SIEMENS1.Flow.Y356
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 ...
[MYPLC]FlowRate
However, for subsequent branches off the main Topic, the period is used. So for "MYPLC", branch "FlowRateReadings" and tag "Drain1" it would be...
[MYPLC]FlowRateReadings.Drain1
Last edit: SpinelliCreations 2014-04-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
"Branch::TagName"
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,
Julian
Last edit: Julian Smith 2014-04-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
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!
Cheers,
Julian
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
SIEMENS1.Flow.Y356
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 ...
[MYPLC]FlowRate
However, for subsequent branches off the main Topic, the period is used. So for "MYPLC", branch "FlowRateReadings" and tag "Drain1" it would be...
[MYPLC]FlowRateReadings.Drain1
Last edit: SpinelliCreations 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:
Random.ArrayOfReal8
Random.ArrayOfString
Random.Boolean
Random.Int1
Random.Int2
Random.Int4
Random.Money
Random.Qualities
Random.Real4
Random.Real8
Random.String
Random.Time
Random.UInt1
Random.UInt2
Random.UInt4
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:
opc -s OPCServer.WinCC -r "ROOTPATH.PATH.PATH.PATH.TAG_X"
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,
Julian
P.S. OpenOPC is otherwise fantastic, thanks! I'm sure we're missing something here...
Last edit: Julian Smith 2014-04-10
Julian,
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?
Last edit: SpinelliCreations 2014-04-10
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:
"Branch::TagName"
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,
Julian
Last edit: Julian Smith 2014-04-11
Julian,
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.
Last edit: SpinelliCreations 2014-04-11