Measurement Studio vs LabVIEW Discussion

[LVB]

I am interested in starting some discussion on the advantages/disadvantages of using Measurement Studio instead of LabVIEW for development.  First let me tell you a little about myself.  I have been programming in Visual Basic for 7 years now, and have 2 years of experience with .NET.  I have 8 months of experience using LabVIEW.  Any participation in this discussion is welcome!

1. Which platform do you prefer (LabVIEW/.NET)?
    I prefer using .NET for GUI interaction, as I find LabVIEW more difficult for such a task.
    I prefer using LabVIEW for control process, because I find it extremely easy to execute concurrent tasks, create timed loops, and display debugging data.

2. Why do you use the platform you prefer?
    I have more experience in .NET, and find it to be easier to create the GUI, but I have trouble creating VB code for control.

3. Support
    It seems that there are much much more resources and examples in LabVIEW for control, where can I find resources for VB?

Finally, is anyone using a combination of LabVIEW (control) and .NET (GUI)?  If so, please provide the community with some examples!


Thanks!

[JonathanN]

HI LVB,

Duplicate post found here.

Best Regards,

Jonathan

[Lycangeek]

As a developer of LabVIEW (i.e., C++), I'm propably not the person you're looking for, but I've done a lot of .NET programming as well (plus Java, etc).

Now, I'm not much of a GUI guy - I've never been able to really get into creating user interfaces, but I started off programming in the kernel, so that probably has something to do with it. The reason I bring this up is that I find it interesting that you prefer to use .NET for GUI. Personally, I'd much rather do the GUI programming in LV since it is typically much easier to get the UI up and running.

On the flip side, I tend to prefer .NET for logic programming. But as had been said in the past, that is probably because of my previous training - it's how I've been taught to think. Reference-based versus value-based programming has many fundamental, but subtle, differences. However, when you start to get into distributed programming, especially considering the options introduced in LV 8 (shared variable, target deploy & run), you can't beat what the LV environment gives you.

That's probably why I'm so pumped up about working on .NET and LV integration (my day job) - trying to get my cake and eat it too.

So, while there was a previous thread last year on a similar topic, I'd also love to hear from people on LVB's question.

[SumRunner]

Funny- I prefer LabVIEW specifically for the logic. I find it much easier because I can "see" each logical case, where with any text language I have to be careful to keep track of what's happening when. I've had to print out the code just so I can mark it up with colored pens. Especially when the logic is embedded, it's much easier to see it in LabVIEW. I also find it easier to test out my lgoc, since I don't have to build a full program, but can test the individual logic blocks as subVI's, independent of the overall program.

Again, it goes back to what you're comfortable with- I have a Physics background, not CS, so this allows me to do things in a logical fashion. I've created some pretty large apps, too, so it's not a question of small vs large- just a question of experience.

Steve

[batesbc]

I have to agree with you, LVB, LabVIEW is excellent for control or talking to hardware quickly and easily. For UI, though, it can't hold a candle to .Net. Internationalization is a pain in LabVIEW. If you want a UI that could pass Microsoft's Accessibility and Usability guidelines (without a bunch of headaches) then .Net is the way to go. LabVIEW's table is string-only, where .Net's grids can have different types per column. In LV8 some of this is addressed, sort of, because you can add .Net controls directly to the panel, and respond to events on them, but it's extra stuff, and extra pain to deal with. The good news is that the ActiveX interface to LabVIEW does a good job of transferring things back and forth, so you can use LabVIEW (even a compiled .exe) as your control, with a .Net UI on top without too much pain.

[LVB]

"The good news is that the ActiveX interface to LabVIEW does a good job of transferring things back and forth, so you can use LabVIEW (even a compiled .exe) as your control, with a .Net UI on top without too much pain."

batesbc,

  It is nice to see someone that shares my viewpoint!  If you have any examples, or resources for doing such please post under this thread.

[batesbc]

The easiest thing I've come up with (especially if there are lots of VI's to talk to) is having wrapper classes in .Net that provide properties for each LabVIEW control, so a VI that has an Int32 counter and a stop button might have the following class as an wrapper (C# code):

class MyVI
{
    private const string VIPATH = @"Path to vi";
    private LabVIEW.Application lv;   // Could also be MyExecutable.Application, if you're running from a LabVIEW built .exe
    private LabVIEW.VirtualInstrument vi;  

    MyVI()
    {
        lv = new LabVIEW.ApplicationClass();
        vi = lv.GetVIReference(VIPATH, "password_if_needed", false, 0);   // see the LabVIEW ActiveX docs for more info on what this is up to.
    }

    public Int32 counter
    {
       get
       {
          return (Int32)this.vi.GetControlValue("counter");
       }
    }

    public Boolean stop_btn
    {
       get
       {
          return (Boolean)this.vi.GetControlValue("stop_btn");
       }
       set
       {
          this.vi.SetControlValue("stop_btn", value);
       }
    }
}

I'm working on a set of VIs / python scripts to generate these automagically using the Front Panel.Controls[] property as a starting point, but I'll have to check with my employer about sharing them here. (It'd be easier if the Export Strings command gave valid XML output instead of almost-valid XML, hint hint NI...)
Time permitting I want to put together an NIWeek paper / presentation on doing this for large-scale projects, we'll see what I have time/permission to do.

[Lycangeek]

Well, sounds like we have some great people to add some comments to my thread here: http://forums.ni.com/ni/board/message?board.id=232&message.id=3017

This is a LabVIEW forum set up to discuss next generation features we're thinking about, and this particular thread is about creating a next gen interface to LV. Since you've been using the ActiveX server interface from .NET, I'd love to get your thoughts!

[LVB]

---

@Lycangeek wrote:
Well, sounds like we have some great people to add some comments to my thread here: http://forums.ni.com/ni/board/message?board.id=232&message.id=3017

This is a LabVIEW forum set up to discuss next generation features we're thinking about, and this particular thread is about creating a next gen interface to LV. Since you've been using the ActiveX server interface from .NET, I'd love to get your thoughts!

---

Brian, it looks like your link goes directly to this thread.  Is that what you wanted?

[batesbc]

From a "Future Features" standpoint, it'd be nice to have a built-in way to generate these wrappers. There are a few gotchas when translating control names over: carriage return, &, ", (, and ) are all allowed in LabVIEW, but not in .Net. All I'm really doing is parsing the (version 7) type descriptor, though. There are some datatypes that don't have a clear equivalent as well, complex numbers are not built in to .Net, neither are true IEEE 80-bit extended-precision floats. Ditto physical quantities as well, but if you needed these it wouldn't be too hard to write a Complex class, or an Extended class, or whatever you needed.

Something I've talked to Brian about in the past has been how to handle clusters. The ActiveX stuff converts them to arrays of variants, or Object[] in .Net. I'm not sure if it would be worth the trouble to generate classes for them with the appropriate contents or not, the extra type-checking could be handy.