Member Login
member
passwd
remember me on
this computer.

- join now -
- forgot username or password? -

Jump to a Date

Cool stuff
Select a topic of interest:
...and press:
RSS Feed
RSS feed Use this link to get an RSS feed of the Modbus Community article flow, for private, non-commercial use only:
modbus.control.com/rss/
To get a personalized feed, become a member at no cost.
from the Forum department...
OPC Server Hanging at will
Human-Machine Interface and SCADA. topic
Posted by MIX on 29 June, 2009 - 12:50 pm
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?



Posted by Curt Wuollet on 29 June, 2009 - 7:43 pm
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


Posted by Mark on 30 June, 2009 - 10:11 am
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/


Posted by Mark on 30 June, 2009 - 3:07 pm
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


Posted by Fred Loveless on 30 June, 2009 - 5:29 pm
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


Posted by Randy T. Jakosalem on 1 July, 2009 - 12:00 am
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


Posted by Curt Wuollet on 1 July, 2009 - 12:01 pm
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


Posted by Fred Loveless on 2 July, 2009 - 9:59 am
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



Posted by Adriel Michaud on 2 July, 2009 - 10:26 am
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


Posted by UTR on 2 July, 2009 - 10:45 pm
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.


Posted by M Griffin on 4 July, 2009 - 7:37 pm
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.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2009 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.