HART via the memory map


#1

All the PAC Project HART commands require the use of a configured Point to interface with HART channels and devices. I found the HART memory addressing in the OptoMMP Protocol Guide starting on page 118, but I’m not sure how to make use of it when all the OptoScript commands require an IO Point as an argument, rather than a hex address to the memmap.

Is there a way to send/receive HART data via the memory map alone? If not, is there a way to dynamically configure IO Points on the fly?


#2

I’m not sure about the hart stuff, haven’t used it but would event messages be something that would work? You can send binary, integer and string data to men map locations either locally or on other devices


#3

Not event messages, but I did find a way to send/receive hart data without a point configured. Thanks also to Julio Jimenez in Opto22 Support for pointing me in the right direction.

The .Net HART toolkit uses the TCP port numbers listed in the OptoMMP Guide to interface directly with the hart modules, without using configured Points. I spent some time with wireshark to see what was being sent/received, and then took apart the included DLL to see how it assembled the command strings.

HART communication is possible from within the strategy using tcp comhandles and TransmitReceiveString, along with the Pack/Unpack string commands. It’ll be a fair bit of work to support all the commands using subroutines and optoscript, but I tested with some hardcoded values recorded from wireshark and it does work.


#4

Hi dwilson,
Just curious, why was the “configured point” method not something you wanted to do? (Perhaps there’s a less labor-intensive way to solve your concern here.)
Thanks,
Mary


#5

The decision was made long before I came along, at levels well above my pay grade. We use Opto products as a data acquisition system on oilfield equipment, and the daq and the process equipment being monitored is mounted on trucks. The company wanted to give the field operators the ability to troubleshoot, diagnose and fix problems with the DAQ without requiring PAC Control, PAC Manager, or any PLC/programming knowledge in general, so the ‘Points’ are uploaded to the string table in the scratchpad, and the strategy parses it on start-up to determine which memmap addresses it should be looking at for the data. All communication between the brains and the PC’s are done via the scratchpad.

We’re stuck supporting a dozen different groupings of I/O requirements, some consisting of several dozen process-plants-on-wheels identical on paper, and every one has it’s I/O cards in different rackslots. Some of them go months at a time without coming back to civilization.

Sadly, doing things ‘the right way’ is the more expensive option at this point, even if we could convince the operations folks that taking away their ability to move things at will was a good thing.