Learn more about the Opto Memory Map Protocol—a powerful method of interacting with Opto 22 controllers

OptoMMP works with everything from SNAP PAC brains to the latest groov products. Let's go over some of the basics about what OptoMMP is and how it works.

In my last blog post I showed how easy it can be to work with OptoMMP using tools built right into groov Manage. To add to that resource, this follow up provides an overview about what OptoMMP is, how it works, and why you might want to make use of it.

First and foremost, Opto’s Memory Map Protocol (OptoMMP) is a method of communication that follows the IEEE 1394 standard. This is the same standard that is implemented in FireWire, that was initially put into development by Apple back in 1986. Since then, it has been expanded by over 250 patents from many technology companies, and continues to be used in production equipment today. It was designed from the ground up to provide reliable high-speed data transfer, and unlike USB, it shares connection management among devices, rather than having one device as the host.

The OptoMMP implementation of this standard is integrated into all Opto controllers and brains from SNAP PAC to groov EPIC and RIO. What it’s mapping is an explicit logical address that can be written out like a street address, and associating that with a physical memory location. What is at the location? It could be I/O, configuration, scratch pad, or informational values. The physical location itself determines the logical hex address, so it can be calculated by following certain starting addresses and offsets, like counting street numbers as you pass each house.

So now we have a map of addresses to physical memory locations. What we read or write to these various locations goes straight into memory, making OptoMMP a very performant method of control and data acquisition. The calculation of the address is pretty straightforward, so the most complex part is interpreting the binary value that is stored at that address or building the binary package to be delivered to that location.

The address for a given point is easy to find because information is stored sequentially. For example, all analog I/O points are stored in order of the module slots and channel numbers. Because each analog value takes the same amount of memory, the offset is consistent. Given just the starting address of the reading or writing analog area and the size each point takes, the addresses can be found with simple formulas, or the tools mentioned in the previous post.

Moving on to the more complex part, you don’t have to worry because both the address calculation and unpacking the data stored at that location can be avoided entirely. While it can all be manually custom programmed, the tools in groov Manage that I went over in my last post and Opto’s Software Development Kits (SDKs) and libraries handle all of that for you.

There are SDKs for .NET, C++, and Python MMP programming languages, where each of these options have functions to calculate memory addresses and pack/unpack the data at those addresses. If you do want to write your own custom program or library to use OptoMMP directly, you are more than welcome to. The entire protocol is very thoroughly documented in the OptoMMP Protocol Guide [Form 1465].

While it’s not critical to understand the intricacies of how OptoMMP works under the covers, why it was implemented, or where it came from, it is an incredible communication protocol that can be a very valuable tool in just about any Opto application. If you'd like to share an application using OptoMMP, want to see how others are using it, or have any questions, be sure to check out the OptoForums.

And as always, happy coding!