GregSands

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

What design feature in LabVIEW do you most appreciate? The one that when you use it, you think "this is just so easy". Or that you'd most miss if you had to program in another language.

For me, it would be the ease with which multiple cores/threads can be used, either with concurrent loops, or with the Parallel For Loop - having done some OpenMP and MPI programming (in Fortran of all things!), LabVIEW just makes this so much more straight-forward. Huge kudos to all who developed these features over the years.

OK, what about you?

A valid point. Have a look at this recent thread which discussed spawning a parallel process and communicating with it. The daemon can be part of the XControl, so the users never see it.

Thanks, I hadn't connected that thread with what I was wanting to do. Will give it a go.

Like I said in the idea, you can use the mouse input VIs to detect scrolling. It would just be a matter of ANDing that with the mouse cursor being over the XControl.

I've been trying to get this to work, but the Facade VI only runs in response to events, so I'm not quite sure where to put the mouse input VIs. I know I can do this outside the XControl, but I wanted to have all the functionality built into the XControl itself.

Does anyone know whether it is possible to detect a mouse scroll in an XControl? Or do we need to wait for this event to be added?

I must say I appreciate when AQ comments on ideas, but as he says, "official" (or even semi-official) responses are few and far between. I would definitely prefer negative comments to none at all!

Jesse -

That's sounds great! Makes a lot of sense to have the core functionality easily available.

The most useful function for me that I didn't mention above would be intrp2d_uneven for 2D interpolation of scattered data. Hope you can also add the use of parallel for loops where applicable.

I just installed it, and it seems to delete some of the Bitman files. It's fixable by installing Bitman again afterwards, but I expect this shouldn't happen.

I think this is also important to consider: As I understand it, you can now deploy MathScript code to real-time targets. On the other hand, NI took all the MathScript functionality out of LabVIEW/Developer Suite and put it in the MathScript RT Module. So be wary that if you are developing MathScript scripts in earlier versions of LabVIEW you will need to purchase a toolkit to use them in later versions. Or am I missing something?

Yes, I should have also mentioned that you would need the MathScript RT module in order to use this routine. However the contour routines can be called directly rather than through the MathScript node.

I wrote my own, based on this paper: http://www.springerl...750730487puqm0/ - it works but would need some tidying before I shared it!

But a better option is perhaps to directly call the VIs that end up being called by the Mathscript contour function, namely vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctions\contour\NIMS_contour.vi (I presume this is legit - at least on the dark side ). Not this routine itself, which has a RUN_TIME_ENGINE check, but the routines called from here:

This begs a related idea I've had - there are a few very useful routines in the Mathscript library that are not "available" in G. That would include these Contour routines, the Delaunay Triangulation, and some other geometric functions like Convex Hull and Polygon Area. Why shouldn't these have menu entries in the main menus, maybe under Mathematics. The low-level routines are pretty much independent of any Mathscript-related variables. It seems detrimental to LabVIEW overall to restrict these to using Mathscript.

Have you tried adding a second plot which contains only the highlighted data? Then you can change the format for that, and it will be drawn on top of the existing surface.

Nice work, I really appreciate this. A few comments and suggestions:

1. It seems to reverse the order of the polymorphic entries when reading a PolyVI. As well as retaining the original order, it would be nice to be able to sort by any of the columns (menu/selector/filename) before writing.
2. Why is the file marked as "changed" when it has just been read in, but nothing has yet been done to it?
3. It should probably ask to save when the window is being closed too.
4. A wonderful addition would be the ability to populate a PolyVI from a "template" by changing controls/indicators to various types. There is an old tool called Create Polymorphic Instances, I think written by PJM ~5 years ago, which did this fairly well. I'm not sure where it was posted - I can't find it online now. But having something like that integrated into the Editor would automate a lot of what PolyVIs are used for (by me anyway!). A nice extension to that would be to be able to automatically create VIs for different array dimensions.

Maybe I'll have a go at #4 if I get some spare time, but my knowledge of scripting is pretty basic.

Can anyone please guide us how to convert a JPG or BMP image into DICOM using LabVIEW 8.6 IMAQ on Windows XP?

Any help or suggestions shall be highly appreciated.

I would suggest looking at openDICOM.NET which is an open-source .NET library for reading and writing DICOM images. I've only used it for reading DICOM images (though my code is specific to one set of images, not generalized) but it is straightforward to call the routines from LabVIEW.

Two new ideas:

1) Change the configuration of parallel loops

2) Allow multi-dimensional arrays to be reshaped to 1D arrays using the In Place Element Structure

Do you other people archive their exes/packages in their SCM?

I have read this can be deemed bad practice - you should only check in non-generated files.

So we can't check VIs in then?

There's a fine argument that VIs shouldn't store the compiled code in the same file.

I took Yair's advice, and here's a possible enhancement for the GetSnippet plugin. There's no error-checking to ensure that the selected Text Decoration is in fact a valid URL, or that the resulting file is a snippet-embedded PNG file. Because the snippet decoding is the same for both, I've moved "Save To Buffer" back into Get Decoration (and also it doesn't seem like you need to open the block diagram or front panel, but perhaps I've missed something - haven't coded any RCF plugins before!).

GetSnippet.llb (Saved for LV 8.2)

Nice!

Any chance that it could work for a URL (Text Decoration)? That's what Firefox gives when dragging a PNG into LabVIEW.

I posted a fix (version 2.1)

Something seems to have got out of sync in the fix. The probes are looking for "C:\Program Files\National Instruments\LabVIEW 2009\XControls\VariantXControl.xctl"

and though they do find "C:\Program Files\National Instruments\LabVIEW 2009\user.lib\_LAVA\VariantProbe\VariantXControl__VP.xctl", the Reset method call in the probe is not shown correctly:

Cheers ~ Greg

I like it!

Just found one small bug - it doesn't show correctly for a cluster with multiple elements of the same name (often un-named!). I think a possible fix is to change browseVariant.vi by converting the Cluster Variant to an Array of VData (using the OpenG routine), rather than pulling out cluster elements by name.

Cheers ~ Greg

• If you have an array the direction key use to navigate the array are not working properly (only the down one is working).

This one at least is already reported: CAR #187466 - see http://forums.ni.com/ni/board/message?board.id=170&message.id=441442

Cheers ~ Greg

It's definitely NOT going to make 2010. As I said at NI Week... you should expect very few LVOOP features in the next one, possibly two, releases. What we're working on now will take significant time and attention, with little bandwidth to spare in the interim.

Well then, I guess you'd better tell us what NOT to be working on, just so as we don't duplicate effort

QUOTE (Mark Yedinak @ Apr 23 2009, 05:40 AM)

With respect to concurrent or parallel I think you are being a bit picky about the terms.

I think there's a distinction worth maintaining, because LabVIEW doesn't do both things well.

• Concurrency is the ability to do multiple things at once - LabVIEW does this very well (parallel execution paths, independent for/while loops etc) and will utilize multiple processors/cores to run several different processes concurrently.
  
• Parallel processing is the ability to split a single task across multiple processors/cores, and LabVIEW doesn't do this well at all. Something like a parallel For-loop is needed; i.e. the ability to take a single section of code, and replicate it across several cores, hopefully also with automatic partitioning of arrays (or at least simple ways to choose how they are partitioned).
  

Cheers ~ Greg

QUOTE (professor_rumsdiegeige @ Feb 26 2009, 10:36 PM)

Has anybody got some hints on how to perform image stitching using Labview?

I.e. I've got a couple of overlapping small images and would like to merge them into a global (bigger) image.

If the images are parallel (i.e. NOT the standard wider-angle panorama from a camera) then a simple approach would be to use routines in the Vision Development Module. A possible algorithm would be to compute the cross-correlation between neighbouring images, and then place each image at an appropriate location within a larger canvas. An enhancement would be to cross-fade between the images where they overlap.

Where there are any significant lens distortions, then a much more complex algorithm is required, although if you know the distortion of your system, it would not be difficult to correct your images for that prior to stitching.

Cheers ~ Greg

Do you have a small code example you could post that shows how you structure things from an "Actor-oriented" point of view? I'm trying to work out how it is different to standard OOP in the practical case.

It would be helpful to be able to choose which array index to automatically access in a For-loop. It's not too hard to handle for a 2-D array (by transposing beforehand), but it becomes more cumbersome for a 3-D array. I suggest a modification like the following, where all methods give the same result.

It may not be straight-forward to allow programmatic access of the array index - if so, it would be sufficient to have a popup menu to choose which index is used, and some visual indication of the usage, as in the lowest example.

The same method could also be used to determine how an array is built out of a For-loop.

QUOTE (Antoine Châlons @ Sep 10 2008, 06:51 PM)

I agree it would be cool if LabVIEW could automatically add a "re-entrant glyph" on the VI icon, but until this feature comes I do it myself.

Just to document what I decided in the end (in case it helps others) - all my reentrant routines now have a red border, making it easy to pick them out of a block diagram or VI hierarchy.

Cheers ~ Greg