Excellent question. A few ideas pop in my head but I’m also wondering what your bigger goal is (since there are usually multiple ways to do things with Opto 22 hardware & software, as you may be figuring out first-hand).
Our microSD card support has some built-in functions that let you load files like firmware, or of more interest to you, the .cdf you mentioned. So if it were me tasked with this, based on what I know now, I would do this:
[INDENT]1) Load the .cdf file via ftp to the R1’s microSD card’s strategy folder. The path would look something like this: ftp://10.0.0.39/sdcard0/STRATEGY/STRATEGY.CDF [note the 8.3 filename]
Restart the R1 so it looks for that file on bootup
[/INDENT]
Relevant links:
[INDENT]1) The SNAP PAC R Series User’s guide, form 1595, see bottom of p. 62 on “Updating, Running, or Testing a Strategy”
On my way in this morning I thought of another option for you. If you had logic in your strategy that ran when you set a particular flag (perhaps from your HMI), you could restart the R1 based on that trigger by having the logic in the strategy write that 5 mentioned above using the PAC Control command: WriteNumToIoUnitMemMap(I/O Unit, Mem Address, Variable). This should be done with caution, of course.
Thank you for all of the good information. I am in the process of reviewing all of this to see what might work.
To give a little more detail:
I have no issues using windows to create the configurations in PAC Manager or strategies in PAC Control. However, these controllers are used in systems that don’t typically have any windows PCs connected to them but do have Linux systems attached. Then I started to realize PAC Manager creates a single file (.otg) and PAC Control can have everything defined in a single file (.cdf) and so if there is a simple way to transfer this two single files to a location on the controller using Linux it would make it very easy for us to update files as necessary for units that are in the field (for when we make changes as we do on occasion).
Typing all of this made me think of one more question: Does the *.cdf file really have the whole strategy defined in it? Or maybe the correct way to ask: Is the *.cdf file the strategy?
I have a lot of reading to do and will let you know what I end up trying.
Typically an *.otg file is used to configure an I/O Unit. Your strategy has I/O Units in it which get configured when you build/run the strategy (either by importing an *.otg or configuring the I/O Units in PAC Control’s configurator).
The *.cdf (controller download file) [I]is[/I] the strategy. Most of what you can configure in an *.otg file (point names/types for example) would also be included in that *.cdf. There are a few other things you could configure in an *.otg file (such as a value to write to the scratch pad) which would not necessarily be part of your strategy, unless you’d written code to do something similar.
What sorts of configuration information do you have in your *.otg? Both types files are just text, FYI. Not normally something one would want to look at, but there have been occasions when I’ve had the need/desire to have a look.
The main reason I think I need an *.otg file is because we are configuring some scratch pad values in PAC Manager that aren’t defined in PAC Control Strategy and also we are setting up Event messages, alarm events, digital events, and snmp rules in PAC Manager.
An interesting aspect to this project is that we are using PAC Manager settings to create SNMP access so that our linux interface has a means to communicate with the controller on some level, mainly just wait for traps to be sent then collect a range of data all using SNMP. This is completely independent of the strategy which is written to manage our system.
I did get curious the other day and opened the files in a text editor to see what they looked like. Although not very pretty to look at, I could see how the files are structured.
Ah! There’s also the “image” file, which is basically a list of all the values stored to flash, and the mem map address where they go. Can be generated from PAC Manager under Tools > Import/Copy I/O Unit.
It wouldn’t be too hard to write some code for your Linux box (or a chart within your strategy, for that matter) that would parse an image file and write the data to the addresses also listed in that file. Might that be an option for you? Are you going to have a bunch of these devices that are identical?
The idea behind this “image” is to help you clone the configuration of one Opto 22 mem map device to another piece of hardware that needs to be configured identically.
