EBO Values Discovery Processor - incorrect value type (always "string")

[mike_meirovitz]

Hi,

We have a discovery processor that is a part of our product. The discovery processor scans all the connected AS-P controllers and finds all values and their type. For example: double, string, long etc..

The discovery works fine for one controller and finds all the values and their correct types, however for other controller the type is always "string" instead of the expected type. See the example below. 

Correct Type

11/9650KU0501_0200/Program/UC/8151GG838T200CS
8151GG838T200CS
double

Wrong Type

11/9650KU0501_0100/Program/UC/8151GG837T200CS
8151GG837T200CS
string

Any idea what may cause this problem?

Thank you.

Mike

[markhotch]

Hi Mike,

Could you provide a little more info?  Is this a SmartConnector that you have built yourself or one that you have purchased from SE?  Usually, the type is determined by the value of the object in EBO.  Due to the way that SmartConnector communicates with EBO, everything is deemed a string and then converted afterwards to the correct type.

Do you know if the values between the one that rights correctly and the one that does not differ in anyway?

Happy to look over screen shots etc that you may have to try and help!

Thanks,

Mark

[mike_meirovitz]

Hi Mark,

Thank you for your answer.

This is a SmartConnector extension that we have developed. The SmartConnector extension contains a processor that discovers all the values in the EBO and attached controllers. 

When there is only one AS-P controller, the value types are correct. When there are two AS-P controllers (see the attached screen capture) the input values inside a Program have incorrect type. "string" instead of "double".

See the attached discovery file of two AS-Ps where the Input values (in a Program) have "string" instead of "double".

In addition, see the attached 2 separate discovery files where the type is correct.

Thank you.

Michael

[ardak]

Hi Mike,

There's till information missing here.

Also, you have provided some conflicting information:

"The discovery works fine for one controller and finds all the values and their correct types, however for other controller the type is always "string""

and 

"When there is only one AS-P controller, the value types are correct. When there are two AS-P controllers (see the attached screen capture) the input values inside a Program have incorrect type. "string" instead of "double"."

To be able to help you, we would need to see your discovery code and know more about your setup. I'd also start looking at differences between the AS. Software version, configuration etc..

BR

Armend

[mike_meirovitz]

Hi Mark,

Thank you for your answer. I have sent the discovery code to Armend Dakic via email due confidentiality.

Can you please ask him to send it to you?

Thank you.

Mike  

[ardak]

I have received no such email, could you please try to send it again.

Also, please specify which lines look wrong to you in the discovery output. At a first glance, what I see doesn't exhibit the behavior you describe.

From EboOpcValues TWO A-P.txt

Example from AS #1 9650KU0501_0100:

11/9650KU0501_0100/Program/c18
c18
double

Example from AS #2 9650KU0501_0200:

11/9650KU0501_0200/Program/UC/8151GG838T200OpsTi
8151GG838T200OpsTi
double

BR

Armend

[mike_meirovitz]

Hi Armend,

Thank you for your answer. I have sent the source code via email again.

See these 2 values:

11/9650KU0501_0200/Program/UC/8151GG838T200CS
11/9650KU0501_0100/Program/UC/8151GG837T200CS

They are both Inputs in a Program. One from AS-P "0200" and one from "AS-P "0100". One of them is double and the second is string...

Thank you.

Mike

[mike_meirovitz]

Hi Armend,

Please confirm that you have received my email with the Discovery source.

Thank you.

Mike

[ardak]

I have received your email.

Ok, so finally we've deduced that some values on some AS show up as string.

1. Is it always the same value?
   1. In that case, does this value exhibit the same behavior when only one AS is discovered?
   2. If so, how does the EWS response(via soapUI)/REST gateway response look for that object?
2. You say these are inputs. What are they bound to? Show screenshots of the program and the relevant inputs
3. Look for differences in the program. 
4. Are the ASs the same version?

BR

Armend

[mike_meirovitz]

Hi Armend,

Thank you for your answer.

See my answers below.

Is it always the same value? Answer: If there are 2 AS-Ps or more, the value is always type "string" instead of "double" (the value of the Input inside the Program).
In that case, does this value exhibit the same behavior when only one AS is discovered? Answer: If only one AS-P is discovered, the type is "double" as expected.
If so, how does the EWS response(via soapUI)/REST gateway response look for that object? Answer: we cannot use the soapUI since the discovery processor uses recursion and the soapUI cannot do the same recursion.
You say these are inputs. What are they bound to? Show screenshots of the program and the relevant inputs. Answer: I will check with the customer.
Look for differences in the program. Answer: I think that the program is the same but I will check with the customer.
Are the ASs the same version? Answer: I will check with the customer.

Thank you.

Mike

[mike_meirovitz]

Hi Armend,

See the the answers of SE Denmark:

1. If you make a discover in only one AS-P the discover process is correct for all values, inputs and outputs.

Seems that if you discover through a Enterprise server it goes wrong.

See the attached screen captures.

2. The programs are not the same. The Input values (in a Program) in 2 different AS-Ps has the wrong type - "string" instead of "double". 

3. Yes the AS-P are same version.

Can you install our EBO-OPC Server on your computer and try the discovery processor? This way, you can see the issue yourself.

Thank you

Mike

[ardak · Accepted solution]

This issue was solved by installing hotfix 3.2.3.6400. There is an issue where in some cases the 3.2.3.59 ES reports the wrong type, versus going directly to the AS, which will report the correct type.

The hotfix fixes this. Another option would be to go directly to the AS if possible.

BR

Armend

[mike_meirovitz]

Thank you Armend for your great support!!!

Mike