OptoScript and SNMP Permission Settings

Code Samples and Tips
1

This is a long post for two short questions, but I need to give a little background
or you’ll be asking, “Why are you doing this?”.

We use SNAP-PAC-R1 controllers in our products, which are very large
computer systems. We use the R1s to control water valves and blowers
that keep the computer systems cool. The controllers connect to
a control network of 100% Linux-based systems.

In my OptoScript strategy, I write the following SNMP parameters
which allow the Linux computers to send “commands” to the R1s
using SNMP. By sending a command, I mean the Linux computers
write a value to the SNMP-accessible scratch-pad registers in the R1s.
For example, if a Linux computer writes a value of 1 to a specific
scratch-pad integer register, the R1 will reset the stored maximum
values for a specific range of I/O points.

// SNMP Trap Version
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c030c, 0);
// SNMP Trap Destination Port
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0308, 22162);
// SNMP Authentication Trap 0=disabled 1=enabled
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0060, 0);
// SNMP Cold Start Trap 0=disabled 1=enabled
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0064, 0);
// SNMP public community name, read, write, and trap enables
Manager_OptoMPPStatus = WriteStrToIoUnitMemMap(LOCAL, 0xFFFFF03c0068, “public”);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c007c, 1);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0080, 0);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0084, 0);
// SNMP xxx community name, read, write, and trap enables
Manager_OptoMPPStatus = WriteStrToIoUnitMemMap(LOCAL, 0xFFFFF03c0088, “xxx”);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c009c, 1);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c00a0, 1);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c00a4, 1);
// SNMP Host settings
Manager_OptoMPPStatus = WriteStrToIoUnitMemMap(LOCAL, 0xFFFFF03c0168, “xxx”);
Manager_IPAddressAsInt = IpAddressStringToInt32(“172.26.0.1”);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c017c, Manager_IPAddressAsInt);
Manager_OptoMPPStatus = WriteStrToIoUnitMemMap(LOCAL, 0xFFFFF03c0180, “xxx”);
Manager_IPAddressAsInt = IpAddressStringToInt32(“172.26.0.10”);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c0194, Manager_IPAddressAsInt);
Manager_OptoMPPStatus = WriteStrToIoUnitMemMap(LOCAL, 0xFFFFF03c0198, “xxx”);
Manager_IPAddressAsInt = IpAddressStringToInt32(“172.26.0.17”);
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF03c01ac, Manager_IPAddressAsInt);

This is how I understand things to work. Let me know if I’m not correct:

In manufacturing, we place my strategy on a microSD card, place that in the R1 and
then power the R1 on. The R1 runs the strategy which sets the SNMP
parameters and writes them to memory (flash memory?). Access does not
work at this point, so we wait 3 minutes, and then power-reset the controller.
This second time, the R1 firmware reads the SNMP parameters that were stored to
memory, and then access works correctly. Then the system ships to the field
with the strategy installed and SNMP access working.

This has been worknig fine, but we just ran into a problem where
in the field, the SNMP access isn’t working. I remotely read the controller’s
memory locations and everything is set the way they are supposed to be.

My only guess as to what happened is that during shipping, the SNMP settings
were somehow cleared from memory. Then, in the field, the R1 has only
been turned on once so the strategy wrote the SNMP settings to memory,
but since the controller has not restarted since then, the settings have
not been read by the firmware.

So, my first question is, where are the SNMP permission settings stored and is it
possible to loose them if the controller is powered off for an
extended period of time?

My second question is, I also use the following OptoScript code in
my strategy to back up the IP address and configuration information.
I thought the SNMP permissions would be backed up in the
/sdcard0/opto22/config/config.cfg file also, are they?

// Write configuration file to microSD card
Manager_OptoMPPStatus = WriteNumToIoUnitMemMap(LOCAL, 0xFFFFF0380000, 0xd);
CND_STR_Active[CND_STR_ipAddressBackup] = Strategy_ConditionOn;

(As a side note, I’m in the proces of changing my Linux-computer to R1
communication to use MODBUS instead of SNMP. So far, it is much
faster and more reliable. But, there is code written by other people that
still requires the SNMP communication.)

2

Hi Don Adams,

There have been several changes in the firmware related to how the microSD card works, so one of my first questions for you would be: what firmware version are you running on those R1s? (Our Product Support Team would want to know this too.)

Since you mentioned a change in behavior (or perhaps a difference between how some R1s behaved vs. others?) I’d be curious to know if those differences correlate to firmware versions.

Let me address a couple of the questions on flash memory you ask here, and also encourage you to check out this SNAP PAC Memory Usage Tech Note which is super handy.

You mention these SNMP parameters might be written to flash memory, do you have the line of code for that part? (Just before where you wait 3 minutes?) Writing to flash does take some time, though I’m guessing that very-long 3 minute value is to wait for multiple R1s?

Also, forgive me if I missed this part, but do the microSD cards ship with these R1s? If so, I suppose those microSD cards, during shipping, could possibly have jiggled. Did you remotely check to see if you can see anything on those card(s)? (I’d use a Firefox browser with ftp://youriphere in the address line, or PAC Manager.)

I’m guessing that your “store to flash” part is something similar to your “write config file” command, but rather than sending that 0xd op code you’re passing 0x3? This would be the equivalent of using PAC Manager’s Tools > Inspect > Status Write, Operation: “Store Configuration to Flash.” (As documented in form 1465 here.)

Since I don’t know the answer to that question, I’m not sure the answer to “where are those values stored” (since it depends on how you stored them).

Toward your second question, form 1465 here promises op code 0xd “Stores the controller’s IP address and configuration data on the microSD card.” I believe that should include the SNMP settings. Do you have reason to believe it’s not doing that?

I’m also not clear on if/why you’re storing those values to the microSD, to on-board flash, and also have those parameters hard-coded into the strategy? I’m a bit fuzzy on the need/function of your microSD card in the mix. I’d be inclined to get rid of as many moving parts as possible, especially since these are getting shipped elsewhere.

Sounds like an interesting application! I’d love to understand it better so I can make better suggestions here.

Thanks,
Mary

3

Our configuration is very unique I’m sure. Since we have a control network of only Linux-based computers, we cannot use PAC Manager or PAC Control in the field. My solution for this is to use the microSD cards. The microSD cards are shipped in the systems and they serve two purposes: remote strategy upgrades/backup and configuration backup.

I use PAC Control on my Windows PC to create a controller download file of my latest strategy. This *.cdf file is then the master and is what is used to upgrade controllers in the field. To upgrade a strategy in the field, we use a secure shell (similar to a DOS command window) to login to the remote Linux system. Then we use ftp to transfer the *.cdf file from our system to the remote Linux system. Then we use ftp again to transfer the *.cdf file from the remote Linux system to the microSD card on the R1 controller. Then, we use a C++ program on the Linux system to power-reset the controller (basically the Opto 22 SNAP Ethernet I/O Command Line Tool). The R1 reads the new strategy off of the microSD card on the restart. This may sound cumbersome, but it actually works very nicely for us. Everyone was very happy when I showed them how we could do this without requiring a Windows laptop or a person on site.

I use the “write config file” command to backup the controller’s configuration to the microSD card. If there ever is a problem where an R1 controller needs to be replaced, we remove the microSD card from the bad controller and place the card in the new controller. When the new controller is powered on, it reads the configuration stored on the microSD card and the strategy stored on the microSD card. The new controller then starts working as if it was always there.

Thanks for the SNAP PAC Memory Usage Tech Note. My question is, when you write to the SNMP permission parameters (using OptoScript or PAC Manager), where do these parameters get stored? I assume that if you write these SNMP permission parameters, it requires a power-reset of the controller for the firmware to restart and actually implement the parameters. Maybe that is not a correct statement? I’ll have to do some more testing.

I think this problem was some type of glitch as we haven’t had any other reported problems yet. I’m just trying to figure out what may have caused this glitch.

All controllers are currently at R9.2c

4

Ah! Thanks for the additional info. Glad to hear all the controllers are using the same firmware–that will rule out any differences in microSD support from version to version (there have been various changes made to that feature over the last few years).

You’re correct, as mentioned in form 1465: “Note that SNMP configuration must be stored to flash memory and the I/O unit restarted for it to take effect.”

As far as where this info gets stored, initially it would be in volatile memory with the rest of the memory map. Then when you write to address F0380000 like you mentioned above, sections of the memory map (including this SNMP config info) get written to… the “where” will depend on your firmware version and the op code written. Also from 1465, here’s what the different op codes do, 0x03 and 0xD are relevant here:

[INDENT]0x03 —Stores all configuration data to flash memory, so it is restored when the device is turned on.
CAUTION:
If you have firmware 9.0 or newer and a microSD card is present, and if the card already has IP address and configuration data stored on it (see op code 0D), code 03 also overwrites the configuration data and IP address on the card with the new configuration.
Exception: On a controller using Secure Strategy Distribution (SSD), configuration data is stored to flash but not to the microSD card. Other data files on the microSD card are not affected. If you have older firmware versions, nothing is saved to the microSD card.

0x0D —Requires firmware 9.0 or newer. Applies only to devices with a microSD card slot and a card in place. Stores the controller’s IP address and configuration data on the microSD card.
Exception: Data is not stored to a card in a controller using Secure Strategy Distribution (SSD).
[/INDENT]
This one could also be handy (and can be done programmatically, with caution–don’t want to get stuck in a loop where the strategy is constantly rebooting the controller); you’d need to set some kind of persistent flag to know if it’s been done already.

[INDENT]0x05 – Reset hardware, which is just like cycling power to the device. If point configuration information has not been stored to flash or flash has been cleared (op code 04), points are reset to defaults. After a hardware reset, the device waits for a Powerup Clear before communicating.
[/INDENT]

Of course, you also need to use those other “write to flash” commands very carefully if you’re doing it in code, since you could very quickly physically where out the internal or microSD card flash if you accidentally wrote it a gazillion times in a loop or something.

Note that, as I mentioned above, there have been some changes to how the microSD card gets handled, and it’s possible that the manual(s) have not caught up to those changes. However, if you’re certain all the controllers are running the same version of the firmware, and most are working as designed, then I’m not sure what else to check.

Have you contacted our friendly Product Support Team about this yet?

-OptoMary

5

Thanks for all of the information. I have not contacted the Product Support Team about this particular inicdent. I have contacted them in the past and they have been very helpfull (as are the well-written documentation, web site, and forum replies from Opto22).

So, to recap, here is what my strategy is doing:

  1. The strategy is loaded on a new microSD card and put in a new controller. Then the controller is powered on.

  2. The strategy sets the SNMP parameters as one of the first things it does. (The strategy does not issue an 0x03 command ever. It just sets the SNMP parameter memory-map locations as shown in my first post on this thread.)

  3. The strategy has a delay of 90 seconds (while other loops start running) and then issues the 0x0D command which backs up the configuration data to the microSD card.

  4. A manufacturing person waits 3 minutes (just to be sure everything is finished writing) then power-cycles the controller.

  5. On restart, the firmware reads the configuration information from the backup file on the microSD card and the SNMP access is working.

  6. The system eventually gets powered down and shipped to the customer site.

  7. On the customer site, the system powers on and the firmware reads the configuration information from the backup file on the microSD card and the SNMP access is working.

But, for some reason, on this one controller, it didn’t work. So, I’m tring to make sure my thinking is correct here. Should I submit this last post to the Product Support Team?

6

Yes, I’d recommend you get in touch with PSG so they can help you troubleshoot and resolve it.

7

PSG confirmed that my thinking was correct. I’m going to write this one
off as a glitch that may not even be the R1 controller’s fault. Here’s
some other suggestions from them:

It looks like your steps are correct, which is confirmed by the fact that this
procedure normally works for you. Please see page 58 of the R1 User’s Guide
for details about minor differences in microSD features between firmware R9.2b
and R9.2c. It also discusses the blink codes you will see during the process
and when it is complete. By monitoring the blink codes, you can know for sure
when the process is complete rather than waiting a fixed amount of time, like
3 minutes.

One thing you might want to do is check the return code from each of the mem
map write commands to make sure they completed successfully. You could also
provide a visual indication to the manufacturing person so that he can know
when this part of the strategy has completed and was successful. If you are
not currently using the serial port on the R1, you could send strings to the
serial port at intervals in order to blink the Transmit LED. Otherwise, you
could send a pulse train to an unused digital output point in order to blink
the LED.