Loop
01-28-2010, 03:20 AM
Problems encountered on workstation using Alerton Envision 1.30A
We service a site that has encountered a user problem since 15 December 2009.
The site runs Envision 1.30A. It includes a BTI (address 201) which has two MSTP LANs. The site is set to run Bacnet/IP because it has to run on the site’s IP backbone. The server on the site has up to seven workstations some of which log in from time to time while two of the workstations are logged-in to the server continuously.
On 15 December 2009, we added two more workstations to the site. As part of the operation, after we had loaded the software and addressed the two new workstations, we did a scan from the Server and added these two new workstations to the Device Manager. The new workstations were allocated vacant addresses that did not clash with existing ones in the Device Manager.
On the morning of 16 December 2009 we received an urgent call from our client who reported that they were unable to log in at any of the workstations and that they were also unable to access the Alarms and Schedules. The server, however, was still able to access the User Set-up menu, Alarms and Schedules on the system.
We checked that we had not accidentally double-addressed any devices and rebooted the system. As an experiment, we removed the two new workstations from the network and also from the Server’s Device Manager Table. The problem persisted.
We checked that the BTI was running the appropriated ROC file (3.40(build 4)) and loaded it again just to make sure. The problem still persisted.
We have found that if we set up one of the workstations to become the Server and make the Server a workstation, the new Server is then able to see User set-ups, Alarm set-ups and Schedules while the PC that has been made into a workstation, has lost access to these tools.
We set up two new PCs on site with a switch and set up a new separate network outside of the network on site. The problem persisted.
It appears that the problem lies with the BTI. We have checked its operation and set-up for anomalies, but all appears to be correct. We are trying to access a spare BTI and install it on site to see if this might fix our problem, but in the meantime is there perhaps something else we can attempt to eradicate this problem?
Charley Cooper (Optimal Control Systems)
We service a site that has encountered a user problem since 15 December 2009.
The site runs Envision 1.30A. It includes a BTI (address 201) which has two MSTP LANs. The site is set to run Bacnet/IP because it has to run on the site’s IP backbone. The server on the site has up to seven workstations some of which log in from time to time while two of the workstations are logged-in to the server continuously.
On 15 December 2009, we added two more workstations to the site. As part of the operation, after we had loaded the software and addressed the two new workstations, we did a scan from the Server and added these two new workstations to the Device Manager. The new workstations were allocated vacant addresses that did not clash with existing ones in the Device Manager.
On the morning of 16 December 2009 we received an urgent call from our client who reported that they were unable to log in at any of the workstations and that they were also unable to access the Alarms and Schedules. The server, however, was still able to access the User Set-up menu, Alarms and Schedules on the system.
We checked that we had not accidentally double-addressed any devices and rebooted the system. As an experiment, we removed the two new workstations from the network and also from the Server’s Device Manager Table. The problem persisted.
We checked that the BTI was running the appropriated ROC file (3.40(build 4)) and loaded it again just to make sure. The problem still persisted.
We have found that if we set up one of the workstations to become the Server and make the Server a workstation, the new Server is then able to see User set-ups, Alarm set-ups and Schedules while the PC that has been made into a workstation, has lost access to these tools.
We set up two new PCs on site with a switch and set up a new separate network outside of the network on site. The problem persisted.
It appears that the problem lies with the BTI. We have checked its operation and set-up for anomalies, but all appears to be correct. We are trying to access a spare BTI and install it on site to see if this might fix our problem, but in the meantime is there perhaps something else we can attempt to eradicate this problem?
Charley Cooper (Optimal Control Systems)