LabVIEW
Teledyne LeCroy, but where should this be?
I'm starting this thread in the LabVIEW forum, as this ultimately will be a LabVIEW thing, and this is generally the forum I'll use. This below was a beauty of a visual of a capture (from my search of all communities, not just LabVIEW,) earlier, so I snipped it and didn't change a thing. I'm posting it here in the hopes that I can get some fruitful direction on this from those more experienced than I.
Please tell me I am not the only person in the known universe to desire to use both LabVIEW and VB.NET and a USB-based connection with a Teledyne LeCroy oscilloscope.
Why would I want to do such a crazy thing? Simple, their LabVIEW driver (a project) may not have what I need; I want the OOP and VB.NET option as well. They use a MAUI (Most Advanced User Interface) Browser that contains every single object available on the scope. I can't get to that via LabVIEW. But I can get to it via VB.NET, somehow. You participants, here, are very knowledgeable. I'm not finding needed answers, so I come to you, even if maybe I am posting this in the wrong place, topic-wise. ...actually, though, maybe I'm not!
Thank you.
Hi *3d0g,
what exactly is the question?
When you look for (LabVIEW) device drivers then you should search in www.ni.com/IDnet. There are a lot of models listed…
When you need something else you may look for that on the LeCroy website…
@*3d0g wrote:
Please tell me I am not the only person in the known universe to desire to use both LabVIEW and VB.NET and a USB-based connection with a Teledyne LeCroy oscilloscope.
You may not be the only one wanting that, but that doesn't make it a real thing. Technically while you could use a VB.Net driver from LabVIEW through the .Net nodes, this is not what LabVIEW users usually want. It hides the entire implementation of the driver in a black box (the .Net assembly) and if things don't work as expected you can't debug and look into that black box and see what is going wrong. So most LabVIEW users expect a driver in LabVIEW source code.
Instrument manufacturers therefore often do two things: They write a driver for their own super duper fancy application they develop for their users. It typically supports most if not all of the most fancy features of the device, or at least as many as they feel like cramming in their in-house app. And then they go and put an intern to the task of writing a LabVIEW driver too. This intern has limited resources, knowledge and motivation to do his task and the resulting driver is often at best a minimal implementation or sometimes just a crude example program supporting the absolute minimum operations to be even remotely useful.
Now, mentioning VB.Net in this time is however similar to talking about Windows 3.1! Unsupported by Microsoft since many moons!
Also, Teledyne and LeCroy were traditionally two very separate and competing companies. Looking for instrument drivers with these two words in them will almost certainly fail, unless it is a very very recent instrument and the software Gods happen to have decided to write a driver for that device. You might have a little more success by looking for the exact device type with either Teledyne OR LeCroy in the name. Add to that that the search function on the NI site is beyond useless. You have more chances to find something on the NI site by using Google, than the NI search function.
However if it is a recent instrument, you will almost certainly have to talk with the instrument manufacturer directly. NI has stopped developing instrument drivers themselves many years ago (or more precisely they may still do that for their inhouse developed test systems but don't bother to publish them anymore on the website).
I have no idea what a MAUI Browser is. It sounds a bit Caribbean to me. 😀
However, whatever it is it is NOT supported by the LabVIEW project. The way to incorporate .Net assemblies in LabVIEW is to use the .Net functions in LabVIEW. Use a Constructor Node to create the necessary .Net objects and then the Property and Method Nodes to reference the according object attributes and methods. Then run that code. It's simpler than writing it all in C# (or VB.Net) but not a point and click only experience. You have to know about the class hierarchy of the .Net assembly and how the various classes relate to each other. Yes it is real programming!
Most Advanced User Interface! 😂, sounds like Koolaid to me. Some marketing guy really did try hard to come up with a very useless name.
You seem to have a tendency to try to go around several very involved corners to reach your goal. If that thing is a .Net assembly, then you can of course write a VB.Net component in order to use that awesome MAUI thingy to click together some even more "amazing" VB code, then compile that into a DLL or .Net assembly and then use either the Call Library Node or .Net nodes to import that thing into LabVIEW. Sounds to me about as complicated than approaching that .Net assembly directly. Yes you can't use some "Most Advanced" point and click browser to click together your driver, but what then? You still need to configure LabVIEW .Net or Call Library Nodes correctly to import your "Most Advanced" generated code library!
Advantages when directly accessing the initial .Net interface: If you need to add new functionality or change the existing functionality, you can directly create the according VIs to access those additional methods. With your MAUI generated assembly you have to go back into MAUI, click together a new "yet more awesome" component that uses these new methods, compile it into a DLL or assembly and then redo the import of its functions into LabVIEW.
Disadvantage: you need to learn about the object hierarchy and relationship of the original .Net driver from Teledyne/LeCroy.
And underneath that .Net assembly is simply some text based communication protocol that may or may not be SCPI related.
