近段時間，遇到不少人都被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更改為指定的系統使用者運作，大多數情況下可以解決問題。