Actions
Forum Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 339 subscribers
  • Views 2973 views
  • Users 0 members are here
Related
See a helpful answer?

Be sure to click 'more' and select 'suggest as answer'!

If you're the thread creator, be sure to click 'more' then 'Verify as Answer'!

Remote Control of MP730027 Digital Multimeter

peter

I recently bought the Multicomp Pro MP730027 benchtop Digital Multimeter and am having difficulty controlling the instrument using the USB or LAN interface and the DMMEasyControl software which came with the instrument. After launching the app and clicking Control > Connect, the program hangs for about ten seconds and then closes. I have tried it with both USB and LAN interfaces and the same thing happens. It has never, as far as I recall, worked with the USB interface, but occasionally, in the early days with the LAN interface.
I have not (for various reasons) tried to use remote control for a month or more. Two things since then which may/may not be significant are 1. I recently upgraded to Windows 11. 2. I bought a RS Pro programmable power supply which uses a similar app (EasyPower) and both instruments are seen by Device Manager as 'USB Test and Measurement Device (IVI). I can control the RS Pro power supply via USB, but not via LAN. Any ideas?

Parents
  • 0

    I have the MP730028, which has the same backend. On mine, LAN never connects. The UI shows the cable is connected, but the lights never flash. I have tried with different cables and have verified the cables work with other devices.

    USB, does work, but I have only been using it with VISA. I haven't tried to use it with either the IVI driver or the DMMEasyControl software.

    On other Multicomp stuff, I have had to use Zadig to change the USB driver to libusb-win32 for their software to work. But I'm hesitant to suggest that because sometimes that is difficult to undo if it doesn't work.

  • 0 in reply to baldengineer

    Oooh I can't help myself here....

    [RANT MODE ON]

    You see, USB, it's a well defined standard. On almost any other operating system in the world there is little need for USB 'drivers' because every USB device identifies itself as a class of device, and describes all it's in- and out- points in great detail. It describes the direction and content of the data, whether it's polled or interrupt, what the data means, how it's interpreted, it's length etc etc etc. Almost every conceivable class of device is covered by the USB specification.

    The operating system should just go "Yeah, you're a <Whatever> CLASS device" and just work, by properly implementing that class. 

    However Windows - for some unknown reason - mainly uses the VID and PID to decide what driver to load... even for well supported USB classes. It's madness and should be banned.

    Even if you invent a new device which doesn't fit into any existing class, it still fits into well known classes of how the data is actually transferred, and the USB Device block, transferred on connection, describes all of this. So you STILL shouldn't need a driver. You could even do it all in user-space. 

    [RANT MODE OFF]

Reply
  • 0 in reply to baldengineer

    Oooh I can't help myself here....

    [RANT MODE ON]

    You see, USB, it's a well defined standard. On almost any other operating system in the world there is little need for USB 'drivers' because every USB device identifies itself as a class of device, and describes all it's in- and out- points in great detail. It describes the direction and content of the data, whether it's polled or interrupt, what the data means, how it's interpreted, it's length etc etc etc. Almost every conceivable class of device is covered by the USB specification.

    The operating system should just go "Yeah, you're a <Whatever> CLASS device" and just work, by properly implementing that class. 

    However Windows - for some unknown reason - mainly uses the VID and PID to decide what driver to load... even for well supported USB classes. It's madness and should be banned.

    Even if you invent a new device which doesn't fit into any existing class, it still fits into well known classes of how the data is actually transferred, and the USB Device block, transferred on connection, describes all of this. So you STILL shouldn't need a driver. You could even do it all in user-space. 

    [RANT MODE OFF]

Children