Connecting to OPC via Python/GO?

Question

Python

Greetings.
Perhaps someone faced a similar problem.
Issuance to external systems from the process control system at the enterprise is organized through OPC DA2.
Third-party clients cling to this OPC server without problems, receive tags, values.
But my attempts to reach him with my scripts fail.
An attempt in Python

# -*- coding: utf-8 -*-
import OpenOPC
opc = OpenOPC.client()

print opc.servers()
print "="*20
opc.connect("K89_Arm1")
print opc.list()

Conclusion

[u'IOServer', u'Graybox.Simulator.1', u'Matrikon.OPC.Sniffer.1', u'InSAT.Multi-ProtocolMasterOPCServer.DA', u'opclogger.Instance.1', u'Matrikon. OPC.Simulation.1', u'dOPC.Simulation.Server', u'IEC_104_server.OPCServer', u'K125_Arm10', u'K67_Arm10', u'K89_Arm1', u'OSO_TC_Arm1']
======= =============
Traceback (most recent call last):
File "C:\Python27\sargon.py", line 7, in
Connect: Interface not supported
opc.connect("K89_Arm1")
File "C:\Python27\lib\site-packages\OpenOPC.py", line 231, in connect
raise OPCError, error_msg
OpenOPC.OPCError:

On the server, you can see the client, who picked up and immediately fell off. The same python code clings to test OPC servers.
Attempt on GO
To other test OPC servers the connection is successful.

package main

import (
  "fmt"
  "github.com/konimarti/opc"
)

func main() {
  client := opc.NewConnection(
    "K89_Arm1", // ProgId
    []string{"127.0.0.1"}, //  OPC servers nodes
    // []string{"Переменные К2_Fсп_р"}, // slice of OPC tags
    []string{"Переменные А8_Tдг_заЗУУ_т.А-Б_р2"}, // slice of OPC tags
  )
  defer client.Close()

  // read single tag: value, quality, timestamp
  // fmt.Println(client.ReadItem("Random.Int4"))

  // read all added tags
  fmt.Println(client.Read())

Conclusion

c: \ the Go \ projects '> projects
' map [Variables A8_Tdg_zaZUU_t.A-B_r2:] the
Exception 0xc0000005 0x8 0x1f538af8 0x1f538af8 the
PC = 0x1f538af8
syscall.Syscall (0x1f538af8, 0x1, 0x4270be8, 0x0, 0x0, 0x0, 0x0, 0x0) the
C: / the Go /src/runtime/syscall_windows.go:184 +0xea
github.com/go-ole/go-ole.release(0x4270be8, 0xc000000000)
C:/Users/bukhval/go/src/github.com/go-ole/go -ole/iunknown_windows.go:51 +0x5a
github.com/go-ole/go-ole.(*IUnknown).Release(...)
C:/Users/bukhval/go/src/github.com/go- ole/go-ole/iunknown.go:56
github.com/konimarti/opc.(*AutomationObject).Close(0xc000043260)
C:/Users/bukhval/go/src/github.com/konimarti/opc/connection_windows.go :112 +0x39
github.com/konimarti/opc.(*opcConnectionImpl).Close(0xc0000ce600)
C:/Users/bukhval/go/src/github.com/konimarti/opc/connection_windows.go:326 +0x97
main.main()
C: + 0x18a
/Go/projects/hello.go:22 rax 0x1f538af8
rbx 0xb70030
rcx 0x4270be8
rdi 0x208000
rsi 0xc00007fe78
rbp 0xc00007fe28
rsp 0x103fe38
r8 0x0
r9 0x0
r10 0x0
r11 0xc00001e5d0
r12 0x1c7e05
r13 0x7ed620
r14 0x0
r15 0x0
rip 0x1f538af8
rflags 0x10293 ?
cs 0x33
fs 0x53
gs 0x2b

This situation is absolutely identical on the physical Win10 x64 and on the WinXP 32 virtual machine.
As an option, I considered an intermediate client-server that would pull data from the process control system, and I already took it from it. But I didn't find anything sane and free.