Emerg. Shut Down

[denis]

How do you shut down FIVE (5)gas furnace/ac residential systems in a small commercial building with one emergency control switch?
"Is it possible to tie all 5 earth grounded 24 volt common wires together and break them as one?

[Carnak]

How about some relays

[Milk man]

Hey Denis, it helps everyone to ask the question on only one forum. Most people look at everthing on this site.

Keeping only one thread everyone sees everyone elses thoughts.

[trane]

Why could'nt you use a separate panel with a main breaker in it?

[Freeze Stat]

denis, we normally add a relay to each unit and tie these together to form a "safety" circuit. The normally closed emergency stop is wired in series with the relays. During normal operation the relays are energized and existing 24 V control circuit is made. When the normally closed E-stop is opened, relays open breaking the 24 V control circuit. Units shut down.

[lonboy]

LON Recipe,

Add one free topology network wired to (5) LonMark thermostats over 22ga twisted pair unshielded cable. Add to the network (1) LonMark digital input module at the emergency switch. Program the shutdown sequence by connecting virtual wires (network variables), add plug-ins, and commission with an LNS based network management tool like LonMaker (graphically based - no code writing!). Optionally add one $600 iLON web server/remote network interface and garnish accordingly.

Enjoy!
lb

[osiyo]

Originally posted by lonboy
LON Recipe,

Add one free topology network wired to (5) LonMark thermostats over 22ga twisted pair unshielded cable. Add to the network (1) LonMark digital input module at the emergency switch. Program the shutdown sequence by connecting virtual wires (network variables), add plug-ins, and commission with an LNS based network management tool like LonMaker (graphically based - no code writing!). Optionally add one $600 iLON web server/remote network interface and garnish accordingly.

Enjoy!
lb

SOMETIMES ... the Lon recipe.

Many of our customers, and sometimes the AHJs, don't accept such solutions when speaking about an emergency switch or a life and safety issue emergency shutdown.

I read the original poster's question but did not answer as he didn't provide me enough information. Since there are numerous solutions. Each having their pros and cons.

Certainly your answer would work. But isn't always the right answer.

***BTW, I'm not knocking LON. I do LON, and BacNet, and propriety.

In the matter of safety and emergency items, few of our customers want to be utterly reliant on computer logic, nor wait for the system to respond. And require hardwired trips and "instant" response. For example, on air handlers we have software monitoring high duct pressure, and it'll do a shutdown if necessary. Same with freeze conditions.

However, we also have standard mechanical high duct pressure trips and freeze stats, hardwired so that when safety parameter is exceeded, standard relays drop out signals and trip the safety line on VFDs, or drop out coil on motor starter. And/or power to damper motor power is interrupted and dampers slam shut under spring return. So on and so forth.

And so far, I've yet to see the situation where we were allowed to use a LON network, or BacNet, or whatever for fire related functions. Such can be used to carry information, but not to perform safety functions. (Talking about the area around here, and jobs we've been on.) We've used fire panels that have LON communications in them, for sending info to a front end, out onto a customers intranet, etc. But for purposes of tripping relays and switches, for actual functioning of safety devices, that actually all occurs over standard fire alarm network and fire system rated wiring.

Likewise we've done a fair number of jobs where we provide for emergency buttons in cases of labs, etc. Where if something happens, lab occupant hits the "Panic Button", which then initiates a number of actions. What, depending on installation. For instance, in one case, hitting panic button disrupted (killed) power holding a number of natural gas valves open. Causing them to slam shut under spring power. Standard audible and visual alarm went off (horn and strobe). Return air damper to local air handler (2 of them in series, actually) slammed shut under spring power. A secondary OA duct, ran parallel to main one, sprang open under mechanical power. Our DDC control of VFD driving that particular air handler under normal conditions, was bypassed and VFD switched to bypass, 100% speed. Add, an exhaust fan in that room (served by the alarm) came on full speed and it's damper slammed full open.

It was all done via standard relay logic, plus mechanical spring power. And NO other method was allowable, period.

In the case of a panic button being hit (there were 12 such rooms served by said switches, separate air handlers, etc) we just monitored via the DDC system the events, and reported event to the front end computer, and to 3 other computer locations in the building via the organizations internal lan system. Giving location, and verifying via positive feedback switches, flow switches, etc that all the items did what they were supposed to do. Alarm signal also being passed to local fire department.

Under normal conditions, our DDC controllers control these things. But NOT when that panic switch is struck. It's not allowed by the customer, the AHJ, or by code.

One needs to be careful when answering questions such as that posed by the original poster. I don't recall that he said, precisely, what he meant by an emergency switch.

One also sometimes has to consider other factors. ie On one project I had. Our design engineer insisted on that project that we did not need to add the mechanical high duct pressure safeties. When I first saw that I told him he was nuts. He insisted that it was required in customer specs, salesman hadn't included price in his bid, yadda, yadda, BS.

These units were big. With fire/smokes on return and discharge. Fire/smokes that would be tripped by the fire alarm system. Engineer insisted it'd be adequate that we not only monitored discharge pressure, but that we'd also pick of the fire signal. And controller program could stop the fans in plenty of time.

Uh huh, sure.

Well, those particular controllers we were using on that project scan their inputs once every half second. Add the wait time for the particular section of code in it to start being executed that'll actually do something with the new input. So If fire alarm input goes high just after last scan, figure pretty close to a full second before inut change is noted. (Controller has some inputs that scan more often but he didn't use em), add a bit while code of whole program is being executed. That's to include any "waits" programmer added in. Which are sometimes used, and were in this case. In any event, I timed the durn things myself. I was curious. As set up for that project, averaged about 2 seconds before controller actually acted upon change in that fire input. Add, as we found out, that fire alarm panel system was programmed so that it FIRST went thru process of tripping associated dampers, and firing off audible and visual alarms, THEN it got around to signalling our controllers to tell em that there was a fire alarm condition.

Upshot was we paid to have some ducting repaired/replaced. After which I got the mechanical safeties I'd wanted. Hardwired to trip stuff NOW. VFD got instructions to ramp down a heck of a lot faster, when safety was tripped and it was operating under it's own ramp down instructions. And I reprogrammed our controllers to do a slower ramp down under normal conditions, so VFDs own ramp down rate wouldn't even be a factor. These VFDs only allowed for one ramp down rate, no provision for a second faster or slower rate based upon an emergency or unusual condition. I didn't want VFDs to ramp down, slow the motors, too fast all the time. Not good. Upshot being I managed to tweak in a rapid response, faster ramp down such that while fan motors were still spinning when dampers slammed all the way shut, they'd shed enough speed and flow so that ducting just rumbled as versus rupturing at the seams as it had before.

Chuckle, I know yah like LON. As does SysInt. But yah can't just give the same answer to every question. Sometimes it doesn't fit.

[sysint]

Notifier is a LON system. I'm not talking a gate, I'm talking the system. Firecomm is another. So you rely on it anyway.

Your programmable controller has a logic function. You rely on it anyway.

Most systems now are not purely mechanical.

LON is very good at getting the priority message. Most AHJ's in my area allow the priority shutdown with LON. It all comes down to method. Companies like Circon have the shutdown variable permanently stored so when the signal goes even if power cycles the units stay down.

And response is really fast. I had a job with 40 rooftops and in less than 1 second they were all down. (and you can use a protocol analyzer to check that) AHJ and owner were very impressed.

Anyway, I understand the need for mechanical shutdown at times. However, got to give the LON guys credit for a very solid network design. This is one area that BACnet cannot equal LON as LON is a 7 layer OSI and BACnet is not. Lonboy makes valid claim as compelling as your observations.

Remember that it could be a LON based fire system signalling your mechanical interlocks.

EDIT: It's technology. I'm sure you wouldn't suggest dumping the new modern fire tech with old mechanical based systems...

[Edited by sysint on 04-15-2005 at 10:04 AM]

[osiyo]

[QUOTE]Originally posted by sysint
Notifier is a LON system. I'm not talking a gate, I'm talking the system. Firecomm is another. So you rely on it anyway. [QUOTE]

No, I don't, SysInt.

I presume you don't do a lot of fire alarm systems?

Some Notifier panels do indeed use a LON network for system monitoring, logging, and reporting.

However, from the panel to the detection and initiation devices ... that includes those fire alarm system relays I was speaking of, SysInt ... otherwise known as Initiation devices ... those panels use an SLC network, just as they have for many years. That's those solid core, 14 gage wire pairs yah see the fire system guys installing.

That wire isn't picked at random, either. There is a reason that a minimum of 14 gage is required, and that the insulation is rated as it is. And that is so the stuff can meet NFPA's minimum requirements for physical strenght (not so easily broken or damaged) and for withstanding for the minimum time requirements, exposure to a certain heat level. (I forget the exact spec off the top of my head and really don't feel like looking it up at the moment.)

And the fire panel itself is rated to withstand a certain degree of heat for a certain period of time. Just as it's required to have a minimum amount of battery backup power to allow it to perform it's functions for the required period of time after failure of it's normal power supply.

The LON network (UniNet 2000),and it's not the only one available ... ie there is Noti Fire Net, comes into play for monitoring the panels, or for programming or reprogramming one from a central or remote location.

Yep, yah can get panels from Notifier with LON built in, but it's simply serving the same function as the older RS232 serial or Modbus communications ports. Allowing one to monitor internal points and info inside the panel. Just to retrieve the info, or to query unit and troubleshoot. Or you can, as I said, program the unit or modify it's program.

Typically everything, talking detection and initiation devices, within a particular fire zone, is connected via an SLC to a single fire panel. Is required to be. There can be no reliance on anything outside of the fire zone. So if yah have a really big zone, with lots of devices, you must get a bigger panel which will handle the required number of devices. Or, you use two smaller panels and link them via SLC so that to each of them, the other is an initiation device. ie Panel A and Panel B are linked via SLC. To Panel A, Panel B is an initiation device. And is "fired" just like any other. To Panel B, Panel A is a detection device. Just as if Panel A were a smoke detector. If Panel A fires, Panel B does so also, immediately. And vice versa. Of course, within the internal memory and programming, yah link a description in text to that input on Panel B to tell everyone that the input isn't really a smoke detector, that it's another Panel.

Now, depending on the installation and the jurisdiction (AHJ), plus considering any requirements by the customer or customer's insurance carrier, you might get away with having secondary, non critical initiating devices fired via message sent out over the LON network. Whether yah can or not, is iffy. I've seen where we've asked, since otherwise we'd have to do a lot of extra wire pulling, and permission in one case was granted, in the other it was denied. And the two buildings and installations were identical. BUT ... each was within the jurisdiction of a different Fire Marshall.

Chuckle, the one who denied permission is a real Prick. But, OTOH, I like him. He runs a tight ship and has one of the best records in this state for the fewest bad fires in commercial buildings, fewest cases of failed or faulty equipment, etc.

Your programmable controller has a logic function. You rely on it anyway.

Correct. However a fire panel is built to MUCH stricter standards than are HVAC controllers. Internally, they're more closely related, logic and circuit wise, to industrial PLCs. Modern digital fire panels, all I know of, are all truly multitasking. It's running multiple tasks (subroutines) at the same time. And is optimized in firmware for a simpler, but faster, machine language.

If yah have one of the models which has a built in GUI display, that GUI is being ran on a separate microprocessor, with separate RAM area, etc. And it's fetching info from it's simpler, less cluttered, faster cousin, and wrapping that info in a nice package for display.

But the core chips and memory that actually do the real work, of monitoring inputs and firing outputs, are older, tried and true technology. That's been debugged for years, then packaged in such a way as to be more heat tolerant, more voltage irregularities tolerant, more impact and abuse tolerant, etc than anything in a standard HVAC controller.

And most critical circuits are wired so that they'll fire upon failure. That's why you hear of far more false alarms going off, fire doors slamming shut, machinery halting, etc than you hear about stuff NOT working when it's needed. In the world of commercial fire alarm systems, anyway.


[Quote]Most systems now are not purely mechanical.[QUOTE]

Of course they're not.

[Quote]LON is very good at getting the priority message. Most AHJ's in my area allow the priority shutdown with LON. [QUOTE]
That might well be, SysInt. But I'm not in Wisconsin and have no great desire to live there, or build a business there.

Tell me, just how many of those places where the AHJ allowed this were required to, and managed to get UL Certification?
That term, UL Certification, has a very specific meaning in the world of fire systems and insurance companies who require it. Just using UL certified products is NOT UL Certification.

And, SysInt, I was not ever, at any point referring to whether or not LON worked. This is not the friggin issue. We're speaking about fire and life safety, and NFPA, etc.

What is the fire rating of that LON network cable?

How reliable is it. ie If I go to one of those sites of which you speak and and simulate a fire condition, my stopwatch in hand, will ALL devices in a zone fire off or shut down within a set time interval? Every time? Regardless of how loaded the network is and how many things are going on over it?

Just wondering. Because on one job site we were trying to save some wire pulling. Towards the very end of the project the local fire marshall took exception with a certain sequence of operation. He decided an air handler outside a particular fire zone should come on if not already on upon an alarm in this one zone. His reasoning was to pressurize slightly a critical hallway, to retard the entry of smoke into it for at least a while. In order to give evacuees a bit more time to get out before smoke became too bad. In fact, a smoke generator was rigged and his idea tested. It worked just as he'd thought it would.

Anyway, we'd not planned on this, it wasn't in the plans or specs. So we proposed a network solution. Fire alarm, and which zone was sent out over the BAS network anyway. Because we did do some "non-critical" fire functions within the BAS system. So all we'd have to do is make a slight program change to said air handler to tell it to start up, goto to 50% OA if fire alarm in zone 5 was reported over the network.

Chuckle, no go. Fire Marshall let me add the subroutine. But then demanded I make the whole network as busy as it'd ever, possibly be. (Easy to accomplish via a program it took me 5 minutes to write) Then he broke out his stop watch and initiated the fake fire alarm. Had one of his guys up at the air handler on the radio who gave him a holler when it actually started rolling. 3 tries, it ALMOST met his time requirement once. So we ended up pulling wires.

That was on a LON network, BTW.

And response is really fast. I had a job with 40 rooftops and in less than 1 second they were all down. (and you can use a protocol analyzer to check that) AHJ and owner were very impressed.

Wonderful, glad it worked for yah.

But, SysInt, only a fool uses a protocol analyzer for determining results of such a test. Makes no difference what that protocol analyzer says. In Fire and life safety, the only measure that counts is how fast the machines themselves shutdown, close, open, or startup. As measured against time of initial alarm. Yah don't count network speed alone. From the very instant of the first alarm, til the moment fan starts to wind down or damper starts to shut.

Where did this AHJ get his credentials?

Anyway, I understand the need for mechanical shutdown at times. However, got to give the LON guys credit for a very solid network design.

I never said the LON guys didn't have a decent design.

Snipped the rest as I didn't try to compare LON to BacNet.

[sysint]

Os- We do Fire systems. The Notifier system panel to panel is LON. Check it out.

You typed too much else to get into it further, however, the basic fact is you rely on communication tech in a fire system, not mechanical latching. Period.

...and I understand UL.

EDIT - "Some Notifier panels do indeed use a LON network for system monitoring, logging, and reporting." -Interesting. The BACnetters would say LON isn't good for that.

"How reliable is it. ie If I go to one of those sites of which you speak and and simulate a fire condition, my stopwatch in hand, will ALL devices in a zone fire off or shut down within a set time interval? Every time? Regardless of how loaded the network is and how many things are going on over it? "

YES. And, you don't need that specific 22 ga wire. Just about the same way the signal to apply brakes on a train works. Priority.

[Edited by sysint on 04-15-2005 at 10:20 PM]

[osiyo]

Originally posted by sysint
Os- We do Fire systems. The Notifier system panel to panel is LON. Check it out.

I don't need to check them out, SysInt. I've worked with a ton of em. And, yes, they'll work via LON, panel to panel. Or panel to front end. Or panel to whatever else is on the LON network. I never said otherwise.

I know I type too much, and my English is poor. However, as in a classroom, sit up and pay attention to the details. I stated very SPECIFIC instances, in which the use of LON was not allowed, almost always. ie Two panels in the same zone are not normally going to RELY upon a LON network for critical info. Period. A panel does not use LON to talk to it's devices. Period.

That leaves yah the capability and freedom to use LON any old whichever way yah want to, otherwise.

You typed too much else to get into it further, however, the basic fact is you rely on communication tech in a fire system, not mechanical latching. Period.

Chuckle, depends on which sort of fire system you're speaking about. In certain cases, you're gonna still use mechanical latching, fusible links, etc.

But, on the whole you are quite correct. And I NEVER said otherwise.

What I stated was that that with only a few exceptions, LON (nor BacNet for that matter} was not a suitable means for signaling in a fire system. Specifically referring to input from fire detector going to logic, decision being made, and signal going out to a device to actually perform some fire protection function.

At least, not at this time. Might change later, but I almost never discuss the future since I lost my crystal ball.

There are reasons that Notifier, as well as Silent Knight and Fenwall (I can't speak about others as I don't work with em on any regularity) offer LON for the type of communications I indicated, but do not have detection and action devices on a LON network. Not the critical devices, anyway.

And it has nothing to do with whether or not LON works well, whether or not BacNet might be better, or any of that garbage.

The signal transmission media must be physically robust. ie The reason for a minimum wire size, heat resistance, etc. As of the last time I checked, NFPA and a number of other organizations were VERY leary of the idea that any other devices should be using the same physical network wiring as that used by the detection and action initiating devices on the same loop, within the same fire zone, other than other fire devices serving that area. Add, most modern fire panels use an SLC loop for it's devices under it's immediate monitoring and control ... which also provides the needed power for any devices requiring power. That power originating from electrical main, but also backed up by an independent battery pack for each panel. Number and sizes of batteries selected to handle minimum operating time required by NFPA and local code after normal power has gone out.

The relays I was speaking of, which would interrupt, for instance, the start signal from one of my controllers to an AHU supply fan, are in fact Notifier relay modules. Addressable (are given a network address used by the fire panel) and cycled by the fire panel via the SLC loop.

...and I understand UL.

I said, UL Certification. So as to distinguish that term from simply saying something was UL listed or approved. UL Certification is a quite detailed on site inspection (far more in depth that a Fire Marshall normally does), testing and verification system that is intended to certify that the entire site fire system meets a certain minimum standard. All components and materials, the precise way they're installed, the overall plan and scheme used, actual operation ... which isn't just observed ... parameters are measured, the programming of each panel, the provided documentation given owner, etc and so forth.

UL Certification usually comes into play at the request of the insurance company used by the facility owner. I was once told, long ago forgot, the general paramters for one to be triggered. Hazard classification of the building and it's use, and overall cost of possible loss are used to trigger such an inspection being required.

[sysint]

Again, I understand UL.... enough to know what I don't like about UL. Check under NRTL and you will find UL isn't the end-all be-all. (and damn well shouldn't be)

A Lonworks Fire/Integrated System
LON Smoke Control

Cetelab (recently bought) has LON sensors for detection.

Standards?

My disagreement isn't your knowledge of what you have seen.

Just that I think you don't grasp how robust a LON network actually can be. Facts are that there are companies using LON tech in sensors... not the way we see things here, but it is done... beyond the reach of UL in Europe. Got more... I'll save it for later.

[osiyo]

Originally posted by sysint
Again, I understand UL.... enough to know what I don't like about UL. Check under NRTL and you will find UL isn't the end-all be-all. (and damn well shouldn't be)

I never said it was, SysInt. Would you kindly stop reading into things? In the world of fire safety, referring to the NFPA and the NEC (which is after all just a section of the National Fire Code), UL is listed as simply one of the accepted certifications. There are others.

However, just which ones are found acceptable depends upon the State codes, local municipal codes, and the local AHJ. And if offering up a product for inspection and approval which you might want to use, your repeated mantra chant of "look and see what the Europeans are doing" carries no compelling argument with most people. For good reason. In some things they excel, in others they suck. Just as the same can be said for the USA.

The point being that items used for fire safety, combustible gas safety, and other specialized safety issues where the consequences of failure are dire and deadly, must in most locations in the US meet some very strident testing and certification standards. And carry some label and listing from a "recognized" testing and certification organization verifying it's suitability for the particular use.

In the case of the requirement for UL Certification, which is after all, just a name, the point ... the important part ... was NOT the "UL" name, it's the site certification procedure. Call it the Skunk Certification is you'd rather not hear or see the initials "UL". The point being that it's a detailed review, verification, and testing of the whole system and all it's parts to ensure it's engineered properly, installed right, programmed correctly, uses only suitable materials and components of known and proven design and reliability. And will perform in live testing within specific criteria and parameters of time (speed), reliability and consistant repeatability, and meet requirements of operational duration and fault tolerance.

And that doesn't mean yah can slap on meter and test comm speed and you're good to go.

I can't even believe you offered that up as some sort of proof or evidence of anything significant.

Snipped the URL's as I don't give a rip about Spam or advertisements. Particularly ones which are several years old. I did read them, but as they offered no hard data I can use, I found em useless.

My disagreement isn't your knowledge of what you have seen.

Just that I think you don't grasp how robust a LON network actually can be. Facts are that there are companies using LON tech in sensors... not the way we see things here, but it is done... beyond the reach of UL in Europe. Got more... I'll save it for later.

Did you miss the several times I mentioned I do LON, as well as other systems?

SysInt, in fact many implementations of what are called SLCs, Signalling Line Circuits, are based upon LON. However, I don't call em LON and most folks in the biz don't call em that, either. They're normally called SLC. And that's to avoid confusion as LON based SLC loops use a specialized implementation of LON. Plus, must meet certain other requirements that aren't inherently required in normal LON networks. ie Variable names are kept short, there are extra limitations placed upon number of nodes connected to one loop (to keep down network traffic and bottlenecking}; restrictions to total loop lenghts, and other requirements.

ie The dedicated controller, which must be standalone and able to perform it's functions independently for high hazard situations and critical functions will have two SLC network connections and the comm loop is a true loop. Going out on port A and coming back on port B. The controller sends out a regular, and tightly timed "heartbeat" signal that's listened to by all nodes (devices). If device 5, listening for that heartbeat on it's comm port A doesn't hear it for a specified time period, it opens up contacts on that port. Assuming a fault condition. And shifts to listening on it's port B. Controller, detecting fact that only devices 1 thru 4 seem to be online on it's port A, starts transmitting the heart beat on port B. Which means, hopefully, if the comm line is cut ot broken or whatever somewhere between device 4 and 5, that it can find and monitor devices 5 and beyond on it's port B. If no alarm conditions are being reported, the controller will send out a message; to it's display panel, and to whatever else it's hooked up to over a separate comm channel, which might be LON, BacNet, Modbus, dialout, or whatever; reporting a fault condition exists. And if queried can usually tell yah between where and where.

If yah have a loop with 20 devices, that is cut (becomes open) in two places, you might end up with a situation where the controller can "talk" to devices 1 thru 7 on port A, and devices 12 thru 20 on port B. In which case all yah know is something is happening in between. Fault, fire, whatever. But if your system is designed and laid out well, detectors surrounding the edges of the affected area should soon start blaring away, yelling that you've got serious problems.

And if your installation people did a damned good job, at the central panel, or front end or fire fighter station one should be able to take a quick look see and immediately see the affected area where fire or other problem may exist, and see which areas are as yet clear and safe. On BOTH sides of the inoperable section of the loop.

Durn, man, I'm not trying to get into a bickering argument about whether or not LON is a good thing, whether LON or BacNet is better, etc and so on and endlessly on. And I'm not interested in reading Web sites that only make glorified and exaggerated marketing claims, without any MEAT for me to chew on.

Meat, for me, is hard and proveable numbers, multiple certifications proving items are listed and approved for type of use planned, actual performance and test data, so on and so forth. Which is all that most of those Echelon sites you keep posting here have. Not useful. As they almost never have enough details and specific data to be useful. And making claims that X installation met every possible want and need, present and future, and performed utterly perfectly without any faults or shortfalls whatsoever ... just make me want to put on my hip waders as I figure I'm now wallowing in some really deep BS. I was actually awake during the Business Law class when we learned about and discussed the legal definition of "touting". Now touting may impress the hell out of the clueless. Me, I want hard data.

The very reason that before responding to this thread,that instead of reading marketing hype, I actually pulled up tech data and technical manuals and looked into the matter.

I'm NOT trying to bash yah or slam yah.

But I am maintaining my position. Lonboy's original response that one could simply toss in any old LON devices and network and pass off the info and required commanded actions over that, MAY ... or MAY NOT have been an adequate answer. As I mentioned, impossible to know with no more information than the original poster gave.

What did he mean by "emergency switch". What's the hazard? Is the installation a Class A fire system? What other factors apply?

ie Typically for a Class A Fire system service, one wants a fast response time. Not a fast data transfer time, that alone does not count and is a meaningless number. I know that typical Class A fire and flammable gas safety control panels usually have a rating of less than 0.1 second between detection (or passing a threshold value plus internal delay within a detector)and beginning of response by the action device somewhere else on that loop or another attached to the same controller. Unless a time delay is needed and specified. In truth, I don't know the Code requirements off the top of my head, but do know from reading it on the controllers that this is typical of ones that'll meet the strictest rquirements for hazardous areas and conditions.

This is one of the reasons for the "modified" LON comm system, which is usually called SLC so that it's not mixed up with the general LON spec network folks are usually talking about on this site.

[sysint]

But I am maintaining my position. Lonboy's original response that one could simply toss in any old LON devices and network and pass off the info and required commanded actions over that, MAY ... or MAY NOT have been an adequate answer. As I mentioned, impossible to know with no more information than the original poster gave.....

Agreed. My only points were that (and you invited me in with your first comment) that a LON network is capable and robust enough to run fire; not that you could arbitraily dump detection devices on any LON network and ignore SLC loops and practice for detection and alarm. And also, the reason for this ability is that LON is actually a full 7 layer OSI.