i have a third party Gateway that acquires data from various RTU's in different remote locations and, the gateway and the rtu speaks modbus language, for the realtime data to be visible in PI Server , we use Matrikon OPC Sacda Modbus along with the PI OPC interface:

the Challenge we are having is the The OPC server hangs at will. therfore we can [mods note: cannot?] see any trending during those hanging periods.

what we did was to use a script to stop/restart the server 3 times in a day. and the hanging was reduced. but we needed a total solution not by using a script to stop the service (the server should run seemlessly).

Also an upgrade has been done to the Scada Modbus server but the situation still remains thesame so we are still using the script.

can any one Suggest a solution to this Problem?

 

I would probably try a different server. Or demand that the author fix it. Without code or diagnostic capability, no one else can probably tell you what is going wrong.

Regards
cww

 

Hi,

The list of possible problems is very long. Without more data, finding the problem and applying a solution will be difficult.

You could try our new MODBUS OPC server.

Good luck,

Mark
http://www.peakhmi.com/

 

Try a different OPC Server. Free, fully-functioning, 30 day trial version available for download at

http://automatedsolutions.com/products/opcmodbusrtu.asp

-Mark
http://automatedsolutions.com

 

Try KepserverEx (http://www.kepware.com). We have and extensive posotive history working with Modbus devices and with OSI PI.

Fred Loveless
Senior Application Engineer

 

Sometimes its not the software but the hardware. Maybe your PC have not enough RAM space to run smoothly your package software. Or there is an issue with hardware conflicts among your interfaces or conflicts in interrupts. Try not to focus on the software because before its been released it had undergoned all the testing in their lab so focus on the hardwares on your PC.

regards
rtj

 

Yes, but with shrinkwrap software shrouded in secrecy, it's very difficult to find out which. So, if the vendor isn't helpful, a change is called for and the software and vendor are the easiest to change. With source, you could put in trace statements, etc. and find out what is going wrong. Or at least understand exactly what it's doing. If you are going to build black boxes, you should be held strictly accountable for what's inside. My pet peeve is shrinkwrap vendors who won't take responsibility for what they prevent the user from knowing.

Regards
cww

 

Not all of us that develop OTS software are like that. I never assume that my software is not at fault. Nobody writes perfect code, and as exteranl parameters like PLC Firmwre and PC OS's change that can directly impact the way your software works intruducing errors or exposing previously unseen errors.

That said, the first things that we do when working with a customer is address all those things that we know can produce a similar issue which do not involve our software. Once those are eliminated we then focus on the one thing left that could be causing the problem. This process does take time and it does require some patience on the endusers part.

Sorry for taking this a little OT. I just don't like being lumped in with that particular sterotype.

Fred Loveless
Senior Application Engineer
Kepware Technologies

 

MIX, have you contacted our OPC Support team? They'd be able to assist in resolving the issue. The contact information is at www.opcsupport.com

Adriel Michaud
MatrikonOPC

 

Having used both Matrikon and Kepware for similar applications I would reccomend moving to Kepware for anything requiring Modbus drivers.

We experienced what seems to be same problem as described. We have had no more problems since switching.

 

Check the memory usage at regular intervals to see if it is consuming more and more memory. If it uses up all the available memory, everything will just gradually grind to a halt until you stop and restart it.

Your vendor is the only one who can fix this. Try to collect some information on what is happening, and then contact them. This is a closed source product, so you are totally dependent upon them.

I had a similar problem with an OPC server from another major vendor, OPC has a history of memory leaks and other problems, so this isn't a problem with just one vendor or one product. Modbus is a very simple protocol and it doesn't take much code to implement it. OPC however is based on Microsoft COM/DCOM, and it is far from simple, so you have to expect problems like this from time to time.