Preferred USB Device Class for Test Equipment

[NF6X]

I'm developing a piece of test equipment with a USB interface, and I'd like to see some opinions about the preferred USB device class that engineers would like to see it implement. This particular item will be a temperature measurement interface, but that's not especially relevant to my questions here.

This piece of equipment will have a USB interface, and will support Linux, Mac OSX and Windows. However I implement it, I'll provide Python bindings to support it. I can think of at least three choices for the device class it would implement:

1) USB TMC (Test & Measurement Class): This is an obvious choice because it has "Test & Measurement" right in the name. Some sort of software layer would be needed to talk to it, whether they're the Python code I provide, some other code like python-ivi, etc. As I understand it, I'll need to provide a signed INF file for Windows users. Low-level communications would likely involve libusb.

2) USB CDC (Communications Device Class): Making the device look like a serial port has the advantage of letting a user talk to it with any old dumb terminal program, without any custom software at all. All of the targeted operating systems already support CDC devices, but I'd still need to provide a signed INF file for Windows machines to get the usbser.sys driver to talk to it. The protocol might be SCPI or something arbitrary, but that's a separate consideration from what device class is used.

3) USB HID (Human Interface Device): The main attraction of this choice is, if I'm not mistaken, that no INF file is needed under Windows. Custom software would still be needed like in the USB TMC case, most likely using hidapi at the low level.

So, what do y'all think about these trade-offs?

[bson]

USBTMC.

[Lukas]

Definitely USBTMC. It's used by all serious test equipment manufacturers and makes your instrument integrate well with the existing software infrastructure (VISA). With an USBTMC driver installed, all USBTMC equipment effectively becomes plug'n play.

[NF6X]

USBTMC does seem like the way to go after more research and consideration. I'll probably duct-tape together a very dumb CDC implementation for my initial hardware bringup since my microcontroller vendor has already done 90% of the work in their example application code, but then I'll implement proper USBTMC firmware before the product leaves my Secret Laboratory.

Hmm, maybe I should get my hands on at least one piece of off-the-shelf test equipment with a USBTMC interface so I can get experience with USBTMC from the other end of the cable. In particular, I want to get a feel for working with USBTMC devices under OSX, which doesn't include a native USBTMC driver (I think).

[Karel]

USBTMC does seem like the way to go after more research and consideration.

You probably already know this but still, one advice. When your usbtmc implementation is ready, use a script or a small program
to send, very fast,  random different (valid and invalid) SCPI commands to your device and check it for stability.
There are a lots of bad implementations of SCPI in tm equipment that behave badly when you want to use it in another way then it was tested during design.

[NF6X]

That sounds like good advice. And when I can't break it any more, then I can ask for some beta testers to help me find the bugs I missed!