I have two servers running the same Ignition gateway configuration. The configuration includes an OPC DA connection to RSLinx on a 3rd server. One Ignition server - we’ll call it “Server 1” - has no problem connecting and subscribing to items from the RSLinx server. The other - “Server 2” - is able to establish and maintain a connection to RSLinx but returns the following messages in wrapper.log when I attempt to initiate a subscription from the Quick Client:
[09:35:11,955]: Creating new COM subscription ‘Subscription 1_199E5126’/1000
[09:35:11,982]: Failure code returned from OPC server when adding item to subscription. Path: ‘[dryprocess]N7:40’ Return Code: ‘-1073479676’
Here are the details of the two builds:
Server 1:
- Windows Server 2003 Enterprise Edn. SP2 (x86)
- Ignition 7.1.6 (b5739) (x86)
- Java Sun Microsystems Inc. 1.6.0_20
Server 2:
- Windows Server 2008 R2 Standard (x64)
- Ignition 7.1.8 (b6427) (x64)
- Java Sun Microsystem Inc. 1.6.0_22
As far as I can tell, the Ignition Gateway configurations, especially for this RSLinx OPC Server Connection, are identical between these machines.
I have gone through the steps to add Everyone and Anonymous Logon permissions to all sections of the COM Security tab of dcomcnfg on all three servers. I have also disabled Windows Firewall on all three.
I downloaded and installed the OPC Core Components 3.00.101.2 on Server 2 and on the RSLinx server. This got me past other connection errors and to this current one.
My research indicates that the Return Code: ‘-1073479676’ is defined by the OPC DA spec to mean “The server cannot convert the data between the requested data type and the canonical data type.” I do not see a method by which you can change the requested data type in the quick client, but I have tried subscribing to items of several different types, all with the same result. I have also tried creating a SQL Tag and specifying different data types there with no luck.
I’m wondering if there is a difference between version 7.1.6 and 7.1.8 or between the 32-bit and 64-bit versions that might be working against me here.
As a side note, I am trying to migrate from Server 1 to Server 2, so it will not be a requirement in the end to have both of these servers running at the same time. I only mention Server 1 because it demonstrates that this connection to the RSLinx server has been working fine.
I suspect it does have to do with the x86/x64 difference. We’ve noticed problems with the OPC-COM module on 64-bit systems- when using the 64-bit JVM, that is. It works fine when the whole stack is 32-bit (java, the opc server) on the same machine, but perhaps there’s something about the remote access, going from the 64-bit machine to presumably a 32-bit one running RSLinx.
In terms of the data types, the OPC-COM module does not request a specific type. This is allowed by the OPC spec, and basically tells the OPC server to send it back in what it considers to be the native format of the address.
I’ll do some more research and see if I can track anything down.
Regards,
Thanks Colby. Yes, your presumption is correct that the RSLinx server is 32-bit. Let me know if there is any more information I can provide to aid your research.
It might take me a few days to track down RSLinx Gateway (required for remote access), as a lot of people are gone this week.
On the 64-bit machine, are you using 64-bit java, and did you install the 32 or 64 bit version of the core components? I would try to make sure that everything was 32-bit. Also, make sure the same version of the core components is installed on both machines.
Regards,
Okay, this looks good… I uninstalled the 64-bit versions of Ignition, OPC core components and jre. Rebooted, then installed the 32-bit versions of each. The connection to RSLinx and subscriptions to its items now seem to work perfectly.
So, I have a 64-bit OS on which I’m running the 32-bit versions of three applications that all have 64-bit options available. Should I consider this to be a long-term solution, or should we follow up on this and eventually try to get to all 64-bit?
Thanks for your help.
Hi,
Glad to hear it’s working. Ideally we would get the COM stuff to work perfectly on 64-bit, but if we step back a bit, I think your long term goal should be to move away from DCOM and RSLinx. DCOM is a rough way to transfer data remotely, and RSLinx is notoriously unpredictable. OPC-UA is a much better for remote access, and works equally well for 32 & 64 bit. Even with RSLinx, if you could put a UA wrapper on that machine, you would be able to run Ignition in 64-bit, and would have a more secure and responsive [size=50](I’m thinking of DCOM’s slow failure detection in some cases)[/size] remote connection.
Running Ignition in 64-bit is really a question of resources, more than performance. The system will have access to much more memory, if it needs it. If your project isn’t really pushing the limit, the drive to switch over isn’t very strong.
So, to summarize, this set up should work for now, but the long term suggestion would be to switch to a UA capable server, such as Kepware or our own. If you need RSLinx for other Rockwell products, a wrapper would help- though with the cost of the wrappers on the market, it may not be worth it.
Regards,