Apologies and another question

DELInstallations said:
Comments for rules are not stored or saved in the control, they are local to the RP DB and only on that DB...so if you connected to the panel from a different machine and RP and connected to it, the comments do not exist. The only way comments exist in the DB is if you sync multiple DB's across RP.
 
Possibly a corrupt DB given what hints have been put out there so far.
 
Do you have a copy of it before the last changes or before the last download? That would be my first place to start to try to diagnose what's going on.
 
Off the top of my head, I don't think there's a repair on RP for an individual account. I'd grab a fresh copy out of the panel and then go through it with a fine tooth comb, otherwise it's looking like you might need to rebuild the program on a fresh DB.
 
I remembered that I had a backup of my account from a couple of weeks ago that is missing a zone or two but good to go. I loaded it, sent it to the control and still the same. The area 2 arms correctly and then voices one of the open zones in area 1. I'm just about done for tonight but tomorrow I am going to secure all of the wireless zones, open a wired zone and then arm area2 and see if it voices the wired zone or if it is specific to the wireless tranceiver.
 
I don't remember the system doing this in the past but I'm not sure if I ever had the chime turned on at the garage/area2 keypad while arming from the  house/area1 in the past.
 
Tomorrow's another day, Mike.
 
If we can rule out the DB...the final variable would be to load a bootstrap into the panel to ensure all the memory is gone (even pull the CR battery under the shield) and then load your DB back.
 
If the issue still persists, I'd investigate your rules. Might be a specific rule causing a conflict based on chime or announcement. Turn one off at a time until the problem goes away. If the rule part pans out, you'd need to check the syntax or other events driven off that rule for issues, before calling it a system bug.
 
DELInstallations said:
If we can rule out the DB...the final variable would be to load a bootstrap into the panel to ensure all the memory is gone (even pull the CR battery under the shield) and then load your DB back.
 
If the issue still persists, I'd investigate your rules. Might be a specific rule causing a conflict based on chime or announcement. Turn one off at a time until the problem goes away. If the rule part pans out, you'd need to check the syntax or other events driven off that rule for issues, before calling it a system bug.

What do you mean by load a bootstrap? It sounds like you want to shunt the system to ground to clear it but how is it done?
 
DELInstallations said:
If we can rule out the DB...the final variable would be to load a bootstrap into the panel to ensure all the memory is gone (even pull the CR battery under the shield) and then load your DB back.
 
If the issue still persists, I'd investigate your rules. Might be a specific rule causing a conflict based on chime or announcement. Turn one off at a time until the problem goes away. If the rule part pans out, you'd need to check the syntax or other events driven off that rule for issues, before calling it a system bug.

What do you mean by load a bootstrap? It sounds like you want to shunt the system to ground to clear it but how is it done?
 
DELInstallations said:
If we can rule out the DB...the final variable would be to load a bootstrap into the panel to ensure all the memory is gone (even pull the CR battery under the shield) and then load your DB back.
 
If the issue still persists, I'd investigate your rules. Might be a specific rule causing a conflict based on chime or announcement. Turn one off at a time until the problem goes away. If the rule part pans out, you'd need to check the syntax or other events driven off that rule for issues, before calling it a system bug.
I have disabled ALL rules, sent to the control and tested....same results.
 
Mike.
 
Pull the memory battery, replace and then put a blank panel program in.
 
From there, I'd try a bare bones program with a zone or two and test.
 
Remember, your DB/program is also suspect, so irregardless of whether or not you disabled the rules, you're still using the same panel program/image.
 
Hate to say it, but corruption happens with large systems, fire panels and the like more often than I'd like to admit.
 
So how does the whole Win 8.1 and your laptop debacle fit into this? Did you do any programming/connecting to the system with it or had you been using a known stable platform?
 
DELInstallations said:
Pull the memory battery, replace and then put a blank panel program in.
 
From there, I'd try a bare bones program with a zone or two and test.
 
Remember, your DB/program is also suspect, so irregardless of whether or not you disabled the rules, you're still using the same panel program/image.
 
Hate to say it, but corruption happens with large systems, fire panels and the like more often than I'd like to admit.
 
So how does the whole Win 8.1 and your laptop debacle fit into this? Did you do any programming/connecting to the system with it or had you been using a known stable platform?
 
I think that it is a good idea to build from a new base at this point rather than trying to trouble-shoot it, especially considering my lack of experience with the system.
 
I have no understanding of how elkrp stores information. I can see that it saves multiple customer accounts in a database but I don't know anything about it's internal structure.What do you mean when you say  a "blank panel program" or "bare bones program"? Do you mean to send an elkrp  template to the control and then start a new customer account in RP? Also is there a way to print a report on the existing system specs so that I can all of the addresses and settings available for the rebuild?
 
And yes the windows 8 pc was used exclusively in configuring my system. I recommend that you stay away from those laptop/tablet combos unless you want to be part of their test base.
 
Mike.
 
RP is basically a shell created within Microsoft Access and then modified by Elk to do as they wish and have the GUI, look and feel they want with a few items tossed in for DB security.
 
Powering the system down, the easiest way to bootstrap the panel and program is to pull the system battery (careful not shorting the spring clip to the terminal. Usually an index card between the battery and clip works well) and then waiting about 10 seconds and then pulling the card out and then repowering the system. Create a basic DB with a single KP and serial, load that into the panel and that's it. Panel has zero information from the prior install and all memory blocks have been overwritten.
 
According to Elk, RP is Win8 stable, so I'd grab a copy of the RP DB (export all accounts or grab a copy of controls and ops .mdb in it's entirety onto a thumb drive, make sure you know/have the security key-or program one for the DB) and then blow out all of the RP files/folders on the machine, which should be in prog files and prog data (check hidden files on machine). Perform a fresh install and then drag the existing db into the new install of RP.
 
That said, you'll have a fresh install of RP, your existing DB (if needed) and you can reprogram the panel on a new DB to see if this is actually a firmware issue or not.
 
I don't worry too much about Win 8.....I'm dealing with enterprise programs and hardware, usually Win 8 isn't on the radar, let alone compatible-too many variables involved still and probably is going to get glossed over like Vista did. Guessing Win 9 is going to be the next one to consider.
 
DELInstallations said:
RP is basically a shell created within Microsoft Access and then modified by Elk to do as they wish and have the GUI, look and feel they want with a few items tossed in for DB security.
 
Powering the system down, the easiest way to bootstrap the panel and program is to pull the system battery (careful not shorting the spring clip to the terminal. Usually an index card between the battery and clip works well) and then waiting about 10 seconds and then pulling the card out and then repowering the system. Create a basic DB with a single KP and serial, load that into the panel and that's it. Panel has zero information from the prior install and all memory blocks have been overwritten.
 
I don't understand what you are saying about an index card. I removed the battery but I am not clear on what to do to drain the system of any memory that it may be holding. IS removing the battery for a minute going to do it? I tried this and it still powers up with zones and stuff in place.
 
Mike.
 
Are you removing the coin cell battery on the M1 board, or just the 12V SLA battery?  You need to remove both.
 
RAL said:
Are you removing the coin cell battery on the M1 board, or just the 12V SLA battery?  You need to remove both.
I turned the switch off which I thought disconnected the backup battery and then removed  the coin shaped battery on the board.
 
Mike.
 
I pulled the coin battery, I removed one wire from the backup battery, I removed one wire from the ac power supply nad I even disconnected the power from the xep. This thing will not let go of it's memory. It comes back and reports the zones and date and time just as usual.! I even flipped the power switch at the control with everything disconnected to drain current and it starts back up reporting zones.
 
Mike.
 
You don't need to remove the coin cell. If you slip an index card between that and the clip it performs the same function. Usually with these sorts of electronics, if you hit the spring tab to the other terminal with no battery in place, that is a bad scenario.
 
You would perform the steps I outlined, then dump a blank program into the panel. You may need to lather, rinse, repeat, or change the steps in variation (put dummy program in and then pull power, etc.) been a while since I've had to perform this dance on an M1....I'm used to monkeying with different hardware more often.
 
There seems to be nothing that I can do to get this control to reset. I disconnected power several times and it just comes back with it's full configuration
 
I loaded a minimal configuration that I had exported in June which includes just one wired zone and four wireless zones. I sent this to the control and it all looked good until I tried to arm it. Now no matter what I do it bypasses any open zones when I arm it. I un-checked bypassable on the zones but it doesn't seem to care. It just bypasses everything and arms the system. I'm starting to think that I've lost my mind. Nothing does what it used to do.
 
Mike.
 
OK first thanks everybody for your patience. I have the system to a point that the house zones are recognized and working properly but I have little confidence to go forward because I never got the control to reset. No matter what I did it would not erase it's account info. I loaded an old account that I had exported in June and it looked good in elkrp but for some reason it ignored open zones when I would arm it. I can't say how I corrected that other than to keep restarting the system which is why I have no confidence in the fix.
 
So how do I get the system wiped? I would feel much better if I could see it power up as a blank slate,,,dumb as a brick, and then load my settings to it. Is it possible? Can it be wiped? What state is the control in when it leaves the factory? Is it preconfigured or blank?
 
Mike.
 
Back
Top