USB-6421, python + macOS

[labby-dab]

seems that the usb driver part (nidaqmx) is for some reason a closed binary, no documented API to capture data directly from the USB-6421

why not just provide a standard protocol or native python source + libusb to talk to these DAQ's?

...imagine in 5+ years when you need to use these with an operating system not supported by legacy drivers. you're doomed and need to buy new hardware. happened me many times with other test-gear vendors, so no very picky about ensuring the usb bridge being documented and not closed source / in binary form

[labby-dab]

I want to use USB-6421 but refuse to use a closed source binary (company policy) to talk to it.

why isn't there a documented API, like a socket pub/sub or open PyVISA implementation to these DAQ's?

[labby-dab]

bump @NI team?

[santo_13]

Not from NI.

In general, it is NI's IP, and they don't intend to give away their driver details, as long as the users can use it through their dll. And a lot of simplification and error checking happens in the driver layer.

[santo_13]

Why is it company policy not to use closed-source binary?

Literally, all paid software is closed source binary, and you still use them (MS Office apps, Adobe etc.,)

[labby-dab]

also lots of bugs may happen in that layer that we can't fix ourselves, so high risk

just look at the number of issues over at github

I would be happy if there was a raw API alternative to capture the ADC's your own way.

second best would be if they decouple the USB part with the serialization-gateware. just let one link up one or many usb-endpoints -> push to binary -> get parameterized data out.

since it works on linux, adding macOS wouldn't be too much work for NI

[labby-dab]

our production-lines may run for 5-10years. 

many times in the past, we've been forced to change (throw away) measurement gear from various audio-test companies as well as RF-test / spectrum analyzers.

last time it happened was when archARM64 came, and the RF company refused to provide new binaries for their middleware usb driver....

our option? start to buy old computers off ebay, no thanks

this is way. call it insurance, safety, longevity.

just the fact that NI doesn't have ARM binaries for macOS is a sign of risk

[santo_13]

---

@labby-dab wrote:

also lots of bugs may happen in that layer that we can't fix ourselves, so high risk

just look at the number of issues over at github

I would be happy if there was a raw API alternative to capture the ADC's your own way.

second best would be if they decouple the USB part with the serialization-gateware. just let one link up one or many usb-endpoints -> push to binary -> get parameterized data out.

since it works on linux, adding macOS wouldn't be too much work for NI

---

We can debate as much as we like but at the end it boils down to whether there is enough business value (enough revenue) for NI to do such a large effort to make things public in a way that is digestible without losing their IP.

[santo_13]

Please refrain from duplicate posts across boards. DAQ is the correct board for this post.
https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/communicate-with-USB-6421-via-open-source-mi...

[labby-dab]

why isn't anyone from NI here replying?

my request is relevant. thanks Santhosh for your insights but please no police work with no constructive replies