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 most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about? In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth. OK, your turn.

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?

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

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.

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: 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. Why is the file marked as "changed" when it has just been read in, but nothing has yet been done to it? It should probably ask to save when the window is being closed too. 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.

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

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.

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

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

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) 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) 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.