String Persistent Variables

Hi I was wondering if string persistent variables work differently than numeric ones. I am working with a string persistent variable that goes back to being blank when the strategy is changed. It retains its value when the strategy is just stopped and started, however any minor change that requires the strategy to be re-downloaded and the variable goes back to its original value. The strategy name and the persistent variable name or type was not changed after downloading the strategy.

Hello pmur,

The symptom you describe sounds like an issue that’s been fixed (see: KB84472). Do you have firmware version R9.4c or newer? Besides that fix, there’s lots of fun new features in 9.5!

FYI, we have now have a utility to help make upgrading firmware (especially preserving those persistent values) much easier than it used to be!

-OptoMary

1 Like

Wow you are right on, sounds like it is the firmware - we are currently on R9.4B. Thank you!

I guess I missed the unveiling of that utility, Mary. That really ought to be built into the firmware upgrade process…add another browse box for the location of the variable file to save to and retrieve from and when the whole thing is done, the persistent vars are all back to the original values…eh?

1 Like

I agree. Even thought about having a little hunger strike/protest but I’m only good for about 2.2 seconds on those… :wink:

1 Like

@mstjohn: I upgraded my firmware and tested out the persistent string variable and it works! After I ran the strategy and assigned its value I made some changes to the strategy and re-ran, the value stayed the same after download and after running revised strategy.

This may seem like a silly question but I just want to make sure that persistent variables can be changed or modified more than once while a strategy is running. That is what I am observing at the moment. I don’t have much experience working with persistent variables and want to make sure this is correct. I assumed that they were supposed to be assigned once and retain the initial value it was given throughout. I guess this is incorrect?

As you’ve seen, persistent values can be changed (their current value will “persist” through a power cycle). Handy for totalizing or totals/counts etc.

Sounds like what you expected is what some programming languages call a const for “constant” (like pi = 3.14… etc).

While PAC Control doesn’t have a special data type for those, some folks use the naming convention of all caps like: MAX_TANKS_TO_MONITOR or some such to indicate the value is a constant and shouldn’t be changed.

Make sense?

1 Like

Oh alright, makes sense. I get it now. Thanks!

Another interesting thing about persistent variables is that they are stored in a physically different place in memory.

I had a project where I was low on standard variable memory (volatile) due to needed to store large SOAP responses from another application. When I upgraded the project from 9.3 to 9.4 the size of my strategy increased just enough that I got an out of space error when I tried to download to the controller!

I wasn’t using a lot of persistent space, and so I changed some of my large string tables to persistent which moved them out of the area that was short on space (volatile memory), and then I was able to download my strategy. After looking at tech note 1646, I realize I could have also “initialized” the variables on download and this should have moved them to the same non-volatile memory area that persistent vars use.

Yeah that is pretty neat, thanks for the tip.

Hi Philip, is there a way to view how much volatile memory we are using in? Currently I have multiple huge numeric array tables worried that I might get no volatile memory space error. I already ran in to that issue with string table. But that error is been solved.

PAC Terminal, View Status…