How to store preset ?

VladaPUB

Is there a way to store preset, and to keep it in memory after reboot / power out ?

vining

VladaPUB wrote: »

Is there a way to store preset, and to keep it in memory after reboot / power out ?

create a persistent variable or write to flash.

VladaPUB

Can you post some code sample ? Thank you in advance !

ericmedley

VladaPUB wrote: »

Can you post some code sample ? Thank you in advance !

There's not really any code sample you need.

Just put the keyword 'PERSISTENT' in front of your variable(s) declarations in DEFINE_VARIABLE that you use to store you preset info in and it will be there when you reboot.

any more code beyond this is a violation of the strict rules laid down by Jeff_Spire in this FAQ section. I've met Jeff and you don't want to break any of his rules.

http://www.amxforums.com/showthread.php?4085-Forum-FAQs

John Gonzales

Here's a link to a post on writing to flash: http://www.amxforums.com/showthread.php?7076-Writing-a-Structure-to-Flash

Basically just handle the file writes in a hold: event handler and you should be good to go.

-John

John Gonzales

And the way I handle presets is to define a hold: event and a release: event for a button, and not a push: event.

Place the store preset function into the hold event, and put the recall preset function into the release event so that if the user pushes and holds the button it will store the preset into a variable, and when they release the button it will call the preset. If you place the recall preset into the push: event, it will call the the preset before the hold: kicks in and you won't be able to store the new value.
-John

PhreaK

When you're putting together a system that needs some user configurable presets there's a two approaches:

1. Store them on your devices (such as a PTZ camera location) where supported
2. Store them on your NI

Which one is best / easiest depends entirely on the equipment capability and functionality requirements.

If you're setting up some preset functionality on the NI you'll want to get familiar with the NetLinx variable modifiers. On the NI's there are three places variables can be stored: volatile RAM, non-volatile RAM (aka flash memory) and battery back RAM. Data stored in the volatile RAM will not survive a power loss, however anything that is in non-volatile memory or the battery back RAM will.

Where the data referenced by a variable is placed depends on the modifier used when declaring the variable. In the global scope these are:

• non_volatile - stored in non-volatile memory. Variables without a modifier default to this.
• volatile - stored in volatile RAM
• persistant - stored in battery back RAM and volatile RAM. These will maintain data not only across a power loss but also when new code is loaded.

And within the local scope (anything declared within a set of curly braces):

• local_var - battery backed RAM (from what I've been told)
• stack_var - volatile RAM

With that in mind if your playing around with giving users (or the system) the ability to save anything the easiest way to do it from the control system side is to just keep track of any of the data required in persistent variables.

If you need any more info have a look at the help file.

jjames

PhreaK wrote: »

And within the local scope (anything declared within a set of curly braces):

• local_var - battery backed RAM (from what I've been told)
• stack_var - volatile RAM

I've never seen a local_var hold its value after a reboot or power outage, but I also rarely use local_vars and instead opt for stack_vars.

vining

Presets generally should also survive a program upload otherwise everytime you tweak your code you'll have to manually re-enter preset values or worse have the clients do that. Basically starting from scratch again so if you want your presets to survive a program upload they must be stored as "Persistent" or "write/read to/from the flash". If you only care about surviving power outages and reboots they can be declared non-volatile. If declared volatile they won't survive a reboot or program upload which is fine for 99.9% of your variables.

As far as local vars being non-volatile I really don't know. I would just have assumed them to be volatile but if not I would think you should then have the option to choose volatile or non which we don't. Usually I'll just use a local when I can't use a stack because of waits so it's not often they're needed and I can't ever think of an instance where I've used them where they needed to be non-volatile. For me non-volatile memory is almost unecassary (keyword "almost").

annuello

For those that are looking after large deployments of masters... A little bit of thought at the start can save a world of pain later. As best as I understand it, persistent variables are backed up by battery (on the Axcent masters) or "time keeper" (on NetLinx masters - essentially a clock with built-in battery). Your persistent variables will survive power outages until the battery goes flat, typically 3 - 5 years. I recall coming across my first flat time keeper while wondering where all my lighting presets had gone. :-(

Unless you want to change batteries or the TimeKeeper every 4 years, it is worth the effort to read/write to the filesystem.

To answer the OP, persistent variable is a good start, but keep in mind the long-term issues.

Roger McLean
Swinburne University

PhreaK

annuello wrote: »

As best as I understand it, persistent variables are backed up by battery (on the Axcent masters) or "time keeper" (on NetLinx masters - essentially a clock with built-in battery). Your persistent variables will survive power outages until the battery goes flat, typically 3 - 5 years.

I enquired about this at the last P3 and was told that in addition to being in the BBRAM they are also dumped out to flash then restored on boot from here. At least that's what's in my notes - I could be wrong. Anyone from engineering care to clarify?

If that is the case you could implement your own backup system. When a preset is saved dump the data to a volatile variable then also serialize it and save to flash. Then as part of your boot sequence read the data that's sitting in flash back out to the variable. When you need it just read from the volatile variable. Ideally though is would be preferential to see that process handled by the firmware as it would ensure that persistent variables are always persistent, regardless of any potential future hardware issues.

John Gonzales

PhreaK wrote: »

If that is the case you could implement your own backup system. When a preset is saved dump the data to a volatile variable then also serialize it and save to flash.

And if you really, really want to make sure, write it down on your arm too when it's stored, just in case .

-John

annuello

PhreaK wrote: »

If that is the case you could implement your own backup system. When a preset is saved dump the data to a volatile variable then also serialize it and save to flash. Then as part of your boot sequence read the data that's sitting in flash back out to the variable. When you need it just read from the volatile variable.

This is precisely what I do. Occasionally I will include an auto-save mechanism so that when changes are made, the volatile is automatically dumped to file. If the volatiles are likely to change in bursts I include a delay so that the dumping only occurs when the volatiles haven't changed for a while (3 seconds).

If AMX were to spend some time on file-related issues I'd rather they sort out the existing file commands first. Last time I checked (which admittedly was back in 2006) the file-based functions left a lot to be desired. See this thread. http://www.amxforums.com/showthread.php?1543-File-read-write-delete-problems&p=9058#post9058 I've kept an eye on corrections in firmware since then, but have not seen any file-related fixes. I should run those tests again to see if the issues have been addressed, and simply not documented.

Roger McLean
Swinburne University