Eurotherm EPower Controller : problem of request

[J.DECHET]

Hi,

I encounter a problem with communicating with an Eurotherm EPower controller (with 4 units) by OPC Server.

I use :

- LV 8.5.1

- iTools OPC Server 7.50 with a corporated product number (license activated)

- EPower Firmware v3.01

Communication between LV and OPC Server is made by 'DataSocket Write' and 'DataSocket Read'.

I can write values with no problem => I only write Main.SP on User event change and all is right.

But concerning reading, I would like read continuously Meas.P, Meas.V, Meas.I for each unit (so 12 url request)

The first read is ok, I get values so, url are ok. But after, it's impossible to loop it => no error, (status=0 on LV and on OPC server) but values are not refreshed with next request.

I tried to play with the option 'wait for updated value' but no success.

The only mean I found is to open OPC Server interface, select the device, right click and select 'Synchronise Active device'. But this option is only one shot and very long because, I suppose, it gets all the device content...

Other point : it runs perfectly with iTools Engineering Studio, commonly named iTools. It's an customer of OPC server as my application.

Other other point : When I launch my application the ID_EPower.exe in process list of Windows is present and consume resources (0 or 1%) so it lives.

To complete, with one hour, I thank them but no way with the hotline from Eurotherm. 

My question is : Is there a special way to obtain continuously measurements such as send a query to each time or a general property to obtain refreshed data?

I used to drive regulator from the same manufacturer with no problem and no need to send a query to obtain values but perhaps here it's a different case.

List of requested URL:

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.1.Meas.V

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.1.Meas.I

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.1.Meas.P

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.2.Meas.V

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.2.Meas.I

opc:/Eurotherm.ModbusServer.1/CLA_Gradateurs.192-168-1-222-502-ID001-EPower.Network.2.Meas.P

... idem for Network 3 & 4

I attached the part of code which is dedicated to read values but it's not really helpful because I think my method to read is correct (data arrive but are never refreshed) so it's only a 'lack' of command to ask the server acquires new data or a bug with the interface LV-iTools OPC Server...

For advanced LabViewers, I know my attached code is not optimised and not the smartest but, keep cool, I needn't crazy performance 😉 

Any suggestion?

[d_n]

Hi, Julien 

I have used ePower with Labview Datasockets to Read and Write parameters without any problems. There is no special way to obtain continuous values, all you have to do is to read continuously the parameters you want and get their values.

I have Labview 8.2 so I can not open your code, but I will be happy to check it if you can save it as 8.2 or 8.2.1 

You mentioned iTools reads and refreshes the parameters correctly. This is because iTools opens and maintains connections with the OPC server, the fact that iTools can connect to ePower proves your wiring is correct. 

From you message it is not clear how do you connect Labview to the OPC server and I suspect the problem with your application and the way you handle the Datasockets. For your application to work correctly you must: 

 1)      Start the Eurotherm OPC server scan and find the ePower instrument(s).

 2)       Use the “DataSocket Open” vi to create Read or Write Datasocket connections with the OPC Server. Note the server will timeout and terminate after 1-2 minutes if no clients are connected. Take a look at the “Multiple OPC Items Monitor.vi” example by searching for OPC in the NI Example Finder.

 3)      You must Open the same number of Read type Datasockets as the number of parameters you want to Read

 4)      You can use a Loop to pass the array of open Datasocket references to the “DatasocketRead” vi to read the parameter values.

 5)      Set the wait for updated value to FALSE to get the last value from the buffer.

 6)      Before you end your application close all opened Datasocket references. 

I hope the above steps will help you identify the problem. If you still have difficulties you can send me your code to take a look if you want. 

Regards

Dimitris

Senior Validation Engineer Eurotherm

[J.DECHET]

Thanks for your detailed response.

You could find my part of code in LV8.2.1 as attached file. It's called in a heavy framework with several state machines  in parallel so I am not able to provide all the distribution. But I am sure that is not a problem of general structure because I check this part runs regularly.  

Compare your advices, the main difference with my code is that I directly use 'Datasocket Read' without maintaining a special connection Id to the server.

I thought 'DataSocket Read' worries about open and close the connection (a little bit similar as new GPIB features) as explained in the LabVIEW help: Dequeues the next available data value from the client-side buffer associated with the connection you specify in connection in and returns the data.

For the moment, I haven't access any more to the bench but I could probably in the next week so I will try to implement all the chain : Open\Read\Close.

Thanks again and I will inform you about that.

[J.DECHET · Accepted solution]

So, I was not on the place for tests but now it's ok.

Several serial actions were done to soluce the problem, but it's difficult to know if all were benefic:

- An update of Eurotherm softwares  : 7.50 to 7.68

- An update of EPower firmware : 3.01 to 3.03

- and surely the main cause of problem : change the cable by a cross-wired (we thought it was but not in reality...). But even if it's the main cause : how it was possible to receive data by forcing update in the OPC Server... strange.

Thanks for your help.