Can VirtualBench be programmed in C (Or anything other than LV)

[johngardner58]

But no .NET or COM (ActiveX)?   That is what we are waiting for.

BTW,   VirtualBench looks very compelling overall,  But a version with a 10-12 bit scope would be helpful.   The speed is fine as are the other instruments.  We deal with small signals and having the extra resolution really helps.

[bstreiff]

Which .NET/COM language are you trying to target?

We don't have a COM-based API, although a COM wrapper could be constructed fairly mechanically around the C API. From C# you could also use P/Invoke to call into the C API.

[johngardner58]

Yes,

It is just the amount of work necessary.   If we have a COM wrapper we can utilize it in any .NET language since .NET supports COM interop very well.

Ideally, though, there would be a .NET library just like available for DAQmx,  DMM, Switch matrix and other NI equipment  (I have a number of PXI cards and a few USB IO and all of them have NI .NET libraries).   COM introduces marshalling overhead and the error reporting facilities are very inferior to .NET exceptions.   Debugging is also harder.  Plus, with a .NET library you can get better intellisense and tool tipping in Visual Studio than with COM as the .NET code generates intellisense content from the XML comment tags.

The libraries should leverage the existing work already available for various discrete programmable power supply, scope, DMM, function generator and multi-io USB and PXI cards.

The .NET language being used isn't important as once you have the .NET DLL libraries any .NET language would work.

[bstreiff]

Intellisense/tooltips aren't too terrible with the C API. 🙂 From one of the MSO examples, in Visual Studio 2012:

We prioritized the C API because we felt that it would more useful, since it can be used directly or have bindings to other non-LabVIEW languages built on it (C# through P/Invoke, C++, there's a person who's posted about Python, etc). That said, I do agree that a proper .NET API would be excellent to have, and the feedback you give (especially your usage description) helps us decide which features to tackle.

[johngardner58]

Thanks,

The main thing is that you already have instrumentation with .NET library support for most of the functions of VirtualBench, so I would integrate with that rather than write something new.   When I first got our PXI-4071 7 1/2 DMM there were no .Net libraries.   A Visual studio component generated the C# file with all the P/Invoke calls  It had horrendous commenting but it worked great.  Later a native .NET library was created.

I am primarily a software developer and project manager, but I am also fluent in hardware.   I look for synergy when ever i can find it.  

We did all our automation in C#.   I found it very fast to develop tests using C#.  I do not even know how to use LV.   One of our automated PXI  testers is used to calibrate an internal proprietary test tool with over 100 external connections.   With a switch matrix, a multi-io card and the dmm I am able to do almost 4000 measurements in 60 tests in 5 minutes.   I am programming both the PXI system and the DUT from the same PC.

[zzcox]

Il est très dommage que ce bel instrument qu'est VirtualBench ne soit pas pilotable à partir de Labwindows/CVI !

A quand cette possibilité ?

[ZachHindes]

---

@zzcox wrote:

Il est très dommage que ce bel instrument qu'est VirtualBench ne soit pas pilotable à partir de Labwindows/CVI !

A quand cette possibilité ?

---

(Warning: My French is really rusty, but I understand your question.  I apologize for the response in English, I hope you can read it!)

While we don't have an official LabWindows/CVI API, we do have a pure C API that does work within CVI.  We made sure to test this use-case.  The only thing lacking from this API that would be present in an official CVI API are custom function panels for our entrypoints.  There is a possibility we add this in the future, but there is no planned support at this time.

[Fast351]

What is the correct avenue for reporting bugs in the C API?  I have everything up and running in 32 bit, and when switching to 64 bit, I've found in a memory corruption issue in functions that return strings.  (I have a minimum code example for niVB_Dig_QueryLineConfiguration, but other functions, like niVB_MSO_QueryEnabledAnalogChannels exhibit the same problem).

[bstreiff]

You can report bugs on this forum. Just to keep things organized, we'd prefer it if you created a new thread (instead of adding on to this one).

[ajog]

Tried programming my new VirtualBench in Visual Studio 2013 but keep getting the following error inspite of including the dll (nivirtualbench.lib) in the project.

Error 1 error LNK2019: unresolved external symbol _niVB_Initialize referenced in function _main C:\Users\Anand\Documents\NIVirtualBench_Automation\Anand Projects\TestRun\ConsoleApplication1\ConsoleApplication1\Proj1.obj ConsoleApplication1

what could be the issue?  My project has a .cpp file with a 'main()' function, a header file "nivirtualbench.h" as well as a link the the nivirtualbench.lib file which I've also copied to the same folder as the .cpp file.

Can NI post an entire Visual Studio project so we can see the settings used?

Thanks!