DAQ channel read

[Sid]

Hi

I have another problem..

I'm using an OPC server (2.0 compliant) and I use DF to read the tags/channels from it. It all works fine when I simulate it (with the OPC server not connected to a PLC - with just the project loaded) and when I connect it to a PLC to test it on my machine.

I'm reading about 30 tags (most of them async. and 4 synchr. read) and I have 2 while loops in two sequences (one waits for the full hour waituntil(floor().......) and the other waits until its midnight to do it's thing) always running with the priority 1 (so that we don't overload the CPU). There are no infinite loops..

On my (test) machine the RAM usage is 60-70MB and the CPU usage is at an average of 2-3% (max 7%).. This machine is a laptop with Core2Duo T7250 CPU (@2.0GHz) and 2GB of RAM memory. So no problem here, everything runs smoothly, even clicking between pages!

On the customer's machine (the same *.ctl file) the RAM usage is about the same but the DF CPU usage runs as high as 70% (average at about 50%-that means one core is at 100%, or both at 50%!!). The machine is a Pentium dual-core CPU E5300 (@2.60GHz) with a 1GB of RAM (probably DDR2-667 as mine). So the machines are somewhat similar.. Then DF starts acting up, becomes really slow and sometimes even unresposive. After a certain time (max 1-2h) DF just vanishes/closes itself.. i can't keep it running!

On both computers the system is WindowsXP Pro .

I've been thinking about it and I can't seem to find the problem.. But there is one thing! On the customers machine they have another application connected to this OPC server. It's purpose is to read data from the OPC and then convert it to XML, which is then sent to a remote server/database for further purposes.. It probably uses DCOM as well as does DF..

Could that be a problem? Some sort of a conflict between them? One time DF alerted me about some errors on reading from OPC? 10-15 minutes after that it just closed itself and that was it..

What do you think? How could I fix this?

Thank you

[Sid]

Hi, it seems noone knows anything about this..

some more info! If anyone sees or knows anything more that could be usefull please reply!

I got the error code from the DF alert window:

Unable to read OPC, error code: 0x800705b4

When DF is started everything is OK, with normal CPU usage, then the CPU usage gets higher by the minute. After 5-10 minutes it gets to around 50-60% and it stays there. After that DF becomes really slow and unresponsive and the data doesn't seem to get through (I went to the OPC watch monitor inside DF and it didn't seem to refresh). That's when the upper error code appears.. After a while DF closes itself!

I checked the hits on google and found an explanation for the OPC error code:

This operation returned

because the timeout period

expired.

This is a timeout. You may need to increase

your timeout settings.

link to the pdf (OPC error codes)

OK, then i found something else:

link

and in that I found the following:

The most common times when you'll see this error are when using the ReadVariable, ReadMultiVariables, WriteVariable or WriteMultiVariables items. This is because these calls are synchronous, meaning that the VB line of code that calls these methods is unable to move onto the next line of code until that line has completed.

When calling one of these methods, the OPC Server is being instructed to carry out the request at the device, and not to respond to the OPC Data Control until the instruction succeeded or failed. The OPC Data control is left waiting.

If the connection between the OPC Server and PLC was a slow connection, then the instruction may take some time to complete. If you leave the OPC Data control timeout settings at their defaults, then a timeout may occur.

That's it! We have a slow connection to the PLC (some factory problem with the PLC), that's why I thought that by changing the method of reading from async. to synch., would make things easier for the OPC and the DF communication.. But as it seems, the 6 tags I chose as synch. (only the analog signals/meters which change more often) were stalling DF.. I just changed the tag statuses to async. and DF started eating from 50-60% of the CPU to only about 0-3%!!!! And it's still running!!!

And I also read somewhere that even though DCOM connection is slow (compared to newer ones) it's still capable of transfering around 20k tags with the CPU load at only about 10%.. So having 2 clients, both of which read from the OPC server through DCOM, shouldn't be a problem (i tested this with two different instances of DF both reading from the same OPC)!

I hope this helps somebody with a similar problem in the future!