I was wondering if anyone has gotten persistence to work over power cycle. If so do you have any example code?
Edit:
To give a little more background i am trying to write a value from the Dashboard and have it be read on the robot. I have this part working. The problem i am having is how do i get the value to be save so that the next time i power the robot on it has the same value.
I am have been trying to used the persistence.ini on the roborio. However ever time i power the roborio off the values are wiped from the .ini file
While you are waiting for replies, you might consider providing more detail about exactly what you are trying to accomplish. What is the problem you are trying to solve?
I did some additional testing, and I can get it to fail.
I looked for a simple bug/fix, and instead found stuff that confuses/disturbs me.
So I need to powwow with some folks to ask some deeper questions. By changing timings, I was able to get it to work more often, but that isn’t a very good solution.
If you want to do a work around, you can move the ini file to the dashboard and have a DB button that updates the variables with the file values once connection is established. I can help you write this if you don’t get it pretty quick.
Hopefully I’ll have a good conversation, slap my forehead, and have a small edit for you that fixes the issue.
Thanks for looking at this. I will give you suggestion a try. Do you think this will be easier then just reading from an excel file. Do you have any example code for this?
If you haven’t already moved away from the persistence, there are two small edits that make it work well for me.
First one is to open the NILVConfig.lvlib/Save Config File.vi. It is located in vi.lib/Utility/config.llb. This VI opens the ini file, writes the strings, and closes the file. If you wire a True constant to the Open so that it disables buffering, this solves the root of the issue. Whether this is a workaround or the best fix remains to be seen as I’ve also asked for others to look at this.
While looking at it, I saw something else that was a race condition and may also contribute. If you open the NT Server.vi. The initialization code on the left of the diagram reads the file to identify the persisted variables and their values. In parallel, the lower right code is started up to handle dirty variables that need to be propagated to other clients. This is also where the code updates the values of persisted variables to the ini file. While there shouldn’t be any dirty variables for a bit, I’d rather make sure that we don’t update the file before we know which variables are being persisted. The fix is to branch the error wire that connects the init code and the communications loop and connect it to the sequence around the DirtyList handler.
Please let me know if you make the changes, build, and still see the issue.
OK. I have had the edit and I’ve done desktop and RT builds with no issues. So I’ll PM to get more info on your system.
The original fix that is harder to describe is to make the value of the constant platform specific. The conditional disable structure with at symbol of TARGET_TYPE and a value of RT.
The attached image shows the T case. The default is F.
Please let me know you’re able to try that and the results.
Greg McKaskle
