edimetia3d / opc-client-x64 Goto Github PK

In
void COPCServer::getItemNames(std::vectorstd::string & opcItemNames)

cycle:
while((result = iEnum->Next(1, &str, &strSize)) == S_OK)
{
WCHAR * fullName;
result = iOpcNamespace->GetItemID(str, &fullName);
if (SUCCEEDED(result)){
USES_CONVERSION;
char * cStr = OLE2T(fullName);
//char * cStr = OLE2T(str);
//printf("Adding %s\n", cStr);
opcItemNames.push_back(cStr);
COPCClient::comFree(fullName);
}
COPCClient::comFree(str);
}

char * cStr = OLE2T(fullName); allocates memory on stack where it is not freed until we exit function. Since it is called in While loop it will cause stack overflow and crash if there is too many items to list,

My workaround was to create wrapper function around OLE2T which moves data to heap.

I'm trying to run OPCClientDemo in x64 mode but it fails in getListOfDAServers() when it calls iCatInfo->EnumClassesOfCategories().
I have OPC Core Components Redistributable (x64) installed. Looking into the registry, I can only find OpcEnum.exe installed in C:\Windows\SysWOW64. Is this right? Am I missing something?
This works fine in Win32 mode...~
Thanks in advance!

Hi everybody,

I have read/write access to a string variable. It's a VT_BSTR.
Reading works fine, I have issues with writing.

First question is: how do I know how many charachters (or bytes) I'm allowed to write, if I didn't get any specs in advance?

Second: How do I make use of all the space I have available?
I ask this because when the string holds, e.g., 10 wchars, I can only write 10 or less.
Using Matrikon OPC I can write all the characters number the PLC developer told me.
My code so far:

std::wstring str(L"The string I want to write");
OPCItemData data;
var.pItem->readSync(data, OPC_DS_DEVICE);
wcscpy_s(data.vDataValue.bstrVal, 64, str.c_str()); // I know I have 64 wchars available
var.pItem->writeSync(data.vDataValue);

"var" is a struct I created:

struct VARIABILE  
{  
	std::string Nome;  
	COPCItem* pItem;  
	VARTYPE tipo;  
};

The above code works well only if the string already holds more than str.length(), otherwise the string gets truncated (and I fear I might be overwriting memory areas somewhere).

Any help is appreciated.

Hello, right now the toolkit here we use has an issue that when read string object, it cause memory leak problem. And i found that the author Mr Beharrell ralready fix the bug. https://sourceforge.net/p/opcclient/bugs/3/
You can build a new version of lib.

Hi,
I am confused about the license of the project. Whilst the source code files tell it is LGPL the license.txt file tells it is GPLv3. As I understood the GPL it is ok to convert the license from LGPL to GPL but not the other way around. So my question is was this change to GPLv3 intended. With GPLv3 I cannot use it in my project.

the problem I think is that 64 bit system uses 64 bit pointers so the items are not correctly addressed
COPCItem * item = (COPCItem *)itemState[i].hClient;
COPCItem pointer size is 64 bit but hClient is DWORD or 32 bit
something similar is for
CTransaction & trans = *(CTransaction *)Transid;
do you already have any solution for this?

Snippet below fails with error: 80040154 with a "Failed sz: Class ID String" error. I explored a bit but didn't find anything worth mentioning.

(**Object** passed into function)
string servername = ""; // connect to local server
servername = Object->OPCDA_servername; //server name holds "Matrikon.OPC.Simulation.1"
//servername = "Matrikon.OPC.Simulation.1";
client->Init();
if (!client->Connect(servername)) {}

Passing in the commented servername variable it works fine.

Hey guys,
I was using the demo (64-bit compilation) with no issues when listing/connecting to remote OPC servers. Now that I need to list the local servers and connect to one of them, I always get:

• No servers listed, when "iCatInfo->EnumClassesOfCategories(1, Implist, 0, NULL, &iEnum);" is called;
• "REGDB_E_CLASSNOTREG Class not registered" (0x80040154), if I ignore the list and force try to connect to a given server (specifically when I call iUnknown->QueryInterface(IID_IOPCServer, (void**)&iOpcServer);).

If I compile everything on 32-bit, everything works flawlessly.

I'm on a Windows 7 64-bit with KepWare 5.11. I've also installed OPC Core Component 3.0.105.1 and then moved to 3.0.106 to try solving the issue, but no luck.

Are you guys facing the same issues on a 64-bit system? Any guesses on what may be wrong?

I can get the server list successfully.
But then connect this, use the method "result = CoGetClassObject(clsid, CLSCTX_LOCAL_SERVER, NULL, IID_IClassFactory, (void**)&iClassFactory);"
then will get the error REGDB_E_CLASSNOTREG.
By the way, I just create a BECKHOFF.TwinCATOpcServerDA

Since I am not an expert in windows programming, the problems in this project have been beyond my ability, I can hardly contribute more to this project.
And also, I am doing some other things now, which are not related to the automation system.
So I couldn't put more energy into this project, only Pull Request will be handled in the future.

Hi,
I have a problem connecting to the Matrikon simulation server with the OPCClientDemo. The local connect works fine but the remote connect doesn't work. After showing the remote servers correctly and selecting the desired server the function GetCLSIDFromRemoteRegistry fails. It seems the RegQueryValueEx call returns only garbage and the CLSIDFromString call fails. Then later throwing an exception in makeRemoteObject.

Does anybody have an idea what might be the reason? From wireshark it seems that the remote registry access works.

I wonder why the remote registry access is required at all. When using some other clients (e.g. Softing demo client) the connection works also without using remote registry. I guess they are using the OpcEnum.exe for getting the clsid?

The old code that this was created from used CoInitalizeEx instead of CoInitialize. Also, there was protection around calling CoGetMalloc. I introduced a change to reinstate the original use of init() and stop() (though named differently) in a way that makes the client's usable in a multi-threaded situation. The init() function currently throws an error when being called from different threads, and also throws an error if you don't call it within each thread. The fix that I have put in (unfortunately over 2 commits) makes this work in a multi-threaded environment. I was using 20 threads to read/write values to/from the OPC server with my proposed change.