I have a pair of TekPower TP4000ZC DMMs. I like them for a few reasons: they're relatively inexpensive ($36), have 4000-count readouts, run for a long time on AA batteries, and most importantly have RS232 output for automated measurments. There are a few drawbacks, however - one of them quite serious. I put this project together to fix the issues I have with these meters.
First problem: the serial output uses a bizarre protocol. Documented here, the meter continuously sends 14-byte packets encoding the state of the segments of the LCD display. This might be convenient if you wanted to re-create a 7-segment display on a PC-based GUI, but for collecting real data from the meter, it's just plain nuts. I wrote some C++ code to decode this protocol when I bought my first meter a few years ago, and hadn't thought about it much since.
Second problem: the meter just streams these packets continuously. If you want to make sure you have the latest data, you have to continuously read the packets and be wary of any buffering in your system. For programmatic measurements, you need to be able to synchronize the meter readings with external events. For instance, a program might set a voltage going in to a device with a DAC, then want to read the output with one of these meters. If there's any buffering of the data, you may end up with a reading taken before the DAC was set: that's just plain wrong. The obvious solution is to flush the serial line before reading, but there's another problem: flushing USB-to-serial converters under linux doesn't work reliably (does it work anywhere?).
I struggled for a while with multi-threaded PC code that continuously read the serial stream (and tossed the results into the bit bucket) to avoid buffering issues, but it was a real pain and I could never get it to be 100% reliable. Last night, I finally got fed up and figured I could use a cheap arduino nano clone as a USB bridge and protocol translator at the same time. I got the thing working today - most of the time was spent designing the 3D-printed enclosure.
UPDATE 20160823: I think found a way to read these meters reliably using software-only (although the adpater is still useful for other reasons. Read the latest build log for the whole story. I haven't updated this details section or other logs to reflect the new info yet.
The details of the hardware and software are in the first build log. The protocol implemented by the adapter is discussed in another log. All the software and OpenSCAD design for the case are in the GitHub repo (MIT license).
I should note that a different way to solve this problem may be to use sigrok to interface with the meter. I haven't tried, but I suspect that would suffer the same issues with buffering. I figured if I was going to need a USB-to-UART bridge anyway (no true serial port on my desktop PC), I might as well throw the smarts in there, too, and avoid the buffering issue altogether.