Hello,
I have a couple of DMMs (about 15 years old) with serial interfaces, so I decided to write TestController configuration files for them.
(You can see everything at
https://github.com/dougbert-b/TestControllerStuff )
The first DMM is a Protek D440, which has some extra settings for automotive use, for example RPM.
It streams a short ASCII message at 1200 baud several times a second, with a numeric code for the mode, followed by the actual value.
I used the DMM2 driver, and I got it working pretty quickly. The only issue is that the meter has an "RPM" mode, and I don't know
if it is possible to define that data type in the DMM2 driver. I see how that can be done in the SCPI and Block drivers using the #value
statement, but that apparently is not supported in the DMM2 driver.
The second DMM is a Metex ME-11. Its serial port works at 600 baud, and every time any character is sent to it, it replies with
a short ASCII line, for example "DC 046.3 mV<CR>". This ought to be really easy to support, but I have tried writing 4 different styles of
config file, and none of them work really well.
My first attempt used the SingleValue driver. It can properly read and display all the V, I, R, and diode data, but it is very laggy, and in debug mode
there are a lot of timeout messages. (When I look at the data stream with a serial port debugger program, it is well formatted and error-free.)
I tried adding a #readingDelay statement , but it had no effect. I am wondering if 600 baud is simply too slow, and TestController is getting confused by it.
My second attempt used the DMM2 driver. It suffers from the same problem as the SingleValue version: lots of lag and timeout messages.
My third attempt used the Block driver. This version reliably polls and reads the incoming messages (I can see the bytes in the debug messages),
and the #pollPause statement works like it should. I even managed to figure out how to get #askModeMathFormat to parse the data stream and
specify the correct #value to use. But I am stuck on one thing: the meter can send "OL" or "O.L" for an overload condition, and this freaks
out the #rxFormat statement. Is there a known way to handle this in the Block driver?
My fourth attempt uses the AsciiBlock driver. I suspect that it will be easier to deal with the "OL" issue in this driver, but it has one fatal flaw: the
AsciiBlock driver does not seem to support the #pollPause statement, and the rapid polling overloads the meter, and it lags and eventually freezes.
Is this simply a bug in the AsciiBlock driver? Is there any workaround?
I welcome any advice. You can see all my code in the Github repository I mentioned above.
Thanks,
Doug