OPC Server reading fine, writing incredible slow

[DPat]

Hello together,

i have a problem regarding the opc communcation with a SimaticNET OPC-Server.

I have to read about 20 tags and write about 15 tags.

My problem is, that reading the tags is quite fine, (takes about 100ms to read the whole set),

but writing is incredible slow: If i write the whole set it takes about 1-1,5 seconds, even if i reduce

the writing to 1 tag it takes about 0,8-1,3 seconds, in which my application hangs. So for what

reason ever there seems to be some kind of overhead of about 1 second for writing the tags.

After making an own thread for the writing my application is fine, but the CPU usage (normally

about 20%) jumps to 100% every time the writing is done.

Has anyone encountered similar problems? I am wondering that the reading is fine while

the writing is so slow. If these are some connection issues, normally both should be slow,

shouldn´t they?

Any idea is appreciated,

Dirk

[RobertH]

hello dirk,

what kind of pc do you have?
may it be that you use a dual core machine or hyperthreading?

regards,
robert h
NI germany

[DPat]

Hello Robert,

thanks for your answer. It is just a "normal" PC, neither Dual Core nor Hyperthreading.

The project i was working on is finished, so i had to leave it with the slow writing.

I found the reason of the CPU usage, which was just me forgetting to put a delay

in the thread for writing the data. (Before putting the delay in the ThreadCallback

just started with while running .... so it was repeated over and over again. After

putting a delay in, CPU usage was fine.)

Actually i am quite sure that the slow writing has something to do with the SimaticNET

OPC-Server or the database on the PLC itself. I don´t think that this is an issue with

CVI.

But thanks for your help anyway,

Best Regards,

Dirk

[sepp974]

Hello,

I have the same problem.

I use a pentium 4 PC and Windows XP....

Somebody can help me?

Thanks,

Giuseppe

[Software_Monkey]

Its probably not much help but heres  an explanation of what you are seeing.

Reading from an OPC server normally reads a local cache which is refreshed by the server at the chosen update rate. Writing however is always to the device and, to quote from the OPC specification, ", the function should not return until it verifies that the device has actually accepted (or rejected) the data".

This might be why your system appears to hang because it is 'inside' the OPC server waiting for a response from the hardware. The question is where is the delay? Is it in sending the TCP/IP packet?

Let me know if you managed to find the cause.

Tony

[erikaasen]

I have exactly the same problem with Labview 8.2 and SimaticNET opc-server. Frustrating. Doesn't seem to be able to write faster than 450ms. I'm trying to do a scan-program with a refreshrate of 200ms. Don't think it is possible with simaticNET. But please tell me if somebody knows otherwise.

Erik

[Tony_Dean]

I have the SimaticNET OPC server working at 100mSec update using 12Mb/s Profibus and it works fine. This is NOT using Labview so I can't say if that is the cause of the problem. I know it will not work any faster than this but you can always perform async I/O if you want 'immediate' response, providing that you dont have a lot of items to read/write.

Its also worth noting that the refresh rate for the OPC server has no effect on the write times. When you write to an OPC item, it is always written to the device and is not cached or polled so it should be pretty much instant, again depending on your network type and speed.

Regards,

Tony

[erikaasen]

I'm a bit new when it comes to opc. Async OPC, is it a setting in the simatic software or is it the way you program to read and write in labview?

[Tony_Dean]

Hi,

Firstly an appology, I incorrectly stated that Async reads can be used to perform direct reads from the device where in fact it is Sync I/O.

I dont know anything about Labview but OPC servers generally provide Async and Sync I/O interfaces. I expect that Labview will provide a means to invoke either of these but I dont know the Labview specifics.

The fastest and most efficient way to read a value via OPC is to use an Async I/O interface. Requests are queued and a callback is issued when the value is available. The values are read from a CACHE in the OPC server which is updated at the OPC update rate. This is usually configurable.

If on the other hand you need to get 'fresh' values from a device quickly, you should connect using sync I/O using DEVICE as the data source. This method does not return until it has got the value from the device. This means that the call can tak longer than Async, and utilizes more CPU time, but the value is fresh and not affected by the update rate of the OPC server.

Hope this helps

Tony

[erikaasen]

Hi,

thank you for the information Tony.

We actually found the problem now. It is not Labview nor the OPC server. It is the PLC program. The guy who made it some years ago made it "big and heavy", and during the years some hardware has been removed. The PLC software has never been updated and are issuing a lot of error messages and probably some timeouts due to the missing hardware. All this mess causes the cycle time of the PLC to take as long as 450ms, exactly the minimum write rate I can atchieve with Labview using datasocket. 

Erik