LabVIEW Idea Exchange

(Similar title here.  Different concept.)

Many OO languages provide an Interface construct that allows objects in unrelated class hierarchies to expose similar functionality that can be called via common methods.  For example, a Car class and a Race class might both implement a Start method.  Unless their common ancestor has a Start method (which may not be practical) there's no way for me to take advantage of dynamic dispatching.  Interfaces allow an object to temporarily disguise itself as a different object so I can use a single vi on multiple objects.

Using the Car/Race example, I would like to be able to create an IStartable interface construct that defines a Start method.  Car and Race, in implementing IStartable, create their own Start methods that will override IStartable.Start.  I could then transform the Car and Race objects into an IStartable type and wire that into IStartable.Start.  IStartable.Start would then automatically transform each object back into its original type and call its member Start vi.

A couple points:

• Classes need to be able to implement multiple interfaces.
• There needs to be a way for class designers to indicate which interfaces it implements.  Setting that up in the class property dialog box seems like the best solution.
• There also needs to be a way for class designers to designate which member vis to use when overriding an Interface method.  I can't think of a good way to do this in the vi itself, so I'd also manage these settings in the class properties dialog.
• The illustration uses a Type Cast prim even though the actual type is not being changed.  It would need a new prim.
• I've toyed with the idea of hiding interfaces on the bd by having an 'Invoke Interface Method' node that would automatically do the transformation and call back into the class' overriding method, but I think that restricts developers too much.

Idea:

Double-click to a wire + holding <ctrl> or <alt> will call the wire-cleanup tool for this particular line => much faster than via context menu

What bugs me about the VI Profiling Tool is that it is not intuitive.  The information it provides is really useful; however, it's so hidden and difficult to interpret that few people actually know where it is to use it.  Let's say you are simply acquiring data using DAQmx and writing that data to a file, as below:

You might want to find out how to make this more efficient, but the only way you know is to insert Tick Count VIs and wrap your wires through sequence structures to do it.  It's annoying, and there are other ideas from JackDunaway (here) and JohnMc19 (here) which aim to simplify the use of those VIs. 

But why re-code your application when the VI Profiler can do it for you?  In addition, the VI profiler has more timing information (longest, shortest, average, total, etc) as well of number of runs and memory allocation data.

Good news: VI Profiler makes getting the data easy. 

Bad news: VI Profiler makes using the data difficult.

Why Using the Profiler is Difficult

First, you need to know it exists among a number of bland and condensed gray menus (Tools>>Profile>>Performance and Memory).

Next, you have to coordinate starting the profiler with starting your VI (start the Profiler, then start your VI, then stop your VI, then stop the Profiler).

Finally, you have to dig through a TON of VIs to find the ones that are relevant (I assume this is because, for polymorphic VIs, all of the instances are loaded into memory, even the dozens that aren't currently being used.)

When you find the VI you wish to examine, it will look something like this:

Have fun sorting through that!  When I finally find a VI that's hogging memory or speed, I'd expect to click on it to navigate to that VI.  NOPE!  All the VI Profiler does is make the line bold.  Not particularly easy to use...

I can't say if it's possible to get rid of VIs that aren't being used, or to make the menu option more visible to the user, but I do have an idea or two for how to make this information easier to understand in LabVIEW.

So here's what I suggest:

Adding a couple of check-boxes to the top of the VI Profiler will view in relation to your LabVIEW VI.  Notice the extra check boxes in the top of this image. 

One checkbox allows you to color the column you wish to highlight in your LabVIEW code.  The other checkbox inserts a text comment containing the highlighted data straight into you LabVIEW code (right next to the sub VIs):

From the above picture, you can clearly see the Write to Spreadsheet File VI is the slowest to execute.  Next in line are the Start DAQmx Task VI and then the Stop DAQmx Task VI.  So if a developer wanted to find out how to make his loop run faster (and therefore increase the rate data is read from his PC RAM), he would know the VIs that are more red are the ones he needs to focus on first.

Also, if a user wants to highlight the memory usage, he could select a memory column from the VI Profiler.

Then the LabVIEW block diagram would look like this:

In this case, if a developer wants to find out how he can optimize his code for memory usage, he knows where to start.

Side-note: I think selecting multiple colors at a time (one for each column of data you wish to highlight) would be cool, but that would start to get messy on the block diagram.

Other data, like the number of runs, could highlight which sections of code are running more often than others.

If we integrate the VI profiler more effectively into LabVIEW, there are a lot of benefits:

1. Re-coding to find timing specs won't be necessary for Sub-VIs

2. Monitoring memory allocations much easier (some users don't know it's possible with LabVIEW).

3. When there's a problem, it's easier to understand which SubVIs are slowing down code or hogging their memory.

4. Developers can further code development WHILE being wary of inefficiencies.

5. More integrated development environment "feel" for new customers or the experienced G-coder.

Please let me know what you think!

Hi,

I suggest an option added to the Open VI Reference primitive to open that VI reference without any refees. I suggest option bit 10, i.e. option 0x200h:

The demand for this arises when you want to access methods and properties of VIs that may be broken, while on the other hand you don't have any need to run those VIs - for instance in one of my current tools (BatchEditor) where I'm tasked with investigating hundreds of VIs simultaneously of which some could be broken or missing dependencies. Other situations would be tools for traversing project trees for instance. Opening a large number of healthy VI references takes a while, and when something is broken in a VI, opening even a single reference could take 30 seconds to minutes.

Currently you can suppress the "loading" and "searching" dialogs by setting option 0x20h on the Open VI Reference primitive, but that only loads the refnum silently as far as that will get you. Opening the refnum takes the same amount of time as if you could see those dialogs, and you are rewarded with an explorer window if a dependency search fails. I just want a way to open a VI refnum without even starting to look for dependencies, thus very quickly and guaranteed silently.

The relevant people would know that this request isn't that hard to implement, as it is kind of already possibly using some ninja tricks. I'd like such an option to be public.

Cheers,

Steen

I16 is currently the only output representation of this function, and it is particularly unhandy - I typically end up typecasting it 90% of the time. I propose the output representation of this primitive can be changed via Right-Click Menu.

Currently with LabVIEW Scripting you can very easily create an event structure and add new event cases to the event structure.    Unfortunately, for some reason, you cannot programmatically configure the event case after it's created.  I think there should be some way, via property nodes, invoke nodes etc, to accomplish this.

PS..  I would love to be wrong about this.  If you know of how to do that, feel free to argue it in the comments and we'll get this closed as completed 😄

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed. 

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂