Persistant Variables - anyone use them?

TrikinCurtTrikinCurt Junior MemberPosts: 158
Does anyone here use persistent variables? I was making it so users can save their own radio presets and persistent variables seemed like a good way. A few times my variables disappeared. Can anyone tell me in what situations they lose their values? Rebooting the controller doesn't do it, yet I came in this morning and they were gone!

Am I going to have to learn how to use file commands?

Comments

  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    I've used persistent variables. They're great. A reboot of the controller doesn't reset the values of the variables, but if you change the definition of any of the variables and resend your code, the values will unset.

    I don't know how to explain how your values are getting lost. Could be a code issue, or it could be other people sending code to your master when you're away.
  • yuriyuri Junior Member Posts: 861
    Persistent variables: if a variable is declared with the PERSISTENT keyword, it is initialized to zero the first time the program is loaded but will retain its value after either power-down or reload.

    which means every time you resend code to your master the variables get reset.

    this is also very nice :(
    NOTE: Persistent variables do not work in Modules.
  • viningvining X Member Posts: 4,353
    TrikinCurt wrote:
    Am I going to have to learn how to use file commands?
    Well that's a good thing to know anyway and if you want persintence in modules you have to save to file.

    yuri wrote:
    which means every time you resend code to your master the variables get reset.
    The persistent variable in you main program should retain its value even after you resend code to your master. I just re-compiled and resent the program and my persistent variables are holding their previous value.

    Are you sure your not initializing them in start up some where?
  • Spire_JeffSpire_Jeff Formerly Caffeinated Programmer Posts: 1,917
    Persistent variables should retain their value after sending code unless you change the variable declaration in code (or you initialize the variables in start up). Keep in mind that persistent variables DO NOT work within modules.

    Jeff
  • annuelloannuello Junior Member Posts: 294
    As mentioned in another thread http://www.amxforums.com/showthread.php?t=3711, I've also had problems with persistent variables, to the extent that I don't use them any more. It seems like up to a third of my masters have issues with it. I still haven't been able to isolate the problem. They are all running the same firmware and same code base. The only thing I can think of is that they may be from different hardware batches, but I seriously hope that is not the issue.

    No, there is nothing in the DEFINE_START section that modifies the values of my PVs. And no, they were not in any module - just in the normal expected places (.axs & .axi files). And no, I didn't change/delete them in my code between program uploads. Can you tell it's frustrating for those of us who have this issue?:)

    I've opted for reading/writing XML files instead, which has been 100% rock solid reliable. If you are having trouble with PVs, I'd suggest going straight for XML files instead. My approach was to create a "prefs" structure with all the values I wanted to save in the one structure. You then just call variable_to_xml() to generate and XML string, and write the string to a file. Message me is you want to see my code.

    Note that the AMX XML string does not have end-of-line characters, and I've found that the AMX master doesn't parse XML files correctly (using xml_to_variable) if you add them in to make editing easier. Use an XML editor like Pete's XML Editor http://www.iol.ie/~pxe/ to edit your files instead of Notepad.

    Roger McLean
    Swinburne University
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I have found the persistent variables to be persistently unreliable.
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,159
    a_riot42 wrote: »
    I have found the persistent variables to be persistently unreliable.

    Strange, I use them al the time and have never had a single issue with them. (At least nothing that couldn't be explained by something I did to goof them up.)

    I use them for presets, Cable/Satellite channel linesups (upwards of 1000 names and channel numbers) power states, etc... I store weather info in them too so when I reboot, weather info comes up quicker on the touch panels.

    I do know that you cannot use all the RAM available for them as the Netlinx master needs quite a bit of that space itself. I try to keep my useage to about 30-60% of the available RAM.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I use persistent variables all the time, and have never once had a problem with them. I use them for anything the customer might want to store themselves - tuner presets, volume level presets, thermostat setback times, stuff like that. I have not once had them lose value except in one of the known cases I was prepared for, namely, you changed the declaration (like the dimension value of an array).
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    The only time I didn?t see a persistent variable stick was when an esteemed colleague of mine :) was testing some code I wrote. If I remember correctly, when the code was reloaded or if the system was soft booted the variable stuck but after a cold boot it didn?t. Turns out the backup battery had to be replaced in the NI.

    Other than that I?ve found that persistent variables are persistently reliable. I don?t use them as much anymore but I?ve had no problems with persistent variables at all.

    I did run across something by mistake that I didn?t know. You can initialize a persistent variable to a value other than 0 when you declare it and that value only gets plugged in the very first time the code gets loaded.

    Consider the following program:
    DEFINE_VARIABLE
    
    PERSISTENT INTEGER nFirstTime = 1
    

    After the program gets loaded, drop nFirstTime into the debugger and you?ll see the value is 1. Change the value to 0. If you then reboot or reload the code the value of nFirstTime will still be 0, it won?t get reset back to 1.

    Maybe this is already common knowledge and I?m just stating the obvious but I didn?t know this option existed.
  • jjamesjjames AMX Sustaining Engineer Posts: 2,900
    Reliable here too. I use them to store favorites (am/fm, xm, etc.)
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    Joe Hebert wrote: »
    After the program gets loaded, drop nFirstTime into the debugger and you?ll see the value is 1. Change the value to 0. If you then reboot or reload the code the value of nFirstTime will still be 0, it won?t get reset back to 1.

    Maybe this is already common knowledge and I?m just stating the obvious but I didn?t know this option existed.
    Knowledge, but not common knowledge. I remember it was used as an example of persistence in my P2 class.
  • annuelloannuello Junior Member Posts: 294
    Hmmm... The battery backup might be my issue. It would certainly explain why my results with persistent variable are not consistent across the fleet of masters. I thought that PVs would have been written to the compact flash (which should retain it's data without any power whatsoever). Perhaps that isn't the case.

    I had my troubles on a freshly purchased batch of NI-3100s. But I guess I can't vouch for how long they were standing in storage prior to us purchasing them. Unfortunately NetLinx masters use a timekeeper rather than plain CR batteries from the Axcent days. I think I'll just leave them be, since XML covers PV issues and RMS does covers time-syncing for me.

    Roger McLean
    Swinburne University
  • richardhermanrichardherman not-so-junior member Posts: 228
    Persistent variables: if a variable is declared with the PERSISTENT keyword, it is initialized to zero the first time the program is loaded but will retain its value after either power-down or reload.
    yuri wrote: »
    which means every time you resend code to your master the variables get reset.

    this is also very nice :(

    I don't think it works this way. It is exactly as stated: it is initialized to zero the FIRST time the program is loaded . If you resend it isn't the first time the program is loaded. They will reset to zero if you rename your program, or save as a file revision.

    Richard
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Resending the program does not reset a persistent variable. That's the whole point. The only thing that resets them is if the variable structure itself gets changed (like array dimensions).
  • yuriyuri Junior Member Posts: 861
    Persistent variables: if a variable is declared with the PERSISTENT keyword, it is initialized to zero the first time the program is loaded but will retain its value after either power-down or reload.



    I don't think it works this way. It is exactly as stated: it is initialized to zero the FIRST time the program is loaded . If you resend it isn't the first time the program is loaded. They will reset to zero if you rename your program, or save as a file revision.

    Richard

    hmm, the problems i have had with persistent variables are probably due to using them in modules.
    Can you define a persistent variable in main, then pass it to a module to use it, or doesn't that work?
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    yuri wrote: »
    Can you define a persistent variable in main, then pass it to a module to use it, or doesn't that work?
    Yes, that works just fine.
  • jazzwyldjazzwyld Registered User Posts: 199
    I use persistent variables in Modules, the only key is passing the values to your Main code...so they don't get lost.
  • pauldpauld Junior Member Posts: 106
    I have had no problems with persistent vars, and I use them for volume, and tuner presets and other user info.

    Pauld
  • yuriyuri Junior Member Posts: 861
    jazzwyld wrote: »
    I use persistent variables in Modules, the only key is passing the values to your Main code...so they don't get lost.

    You mean passing variables from DEFINE_MODULE in your main right?
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    yuri wrote: »
    You mean passing variables from DEFINE_MODULE in your main right?

    The other way around. If you need the variable to be persistent, you have to define it in your man program, then pass it to the module as a parameter. Since NetLinx passes parameters by reference, any changes to it in the module become the "new value" that will survive subsequent reloads.
  • yuriyuri Junior Member Posts: 861
    DHawthorne wrote: »
    The other way around. If you need the variable to be persistent, you have to define it in your man program, then pass it to the module as a parameter. Since NetLinx passes parameters by reference, any changes to it in the module become the "new value" that will survive subsequent reloads.

    that's what i was saying :)

    <-- dutchie ;)
  • TrikinCurtTrikinCurt Junior Member Posts: 158
    Okay, I had cheated and the radio presets were just handled in the main code, which I don't like. So, my next question, is there a way to pass a structure into a module? For example:
    MODULE_NAME='OnkyoT4555_UI' (DEV vdvDevice, DEV dvTP[], RadioPreset radioPresets)
    

    I get a syntax error trying to pass in radioPresets that way. For what it is worth , the structure is defined
    STRUCTURE RadioPreset {
        char presetName[20]
        integer presetStation
        integer presetSubstation
    }
    
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    TrikinCurt wrote: »
    So, my next question, is there a way to pass a structure into a module?
    Not directly, but you can use VARIABLE_TO_STRING and STRING_TO_VARIABLE. I'm using this method on a project I'm working on right now and it works great. Check out the following thread for an example.

    http://www.amxforums.com/showpost.php?p=23920&postcount=21

    HTH
Sign In or Register to comment.