Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Tue Nov 21, 2017 8:30 pm

All times are UTC - 7 hours




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Persisting variables
PostPosted: Thu Oct 07, 2010 9:09 am 
Offline

Joined: Thu Oct 07, 2010 8:59 am
Posts: 7
G75 terminal
2.611 firmware

I am having trouble getting a variable to persist across restarts of the G75. What I am trying to do in the following code is write a value to a file in the terminal filesystem and then read it. It isn't working, and I'm now unsure where there's a mistake in my code.

Write code:
Code:
 m_iPanelType = 1
    SaveSettingsFile = Openfile("\Settings.txt", FILE_BINARY And FILE_WRITE)
    WriteFile(SaveSettingsFile, m_iPanelType)


...

Read code:
Code:
dim SaveSettingsFile as filedesc
     dim savedvar as integer

     SaveSettingsFile = Openfile("\Settings.txt", FILE_READ And FILE_BINARY And FILE_WRITE)

    ' Check if there is any saved data in the file
    if EndOfFile(SaveSettingsFile) == false then     ' Data saved from previous run
        ' Read Contents
        ReadFile(SaveSettingsFile, savedvar)
    endif

    ' Close settings file
    CloseFile(SaveSettingsFile)


Thanks


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Thu Oct 07, 2010 9:18 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
A couple of thoughts come to mind.

First of all, opening a file for write will wipe any existing contents. (Open it for append if you don't want this behavior). So I suspect you would never successfully read anything. Try

Code:
SaveSettingsFile = Openfile("\Settings.txt", FILE_READ And FILE_BINARY)


instead.

Next, make sure you do something with savedVar. Your code as it stands would read the variable but do nothing with it once it was read.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Fri Oct 08, 2010 5:12 am 
Offline

Joined: Thu Oct 07, 2010 8:59 am
Posts: 7
Thanks for the prompt reply. Since I'm using the OpenFile command to also check if the file exists, I was able to add the APPEND flag in and move the position to 0. From there I could tell if I was at EOF or not.

I am using savedVar, I just cut out some code for posting so no problem there.

I did have one more question though. I was hoping that the file Settings.txt would be wiped off the memory when the G75 is reprogrammed, but it looks like this is not the case. Is there any way to make this happen? The issue is that I'm using this code in a first run only initialization procedure. If the panel is reprogrammed the initialization screen needs to run to allow the user to set these one time parameters. At the same time, if something like a power outage happens for some reason, the panel needs to just come back into the run screen instead of sitting there waiting for a user to come configure it again.

So I guess I'm asking if there's a way to tell the difference between a power cycle and the node being reprogrammed.


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Fri Oct 08, 2010 6:45 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
A couple more thoughts on the original question before I move on.

I would still be hesitant to open a file for writing that is only intended for reading. If you are trying to detect if the file exists (reasonable), try using check error

Code:
check error
    SaveSettingsFile = Openfile("\Settings.txt", FILE_READ And FILE_BINARY)
on error
    _ClearException()
    'Do whatever you want to do in the no-file case
enderr

All of the file system APIs can throw exceptions and are intended to be used with the check error construct.

Next, I forgot to put in my original post: The PersistantVariablesV2 object will actually deal with all the file system code for you if you merely want to save and restore one or more global variables or object properties. This is the object I use when I want to save some variables.

Now moving on:
There is no intrinsic way to tell between power cycle and node being reprogrammed. While there are certain situations where reprogramming the terminal will cause the file system to be wiped (primarily if the application BFF has grown or shrunk beyond a 64 kByte boundary), I would not rely on that behavior.

I would suggest using an application version variable in your workspace instead. For instance:

Code:
 'Global Variable
dim applicationVersion as integer
init applicationVersion := 24


Next, when you write your saved variable file, write the application version to it. When you read the file, check the application version stored in the file and see if it matches global variable applicationVersion. If it does not you can assume that the terminal was upgraded since the last boot up.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Fri Oct 08, 2010 12:51 pm 
Offline

Joined: Thu Oct 07, 2010 8:59 am
Posts: 7
Thanks for the quick response again. The check error based approach makes much more sense so I used that.

Our other issues have now all been worked through so thanks for the help.


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Wed Feb 09, 2011 2:23 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Jeremy wrote:
Next, I forgot to put in my original post: The PersistantVariablesV2 object will actually deal with all the file system code for you if you merely want to save and restore one or more global variables or object properties. This is the object I use when I want to save some variables.

A question about PersistantVariablesV2...

We are using this in our app to save variables. Is there any way to clear the saved variables?

In particular, I would like to do this when simulating in Qlarity Foundry. When our code runs for the first time, it notices there is nothing saved, then does some initialization logic. On further runs, it notices saved data, and skips the initialization. I would like to be able to manually clear the saved data, so I can run the initialization logic again, to test/examine it better. I don't want to change my code (which is my current workaround), since any such changes should not get into the final app, but I do want to test the initialization logic. Thus I am looking for some button etc. in Qlarity Foundry to force this. Is there such a thing?

P.S. I am using a QTERM-G55, no extra hardware, with Qlarity Foundry 2.60.

Thanks,
Mark


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Wed Feb 09, 2011 3:21 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
The easiest solution would be to delete the persisted file. The default file will be "/_PersistantVaraibles/Persist.dat" However, that will vary based on the filename property of the PersistentVariables object you use.

Code:
EraseFile("/_PersistantVaraibles/Persist.dat")

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Wed Feb 09, 2011 4:02 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Jeremy wrote:
The easiest solution would be to delete the persisted file. The default file will be "/_PersistantVaraibles/Persist.dat" However, that will vary based on the filename property of the PersistentVariables object you use.

Code:
EraseFile("/_PersistantVaraibles/Persist.dat")

Where is this file on my local PC when I am running Qlarity Foundry? (I am using Windows 7.)
I don't think I am changing the filename, I searched and did not find a Persist.dat locally.
Windows may have skipped relevant 'special' folders in its search though, I have not learned how to control the searches in Windows 7 well yet.

Deleting that file manually would be entirely adequate for my needs.


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Wed Feb 09, 2011 4:26 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Unfortunately, the simulated file system is not on your local PC, rather it is stored in memory in Qlarity Foundry.

You have a couple of options, I suppose -- you could restart Qlarity Foundry each time you want to reset things. Similarly, you could create another mini-app that simply deletes that file. You could open that file in QF and quickly go to Layout View or Simulation View, then open your original app again (not sure which would be less work)

The other option would involve modifying your app. In the past when I have wanted this functionality, I have added a button to the admin/settings screen in my application with a caption like "Revert to defaults." I am not sure if that would be useful to your application though.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Wed Feb 09, 2011 5:20 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
The settings seem to be stored somewhere besides just in memory in Qlarity Foundry.
When I reopen Foundry, load my program, and run it, the previously saved settings are detected and used.

I only get the initialization code running, when I run the program for the very first time on a new machine.
(Which I just did yesterday, I just installed QF, and seeing our init code run reminded me of this.)

I would be perfectly happy restarting Foundry every time I wanted to clear this file, but it doesn't seem to work.

Adding a 'Reset Options' to our admin screen would make sense and be useful, but I guess I was hoping to avoid that work :)


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Thu Feb 10, 2011 8:09 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
What version of Qlarity Foundry are you using? I know that I added file system persistence to Qlarity Foundry as an experiment at one point, but I never had the time to fully test and validate the feature, so I disabled it before release.

Your comment made be look at the latest Qlarity Foundry (2.63). Upon further investigation, it seems like the persistence feature may be back. (I have added an issue report for Qlarity to investigate this, and see when and why the feature was reenabled, and make sure it gets full testing for the next Qlarity release). If you are using Qlarity 2.63, the persistence file is located in your current user application data folder. For me that is "c:\documents and settings\<my login name>\Local Settings\Application Data\Qlarity2\runtime\Filespace.qflash." For earlier versions of QF, it will be in your QF directory (e.g. "c:\program files\QSI Corporation\QlarityFoundry\Filespace.qflash")

Since that file is read into RAM when QF starts and saved when QF exits, you can clear it by closing QF, deleting the file then restarting QF.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Thu Feb 10, 2011 2:45 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
I am using Qlarity Foundry 2.60. The .qflash extension was the hint that I needed, I found a couple of files, Filespace.qflash and UserConfigBlk.qflash, they were in my (deep breath):
\Users\<my-name>\AppData\Local\VirtualStore\Program Files\QSI Corporation\Qlarity Foundry 2.60 folder.

The UserConfigBlk.qflash seemed to be the one that held the persistent variables, I renamed Filespace.qflash and nothing changed, but when I renamed UserConfigBlk.qflash, my initialization code ran again.

This will work fine for my tests, I'll just make a note of the filenames since they are in a, thanks to Win 7, uh, somewhat obscure location :)

Thanks,
Mark


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Thu Feb 10, 2011 2:56 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I'd like to close the loop. I had a chance to go back through the version history and change history of Qlarity Foundry to figure out what is going on.

Quite a while ago, I added experimental support to file system and user config persistence. We eventually decided to support user config persistence but not file system persistence. There was some vestigal code left in that created the filesystem.qflash file but the contents of that file are never used.

Additionally, your persistence variable object must have the "SaveToUserDataArea" property set to true. I assumed that this was set to false (as false it the default for that property) and so steered you to removing a file from the file system, while in fact the persistent variable data was saved to the user config block. (In general we recommend saving it to the file system -- there is a fairly lengthy discussion about the advantages and drawbacks in the help for that property).

Given that, then yes the actions you took are the correct ones to delete the file.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Thu Feb 10, 2011 3:07 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Jeremy wrote:
Additionally, your persistence variable object must have the "SaveToUserDataArea" property set to true.

Yes, it was set this way. I'll make a note of that as well. (I kind of inherited this stuff.)
Thanks again.


Top
 Profile  
 
 Post subject: Re: Persisting variables
PostPosted: Fri Mar 18, 2011 1:41 pm 
Offline

Joined: Thu Dec 03, 2009 9:18 am
Posts: 15
Another question about the behavior of Persistent variables...

Lets say I have an array of some size, say:
dim MyArray [5] as float
and I put this in the persistent variables savelist, and so save this.

I am using the SaveToUserDataArea = True, as I want these saved values to remain if I download an updated app.

Now, say I change my program to have a larger sized array, e.g. I expand to:
dim MyArray [10] as float
and download this updated program to a tablet with the old, 5 long, array saved on it.

Now when my new program runs for the first time, and loads the persistent variables, the program thinks this array has size 10, but the saved data has only size 5.

What happens then? Is this an error? I assume that my program shouldn't try and read from the saved data past the fifth element, and I could easily arrange this (e.g. saving the size written as well). If I check the bounds like this, is it ok if my array grows in the future?

Thanks, Mark


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group