Changes in .NET assembly not shown in LabVIEW

[Even]

I am evaluating LabVIEW as an alternative platform to programming everything from scratch in C# with NIDAQmx drivers. I want to use LabVIEW with its prebuilt modules in a combination with methods made in C#. Our local NI representative suggested making dlls and connecting them to LabVIEW, so I want to test this functionality before buying anything.

I found out that it's possible to directly connect to .NET classes via "Connectivity-.NET". My problem is that the changes I make does not seem to reflect in LabVIEW. If I change the Constructor of a class from default "Class1()" to "Class1(int input1, int input2)" the changes are not shown in labVIEW. I have also tried adding several classes in the same dll without any change. I have tried changing the build from debug to relase, moving the dll and cleaning/rebuilding, but without any changes shown in labVIEW.

How can I make changes on the fly in C# that are shown and can be used in labVIEW? Are there any good tutorials showing the work flow between Visual Studio and labVIEW?

[smercurio_fc]

This is a known problem with LabVIEW, and one of my pet peeves. Typically the only way to get the new assembly to be recognized is to delete the constructor node and recreate it. In some cases I've had to go and delete the .NET controls and indicators on the front panels of VIs and re-create them. It's not pretty.

You should also be aware that calling .NET code from LabVIEW is slow. 

[Even]

So what you are saying is that it doesn't matter what you do when programming/compiling - the problem is solely related to LabVIEW? I have tried deleting and recreating the "constructor node", but it allways seem to stick to the first dll I created. This happens even though I browse to a newly built dll. I have no other .NET controls in my VI.

How slow is slow? Can I for instance take a stream of data at 20kHz, call my function with the dataarray and plot the result within LabVIEW without running into trouble?

Have anyone used the "Call Library Function Node" or any of the ActiveX components with greater success (speed/ease of use) than the .NET components within LabVIEW?

Message Edited by Even on 11-19-2008 02:36 AM

[smercurio_fc]

---

Even wrote:

So what you are saying is that it doesn't matter what you do when programming/compiling - the problem is solely related to LabVIEW? I have tried deleting and recreating the "constructor node", but it allways seem to stick to the first dll I created. This happens even though I browse to a newly built dll. I have no other .NET controls in my VI.

---

This happens because the .NET information is saved with the VI. Usually what you have to do is to delete the constructor, save the VI, close the VI (this may or may not be necessary), and then place a new constructor node. Like I said, a real pain.

---

Even wrote:

How slow is slow? Can I for instance take a stream of data at 20kHz, call my function with the dataarray and plot the result within LabVIEW without running into trouble?

---

How fast is fast?   To be honest, I have no idea whether that will work. What are you doing in the .NET assembly that you can't do in LabVIEW?

---

Have anyone used the "Call Library Function Node" or any of the ActiveX components with greater success (speed/ease of use) than the .NET components within LabVIEW?

---

The Call Library Function function requires you to write an "old-style" DLL. ActiveX will be a little faster, but it requires you to write an ActiveX component. Both are different from writing in .NET. So, the question comes back to what you're doing that requires you to do this in C# as opposed to doing it in LabVIEW. My guess is that you probably have some algorithms already written and you don't want to have to rewrite them in LabVIEW. 

[Even]

Thank you for making things clearer for me! 

You are absolutely right that I am trying to use algorithms that I allready have. They typically require a sample by sample availability and control. I tried implementing the algoritms in a high level system, DASYLab, a few years ago. I had problems doing anything else but whole buffer manipulation so I ended up programming the algorithms in delphi and later C#.

My guess is that if you where to implement those algorithms in LabVIEW you have to use a set of predefined blocks or use a proprietary LabVIEW language that I have to learn. Am I right?

[smercurio_fc]

I'm not sure what you mean by "predefined blocks". Do you mean the functions that are built into LabVIEW? If so, these tend to follow mainstream implementations. If their implementations don't do what you need them to do, then you can always program them yourself using the LabVIEW primitives, as you already have done in C#. The biggest problem people who have a text-based programming background have programming in LabVIEW is that LabVIEW is a dataflow language, not a procedural language. There are also no variables per se. Wires are variables.  There are local variables, but they are just another way to access front panel item, and are not designed to substitute as traditional text-based variables, even though people insist on trying! 

Yes, LabVIEW is a proprietary language, so you have to consider this if you need to make the algorithms be more "understandable" by a wider audience. But then, LabVIEW has been around for over 20 years, and is widely used, so one can argue that it's as "understandable", if not more so, then, say, C++. 

In the end, though, you're the one who has to make the decision as to how much, if any, to implement in LabVIEW.