11-13-2008 10:29 AM
I am upgrading a customer from Lookout 5.1 to 6.1 and am having trouble with Hypertrend data showing up on client machines. Here is some background:
We have 2 server machines and several client machines on different subnets. The server IP addresses are 10.1.1.200 and 10.1.2.200. Some clients are on the same subnets as these, others are on different subnets. I have a hosts file set up to resolve the IP addresses to names. I can ping from any machine to any other machine using the machine names as well as IP addresses.
All clients can see live data from either server. The client process running on the server machine has no problem seeing hypertrend data from it's local server process. However, the remote clients (client process running on different machine than server) do not see any hypertrend data from either server. I get this error "The trace may not exist, or it's not logging to a Citadel 5 database."
Does anyone have any ideas on how to fix? Your help is greatly appreciated in advance.
11-13-2008 03:22 PM
I had a similar problem where I would have trends on my clients but would randomly lose those trends.
If you initially do see the trends, then see this link:
http://forums.ni.com/ni/board/message?board.id=190&thread.id=5414
Good luck!
11-13-2008 05:36 PM
Thanks for your reply Jason. I had read your previous thread. Unfortunately, I have never seen any Hypertrend data on the clients after I have upgraded to 6.1.
BTW, I see you are in Jefferson Parish. Have you dealt with any of the Prime Controls guys down there?.
I worked on the Corps of Engineers interim closure structure projects down there in '06 & '07. During that project we opened an office in Gonzales to serve South Louisiana.
If you ever need any help with anything, feel free to contact Jim Shepherd @ 225-803-4835 or j.shepherd@prime-controls.com. He is our branch manager.
Thanks again for your help. Hopefully someone from NI will get back with me soon.
Garrett
11-14-2008 03:47 AM - edited 11-14-2008 03:49 AM
The hypertrend use Citadel service to transfer the data between computer, while the live data is different, so your problem is probably in networking setting or firewall.
If you have firewall on either computer, follow these KBs.
http://digital.ni.com/public.nsf/allkb/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument
http://digital.ni.com/public.nsf/websearch/8AE45BBFA1D7025E862570F200642FD8?OpenDocument
Lookout client software doesn't install MAX.exe, but if you have MAX.exe on the client computer, you can use MAX to check the connection. In MAX, try to view the remote trace.
You can also use the NI Hypertrend ActiveX object to check the connection. Create a client process with just a NI Hypertrend ActiveX object. Move it to client computer. Edit its properties and add a trace, then try to view the remote trace. See the attached screenshot. If the Citadel communication has problem, you will not see the database or the trace.
The ActiveX object doesn't fix the problem, but can tell you whether the remote connection is good or not.
11-14-2008 10:23 AM
Garrett,
We are actually working with Prime on a project right now involving our pump stations.
I am very pleased with the work you guys are peforming.
Thanks and good luck with your problem.
11-17-2008 10:00 AM - edited 11-17-2008 10:07 AM
Ryan,
I had already completely disabled the firewall on both computers as part of my troubleshooting. I am convinced that it is some kind of networking issue, since the client process running on the server machine can see the historical data but the client process running on a separate machine can not. During my testing, my client machine is plugged into the same ethernet switch as the server and they are both on the same subnet.
We will try the hypertrend activex and report back.
Garrett
01-16-2012 07:11 PM
Ryan,
We are having similar problems with a 6.5 deployment. We have redundant servers with the same hardware/software configurations. Our connectivity is sporadic, we have some clients that can connect, or can connect for some period of time and then they lose their connectivity, we have others that don't seem to be able to connect at all. One of the two servers seems to have more problems then a second, but both demonstrate similar problems. I have tried tag browser, registering the IP address of the server, the ActiveX HT and all have the same results with us unable to connect. My personal computer is sporadic in its connectivity, but currently cannot connect to either of the two servers. Our Windows Firewalls are all disable by Group Policy (both client and server). Servers do not have AV or other firewall software on them. Clients mostly run Kaspersky, but for testing purposes we have tested with and without Kaspersky installed, and with/without Kaspersky enabled. None of these scenarios have demonstrated a consistent result. Every test of these that we have run have either worked temporarily and then stopped, or not worked at all on some computers. We have a client mix of XP Pro 32-bit and an increasing number of Windows 7 x64 workstations. Servers are Windows 2008 R2 Standard with SP1. We are also running Kepware KepServerEX, Fieldpoint OPC, and GE Historian Collectors on these systems. I don't see problems communicating with these servers from other applications. I can ping the servers consistently from workstations across the network. I can also browse the servers consistently from across the network. I'd love to get this resolved as my clients are getting frustrated with the inconsistency of their connections.
01-18-2012 07:36 PM
Did it ever work before? Did this problem happen after you upgraded lookout or the OS?
What happens when client "lose connectivity"? For example, a client reads a live data from server, but it shows red X after a while. like this?
After the connection is totally lost from a client, is there any way you have found to make it work again without restarting computer? For example, does it work if you restart the lookout server process and also the client process?
If it's possible, I'd like you to do a simple test.
1. stop the current lookout server process.
2. create a new simple server process with just one pot, and a client process reading this pot.
3. run the server and client process, and see if the client will lose the connectivity after a while.
I want to know if this problem is related to your specific process.