Not possible to subscribe an OPC server to the Distributed Systems Manager

[krasnus]

Hi everyone,

I am trying to subscribe a OPC server into the DSM and it gives me back a "NI OPC client Status" OPC like tree.

When i try with localhost matrikon it doesnt give a problem, so i expect that it is a network permissions issue.

is it? is it not? is there something in the NI services that i need to fix? is it DCOM?

If it is not, can you please give me some advises? 

[Danubio]

Hi Krasnus,

I recommend checking the DCOM configuration. Here are some documents related as well:

Why Can't LabVIEW DSC Connect to My OPC Server When Server Explorer and DataSocket Can?
http://digital.ni.com/public.nsf/allkb/9D1690C5B1CE1D25862572FA0053150D

Configuring Local OPC Servers to Work with OPC Client IO Servers (DSC Module) - LabVIEW 2011 Datalogging and Supervisory Control Module Help
http://zone.ni.com/reference/en-XX/help/371618G-01/lvdschelp/config_local_opc_serv/

Best regards,

Daniel C.

[krasnus]

DCOM is correclty configured...

I have tried registering the OPC server as a local IO server in the SVE with a very strange result:

I can correctly subscribe, i can ennumerate all the variables without a problem, i can even use the SVE interface to write to the variables, (and the value reaches the PLC at the other end...) but... 

when i try to use the address .i.e. psp://localhost/whateverisnext as an URL for a very simple Datasocket OPC read (lavibiew, hommemade datasocket open-> then read) testing program, it COLLAPSES all the Shared Variable Engine Service. (obviously does not succeed to read)

[Jacobson-ni]

Can you explain what you mean by "it collapses all the shared variable engine service."?

[krasnus]

Let me put an example:

1)I add the opc server as IO server using the DSM, OK.

2)I browse the IO server in the SVE, OK.

3)I ennumerate individual elements inside the OPC (now ioserver), ennumerate comes OK.

4)i can see the values in the VALUE column, and i can even enter new values in the already connected logs, ok.

then....

5)i copy the whole address of the variable inside the IOserver, i add the "psp://", and i paste it as an entry in a VI that contains a datasocket open ->datasocket read -> datasocket close,....

and nothing happens.

6) After doing this last step. NOW I AM NOT ABLE TO ENNUMERATE OR BROWSE THE SVE ANYMORE. I need to go to services, open NI Shared Engine, stop and Start. 

I have my own theory that the lenght of the string for the PSP url is too long: this is an example URL string that gives me this bug: (anyway this should not happen)

psp:\\localhost\OPC-PSP\OPC.OS_OS_SRV01::.List of all structure instances.KILNMASTER/KIMA_COM.'KILNMASTER/KIMA_COM.spare_out5' 

total chars in string=126

[Jacobson-ni]

---

@krasnus wrote:

I have my own theory that the lenght of the string for the PSP url is too long: this is an example URL string that gives me this bug: (anyway this should not happen)

psp:\\localhost\OPC-PSP\OPC.OS_OS_SRV01::.List of all structure instances.KILNMASTER/KIMA_COM.'KILNMASTER/KIMA_COM.spare_out5' 

total chars in string=126

---

I tried this on my end because I thought it might be possible but didn't run in to the same error when using the 194 character URL, psp:\\localhost\OPC Process\OPC IO Server Name\Simulated Channel\Simulated Device\Really Long Group Name\Really Long Nested Group Name\We Can Nest This Even Further\Why Is The Tag Name This Long

Is this only an issue for some tags and not all though? I would also be interested to see if you get the same behavior by using the Shared Variable API under the Data Communication palette which I have also used to read tags from an I/O Server.

[krasnus]

I cannot know because all the opc tags are in the same, lets say, folder. so, not possible to get short strings as PSP URL.

but.. what i did, as you say, i registered manually the variables, one by one, in the SVE, using the same PSP address but now getting a shorter, newer PSP url to work with. Lets say i solver my problem using an alternative solution but, Anyway, i am still wondering why the SVE is behaving that way.