Documentation for the socket API used by the iPad app?

[davtek]

Hi,

Is there documentation and/or boiler-plate code (pref. Python) for the socket API used by the iPad app?

This would open up for a whole world of nice desktop-lab / continious integration setups.

Thanks /d

[SasounT]

Hello 

Could you be more specific as to which API and version you're using?

Thank you

[davtek]

I'm not using it, right now looking for the documentation so I can use it 🙂

It's for the VirtualBench hardware. Since the ipad app is not feature-complete, I want to build my own control-software. 

There should be an API for this, same one as the ipad uses to talk over wifi/IP to the NI hardware

thx /david

[SasounT]

Hello

See if this link to another forum post helps:
http://forums.ni.com/t5/VirtualBench/Announcing-free-firmware-update-version-1-1-adds-SPI-and-I2C/td...

There have been recent changed to the API to allow usage of Python and C, and the download links can be found there.

Thank you

[bstreiff]

The only programmatic access that exists today is via the VirtualBench LV and C APIs (the C API consists of a precompiled binary for Windows x86/x64 only). The Python API mentioned upthread wraps the C API.

There's presently no official documentation on the underlying socket API.

[davtek]

hmm, that seem to only be for Windows.

I'm after the socket API (TCP/IP) that goes over Wifi, i.e. iPad -> Wifi AP -> VirtualBench

[davtek]

Hi Brandon,

I believe the socket API is completely separated from the C API (that runs over USB).

NI:

 - Why is the C API precompiled? We need the source-code for this as we need to run this on Linux and Mac.

[bstreiff]

I'm guessing you're a software developer or at least familiar enough with open-source projects to be willing to compile things yourself, so I'm assuming that level of technical knowledge in this reply. If that's not appropriate, please let me know.

For clarification (since you seem to be using them interchangeably), I'm referring to "API" as the binary DLL components and corresponding headers (for C) or VIs (for LabVIEW). The on-the-wire[1] packet formats are a "protocol".

We maintain compatibility across versions with the LV and C API layer. We do not necessarily maintain compatibility at the protocol layer (the thing you're asking for). We could in theory change details about the underlying protocol from version to version or between different models of VirtualBench hardware[2].

As far as "why is this precompiled and not open-source": The LV and C API DLL components encompass more than just an implementation of the USB and TCP communication protocols[3]; specifically, it also handles device discovery, storing connection information, authentication, and some data processing to account for hardware differences. Some parts are based on open-source technologies[4] but some of them are based on proprietary NI IP. Because of this, it's substantially easier for us to release binaries than source.

That said, a request for public documentation on the protocol does not seem wholly unreasonable (in fact, it seems in-line with other product lines, such as the MHDDK), but it does require developer time and effort to compile said documentation. I've added it to the feature backlog, but note that I cannot give a timeline on when or if that work will be scheduled.

[1]: Or "on-the-wireless" as the case may be.

[2]: In fact, due to hardware differences there are some such differences between VB-8012 and VB-8034 that the API DLLs abstract from you.

[3]: In reference to your previous post: The LV and C APIs work with both USB-connected and network-connected VirtualBenches, not just USB.

[4]: For example, the communication protocol is based on Apache Thrift. TCP uses a different transport than USB, but the messaging is fundamentally very similar.

[davtek]

Hi Brandon,

Thanks for your detailed reply. Quick follow-up:

- Understand the reason for the API libs being closed source. Reason to this question was the fact these libs aren't built for Linux and macOS. If they were I'd much rather use them pre-compiled than having to setup cross-compile toolchains for this...

Can you explain a bit why many other NI products have Linux API's available, but not the VirtualBench hardware?

 - If I understand you correctly. The iPad app uses the same API's as the what's already documented for the Windows DLL's? If so that sounds great as we could potentially roll our own network-based integration to overcome the current windows dll limitation.

The only thing here is that we would still have to Wireshare and reverse engineer how the discovery, handshake and such works before you have a connection up to the VirtualBench HW, correct?

- The LV and C APIs work with both USB-connected and network-connected VirtualBenches, not just USB.

This is good news. So Wifi, Ethernet, USB all uses the same protocol under the hood. Let me know how we think we best could find a solution to run "simple" communication over wired ethernet (assuming no DLL's can be run).

Our use-case is "CI build-pipelines" that we run in our Gitlab setup, so every commit deploys code (actually via rasperrys + jtag/usb/serial dep. on target), right after we want to sequence a few things by controlling the power-supply section of the VirtualBench and just read-back some basic I/O and capture a scope-plot or two in case something fails.

best david

[bstreiff]

- Understand the reason for the API libs being closed source. Reason to this question was the fact these libs aren't built for Linux and macOS. If they were I'd much rather use them pre-compiled than having to setup cross-compile toolchains for this...
Can you explain a bit why many other NI products have Linux API's available, but not the VirtualBench hardware?

It's a combination of not wanting to do an "API-only" release (that is, without an app) for some platforms, along with macOS and Linux being further down the priority list. The VirtualBench application is considered the main differentiator (and thus the main focus) of the product, and having API support only on certain platforms could result in confusion especially from a support perspective.

From a technical aspect, the Linux case is also complicated in terms of support-- there isn't one "Linux", there are a number of different Linux distributions on different architectures with different compilers and versions of the C/C++ runtime libraries (on Linux platforms, the C/C++ runtime is a system component, unlike on Windows). The VirtualBench driver codebase is implemented using C++11 features, which require a newer libstdc++ than what several distros on the supported-distros page have.

- If I understand you correctly. The iPad app uses the same API's as the what's already documented for the Windows DLL's? If so that sounds great as we could potentially roll our own network-based integration to overcome the current windows dll limitation.
The only thing here is that we would still have to Wireshare and reverse engineer how the discovery, handshake and such works before you have a connection up to the VirtualBench HW, correct?

There are, sadly, limits to what I can confirm or deny with regard to reverse engineering. But some details that are already disclosed (because we use open-source components to implement them): the protocol is based on Thrift, and network discovery uses Apple mDNSResponder.

- The LV and C APIs work with both USB-connected and network-connected VirtualBenches, not just USB.
This is good news. So Wifi, Ethernet, USB all uses the same protocol under the hood. Let me know how we think we best could find a solution to run "simple" communication over wired ethernet (assuming no DLL's can be run).

Wifi and Ethernet are identical. USB is slightly different (mostly in request framing), but it sounds like you care more about network than USB.

Our use-case is "CI build-pipelines" that we run in our Gitlab setup, so every commit deploys code (actually via rasperrys + jtag/usb/serial dep. on target), right after we want to sequence a few things by controlling the power-supply section of the VirtualBench and just read-back some basic I/O and capture a scope-plot or two in case something fails.

First I've heard of someone doing that! That sounds seriously cool.

That said, that does illustrate the "many different Linuxes" point above; not only would you need a precompiled binary, you'd need one for ARMv6 (RPi 1 and Zero) or ARMv7 (RPi 2 or 3), and it would need to be with a matching -mfloat-abi. The testing matrix becomes quite a mess.