WebCTRL and Server 2008

[xarralu]

Hey all,

I was just wondering if anyone else has had problems with alarms being delayed by several hours.

It is only happening at our sites that are running Server 2008 and SQL server.

We have been going back and forth with ALC and was just seeing if there was anyone else that has seen this.

Odd thing is when webCTRL is rebooted (not the server) they all come in.

TIA.

[MaxBurn]

I DID see that just last week, I didn't have time to deal with figuring out why so I NAT'd the whole system which resolved the time delay and decided to return to this problem later.

Using SiteScan Web with SP1b for that site and the servers are 2008 R2.

[rellufnalla]

Hey all,

I was just wondering if anyone else has had problems with alarms being delayed by several hours.

It is only happening at our sites that are running Server 2008 and SQL server.

We have been going back and forth with ALC and was just seeing if there was anyone else that has seen this.

Odd thing is when webCTRL is rebooted (not the server) they all come in.

TIA.

I doubt it is an issue with the server ops. It is more likely in the logic config for your alarms reporting. If you are seeing it repetitivly on similar points, the error was probably created globally by the editor when he was developing your site. I do not recall if ALC techs sign their programmming. If they do you may find it is the same tech on all the databases. Regardless, there is a guy named John in the Atlanta office that could find the answer.

The problem with all those little logic blocks is that it is easy to overlook an error and they can be hard to find. The core issue with ALC programmers is that they are not hvac techs and write their script "by the book" for an application when engineering a site. The installed product never quite does everything it should and it is a challenge for the local ALC tech to resolve issues. It just takes a lot of time (hours, days and weeks) to review and edit programming, study trended feedback data and do the required process tuning to keep your systems running at optimal efficiency.

[MaxBurn]

I doubt it is an issue with the server ops.

The problem with all those little logic blocks is that it is easy to overlook an error and they can be hard to find.

On our side for better or worse the programs and all those microblocks are from a standardized library for our sstems, so a huge problem like this would be spotted quick.

Weird thing on this customer was we had no excuse for alarm delivery trouble, one subnet with everything on it. No access to other subnets or Internet.

[xarralu]

I doubt it is an issue with the server ops. It is more likely in the logic config for your alarms reporting. If you are seeing it repetitivly on similar points, the error was probably created globally by the editor when he was developing your site. I do not recall if ALC techs sign their programmming. If they do you may find it is the same tech on all the databases. Regardless, there is a guy named John in the Atlanta office that could find the answer.

The problem with all those little logic blocks is that it is easy to overlook an error and they can be hard to find. The core issue with ALC programmers is that they are not hvac techs and write their script "by the book" for an application when engineering a site. The installed product never quite does everything it should and it is a challenge for the local ALC tech to resolve issues. It just takes a lot of time (hours, days and weeks) to review and edit programming, study trended feedback data and do the required process tuning to keep your systems running at optimal efficiency.



Well, the two areas that we are having issues with are the Alber battery's and just one of the five generators. The Alber stuff we are getting BACNet IP to a LGR 1000 and the generator is on a separate LGR (MODBUS), pure interfaces with programs we made in house.

The only thing that seems typical between sites is that between the addition of the effected equipment service pack "B" was brought into the mix.

Strange thing is that when you reboot WebCTRL the effected alarms show and they have the correct time and date stamp. They even show up in the alarm page in correct order as if they have always been there.

You can check the alarm buffer(s) and they come in and then out as they should.

Weird, and it would have to happen to data centers of all places!

[MaxBurn]

The date/time stamp behavior is normal for delyed alarms on this system because webctrl does the date/time stamp in the module where it is generated, not in the web server where they are received.

I am thinking there is some firewall issue on the server maybe in how it deals with broadcast traffic verses the unicast after I did he NAT.

[xarralu]

I am thinking there is some firewall issue on the server maybe in how it deals with broadcast traffic verses the unicast after I did he NAT.

Sounds about right. I NAT'd as well seems to be working as of now. Thanks for the info MaxBurn