FireNet Community
FIRE SERVICE AND GENERAL FIRE SAFETY TOPICS => Technical Advice => Topic started by: Benzerari on July 19, 2007, 02:32:51 PM
-
Last week a serious event happened in one of our customers sites, it was a genuine fire and the system did not trigger at all, it is an advanced 4000 (I am not blaming advanced system), fortunately there was no substantial damage in live/property, the system was displaying healthy, but when checked through View/Edit, No device was found in the loops. What ever the cause was human error ... of the last engineer who worked on or not..., why should the system not displaying 'No Device Log' instead of system healthy, because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...
Should not be better, to be considered by BS, that first you buy an analogue addressable panel and power it up, instead of showing system healthy, it should show i.e. 'No Device Log' yet, just to make the difference between ‘Panel healthy’ without Device Log in it, and ‘System Healthy’ with the Device Log in it…
I hope I am making sense. ;)
Thank you
M C Benzerari
-
Possible faults are (1) Faulty loop card (although you would assume that the panel would show this I have had a Morley do something similar) (2) System autolearnt with no field devices connected (again,I have seen this done after a modification on the loop but thankfully only the once!).
-
if you power the Advanced panel up and connect the batteries,it will sit happily as normal.
As Buzz mantioned,if you happened to autolearn the panel which was previously up and running,without loop connected,it will again sit as normal.
or the erase all programming may have been used by accident.
-
Yes I do agree this is the way advanced or other analogue addressable panels are designed to show system healthy at the moment, despite that no device are learnt yet, or probably the engineer who dealt with may have done some thing wrong by mistake, either by learning the system without the loops connected as mentioned by Buzz, or the misuse of the program jumper as mentioned by Graim... what ever the reason is... my concern is completely more about the confusion raised from the loss of the program, when the system was still showing healthy despite that no device in the loops, and no one would know about, till the next weekly bell test.
Therefore, may I repeat my question as follows?
Should not be better to be considered by BS5839, that first you buy an analogue addressable panel and power it up, instead of the system displays 'System Healthy', it should show i.e. 'Panel Healthy, No Device Log Yet' with beeping, just to make the difference between ‘Panel healthy’ on its own without 'Devices', and ‘System Healthy’ which means with the 'Device Log' linked to it…
I hope I am making sense about this concern.
Thanks
-
Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.
-
When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)
-
When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)
this is my opinion.
the problem here is not with the equipment, but whoever was working on it before it went tits up.
you chould have checked the event log to see exactly when the devices were learnt off the system, and at the very least when there was last a successful test on it.
if it had been left in that way by an engineer, first off they should be strung up, and second they obviously put the panel in that state for a reason. presumably if the panel did, as you say, register a fault when it had no devices in its programming, the engineer in question would have used a workaround such as wiring a single mcp up inside the panel to keep it clear of fault.
the problem in these cases isn't with the equipment, more with the people responsible for its correct operation.
-
When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)
Yes I agree there is no difference..., conventional system is sharing the same problem with analogue addressable one, if some engineer refits the EOLs of the faulty zones into their terminals at PCB levels, just to hide the faults in the zone circuits and go home early..., the panel will show healthy but the system in fact is NOT. or as you said when you buy brand new conventional panel and power it up it will show healthy too.
Yes I agree there is no thing in contrary to the requirement of BS5839.
However, addressable system is more computer based system, it can be programmed to display what we want it to show i.e. 'Panel Healthy, No Device Yet' and also deliver a beeping fault, this beeping can be cleared out only once the 'Device Log' is uploaded and updated, then lock its memory.
Is that against BS5839?
Thank you
-
i can see where you are coming from but
if you install an a/a panel from scratch then you will know that you have to then autolearn the loops to get from system normal to any double address,open circuit etc faults to show.
Technically if you install a panel,add 240v and battery without autolearn,then the system is normal.
If you are working on an existing system,you need to the knowledge to get into engineer mode to make any alterations wether that be a modification or a erase all programming ,which will prompt you with "are you sure".
I could understand if the panel could be erased in a general user level but you if you require the engineer code to access the level where the programming can be altered then that deems you the competant person.
-
Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.
I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.
Also in that case, I would not call it error any more, if an engineer walks around and turn OFF all of that 'Dill Switches' to delete the program.
The other thing I think it is better to be considered, is that first you by an analogue addressable panel and power it up instead of displaying system healthy it should dislpay a message saying 'Devise Log required' and not 'System Healthy'
As far as I understood a fire alarm system is ( the panel , the cabling and the devices ) when and only when every single element is healthy then the fire alarm system can display 'System Healthy'.
Thanks
-
you could argue that the first thing you should do is check the control panel is not faulty.
that means power up on mains and battery with nothing else connected.and in the case of non addressable-with all eol's in the panel terminals.
if panel shows fault,then you know that the control panel is the cause.
-
Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.
I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.
Thanks
So your going to autolearn a fully loaded 4 loop system then go round every head tripping a dil switch ? I don't really see the point of that.
The control panels check the actual devices fitted against the map stored in memory... if it changes a fault is recorded. Kentecs show an "unexpected device" if a detector is added and not programmed on... other systems I know don't do this and devices can sit on a loop doing nothing till programmed on. This is wrong.
The scenario here is that the engineer must have autolearned the panel with no devices present... or didn't check any analogue values after auto learning or whatever.... Sounds like "engineer" error to me.
-
Agreed - there should be some sort of "check bit" on the device that lets the panel know that it is on the loop but not configured into the system for operation.
I think you have raised a great idea Buzz, to set a double security against losing the program, if all devices have an extra sort of 'Dill Switch' to be turned ON once learnt, in which the device can not be deleted from the panel by program either deliberately or by error, till you turn OFF the 'Dill Switch' of that device, and it would be simillar if the whole program is lost, a fault would be generated with a beeping, requiring an upload back of the program.
Thanks
So your going to autolearn a fully loaded 4 loop system then go round every head tripping a dil switch ? I don't really see the point of that.
The control panels check the actual devices fitted against the map stored in memory... if it changes a fault is recorded. Kentecs show an "unexpected device" if a detector is added and not programmed on... other systems I know don't do this and devices can sit on a loop doing nothing till programmed on. This is wrong.
The scenario here is that the engineer must have auto learned the panel with no devices present... or didn't check any analogue values after auto learning or whatever.... Sounds like "engineer" error to me.
Yes I totally agree about this bit, the engineer must be well trained and if he does any mistakes he has to pay the price for any bad incident that could happen, the idea is to minimise the loss of program in very short time (few seconds) through a misdealing with programming stuff, more particularly when it happen by error,. In other words is to BLOCK the human error that could cause the program to be lost while the system still displays 'System Healthy'. It is just extra security measures.
Once the device is learnt it holds its place in the configuration by turning its 'Dil Switch' ON, and to delete that device from the panel either by error or deliberately it prompts you to the message 'Device Locked', that 'Dill Switch when turned OFF it sends back a permission signal to the panel to delete the device and like that it would take longer time to delete the whole 'Device Log' even on purpose or by error, this expansion in time when deleting 'Device Log' may give more time to who ever is dealing with the programming to be reminded each time he delete or lose a device from the configuration. and when losing the whole 'Device Log' by error the panel would display 'Device Log required' with Yellow LED ON and a beeping. Which can not be cleared out, till
1. All ‘Dil Switches’ turned OFF if deleting them on propose. or
2. Upload back the 'Device Log'.
AND JUST NOT THE PANEL DISPALYS ' SYSTEM HEALTHY'
The only disadvantage of this is the time consuming and cost of the commissioning, also a little change in the protocol of comunication and the hardware of both (Device and panel) . A part from that it is just double security measures.
Am I making sense?
-
Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.
Rely on competent engineers instead of pointless safeguards like dil switches! If you really feel the need for a double safeguard, why not see if a panel manufacturer could incorporate something like "System Healthy - 87 devices active" into their display??? See what sort of response you get?
-
Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.
Rely on competent engineers instead of pointless safeguards like dil switches! If you really feel the need for a double safeguard, why not see if a panel manufacturer could incorporate something like "System Healthy - 87 devices active" into their display??? See what sort of response you get?
The loss of the program can be caused by many ways: competent engineer who missed out some thing by error, earth fault which can corrupt the data, loop card failed, using the internal reset button while the memory is open, and many others depending upon the makes...
Do you see it normal that a panel not programmed at all, WIHTOUT 'Device Log' displays 'System Healthy', and programmed WITH certain number of 'Device Log' displays the same message 'System Healthy' too? You may say, so what? What is wrong?
However, it was just the incident stated in the first thread of this topic that has led me to think about this double security, and I believe every single engineer have seen such incident at least once in his entire work experience. A loss of the program while the panel still displaying ‘System Healthy’ and the worse thing is that no one would know about till the next weekly bell test or service…
I think, it has to be made some sort of difference between 'Panel Healthy' on its own and 'System Healthy' with the devices and the cabling? The ‘Dil Switch’ method is not the only way to double secure the program…
It could be programmed a warning message that appears say each 10mn to remind who ever the user of the system… the message could be i.e. ‘Panel Healthy, Device Log Required’ but just not ‘System Healthy’ for ever, where there is no ‘Device Log’…;)
-
Did the customer carry out his weekly tests?
-
Did the customer carry out his weekly tests?
yes
-
Did the customer carry out his weekly tests?
yes
how did the problem not get shown up then?
-
Did the customer carry out his weekly tests?
yes
how did the problem not get shown up then?
Regarding the incident stated in the first thread of this topic, a genuine fire happened before the next due bell test, and that is the heart of the problem. If no fire occurred at all during the 2-3 days left, the loss of the program would be noticed during the next due bell test, and that is fairly clear.
Between day and night any thing could happen, isn't it?
Also if the on site responsible noticed a message saying 'Device Log Required' with a beeping, he would have called the engineer, would he? But unfortunately the panel was displaying ‘System Healthy’ and that is the worse thing.
-
"The loss of the program can be caused by many ways: competent engineer who missed out some thing by error, earth fault which can corrupt the data, loop card failed, using the internal reset button while the memory is open, and many others depending upon the makes..."
All the above will be noticed either by fault warning or by proper testing after work being carried out.
I can see where you are coming from, but I think you are going too far.
In this case had the weekly tests actually been carried out?
Regards
John.
-
"The loss of the program can be caused by many ways: competent engineer who missed out some thing by error, earth fault which can corrupt the data, loop card failed, using the internal reset button while the memory is open, and many others depending upon the makes..."
All the above will be noticed either by fault warning or by proper testing after work being carried out.
I can see where you are coming from, but I think you are going too far.
In this case had the weekly tests actually been carried out?
Regards
John.
Yes the incident happened between two successful weekly bell tests, and we still doing our weekly bell test too on behalf of the customer, the investigation is now going on by checking the 'Event Log' to find out the last minutes the 'Device Log' was in the panel and what caused the program to be lost. Also, I agree it could be the last engineer's error ... and in that case he should be hanged up if you want...:O. But
My concern is more about, BLOCKING OFF the way to any sort of mistakes that could cause such incident; the program was lost while the system still displaying 'Systems Healthy', it is just further future measures, and it is not really IMPOSSIBLE to find out a cost affective way to double secure the program from being lost without any warning message left.:)
I am aiming to set a warning message in the panel saying i.e. 'Panel Healthy, Device Log Required' with a beeping, in which the message would not be cleared out without uploading back the 'Device Log' I do not think I am going that far...if it is for safety reason
Thanks
-
When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)
this is my opinion.
the problem here is not with the equipment, but whoever was working on it before it went tits up.
you chould have checked the event log to see exactly when the devices were learnt off the system, and at the very least when there was last a successful test on it.
if it had been left in that way by an engineer, first off they should be strung up, and second they obviously put the panel in that state for a reason. presumably if the panel did, as you say, register a fault when it had no devices in its programming, the engineer in question would have used a workaround such as wiring a single mcp up inside the panel to keep it clear of fault.
the problem in these cases isn't with the equipment, more with the people responsible for its correct operation.
I would string him up to. He must be the most useless engineer on the planet. i would sacked him in an instant.:
-
When you buy a conventional panel, most have eol devices fitted in the panel, therefore someone could install this panel without connecting any ancillaries to it?
There is no difference between this and what you are saying about an analogue addressable panel.
Whoever installs either type must be competent to do so, and must properly test it!
It is all too common to see poorly designed/installed/tested equipment, usually by electricians who buy the cheapest kit from a wholesaler. (apologies in advance to the minority of sparkies who do a good job!!!)
this is my opinion.
the problem here is not with the equipment, but whoever was working on it before it went tits up.
you chould have checked the event log to see exactly when the devices were learnt off the system, and at the very least when there was last a successful test on it.
if it had been left in that way by an engineer, first off they should be strung up, and second they obviously put the panel in that state for a reason. presumably if the panel did, as you say, register a fault when it had no devices in its programming, the engineer in question would have used a workaround such as wiring a single mcp up inside the panel to keep it clear of fault.
the problem in these cases isn't with the equipment, more with the people responsible for its correct operation.
I would string him up to. He must be the most useless engineer on the planet. i would sacked him in an instant.:
Due to employment laws you probably couldn't sack him. Only if you could prove that the engineer had been provided with sufficient training and the proper tools to carry out the task you asked him to AND the full written Company disciplinary procedure had been strictly adhered to, could you even begin to consider taking any action without facing an employment tribunal!
Customers who expect Companies to have employees that don't make any mistakes because they would otherwise face instant dismissal have no idea of the 'real world' !!!!
-
Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.
?
not if it was the kind of weekly test i come across all the time.The user pressing the evacuate button every week for 5 seconds.
I was at a site today trying to persuade the end user to not use the evacuate button but a mcp every week in rotation.
He was not having it,even when i found half a floor not working during testing,which would have showed if he had been doing proper tests.
This half has not been working for years seemingly...
-
Just as much to the point, was the customer carrying out his weekly tests? If so, then the problem would have become evident instead of becoming evident in the event of a real fire.
?
Not if it was the kind of weekly test i come across all the time. The user pressing the evacuate button every week for 5 seconds.
I was at a site today trying to persuade the end user to not use the evacuate button but a MCP every week in rotation.
He was not having it, even when I found half a floor not working during testing, which would have showed if he had been doing proper tests.
This half has not been working for years seemingly...
Was the panel showing healthy in that site, despite that half of the floor was out of system, And if yes, would the last service engineer be hanged up? :O Or
Would conventional system design be better reviewed too, to BLOCK OFF all that sort of mistakes that could occur? :)
Benzerari
-
an old never maintained system which has been added to and altered by numerous "fire is a doddle" sparkies.
The area in question turned out to be a spur off a zone which had been cut out when rewiring as it would have not registered on the sparks inductance tester when he was ripping out old cables.
The sounders also had three additional end of lines with no resistors-again spurred of the sounder circuit.
I laugh when i hear the famous words "fire is easy" as it guarantees that person is not doing it correctly.
-
Just a little note. If the engineer re-learnt the loop with nothing connected he must have shorted pos to pos and neg to neg in the loop connections or he would have had open circuit faults. I know with some panels you can switch off open loop polling or allocate it out, but me thinks not on an advanced elctronics panel. As Benzerari said "because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...". If you work it out logically its very hard to be a complete donut on open protocol panels. Wrong text, wrong zone, (sounders left disabled) for most and poor cause and effect for the rest. That in my opinon is human error on plug and play systems. Its the details that get you in the end.
-
Just a little note. If the engineer re-learnt the loop with nothing connected he must have shorted pos to pos and neg to neg in the loop connections or he would have had open circuit faults. I know with some panels you can switch off open loop polling or allocate it out, but me thinks not on an advanced elctronics panel. As Benzerari said "because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...". If you work it out logically its very hard to be a complete donut on open protocol panels. Wrong text, wrong zone, (sounders left disabled) for most and poor cause and effect for the rest. That in my opinon is human error on plug and play systems. Its the details that get you in the end.
Salut
'Oui, justement nule n'est parfait, a part le bon Dieu'
Analogue addressable system's 'DESIGN' as it is actually, either of open or closed protocol’s systems, is not really the final concept for ever. It must be some sort of updates some times in the standards... and then the technology provides its bests and latest... TO BLOCK OFF THE HUMAN ERRORS FROM HAPPENING…, it is NOT necessary the means of CORRECTING the previous, but probably COMPLETING what might be missing...
What is relatively perfect today may NOT be by next year...
This is just my opinion
:)
-
Another system losts its program, this time is a ZETFAS analogue addressable system of ZETLER, no one touch it, when checked in side its main Control Unit which has a size of a normal door (1m * 2m), we found that one of the loop card definitely failed and probably other things too, the display shows 'Control panel in programming mode' without beeping just processor fault yellow LED illuminated.
This system is designed to show this message if there is no program uploaded yet!
Has any one else ever seen such things?
Thank you
-
Last week a serious event happened in one of our customers sites, it was a genuine fire and the system did not trigger at all, it is an advanced 4000 (I am not blaming advanced system), fortunately there was no substantial damage in live/property, the system was displaying healthy, but when checked through View/Edit, No device was found in the loops. What ever the cause was human error ... of the last engineer who worked on or not..., why should the system not displaying 'No Device Log' instead of system healthy, because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...
Should not be better, to be considered by BS, that first you buy an analogue addressable panel and power it up, instead of showing system healthy, it should show i.e. 'No Device Log' yet, just to make the difference between ‘Panel healthy’ without Device Log in it, and ‘System Healthy’ with the Device Log in it…
I hope I am making sense. ;)
Thank you
M C Benzerari
hey Benz
i was working on a panel today that jogged my memory about your question.
If you wipe the memory all the devices on the loop will all show up as disablements until autolearned.
Aritech panel.
-
Last week a serious event happened in one of our customers sites, it was a genuine fire and the system did not trigger at all, it is an advanced 4000 (I am not blaming advanced system), fortunately there was no substantial damage in live/property, the system was displaying healthy, but when checked through View/Edit, No device was found in the loops. What ever the cause was human error ... of the last engineer who worked on or not..., why should the system not displaying 'No Device Log' instead of system healthy, because the panel was healthy with itself without the rest of device. I mean not the whole fire alarm system was healthy...
Should not be better, to be considered by BS, that first you buy an analogue addressable panel and power it up, instead of showing system healthy, it should show i.e. 'No Device Log' yet, just to make the difference between ‘Panel healthy’ without Device Log in it, and ‘System Healthy’ with the Device Log in it…
I hope I am making sense. ;)
Thank you
M C Benzerari
hey Benz
i was working on a panel today that jogged my memory about your question.
If you wipe the memory all the devices on the loop will all show up as disablements until autolearned.
Aritech panel.
Grame;
What do you mean by wipe the memory? is that flashing it? If yes where the disablement message is stored to be shown on the display then? that's new to me! it must be based on a different architecture, and it must be two seperate memories in the main PCB then, one of them is used as back-up or recovery memory, this just my guessing!
Even Aritech is new to me too, I would like to see its guides if possible, this has made me currios...?
Thanks Grame
-
if you erased the memory or auto-learned a loop with nothing connected(and then reconnected) the panel knows that all the devices are there but logs them as all disabled until the loop is auto-learned again.
so if you had 70 devices on the loop,the panel would show 70 conditions. A disablement on this panel is a condition.
-
if you erased the memory or auto-learned a loop with nothing connected(and then reconnected) the panel knows that all the devices are there but logs them as all disabled until the loop is auto-learned again.
so if you had 70 devices on the loop,the panel would show 70 conditions. A disablement on this panel is a condition.
What makes the panel then to keep remembering them in its memory if they are back connected if its memory is totally erased?
It must be a second recovery memory in which when the panel's software scan the loop then compare it against the previously recorded in the recovery memory... therefore the panels report them as disabled or isolated till logged back on...
If you have got any guides of this system that would be appreciated
Thanks Grame
-
it's not memory.The panel knows if you install another device on the loop but do not autolearn.
so say you installed an additional optical,the panel see the detector but this detector will not do anything until you tell the panel to enable it or autolearn the loop.
-
it's not memory.The panel knows if you install another device on the loop but do not autolearn.
so say you installed an additional optical,the panel see the detector but this detector will not do anything until you tell the panel to enable it or autolearn the loop.
This feature does exist with Notifire or Kentek if my memory still intact, not like Morley or advanced they do not see devices which are connected in the loop but not learned yet...
-
it's not memory.The panel knows if you install another device on the loop but do not autolearn.
so say you installed an additional optical,the panel see the detector but this detector will not do anything until you tell the panel to enable it or autolearn the loop.
This feature does exist with Notifire or Kentek if my memory still intact, not like Morley or advanced they do not see devices which are connected in the loop but not learned yet...
If you programme a new detector with an address that is not already used on the system, then it depends if the particular panel operating system looks for all addresses or only those addresses that it has been told should be connected. Looking for addresses that shouldn't be there wastes vital time if carried out on every loop scan, so many panels normally interogate only those addresses it is expecting (programmed) to see on most loop scans and then every so often interogates every possible address and if it then sees one it wasn't expecting (programmed) to see, it will fault as something like 'additional device detected'
-
it's not memory.The panel knows if you install another device on the loop but do not autolearn.
so say you installed an additional optical,the panel see the detector but this detector will not do anything until you tell the panel to enable it or autolearn the loop.
This feature does exist with Notifire or Kentek if my memory still intact, not like Morley or advanced they do not see devices which are connected in the loop but not learned yet...
If you programme a new detector with an address that is not already used on the system, then it depends if the particular panel operating system looks for all addresses or only those addresses that it has been told should be connected. Looking for addresses that shouldn't be there wastes vital time if carried out on every loop scan, so many panels normally interogate only those addresses it is expecting (programmed) to see on most loop scans and then every so often interogates every possible address and if it then sees one it wasn't expecting (programmed) to see, it will fault as something like 'additional device detected'
How long is that waste of vital time? if it's hours that would make sense but if it's just few mili seconds that would still beneficial I think!
The other issue is it because of that waste of that vital times the BS5839 did not sets this issue as an obligation for panel manufacturers to look even for none logged on devices?
I need to know the position of BS too
Thank you
-
This feature does exist with Notifire or Kentek if my memory still intact, not like Morley or advanced they do not see devices which are connected in the loop but not learned yet...
If you programme a new detector with an address that is not already used on the system, then it depends if the particular panel operating system looks for all addresses or only those addresses that it has been told should be connected. Looking for addresses that shouldn't be there wastes vital time if carried out on every loop scan, so many panels normally interogate only those addresses it is expecting (programmed) to see on most loop scans and then every so often interogates every possible address and if it then sees one it wasn't expecting (programmed) to see, it will fault as something like 'additional device detected'
How long is that waste of vital time? if it's hours that would make sense but if it's just few mili seconds that would still beneficial I think!
The other issue is it because of that waste of that vital times the BS5839 did not sets this issue as an obligation for panel manufacturers to look even for none logged on devices?
I need to know the position of BS too
Thank you
If scanning for 'unused addresses' was an obligation in BS/EN then all control panel manufacturers would do so as a matter of course. Otherwise they couldn't say that their panels complied with the standards. It is obviously not required in the standards.
Even wasted milliseconds are critical in addressable systems.
The scanning process invariably includes re-checking some information received back a number of times to ensure it is not being corrupted by outside interference. This increases the loop 'scan' time.
If you can't understand why milliseconds must be critical, have you never noticed how it can sometimes take some seconds for the 'operated' LED on a MCP using XP95 protocol to illuminate after the glass is broken? Because the control panel is trying to deal with other 'time-critical' processes, it doesn't prioritise this as an urgent function. However, BS asks for the alarm warning devices to operate within a specific time limit after the actual operation of a MCP, and actioning this process is more important than turning on the LED.
I'm sure that improvements in microprocessor speeds will eventually lead to the ability to check all addresses on all loops, re-check information received a number of times, and operate all other functions, in a blink of an eye. It may also lead to protocols allowing more than approx. 126 devices on one circuit to become more common.
Speak to panel manufacturers about this and you will realise how critical 'wasted' time in scanning 'unused' addresses can be for them.
-
I will do;
High speed microcontrolers or microprocessors may be beneficial in this issue, or dual core microprocessors would be ideal, to deal with more advanced features too!
How ever I still see that it is more beneficial for the fire alarm software to detect none logged on devices if they are in the loop...