http://www.diangon.com/wenku/PLC/201504/00021970.html
近段时间，遇到不少人都被OPCClient与OPCServer之间的通讯搞得头大，通过几次远程协助后，总结了OPCClient和OPCServer在Windows上运行方式的恩怨，希望对各位有用。
目前市场上的OPCClient和OPCServer软件在Windows上的运行方式有Windows 桌面程序和Windows NT服务。本来也没啥。但由于OPCCLient是一个厂家的软件，而OPCServer是另外一个厂家的软件，由于软件的多样性，也就导致了如下一些现象：
1. OPCCLient连接目标OPCServer，发现无法连接，但在OPCServer计算机上明明看见OPCServer进程已经启动。
2. OPCCLient连接目标OPCServer，能连接，也能看见测点，但无法获取到数据。
经过多次现场的积累后，发现此类问题多出现在OPCClient和OPCServer软件在Windows上的运行方式不同导致的。也就是说，OPCClient和OPCServer软件的运行方式不一样。譬如，OPCCLient是Windows NT服务方式，而OPCServer是桌面程序方式（多是组态软件的OPCServer都是桌面程序方式吧！！）。而当OPCCLient是Windows 桌面程序方式，OPCServer时Windows NT服务时，发现上面的现象基本不出现。这是为什么呢？
原因如下：
OPCClient和OPCServer都是基于DCOM的应用，DCOM的特点是OPCServer无需先运行或启动，等待OPCCLient请求时，由操作系统在将OPCServer拽起来。这种机制的好处就是随用随启。但这种机制如果处理不好吧，就会导致一些问题。当OPCCLient是Windows NT服务时，OPCServer被拽起来后，是运行在System这个系统账户下面的。相对于Windows的桌面用户来说，是另外一个隔离开的空间。因此当桌面运行类型的OPCServer被Windows NT服务方式的OPCCLient拽起来后，被运行在System这个系统账户的空间。而如果这个OPCServer程序又做了全局唯一进程运行的限制或与数据库只允许一个TCP连接时，上述的两种现象基本就会出现。这就是这段时间好几个朋友遇到的OPC通讯故障现象。
如果让自己开发的OPC程序兼容性更好呢？
1. 当开发OPCCLient程序时，最好使用Windows桌面程序方式，这种方式可兼容OPCServer程序运行在Windows桌面程序方式和Windows NT服务方式。
2. 当开发OPCServer程序时，最好使用Windows NT服务方式，这种方式可兼容OPCClient程序运行在Windows桌面程序方式和Windows NT服务方式。
如果很不幸遇到了Windows NT服务的OPCClient去采集Windows 桌面程序的OPCServer（加上OPCServer本身的全局唯一限制），那么你可以去Windows NT服务的管理器中将Windows NT服务的OPCClient更改为指定的系统用户运行，大多数情况下可以解决问题。