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.
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!
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?
@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.
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.
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.