Geo SCADA Knowledge Base
Access vast amounts of technical know-how and pro tips from our community of Geo SCADA experts.
Link copied. Please paste this link to share this article on your social media post.
Originally published on Geo SCADA Knowledge Base by Anonymous user | June 10, 2021 03:05 AM
ViewX can fail to connect to a ClearSCADA server for a number of reasons. This page lists some of the common problems seen and some ways to fix the problem where possible.
ClearSCADA can shut down on its own, either due to licensing or some logic running within the database. Typically this will catch people out when the client and server are on different machines but it is often a simple thing to check which might save some effort
It does happen, albeit rare, that either the server is so overwhelmed with point data or logic that it cannot process any client requests that it appears offline yet the DBServer.exe process is running on the server; or a deadlock (very rare) has occurred within the database. In the case of a deadlock there isn't much you can do (refer to What To Do If DBServer Freezes Indefinitely for help in this scenario). If the server is under heavy load the system should be investigated to see what the root problem is and how this can be resolved. Clients may connect and disconnect, or just behave really slowly, if the server is overloaded.
Quite simply ViewX is trying to connect to the server however something external is blocking it. Often this is in the realm of IT departments and not directly under the control of the people that are affected. Tools such as telnet from the client to TCP port 5481 (or tools such as nmap if company policy allows) can be used to help investigate possible causes.
With a NAT, port forwarding should be configured to allow ViewX to connect.
ViewX uses a listening TCP port, by default in the range 5500 to 5509, to allow the server to push updates through, however if this connection is blocked then the client will never connect. In this case some other clients such as ODBC clients and QueryPad, and users of Server Status/Server Configuration may be able to connect successfully.
For host-based firewalls ensure that the connection used to the server are configured in the right network zone (e.g. domain, private or public for Microsoft's implementation) for the configured firewall rules.
Within ViewX this cause is typically characterised as the system not showing failed within a second or two of connecting. Instead the system icon in the sidebar is slightly transparent for approximately 20 seconds and then finally shows as the solid failed icon indication.
With a NAT, port forwarding should be configured to allow ViewX to connect.
Workstation names allow for alarms to be assigned to a specific workstation however only one workstation with that name can be connected to the system at a time. For non-Citrix clients this is generally not a problem unless someone has made a configuration error with the client setups, however with Citrix or general servers where multiple users can log in to the same machine and run ViewX, having a workstation name and using only the default Systems.XML file will only allow one user to connect to a system.
Workstation names should not be used on any machine where more than one Windows user can log into the operating system concurrently. If you wish to do this you must use custom Systems.XML files for each user each with a unique workstation name.
Should there be duplicate workstations then an event will be recorded within the ClearSCADA system against the root group.
For a ViewX session to connect then there must be an available client-side licence or a floating licence on the server. If neither are available then ViewX will not connect. Be aware that if you run a server on a machine then the licences for that server may also include client-side licences. To configure up where the client-side licences are read from using the Licence button in the Configure Connections dialogue.
Some versions of ViewX cannot talk to some versions of the database. Check the ClearSCADA Version Compatibility Matrix page for any possible compatibility problems.
The logging within ClearSCADA can be used to help track down the cause. Typically the following logging options are recommended to be enabled and the resultant logging investigated to help find the cause:
Note that in some case, e.g. the lack of any logging showing a connection within DB logs, might be all that the log files may provide.
Go: Home Back
Link copied. Please paste this link to share this article on your social media post.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.