Instrument Control (GPIB, Serial, VISA, IVI)
non-scpi compliant command strings
They might be register level programmed. Since they are supposed to be used by the IVI style DMM instrument driver, the actual communication underneath is pretty irrelevant and register level programming can make the hardware considerably simpler to implement. However, register level documentation is usually quite hard to get, support for that is very difficult as the average user has not really any idea where to even start with this, so making the documentation proprietary and only hand out for very special requests and under very strict NDAs is not uncommon.
Personally I would consider the choice to base all your instrument control on an uniform SCPI configuration manager as a bit short sighted. There are virtually millions of devices out there and unless you happen to use a standard external T&M instrument, it is very unlikely that it will operate with SCPI commands or even string based non-SCPI commands. A SCPI capable device requires a local processor that can parse the SCPI commands and translate them into the internal register based control logic. Since a PXIe module is in fact a register based device by default and can add a message based interface as option, the direct route is in fact the most simple. The IVI standard is supposed to offer an easy and versatile interface to such devices, except when you try to drive that device with a precooked string based configuration manager.
What if you try to integrate an external device with a manufacturer provided DLL (standard, ActiveX or .Net interface)? What if it is using a different bus than RS-232, GPIB or USB-TMC? CAN maybe, or EtherCAT, Profibus, Ethernet/IP, OPC UA, etc?
I think you will sooner or later anyhow have to consider some different or additional approach. What about a sort of intermediate layer?
Have a string command ToIVI-DMM translator, one for ToIVI-DC etc. Add some extra keyword to your configuration for that device that specifies which translator to use. You say you program in C++, with a little effort to come up with a good design, you could do that easily with little extra effort to your current setup and simply have it load the right C++ class for the according device type.
Basically IVI is a fully class based interface too, so maybe it would be even easier and build on that and implement a special SCPI IVI class to interpret your current device configurations.
@novaktamas wrote:
What's made me really upset a couple hours ago, that I downloaded the API reference of NI-DCPower, which is a whopping 787 pages PDF. If I'm lucky it takes only a couple days to implement the new API, but it can easily be prolonged for some weeks.
You should feel happy. 😁 Some manufacturers make the task of getting any form of manual beyond the Users Manual an exercise in persistence and begging, until you get some kind soul that is willing to make that extra step to search for the document internally and send it to you. Or they make you go through 40 pages of legalize and then sign the document in which you pledge your first born for the case that you accidentally let the document slinger around and get into the wrong hands (which is generally anyone that they haven't been able to force to go through the same procedure). 🙄
