The Yoctopuce library as a .NET Assembly

The Yoctopuce library as a .NET Assembly

The most common way to use Yoctopuce modules in an application consists in integrating our library in the source code of the application, in order to be able to interact with the modules through a simple and efficient object oriented interface. But in cases where source code integration is not possible, we have today a new solution to show you: a dynamic library in the shape of a .NET Assembly.

A .NET Assembly enables you to share a set of pre-compiled classes to offer a service, by stating entry points which can be used by third-party applications. In our case, it's the whole Yoctopuce library which is available in the .NET Assembly, so that it can be used in any environment which supports .NET Assembly dynamic loading.

To be completely open, our first aim for this Assembly was to enable the use of Yoctopuce modules into LabVIEW, which precisely allows loading of .NET Assembly. Thanks to this, we have been able to recently offer a complete Yoctopuce library for LabVIEW.

But LabVIEW is not the only third-party environment which can benefit from this technology. You can also use it with MATLAB, WINDEV, or even the Microsoft PowerShell. Therefore, we decided to document this "library" on its own, in order to make its reuse easier. You can now download it from our library page, along with its documentation, in the same interactive format as for the other libraries.

The .NET Assembly content

The Yoctopuce library as a .NET Assembly does not contain only the standard C# Yoctopuce library, as this wouldn't have allowed an optimal use in all environments. Indeed, we cannot expect host applications to necessarily offer a thread system or a callback system, although they are very useful to manage plug-and-play events and sensors with a high refresh rate. Likewise, we can't expect from external applications a transparent behavior in cases where a function call in Assembly creates a delay because of network communications.

Therefore, we added to it an additional layer, called .NET Proxy library. This additional layer offers an interface very similar to the standard library but somewhat simplified, as it internally manages all the callback mechanisms. Instead, this library offers mirror objects, called Proxys, which publish through Properties the main attributes of the Yoctopuce functions such as the current measure, configuration parameters, the state, and so on.

.NET Assembly architecture
.NET Assembly architecture

The callback mechanism automatically updates the properties of the Proxys objects, without the host application needing to care for it. The later can thus, at any time and without any risk of latency, display the value of all properties of Yoctopuce Proxy objects.

Example of use with MATLAB

Here is how to load our Proxy .NET Assembly in MATLAB and how to read the value of the first sensor connected by USB found on the machine:

import YoctoProxyAPI.*

errmsg = YAPIProxy.RegisterHub("usb");
sensor = YSensorProxy.FindSensor("");
measure = sprintf('%.3f %s', sensor.CurrentValue, sensor.Unit);

Example of use in PowerShell

PowerShell commands are a little stranger, but we can recognize the same structure:

Add-Type -Path "C:/Yoctopuce/DotNetProxyLibrary.dll"

$errmsg = [YoctoProxyAPI.YAPIProxy]::RegisterHub("usb")
$sensor = [YoctoProxyAPI.YSensorProxy]::FindSensor("")
$measure = "{0:n3} {1}" -f $sensor.CurrentValue, $sensor.Unit

Specificities of the .NET Proxy library

With regards to classic Yoctopuce libraries, the following differences in particular should be noted:

No FirstModule/nextModule method

To obtain an object referring to the first found module, we call YModuleProxy.FindModule(""). If there is no connected module, this method returns an object with its module.IsOnline property set to False. As soon as a module is connected, the property changes to True and the module hardware identifier is updated.

To list modules, you can call the module.GetSimilarFunctions() method which returns an array of character strings containing the identifiers of all the modules which were found.

No callback functions

Callback functions are implemented internally and they update the object properties. You can therefore simply poll the properties, without significant performance penalties.

Be aware that if you use one of the function that disables callbacks, the automatic refresh of object properties may not work anymore.

A new method YAPIProxy.GetLog() makes it possible to retrieve low-level debug logs without using callbacks.

Enumerated types

In order to maximize compatibility with host applications, the .NET Proxy library does not use true .NET enumerated types, but simple integers. For each enumerated type, the library includes public constants named according to the possible values. Contrarily to standard Yoctopuce libraries, numeric values always start from 1, as the value 0 is reserved to return an invalid value, for instance when the device is disconnected.

Invalid numeric results

For all numeric results, rather than using an arbitrary constant, the invalid value returned in case of error is NaN. You should therefore use function isNaN() to detect this value.

Using .NET Assembly without the Proxy library

If for a reason or another you don't want to use the Proxy library, and if your environment allows it, you can use the standard C# API as it is located in the Assembly, under the YoctoLib namespace. Beware however not to mix both types of use: either you go through the Proxy library, or you use he YoctoLib version directly, but not both!

Add a comment No comment yet Back to blog

Yoctopuce, get your stuff connected.