Post a reply to the thread: siemens BAS
You may choose an icon for your message from this list
Please enter the name by which you would like to log-in and be known on this site.
Please enter a password for your user account. Note that passwords are case-sensitive.
Please enter a valid email address for yourself.
Will turn www.example.com into [URL]http://www.example.com[/URL].
FIREWALL Check The firewall!! I thinks that the problem was over!
FIREWALL
Siemens has released an update to panel firmware that makes ethernet panels more resistant to "network storms". PROBLEM: Ethernet Field Panels running Firmware Revision 2.8 Build 1104 or 2.7 Build 1006 may stop communicating on an APOGEE Ethernet ALN after a period of heavy network traffic occurs. Some of the known symptoms after the field panel fails to communicate on network are: Insight and the rest of the network show the field panel FAILED and the field panel gets disconnected from the network. Even after the field panel fails on the network, local node table of the panel may show it is still communicating on the network. The field panel may still respond to PING and TELNET commands. Typically a coldstart of the controller would be only way to bring it back online. YOUR ACTION: The solution/patch has been successfully tested at several job sites. The permanent solution is incorporated into Firmware Revision 2.8 Build 1105 which will be available on StdApps drive within the next 1-2 weeks.
I would try to use a ethernet datacapture software (like Ethereal witch is free) and see what actual happens. You need FW 2.7 build 1006 to overcome all datastorm issues. If you give me a name in FS I can work from the "inside" and have a look what they have done so far. I am only a couple of feet away in the same building. Udo
Well, good luck Rob. If you have Siemens in there looking at it, the campus should be back up in short order. If Siemens was just there for another purpose and didn't work on the network failure, then you'll need to "divide and conquer" to find where the communications are failing at.
regarding it weve had siemans come in as they needed to input something ,not sure as ive been doing other things but will find out, as soon as i can, as we still have a whole campus down and showing cab failure,we did reset the panel or should i say tried by shutting power then back in but to no avail,thanks for any answers
regarding it
also the It dept had done some work in to the system which gave us a bubnch of issues If you IT department is not familiar with the ethernet based panels you need to get them up to speed. I've dealt with several locations that the IT "guru's" decided to relocate a data rack or, even better, completely revamp the IP addressing scheme. We, of course, found out AFTER the cables were cut too short or suddenly whole buildings were "gone." Make friends with them, buy them a drink, get them up to speed, whatever. It WILL make your life smoother down the road.
Siemens im fairly new tto the hvac filed,im learning some of the siemens apogee,and we just had a BAS failure, had to find a short as the possible cause,the super had to reload the noads,also the It dept had done some work in to the system which gave us a bubnch of issues
Siemens
Back at ya, Dingman. I didn't think of an AEM, I just took it for granted that they were Ethernet panels.
Originally Posted by crnelson A "network storm" is is the term used by my IS group to describe a large network outage characterized by high traffic and corrupt data. Usually most other applications shutdown also, such as outlook. If Outlook is shutting down across the network, the above is correct! Your IT people need to get the "pipe" fixed. If Outlook is shutting down on the local machine (workstation), that may be another problem. Example: We had the server doing a backup to an external drive @ 0200. No problems, until the local branch got the great idea that we needed to do a "ghost" instead of a backup. This was thru USB to the external drive. All it took was one cab. to have problems (in/out of failure) to lock up the server (not enought resources). Workstations could not talk to the server nobody was happy. Moral of this story is the IT guys may be right, but don't discount PC problems.
Ahhh, well then, there's your answer right there. It sounds as if the ethernet is causing the problems and your IT people already know about it. I've worked on many (smaller) ethernets and I don't think I've ever seen a "network storm" shut down applications on PC's~ it must be an event of significant size going on there. Unfortunately, no equipment is bullet-proof. If you hit it enough times with a big hammer, it will break. Good Luck. Talk to your IT people. (Good questions Cheesy-dood) EDIT: The AEM uses the TCP/IP communications protocol to transfer the BLN information back to the APOGEE Insight. It connects via an Ethernet connection and to the APOGEE field panel via the RS232 modem port. Originally Posted by crnelson A "network storm" is is the term used by my IS group to describe a large network outage characterized by high traffic and corrupt data. Usually most other applications shutdown also, such as outlook. I am told it can be caused by a failure of any network card, switch, or router. Our panels are connected directly to a local network port and then directly to an ethernet hub. What is an AEM?
A "network storm" is is the term used by my IS group to describe a large network outage characterized by high traffic and corrupt data. Usually most other applications shutdown also, such as outlook. I am told it can be caused by a failure of any network card, switch, or router. Our panels are connected directly to a local network port and then directly to an ethernet hub. What is an AEM?
1) Do these cabs. plug directly into the ethernet or do you have AEM's. If you have AEM's then cabs. on the BLN may fail because of problems. The AEM may have a bad power supply or be bad itself. 2) We just had a cab. that had a module short on/off and caused problems on one network?? Just a thought..
Not being a wise guy, I just don't want to take anything for granted. What are you calling a network storm? A high volume of ethernet activity? UPS kicking in for a moment during an electrical storm? Multiple routers making/dropping connectivity? Just looking for some clarification on that. If you are able to deliberately recreate the conditions during the storm and for an extended period of time I would consider running a tracert aaa.bbb.ccc.ddd (letters = IP address of field panel) and see where the breakdown might be happening. It will trace up to 30 "hops" from your terminal to the end device. If you end up bogging down in one spot for most/all the panels that switch/hub may be part of the problem. You could also try to ping aaa.bbb.ccc.ddd -t The -t switch will keep in pining the IP address until you hit Ctrl-C vs. 4 hits (standard) and quitting. Win XP can open multiple DOS shells to do both at the same time. Not as good as a sniffer but it can *possibly* help you narrow down the search a bit. Not a fix but rather a "Band-Aid," can you accelerate your trend collections? Instead of waiting every 24 hours (or whatever) could you just schedule a trend collection every, say 3 hours? You can always remove the extra collections later but it can help you save that data you're looking for.
I have been at my site with the comm. failures, ran sniffer and had the worst results that field support had seen. It ended up as a TEC that was internally shorting out the FLN. When I tested for continuity to ground, on the active FLN, I was showing intermitent shorts. I have 3 more FLNs with similar failures, just not as frequent. I ran Sniffer again today on another network and will submit the results to field support in the morning. Hopefully the results will at least let me know if I am dealing with a similar cause of the other failures.
Originally Posted by crnelson Has anyone out there experienced multiple, simultaneous BAS panel failures and coldstarts with a Siemens Apogeee BAS? It looks like the problem may be caused by problems with the ethernet network connecting the servers and panels. It sounds like the Real Metasys Man has been there!
This is interesting, I'll be watching to see if you come with anything definitive. Originally Posted by ttstrutt I am dealing with a sight with similar network failures, minus all of the coldstarts. I have all MECs v 2.6 build 941 and 2.7 build 1005. I was told to flash the 2.6 to the 946. One panel locked up and that is why we have the v2.7 with the 1005 build. The 1005 is supposed to have all of the fixes that the v2.6 946 build, and then some. The problem continued with 2.7 and field support is really scratching their heads, me too. I believe we have gone over all of the basics (cable condition and connectons, power quality, etc.) I will be back to run NDPT, again, and Sniffer this week in hopes of narrowing our search on the network. I will check back if I come up with any possible solutions that may help you. Good luck. Last week I had an Insight workstation that would reboot everytime that Insight was opened up. It turned out that 2 Microsoft updates caused this, after too many hours of the customer looking over my shoulder asking if I figured it out and wanting to know when his system will work again.
Those are good details. Since your panels and firmware are up to date, I don't have an easy answer. The next step as I see it would be to try to re-create the issue (the "network storm") while watching the network with a sniffer. I'd be watching for whatever packets were coming in faster than others and if any of the packets were corrupted. Sorry, I don't have any really large ethernet BLN's, so I'm not much help. It does seem that the panels are getting either too many of a particular packet or getting corrupted packets. Nothing else I can think of that would cause what you are seeing. Originally Posted by crnelson The problem is random. Twice it has coincided with a "network storm". It seems like the panels automatically disconnect from the network when the network is having a problem. The panels also automatically cold-start which deletes all trend data. I have not checked the batteries other than by running a panel configuration report. Just to be sure, I'll check & replace as needed. However, a battery failure in one panel should not cause the other 36 panels to coldstart at the same time. As proof of this, a prior battery failure did not cause any problems. All of the panels are on E-power and have a local UPS with clean power. The reserve time is approximately 20 minutes. The panels are mostly MBC-42 with a few MECs. The firmware is a mix of v2.7 and v2.6. Most of the v2.6 has been upgraded to build 946, per Siemens recommendation. The upgrade has not corrected the problems. I have talked to Siemens technicians who have experience with installations of large numbers of MBCs on ethernet networks. My site is the only one that has had this problem. None of these panels use BACnet. They use the standard Siemens' protocols. Thanks for the feedback.
I am dealing with a sight with similar network failures, minus all of the coldstarts. I have all MECs v 2.6 build 941 and 2.7 build 1005. I was told to flash the 2.6 to the 946. One panel locked up and that is why we have the v2.7 with the 1005 build. The 1005 is supposed to have all of the fixes that the v2.6 946 build, and then some. The problem continued with 2.7 and field support is really scratching their heads, me too. I believe we have gone over all of the basics (cable condition and connectons, power quality, etc.) I will be back to run NDPT, again, and Sniffer this week in hopes of narrowing our search on the network. I will check back if I come up with any possible solutions that may help you. Good luck. Last week I had an Insight workstation that would reboot everytime that Insight was opened up. It turned out that 2 Microsoft updates caused this, after too many hours of the customer looking over my shoulder asking if I figured it out and wanting to know when his system will work again.
more details The problem is random. Twice it has coincided with a "network storm". It seems like the panels automatically disconnect from the network when the network is having a problem. The panels also automatically cold-start which deletes all trend data. I have not checked the batteries other than by running a panel configuration report. Just to be sure, I'll check & replace as needed. However, a battery failure in one panel should not cause the other 36 panels to coldstart at the same time. As proof of this, a prior battery failure did not cause any problems. All of the panels are on E-power and have a local UPS with clean power. The reserve time is approximately 20 minutes. The panels are mostly MBC-42 with a few MECs. The firmware is a mix of v2.7 and v2.6. Most of the v2.6 has been upgraded to build 946, per Siemens recommendation. The upgrade has not corrected the problems. I have talked to Siemens technicians who have experience with installations of large numbers of MBCs on ethernet networks. My site is the only one that has had this problem. None of these panels use BACnet. They use the standard Siemens' protocols. Thanks for the feedback.
more details
I agree, more details are needed. Obviously, these panels exist on a ethernet, so we know that. 1) Is the problem replicable? 2) Are you SURE the batteries are good. 3) What type of panels 4) Firmware revision would be nice It takes a large event to coldstart multiple panels on a RS-485 and I can't remember ever having this issue with an Ethernet set of panels. (other than when adding them to the BLN, like Cheesey-dude said) Originally Posted by chesehd I've not heard of this on ethernet panels either, like Shiff said only on RS-485 networks and then usually when a device on the network fails. What led you to the conclusions regarding the network causing the problems? What's the battery status? Don't just take the field panel's status at it's word, go out and check it with a VOM. It is a AA battery or a Li battery? You sure the power didn't flash several times before dropping out completely? I've had that mess up panels on both types of network. Enough guessing on my part. Could you provide more detials on yours, please? Thanks
Forum Rules