COsiecki

Going off Hooovahh's code, since you say the inputs are sorted, you could use the found index as the initial search location for the next iteration. I know you lose the parallel-for-loop benefits, but it may make up for that by having a decreasing search pool for each subsequently found element, You'd need to catch when the B element wasn't found so you don't reset your starting point.

First, you have to be running the Pi edition of Minecraft on a Raspberry Pi on the same subnet as your LabVIEW code. This doesn't work with the full version of Minecraft. You can download Minecraft for the Raspberry Pi at http://pi.minecraft.net. Once its installed, start a game and load a world. This will start a server in the background. In the Minecraft-Pi library, you create a Minecraft-Pi object using Init.vi in the Connection Methods folder. You call it with the IP address of the Raspberry Pi running Minecraft. Once you have created the object, use Connect.vi to connect to the server. From there, if it didn't error, you are connected until you call Close.vi. You can use any of the other methods to set or read the available values. I included the "mcpi-protocol-spec" text file to explain how the functions work. Beyond that, make sure you can ping your Raspberry Pi and that your networking isn't blocking the ports. The Minecraft-Pi server uses port 4711.

I have written a LabVIEW version of the API for Minecraft on the Raspberry Pi. I used the API spec sheet and the sample python code provided by Mojang to make my version. I have uploaded it to the NI example code section. There's enough people here who like to use LabVIEW in unique ways, so I thought someone might like it. Any feedback is also welcome. Example code link: https://decibel.ni.com/content/docs/DOC-26662

You could have your VI send messages to a pop-up handler. That way, whether remote or local, its not dealing with the pop-ups itself. Then you would not need multiple versions of your VI

Our method is similar to the ones described here. When we start recording, we pass references to all the channels we want to record to a process that extracts header info from the channels. It then creates a TDMS file and a common receive queue. Each channel then gets its own "data grabber" spawned. The data grabbers will dump data into the common queue when their channel updates (this action is event based). The original recording process will pull the data chunks from the common queue and write it to the appropriate channel in the TDMS file. When the recording stops, an event is fired that kills all the data grabbers. We use a parent data class with type-specific children as our queue elements so we can easily combine different data types in our file. We can also have multiple files grabbing the same data if we need to.

I do it all the time! The only thing that I would warn you about is that front panels and block diagrams open where they were saved. If they were saved on your second monitor and then opened on a system with only one screen, they will open off to the edge of the screen. This can be a little annoying for you, but if that happens to the user, you'll certainly hear about it. Other than that its great! I have dual monitors set up at work and home. I was fortunate enough on one project to get a triple monitor setup. That was live heaven.

I saw this article and those displays jumped right out. http://today.msnbc.m...p/#.T2N_v8Uf4qw

Something I have done in the past is to create a set number of subpanels and then have a library of functions to handle sizing, positioning, loading, and unloading of VIs through an interface. You are limited to the number of subpanels you create initially, but as you place them on the front panel, the regular scrollbars will allow you to move around the panel. As a bonus, it becomes very easy to save the template so the user can pull the exact same layout up again. The unused subpanels are shrunken and moved off screen. My system used 30 subpanels and I never had any performance issues, even on some 2005 era single-core computers.

TDMS is a fantastic format. Because I wrote almost all of the DAQ software we have, I have replaced the custom formats we used with TDMS. The ease of use through LabVIEW makes it almost as simple as adding an indicator to your front panel. It's also very powerful for adding metadata. You don't have to figure out where you are going to put some new property in your file that doesn't mess with your offsets, or if you can add another channel without needing to re-write your reader. We have had some issues using TDMS in MATLAB. As far as I know there are is no official support for TMDS by Mathworks (they probably see NI as a competitor). One way to do it is to use the TDMS dll and do library function calls, but those can be finicky and can cause MATLAB to crash to desktop. The other problem we had with that method is that, at least when we were using it, the 64-bit version of MATLAB had no built in way to use a dll and you had to link it to an external compiler. It was not an ideal solution. In the end, we wound up using the TDMS format white paper to write a MATLAB-native reader, but there are some data types that aren't supported and we are lacking a number of nice features. It works for the way we tend to use the files we create though.

Nearly every one of my VIs looks exactly like ShaunR's style. I'm a fan of straight wires and you just can't do that with icons. I actually wish the DVR constant was smaller because its twice the size of an icon. So bulky! +1 for Terminals

I like to map buttons 4 and 5 to undo and redo. Its the same behavior as forward and back in a browser. I also sometimes map Align and Distribute to the wheel rocking. Unfortunately, I don't think you can map individual Align or Distribute functions. All you can do is just a repeat of the last operation you selected. Ideally, I'd love to have Align Left and Align Right as my left and right wheel rock respectively. I'm kinda OCD about my code, and I do a lot of alignment. With wire alignment in 2011, its worse... thanks NI

What about their Real-Time Hypervisor for Windows? http://sine.ni.com/n...g/en/nid/207302 You could do your acquisition on the RT side of the system, then shoot the data to Windows for processing with your existing signal processing. It might be something to look at.