FireNet Community
FIRE SERVICE AND GENERAL FIRE SAFETY TOPICS => Technical Advice => Topic started by: Benzerari on September 13, 2008, 01:34:54 AM
-
Hi Guys:
It seems I am late to know about the Apollo Discovery detectors, if there is a lost of protocol in the loop (lost of configuration), by means no analogue values ... etc, the device will switch to a simple conventional detector, so when detecting conventional alarm threshold, it triggers an alarm and the panel would display alarm in the loop in question, without any further details due to the protocol is been lost...
Also, both discovery detector and the panel together, make the decision of whether alarm condition should take place or not… etc
Have some one tried to trriger a discovery detector prior i.e. of loop auto learning, and fire condition took place?
I will try that soon :)
It’s really amasing if it practically works!
-
It switches to conventional should the control panel develop a processor fault so i would imagine that if the panel has no FEP to make the decision then the head will.
-
In my understanding, Discovery is not only better sensitive to genuine fires and less prone to false alarms. bIt's even, more safe in case of lost of configuration for what so ever reasons, why don't we stop using XP95 and stick into Discovery as long as the price is not of big difference ?
-
In my understanding, Discovery is not only better sensitive to genuine fires and less prone to false alarms. bIt's even, more safe in case of lost of configuration for what so ever reasons, why don't we stop using XP95 and stick into Discovery as long as the price is not of big difference ?
Older systems can't take them.
-
In my understanding, Discovery is not only better sensitive to genuine fires and less prone to false alarms. bIt's even, more safe in case of lost of configuration for what so ever reasons, why don't we stop using XP95 and stick into Discovery as long as the price is not of big difference ?
Older systems can't take them.
Indeed, have already tried that with old morley, it did like discovery...
-
In my understanding, Discovery is not only better sensitive to genuine fires and less prone to false alarms. bIt's even, more safe in case of lost of configuration for what so ever reasons, why don't we stop using XP95 and stick into Discovery as long as the price is not of big difference ?
it is if you are pricing a large install.
-
Be careful here, the Discovery detectors have the facility to signal an alarm if no protocol is present, however I don't believe any panels have the ability to pick up the alarm pulses generated. Basically what happens is if the protocol stops for any reason the Discovery detector has the ability to still signal an alarm. It does this by sending these alarm pulses, however a panel would require additional hardware to pick these pulses up.
I'm also wondering how likely it is for the panel processor to fail without the whole panel breaking down, in which case would there be any DC on the line to run the devices in the first place?
-
Be careful here, the Discovery detectors have the facility to signal an alarm if no protocol is present, however I don't believe any panels have the ability to pick up the alarm pulses generated. Basically what happens is if the protocol stops for any reason the Discovery detector has the ability to still signal an alarm. It does this by sending these alarm pulses, however a panel would require additional hardware to pick these pulses up.
I'm also wondering how likely it is for the panel processor to fail without the whole panel breaking down, in which case would there be any DC on the line to run the devices in the first place?
If the protocol signal is lost, this shouldn't affect normally the DC value of 24Vdc, because in fact the protocol digital signal is a succession of 0s and 1s of 5Vdc amplitude above the DC feed (24Vdc).
-
but they are both sent on the same wires. If the protocol pulses disappear it is likely the reason for that is the voltage has dropped to zero. The 5 volt pulses are on top of the 24v used to power the devices.
-
but they are both sent on the same wires. If the protocol pulses disappear it is likely the reason for that is the voltage has dropped to zero. The 5 volt pulses are on top of the 24v used to power the devices.
NO, not necessary, lost of protocol doesn't mean necessary drop of voltage in the normal DC feed (24Vdc)
the only way to cut the 24Vdc is by a minimum of two open circuits in the loop, means part of the loop circuit is lost :)
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Imagine you have just about to commission analogue addressable system, but not yet! all the second fix are done, there is no protocol yet, as long as there is no configuration yet, no autolearning yet, the loop should still have 24Vdc shouldn't it?
The same thing will happen if causing an internal reset by error...etc, you will lose the protocol but not the feed of 24Vdc. and then the system needs to be reconfigured or recommissioned...
The loop card faillure, is not the only way to loose the protocol :)
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Have to agree.
I've been in the business over 20 years and i can't recall losing a loop simply because it had lost the means to communicate - maybe we just never came across the right panels...!
Personally I think a lot of the discovery features are just "gimmicky" and an excuse to charge more money..... When they first brought them out the heads had a lot of problems, and more recently a job just over two years old (installed by Siemens funny enough!) in a computer room we look after, aproximately 50 or so heads, there is a pile of 10 detectors left on the panel that have been swapped out so far....
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Have to agree.
I've been in the business over 20 years and i can't recall losing a loop simply because it had lost the means to communicate - maybe we just never came across the right panels...!
Personally I think a lot of the discovery features are just "gimmicky" and an excuse to charge more money..... When they first brought them out the heads had a lot of problems, and more recently a job just over two years old (installed by Siemens funny enough!) in a computer room we look after, aproximately 50 or so heads, there is a pile of 10 detectors left on the panel that have been swapped out so far....
Dave:
This is one opinion among many, the discovery features is a bit advanced than the XP95 ones, and the majority of analogue addressable panels are designed to support the XP95 protocol but not necessary the extended one of discovery, even the protocol's basis is the same...etc
However, my guess is that the timers of analogue adderssable systems compatible to XP95 and discovery are not the same, which means; if analogue addressable system is designed to support XP95, its data transfer in each conversation wouldn't be completed to swap over the comunication, if using Discovery...,and threrefore this may cause some data to be lost...ect
Therefore If analogue addessable systems are designed to support Discovery extended protocol that would be grate.
Also this is one opnion among many :)
-
So how long has Discovery been on the market and how many panels support the full extended protocol and how many manufacturers intend to support the full extended protocol ??
-
So how long has Discovery been on the market and how many panels support the full extended protocol and how many manufacturers intend to support the full extended protocol ??
This is actually very good question, I personally would like to know the answer :)
I am still impressed by the fact that, Discovery has the option to make analogue addressable system behaving as a conventional system (according to the catalogue of discovery).
However, say i.e. the first time analogue is fitted and powered up, the loops behave as zones, till the system is configured and commissioned properly, then it becomes a true analogue addressable system. This option I think is very beneficial, in case of lost of configuration (lost of protocol), thus the system still trigger any way in case of a genuine fire.
I haven’t tried it myself up till now, but will try to prove this option, with the latest manufactured Apollo compatible system, in due time.
Usually, none configured detectors are sitting in the loop and the panel would not see them, till the loop is auto-learned or scanned, then the protocol start to take place, but with this new option of discovery which is still doggie with old analogue addressable systems, it will give further security to the new compatible systems.
-
Wozzer is right. The facility of Discovery to deal with the loss of the protocol and still initiate a fire signal is down to a circuitry that monitors that the device is receiving protocol pulses and if it sees none for 180 seconds it can generate it's own series of special pulses, on sensing a fire condition, which panels which have extra circuitry to detect these special pulses can respond to. I understand that apart from a couple of special panels specifically designed for the 'marine' market there are no UK panels that use this facility i.e most UK panelsdon't have the circuitry to deal with the special pulses, so the 'benefit' of it has no real use in the UK at present.
The liklihood of a panel processor failing and still having the normal loop voltage available is very possible. The processor will control the protocol pulses but is unlikely to control the loop power requirements.
Discovery protocol is just an extended version of the XP95 protocol (extra bits of information) and has been around for years, and most control panel manufacturers have models that support it.
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Imagine you have just about to commission analogue addressable system, but not yet! all the second fix are done, there is no protocol yet, as long as there is no configuration yet, no autolearning yet, the loop should still have 24Vdc shouldn't it?
The same thing will happen if causing an internal reset by error...etc, you will lose the protocol but not the feed of 24Vdc. and then the system needs to be reconfigured or recommissioned...
The loop card faillure, is not the only way to loose the protocol :)
From my conversations with Apollo the protocol is always present as soon as the loop is wired even before you have 'learnt' the system. I asked them about this 'Conventional alarm mode' and it is really just a method they put in to comply with a standard that wasn't released until later. It was put in to cope with possible processor failure. The standards dealt with it anyway by saying that 'no more than 514 devices should be lost due to processor fault'. The panel manufacturers dealt with this by designing panels that had processors supporting no more than 514 devices. So the detector feature wasn't used by most.
-
Discovery protocol is just an extended version of the XP95 protocol (extra bits of information) and has been around for years, and most control panel manufacturers have models that support it.
Yes they support Discovery Protocol (generally) but this specific element of panels recognising a signal from a detector when comms has been lost I would say isn't supported by anybody (ducks and waits for the deluge of "oh yes they do abuse) !!
Just spoke to Kentec and they've never heard of it....!!!
-
Wozzer is right. The facility of Discovery to deal with the loss of the protocol and still initiate a fire signal is down to a circuitry that monitors that the device is receiving protocol pulses and if it sees none for 180 seconds it can generate it's own series of special pulses, on sensing a fire condition, which panels which have extra circuitry to detect these special pulses can respond to. I understand that apart from a couple of special panels specifically designed for the 'marine' market there are no UK panels that use this facility i.e most UK panelsdon't have the circuitry to deal with the special pulses, so the 'benefit' of it has no real use in the UK at present.
The liklihood of a panel processor failing and still having the normal loop voltage available is very possible. The processor will control the protocol pulses but is unlikely to control the loop power requirements.
Discovery protocol is just an extended version of the XP95 protocol (extra bits of information) and has been around for years, and most control panel manufacturers have models that support it.
Wiz;
In my understanding, there is no need for extra circuitry for the panel side to make a discovery trigger as a conventional detector in case of lost of protocol, the processor can monitor the impedance at the loop in both ways, if it sees drop of impedance to a level say i.e. 470Ohms, it trigger an alarm signal...etc
This can be done by software rather then additional hardware, by incorporating a simple If statement algorithm...
If (presence of protocol) then
Statement 1: Device behave as analogue addressable device
Else
Statement 2: Device behave as conventional device
End If
Statement 1: can take place as long as the processor is receiving analogue values from all devices in the loop.
Statement 2: takes place if not receiving any analogue value.
Now, the major concern is that, would this algorithm works for each device separately or only when the whole protocol is lost, by means a 'Partial loss' ( device no reply ) or 'General loss' ( no reply from all devices ), this is actually down to the programming to setup either way...etc
However do the existing manufactured panels have such algorithm incorporated, the answer is: I don't know! :)
This is down to substantial evidence…etc. :)
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Imagine you have just about to commission analogue addressable system, but not yet! all the second fix are done, there is no protocol yet, as long as there is no configuration yet, no autolearning yet, the loop should still have 24Vdc shouldn't it?
The same thing will happen if causing an internal reset by error...etc, you will lose the protocol but not the feed of 24Vdc. and then the system needs to be reconfigured or recommissioned...
The loop card faillure, is not the only way to loose the protocol :)
From my conversations with Apollo the protocol is always present as soon as the loop is wired even before you have 'learnt' the system. I asked them about this 'Conventional alarm mode' and it is really just a method they put in to comply with a standard that wasn't released until later. It was put in to cope with possible processor failure. The standards dealt with it anyway by saying that 'no more than 514 devices should be lost due to processor fault'. The panel manufacturers dealt with this by designing panels that had processors supporting no more than 514 devices. So the detector feature wasn't used by most.
Wozzer;
We are talking about the same thing but interpreted differently, the protocol is the language or the conversation between the panel and its devices, and it is initially considered as program in memory…etc, as a program it is in there even before you power up the panel or the panel is still brand new on the shelves or is packaged…etc.
But the protocol as conversation and language on the loop there is no protocol in the loop before you auto learn the loop, by means there is no conversation between the panel and its devices before auto learning the loop, the panel doesn’t know either if the devices are in the loop, so how can he talk to them?
Except very few makes they scan periodically the loop them selves and thus the panel in that case can know straight away there is a device that need to be configured (enter its location text…).
This is my understanding if I am wrong please feel free to correct me :)
Regarding the answer of Apollo, it is very interesting to hear that the option was added just in case of processor failure according to what they said, through your post. And in that case an additional electronics circuitry will be a must within the panel to behave as conventional, as the processor wouldn't be able to monitor the impedance of the loop...etc :)
-
All im saying is it isn't likely that you will lose protocol if you have not already lost the whole loop card. i.e. the liklihood of losing the protocol alone is small.
Imagine you have just about to commission analogue addressable system, but not yet! all the second fix are done, there is no protocol yet, as long as there is no configuration yet, no autolearning yet, the loop should still have 24Vdc shouldn't it?
The same thing will happen if causing an internal reset by error...etc, you will lose the protocol but not the feed of 24Vdc. and then the system needs to be reconfigured or recommissioned...
The loop card faillure, is not the only way to loose the protocol :)
From my conversations with Apollo the protocol is always present as soon as the loop is wired even before you have 'learnt' the system. I asked them about this 'Conventional alarm mode' and it is really just a method they put in to comply with a standard that wasn't released until later. It was put in to cope with possible processor failure. The standards dealt with it anyway by saying that 'no more than 514 devices should be lost due to processor fault'. The panel manufacturers dealt with this by designing panels that had processors supporting no more than 514 devices. So the detector feature wasn't used by most.
Basically spot on Wozzer but I think you'll find the figure for the maximum amount of devices that can handled by a single microprocessor is 512 ;)
-
Imagine you have just about to commission analogue addressable system, but not yet! all the second fix are done, there is no protocol yet, as long as there is no configuration yet, no autolearning yet, the loop should still have 24Vdc shouldn't it?
The same thing will happen if causing an internal reset by error...etc, you will lose the protocol but not the feed of 24Vdc. and then the system needs to be reconfigured or recommissioned...
The loop card faillure, is not the only way to loose the protocol :)
From my conversations with Apollo the protocol is always present as soon as the loop is wired even before you have 'learnt' the system. I asked them about this 'Conventional alarm mode' and it is really just a method they put in to comply with a standard that wasn't released until later. It was put in to cope with possible processor failure. The standards dealt with it anyway by saying that 'no more than 514 devices should be lost due to processor fault'. The panel manufacturers dealt with this by designing panels that had processors supporting no more than 514 devices. So the detector feature wasn't used by most.
Wozzer;
We are talking about the same thing but interpreted differently, the protocol is the language or the conversation between the panel and its devices, and it is initially considered as program in memory…etc, as a program it is in there even before you power up the panel or the panel is still brand new on the shelves or is packaged…etc.
But the protocol as conversation and language on the loop there is no protocol in the loop before you auto learn the loop, by means there is no conversation between the panel and its devices before auto learning the loop, the panel doesn’t know either if the devices are in the loop, so how can he talk to them?
Except very few makes they scan periodically the loop them selves and thus the panel in that case can know straight away there is a device that need to be configured (enter its location text…).
This is my understanding if I am wrong please feel free to correct me :)
Regarding the answer of Apollo, it is very interesting to hear that the option was added just in case of processor failure according to what they said, through your post. And in that case an additional electronics circuitry will be must within the panel to behave as conventional, as the processor wouldn't be able to monitor the impedance of the loop...etc :)
Benz, believe me there is protocol on the loop as soon as it is powered up!! If you put an oscilloscope on the loop you will see it, before you do a loop learn etc. I had an indepth session with Andy Haynes at Apollo and I know a fair bit about protocol.
Extra circuitry would be required to pick up the alarm pulses as Wiz and Dave R have described and NONE of the UK panel manufacturers have included this extra hardware.
-
Doh 512......thats what i meant ;) Thanks Wiz !!
-
Wozzer is right. The facility of Discovery to deal with the loss of the protocol and still initiate a fire signal is down to a circuitry that monitors that the device is receiving protocol pulses and if it sees none for 180 seconds it can generate it's own series of special pulses, on sensing a fire condition, which panels which have extra circuitry to detect these special pulses can respond to. I understand that apart from a couple of special panels specifically designed for the 'marine' market there are no UK panels that use this facility i.e most UK panelsdon't have the circuitry to deal with the special pulses, so the 'benefit' of it has no real use in the UK at present.
The liklihood of a panel processor failing and still having the normal loop voltage available is very possible. The processor will control the protocol pulses but is unlikely to control the loop power requirements.
Discovery protocol is just an extended version of the XP95 protocol (extra bits of information) and has been around for years, and most control panel manufacturers have models that support it.
Wiz;
In my understanding, there is no need for extra circuitry for the panel side to make a discovery trigger as a conventional detector in case of lost of protocol, the processor can monitor the impedance at the loop in both ways, if it sees drop of impedance to a level say i.e. 470Ohms, it trigger an alarm signal...etc
This can be done by software rather then additional hardware, by incorporating a simple If statement algorithm...
If (presence of protocol) then
Statement 1: Device behave as analogue addressable device
Else
Statement 2: Device behave as conventional device
End If
Statement 1: can take place as long as the processor is receiving analogue values from all devices in the loop.
Statement 2: takes place if not receiving any analogue value.
Now, the major concern is that, would this algorithm works for each device separately or only when the whole protocol is lost, by means a 'Partial loss' ( device no reply ) or 'General loss' ( no reply from all devices ), this is actually down to the programming to setup either way...etc
However do the existing manufactured panels have such algorithm incorporated, the answer is: I don't know! :)
This is down to substantial evidence…etc. :)
Sorry Benz but you are wrong. It never operates as a non-addressable device, in the common sense of the description, therefore special panel circuitry is required to react to it's special pulse facility to warn of operation when the normal protocol system has failed.
You don't have to believe me (you rarely do!) just give the technical department at Apollo a call (ask to speak to The Oracle) and you will find, for some strange reason, that you'll get exactly the same answer that I have given you.
p.s. 'conventional' is now an obsolete term in the fire alarm industry. All systems that aren't addressable should now be called 'non-addressable'
-
.......But the protocol as conversation and language on the loop there is no protocol in the loop before you auto learn the loop, by means there is no conversation between the panel and its devices before auto learning the loop, the panel doesn’t know either if the devices are in the loop, so how can he talk to them?
Except very few makes they scan periodically the loop them selves and thus the panel in that case can know straight away there is a device that need to be configured (enter its location text…).
This is my understanding if I am wrong please feel free to correct me :)...........
The control panel's protocol will generally interrogate every possible address on every loop automatically and search for devices at that address number even if the panel has not been configured by 'auto learn' or otherwise.
If the panel has a configuration programmed it will compare what it finds against that configuration.
If it finds a device that is not entered or is different to it's configuration it will highlight it.
In many panels after a configuration programme is entered, it will only 'talk' to those devices included on the configuration on most of the 'scans' to save the time it would waste in otherwise checking non-configured addresses. However every x number of scans it will do a full scan of every possible address to check that no 'extra' addressed devices have been added since it last checked.
-
From my conversations with Apollo the protocol is always present as soon as the loop is wired even before you have 'learnt' the system. I asked them about this 'Conventional alarm mode' and it is really just a method they put in to comply with a standard that wasn't released until later. It was put in to cope with possible processor failure. The standards dealt with it anyway by saying that 'no more than 514 devices should be lost due to processor fault'. The panel manufacturers dealt with this by designing panels that had processors supporting no more than 514 devices. So the detector feature wasn't used by most.
Wozzer;
We are talking about the same thing but interpreted differently, the protocol is the language or the conversation between the panel and its devices, and it is initially considered as program in memory…etc, as a program it is in there even before you power up the panel or the panel is still brand new on the shelves or is packaged…etc.
But the protocol as conversation and language on the loop there is no protocol in the loop before you auto learn the loop, by means there is no conversation between the panel and its devices before auto learning the loop, the panel doesn’t know either if the devices are in the loop, so how can he talk to them?
Except very few makes they scan periodically the loop them selves and thus the panel in that case can know straight away there is a device that need to be configured (enter its location text…).
This is my understanding if I am wrong please feel free to correct me :)
Regarding the answer of Apollo, it is very interesting to hear that the option was added just in case of processor failure according to what they said, through your post. And in that case an additional electronics circuitry will be must within the panel to behave as conventional, as the processor wouldn't be able to monitor the impedance of the loop...etc :)
Benz, believe me there is protocol on the loop as soon as it is powered up!! If you put an oscilloscope on the loop you will see it, before you do a loop learn etc. I had an indepth session with Andy Haynes at Apollo and I know a fair bit about protocol.
Extra circuitry would be required to pick up the alarm pulses as Wiz and Dave R have described and NONE of the UK panel manufacturers have included this extra hardware.
I do apreciate you had an indepth session with Andy Haynes at Apollo and you know a fair bit about protocol and I do believe that.
What you are saying there is no UK panel applying the option of conventional mode of discovery, I didn't know that! :) Thank you
If the protocol is in the loop before loop auto learn, the processor wouldn't see any device, means the processor wouldn't talk with any device in the loop, so the protocol which you said is present is doing what?
-
Wozzer is right. The facility of Discovery to deal with the loss of the protocol and still initiate a fire signal is down to a circuitry that monitors that the device is receiving protocol pulses and if it sees none for 180 seconds it can generate it's own series of special pulses, on sensing a fire condition, which panels which have extra circuitry to detect these special pulses can respond to. I understand that apart from a couple of special panels specifically designed for the 'marine' market there are no UK panels that use this facility i.e most UK panelsdon't have the circuitry to deal with the special pulses, so the 'benefit' of it has no real use in the UK at present.
The liklihood of a panel processor failing and still having the normal loop voltage available is very possible. The processor will control the protocol pulses but is unlikely to control the loop power requirements.
Discovery protocol is just an extended version of the XP95 protocol (extra bits of information) and has been around for years, and most control panel manufacturers have models that support it.
Wiz;
In my understanding, there is no need for extra circuitry for the panel side to make a discovery trigger as a conventional detector in case of lost of protocol, the processor can monitor the impedance at the loop in both ways, if it sees drop of impedance to a level say i.e. 470Ohms, it trigger an alarm signal...etc
This can be done by software rather then additional hardware, by incorporating a simple If statement algorithm...
If (presence of protocol) then
Statement 1: Device behave as analogue addressable device
Else
Statement 2: Device behave as conventional device
End If
Statement 1: can take place as long as the processor is receiving analogue values from all devices in the loop.
Statement 2: takes place if not receiving any analogue value.
Now, the major concern is that, would this algorithm works for each device separately or only when the whole protocol is lost, by means a 'Partial loss' ( device no reply ) or 'General loss' ( no reply from all devices ), this is actually down to the programming to setup either way...etc
However do the existing manufactured panels have such algorithm incorporated, the answer is: I don't know! :)
This is down to substantial evidence…etc. :)
Sorry Benz but you are wrong. It never operates as a non-addressable device, in the common sense of the description, therefore special panel circuitry is required to react to it's special pulse facility to warn of operation when the normal protocol system has failed.
You don't have to believe me (you rarely do!) just give the technical department at Apollo a call (ask to speak to The Oracle) and you will find, for some strange reason, that you'll get exactly the same answer that I have given you.
p.s. 'conventional' is now an obsolete term in the fire alarm industry. All systems that aren't addressable should now be called 'non-addressable'
Wiz;
In what I am wrong? And in what I don't believe you? I believe into the technical evidence and explanation from who ever the come from, once I am convinced I will say thank you for that, as usually I do, but please allow a delay time compatible to my slow assimilation timer :)
As for the philosophy of the appellation of either conventional and its new fashion non-addressable appellation, even the latest guides of Apollo still mentioning conventional rather than non-addressable and many people in the industry still use conventional name... I think things will take time to be standardized into one general single appellation; there is no rush... etc.
In fact conventional system is addressable too, it’s addressed by zones, while the analogue addressable one is more specific (it's addressed by devices within the zones/loops) and so it is addressable too or rather it’s analogue addressable, thus both of them are addressable.
Conventional name was a good appellation in the old days, and used to make sense, before analogue addressable was developed, conventional appellation was compared to the previous standalone smoke alarms where there was no conventions, standards and norms, therefore the conventional was the first one to be designed to certain conventions and therefore the name of conventional system came out...etc
Now conventional name is compared to its successor system rather than the predecessor one, the successor to conventional is more efficient in terms of conventions and therefore they didn’t call it the ‘more conventional’ system, because probably this will not make sense any more, they have called it analogue addressable system, which is more descriptive name, and the new name for conventional which is non-addressable came out by comparing the conventional to its successor one instead the predecessor one, so they preferred to use ‘the new latest name minus one’ which is normally in more descriptive word the ‘less addressable’ but they preferred the name of ‘non-addressable’ which is in my opinion is NOT the right name...etc
Because in fact things come back into a closed vicious circle the conventional system is addressable too and they call it 'non-addressable' just because it's ‘less addressable’ than analogue addessable one... or probably the most descriptive name making the distinction between them, is the name of 'non-analogue' instead of non-addressable, or rather 'non-Digital' as for the analogue addressable is 'Digital' this may make more sense to the appelations...etc but just not 'non-addressable'
Never mind. :)
Better of finding another name rather than 'non-addressable' or 'conventional'!
Waiting for what the future reveal :)
-
.......But the protocol as conversation and language on the loop there is no protocol in the loop before you auto learn the loop, by means there is no conversation between the panel and its devices before auto learning the loop, the panel doesn’t know either if the devices are in the loop, so how can he talk to them?
Except very few makes they scan periodically the loop them selves and thus the panel in that case can know straight away there is a device that need to be configured (enter its location text…).
This is my understanding if I am wrong please feel free to correct me :)...........
The control panel's protocol will generally interrogate every possible address on every loop automatically and search for devices at that address number even if the panel has not been configured by 'auto learn' or otherwise.
Indeed this makes sense, the protocol exist in the loop before auto learn, it attempts to check for any device requiring its output analogue value, but will not get any till the loop is auto learned. if it's like that thank you very much this make sense. looks like blind protocol signal patroling around and not seeing what is around...etc
If the panel has a configuration programmed it will compare what it finds against that configuration.
Indeed
If it finds a device that is not entered or is different to it's configuration it will highlight it.
The panel will not see at all, any device not previously configured, except very few makes, otherwise what you mean by 'not entered'
In many panels after a configuration programme is entered, it will only 'talk' to those devices included on the configuration on most of the 'scans' to save the time it would waste in otherwise checking non-configured addresses. However every x number of scans it will do a full scan of every possible address to check that no 'extra' addressed devices have been added since it last checked.
Indeed, while I insist that most makes, the panel would NOT see non-configured device
Now I am convinced there is protocol in the loop before loop auto learn, means processor try to interogate what is in the loop and will not see any, even devices sitting up physicaly on the loop, and thus it will be no conversation yet with the non-configured devices. :)
If its like that, it makes more sense. Thank you very much Wiz and Wozzers, Dave, and the rest. :)
I have learnt some thing new :)
-
All good Benz ;) have a good day!!