So I thought I had all my ducks in a row to update my SNAP-PAC-R1 firmware to R10.4d without losing my calibrated points. I backed up my control strategy, then used OptoTagPreserve to upload my tags. I updated the firmware using Manager and then I’ll admit, at first I forgot to re-load my strategy. So I ran the restore function of OptoTagPreserve and it obviously failed because of the missing tags. I loaded my control strategy by selecting debug in Control (I didn’t run it). Then I went back to the command line and attempted again to restore my tags. It progressed normally until it just seemingly hung at “Restoring tags…might take some time!”. I’ve got maybe 100 tags, which seeing what this equipment is designed for, has to be a small quantity. It also took a relatively short time to create the file during the upload process. I waited ~7 hours before killing it with ctrl+c. I reloaded the firmware and control strategy and it’s now sitting at the same thing in the command line.
Any advise would be appreciated. I haven’t updated the software to 10.4003 yet, I was going to do that afterwards. I have another controller to update but don’t want to touch it until this is sorted - there are a lot more tag values I don’t want to lose on that one.
That does not sound right… I have never heard of it hanging like that…
Tag preserve has been so reliable for me that I put the commands into Node-RED (running on Windows) to do it automatically for me.
Back to your setup. You did the thing I was thinking, ie, another firmware update (ie reflash it to a known ‘blank’ state) and try again, but no luck.
So, this makes me think about the actual tagpreserve file… Did you encrypt it? If not, you should be able to open it and see the data and see if anything is a bit scrambled or a line feed where there should not be one.
It might be repairable and thus restore without hanging.
I ran the upload with no options and didn’t add any encryption as far as I know. It does display scrambled when open in notepad. Based on the documentation, I was under the impression that was normal. I also noticed the documentation wants the filename in quotes, but it was generated with underscores that don’t require quotes. I figured maybe the doc just didn’t catch up to the script updates. I removed the underscores and put the filename in quotes just in case maybe tagpreserve was looking for the filename with spaces instead. In both cases the program ran seemingly normal until the hang at “Restoring tags…”.
As a safety net, I decided to screen-shot the heck out of my second controller’s inspect screens and try to update it’s firmware and back up tags using the OptoTagPreserve utility. Well, on this unit, it was successful on the first try, however none of the offset or gain values re-populated as expected. I’m not sure if it’s normal behavior, but the point names and scaling didn’t update in the inspect window until I ran the strategy in Control. I’d think that would happen once the OptoTagPreserve restore command was executed successfully. Did I need to use Send Configuration to I/O Unit? Is that also possibly why my cal values didn’t populate?
I’ve written off the failed attempt on the first unit to not having updated the Project software first, that’s the only logical explanation. I’m still hoping I did something wrong or missed a step because it seems odd that we’d have to re-enter offsets/gains each time there is a firmware update. Even Tech Support had said the utility would do it when I emailed them months ago.
Unless you have your strategy populate your offset and gain values from a table that is persistent in the strategy, why would they be backed up and restored?
OptoTagPerserve is what it’s name describes. PAC Control strategy tags.
If you want offset and gain (and other similar stuff), you need to use PAC Manager to backup the whole I/O unit.
Cut / paste from another unrelated thread I mention it in.
Note point 2.
