Community
Participate
Working Groups
Hello there, I have a question about OPC DA communication, We are trying to read a variable in a OPC-DA server that has the name "PIC7101:INTERACTIONPAR.OUTMAXLIMIT"... That seems like trouble due to the ":" and possibly the "." in the variable name. We are using the following string in the client_0_1: ``` opc[10.32.1.81:ABB.AfwOpcDaSurrogate.1:2000:0.1::PIC7101:INTERACTIONPAR.OUTMAXLIMIT] ``` My question is: How can I tell the block that a ":" is part of a name and not a separator in the string.
can you please help to verify if it is caused by ":" or "." ? thank you
We are currently changing the function: ``` COpcComLayer::processClientParams ``` In the file "src/com/opc/opccomlayer.cpp" to use ";" as separator. I'll let you know the test results. We will try reading different variable names to check this.
We are able to read a variable called "System Tags.Seconds" just fine. So we believe it is really the ":".
(In reply to Pedro Souza from comment #2) > We are currently changing the function: > ``` > COpcComLayer::processClientParams > ``` > In the file "src/com/opc/opccomlayer.cpp" to use ";" as separator. I'll let > you know the test results. > > We will try reading different variable names to check this. I think you have found the correct place to change. And what if there is ";" in tag name? So can you please help to check the OPC standard for invalid signal for tag name?
(In reply to xin zhao from comment #4) > (In reply to Pedro Souza from comment #2) > > We are currently changing the function: > > ``` > > COpcComLayer::processClientParams > > ``` > > In the file "src/com/opc/opccomlayer.cpp" to use ";" as separator. I'll let > > you know the test results. > > > > We will try reading different variable names to check this. > > I think you have found the correct place to change. > And what if there is ";" in tag name? So can you please help to check the > OPC standard for invalid signal for tag name? signal => symbol, :)
https://opcfoundation.org/forum/classic-opc-da-ae-hda-xml-da-etc/opc-da-tag-naming-convention/ it seems the invalid character for tagname is not defined from opc DA standard.
Ok so we are bypassing things just to work because we need it fast :D ... But this need to be thought through in the near future. So far we found tags containing double colon ":" and also containing brackets "[" and "]" For example: ``` [Control Structure]/Root/Control Network/TIT7101J:OUT ``` This causes everything to break because both brackets and double colons are separators used in translating the string to Forte. The bypass we are making consist in changing those separators into stuff we don't find in the variables we need to read (at least not in this OPC at this client). So far we've changed the parsers of ":" to ";" and "[]" to "{}" ... this is definitely not a good solution but it does solve our immediate problems.
I think that a better solution would be implementing some kind of escape characters ... Like when you what to use "\" in a python string you can't because this symbol is reserved to the interpreter. Therefore to write the symbol "\" you need to prepend a character to it to tell this to the parser ... so, in python, writing "\\" will be interpreted as just printing "\". I think the same logic applies to this situation we have here. Forte will use "[" to separate the protocol and ":" to separate arguments, therefore in order to use "[" or the ":" as the literal symbol the user should add something to tell the interpreter that he wants that symbol written. Similar stuff happens in regex syntax, if you want a match with any character you type "." but it you want to match the dot you'll type "\." Some example using "\" as this special character will be: ``` opc[10.32.1.81:ABB.AfwOpcDaSurrogate.1:2000:0.1::\[Control Structure\]/Root/Control Network/TIT7101J\:OUT] ``` This should be able to tell to the parser that "\[" should be interpreted as "[" and "\:" as ":"
yes, it seems this is a thorough solution as the ID is used for many protocols. Even we find the solution to opc DA, there will be problems for other communication FBs. it is very much appreciated if you are interested in writing an escape solution for chars in ID.
Following this reply on the Forum: https://www.eclipse.org/forums/index.php?t=msg&th=1099743&goto=1809430&#msg_1809430 The correct escape character is `$`
use '$' is good if the ID contains ',". have you tried "$:" in ID? I guess the default escape logic does not contain escaping ":".
(In reply to xin zhao from comment #11) > use '$' is good if the ID contains ',". have you tried "$:" in ID? > > I guess the default escape logic does not contain escaping ":". Unfortunately the dollar sign only work to escape quotes and double quotes.
To find which protocol it is, the method "extractLayerIdAndParams" searches for bracket "[ ]" and in this method the "\" is used to escape them. Meaning that a "\]" will be ignored when searching for the closing bracket. I've extended this behavior to the "COpcComLayer::processClientParams" method and used the boost library to handle this separation. I can be done without boost of course, but as the OPC already has a dependency on it I didn't see any harm in it. The way it is implemented now we can handle a weird variable like: ``` Pressure_Line_1,5bar:OUT[3].value ``` This can be achieved by writing it like: ``` Pressure_Line_1\,5bar\:OUT\[3\].value ``` - The "," need escaping because it is the separator for variables - The ":" need escaping because it is the separator for parameters - The "[" and "]" need escaping because it separates the protocol form parameters
Created attachment 288683 [details] Patch to branch 2.0.1 This patch can be applied at branch 2.0.1 ``` git apply path/to/patch/file ``` It is a possible implementation of "COpcComLayer::processClientParams" using boost to separate the parameters and variables with "\" as a escape characters for it.
