hooovahh

Did you recently buy LabVIEW? If so it comes with one year of SSP support which comes with some real good self paced online training. Other than that there are several other free resources out there. Here are some. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Aside from that the best way I learn, is to use the function on the palette one by one and see how they work. Be sure and read the help on each function too. Open the Context Help (CTRL+H) and hover over the function.

It's basically the same on both targets. I've worked with XNet on PXI, and embedded cDAQ running the Linux RT OS and both work pretty well, with a few database functions not being supported. The RT may have some more limited database functionality (like not allowing to import or export databases) but for the most part things just work the same. These will return an error stating they aren't supported if this is the case. One thing that might help make your development easier is to deploy the database to the RT target using the XNet Database Editor software. From there go to File >> Manage Aliases, and here you can connect to a remote target (given an IP address) and then deploy a database from your host to your target. I think you can also add a database if you have the XML file on the target and invoke the Add Alias function. After that just add your target in a LabVIEW project, connect to it, and you should be able to run the VIs you already have written.

Here is an example of an asynchronous VI running, and having user events send data back. https://forums.ni.com/t5/Example-Program-Drafts/Non-Blocking-Multibutton-Dialog-Box/ta-p/3509941 But I think a simpler design would be two while loops, that communicate to each other with a couple of queues. In 2016 there is channel wires that could be useful too. Then your one while loop can be dedicated to just doing PLC stuff, and the other is for UI updates, and interactions with the user.

Okay great, thanks for testing this out, I just assumed it would work since it was putting multiple images in the EXE so why shouldn't it be reference like the multiple images in LabVIEW's EXE.

My experience is also only with the evaluate formulas. I ended up augmenting it a bit with a few pre and post function calls for doing custom things.

Sure it's possible. When you are making your application in the project be sure and add an ICO file to the project that has multiple images in it. I usually do this to have several resolutions since it sometimes looks better when larger or smaller. I usually make an icon that has 5 images in it at different resolutions: 128x128, 64x64, 32x32, 24x24, and 16x16. Then in the application builder settings, pick the icon as the one from the project. I just opened my EXE in resource hacker and see them all listed under the icon section so I assume you can probably reference them by the index, just like LabVIEW does. Otherwise you could just include multiple image files in your application builder that just go into support. Then have your icon be a path to that image file by setting that in the registry.

I only have but one 'like' to give. I don't see myself ever using the pink-ish one but all the others I could see uses for depending on the UI design. The larger check box with a hover is something I could use now. The existing Rounded Square, or Google style are also very refreshing.

Awesome job. I installed these a while ago when you first posted them and had forgotten about them. I then needed a checkbox and knew the only options were ugly old ones that scale, or system ones that look nice but are small and my UI is made to be a bit bigger. I did a QuickDrop and to my surprise found several awesome looking modern ones that I could change the size of. I've since installed the newer ones from the tools network and am even more delighted with the updates. Thanks again.

I found the old Tetris demo that used to ship with LabVIEW. This example was pulled from LabVIEW 2011. I'm unsure what version stopped shipping it. InputDemo Tetris.llb

Collision detection? Basically each block (normally only one falls at a time) will keep incrementing until a stop condition is seen. In your case it will be from the lowest block hitting the floor, but when the game goes on you could have any block hit another block forcing the whole 4 pixel object to stop moving down. You already have in a shift register where your objects are, so I'd suggest doing something like shift down, then count the number of Trues in the array. If they are less than the number of Trues before the shift then you know you shouldn't perform the shift and should revert back to where it was. There are examples on the web of doing tetris in LabVIEW and LabVIEW even used to ship with a version of it in the example finder. I can't seem to find it in modern versions but if I do I'll post it. Here is one discussion with several demos. https://forums.ni.com/t5/LabVIEW/Tetris-in-Labview/td-p/265716

Attached is an updated version which adds support for the front panel not being set to 0,0 but instead has the offset from where the first pane (at the moment support for only one pane) is on first run. So if you scroll around on the front panel it should make the web page view what you are viewing, and even with some support to update it when the VI is running. The Update Origin needs to be triggered when the scroll takes place and the demo was updated to use this. There are a few bugs for sure. The borders, and static text don't get re positioned with a window resized or scroll. But other controls, labels, and images will move with a front panel that scrolls around. The other asynchronous VIs were updated to stop if the Queue reference becomes invalid (the VI that made the reference went idle). And the clean up functions were changed to not create new references if they don't exist. This means you should be able to call the Clean Up function first (like you did) and everything else should still work FP Publisher With Origin and Cleanup Fix.zip

Well the issue is with the fact that you are calling the Clean up function right away before anything else. I'll admit that probably should work, but it doesn't. This is because it goes and looks to see if some object has been created before, and if it has then it doesn't add the right information like where to write the file to. Removing that first Clean Up allows the files to be written without error and the page to be opened...however the page that is opened is blank. This is because of yet another bug (thanks again) which creates the page setting the origin at 0,0 on the front panel. Your controls are placed somewhere around -400, -500. So if you take all three of your controls and move them about 500 to the right, and 600 down then run the VI it should work as expected. For testing I'd recommend not using the static IP string constant you have unless you know that is your computers IP address.

You'll find that OpenG is the most common LabVIEW reuse library there is. It was originally developed around the LabVIEW 4 era (as far as I can tell) and has several major updates and improvements, but hasn't been updated recently. It predates VIPM, tools network, and LabVIEW projects. Since OpenG is so commonly used in the community, many members forget to list it as dependencies (myself included). With the very open BSD license, there is little reason to not just install OpenG with every copy of LabVIEW. Look around your newly added palette and you'll find all kinds of awesome useful tools. The Array palette is probably the one I use the most, but File I/O, LabVIEW Data, Application Control, and Variant Config are also very useful.

The Open Registry Key.vi is a VI installed with LabVIEW. It is part of the vi.lib. If this VI is broken then there is probably something wrong with your install of LabVIEW and you should probably repair it. I opened the posted code and nothing is broken.

Yup, the .Net part accepts many different image types. ICO is one of them so I pass in the stream that is an ICO file that is then displayed in the PictureBox, or saved back as a new PNG stream. Same with all the other file types, .Net opens a JPG and displays it, then saves it as a PNG stream, then LabVIEW interprets it as LabVIEW data.

You mean a shift register? XYZ Example 3.vi

This document talks about the 32 to 64 bit comparison. http://www.ni.com/white-paper/10383/en/ The main take away is that not all toolkits are 64 bit compatible and you may not be able to make your program in 64 bit. Vision appears to be one that is supported so you might be okay. I've never made a 64 bit LabVIEW program but I've heard the benefits are minimal. You can give it a try but if your program is running slow now, don't expect it to run fast in 64 bit. A much larger contributor to performance is going to be how the program was written, and the state of the machine running it. Is the computer slow in general? Then this program likely isn't going to run any better. If you do make the switch be sure and report what your experience is.

A method using regular expression to find the first number after X, Y, and Z. There could be a bug if you entered something like xy10z3 because it will find the first number after x which is 10 and use that. Feel free to improve it. XYZ Example 2.vi

I don't have IMAQ installed, but I used a similar technique for detecting the edges of LCD segments. First get consistent lighting and positioning. Good, consistent, and uniform lighting is an art form. Once you have that turn the image into a binary one. You'll want some kind of thresholding applied and maybe a routine that allows you to adjust the levels. Alternatively you could try to auto detect the binary levels needed using the histogram data. From there I'd use pure math and abandon any premade NI functions. Partially because I'm not familiar with all of them, but also because if they fail to work properly I can't debug them and figure out why. In this case the math probably should be too hard. Your image is now just black or white pixels and you can apply a small filter to maybe eliminate any noise (like remove any black pixels not surrounded by black pixels). Then I'd split the image in half and process each half looking for the black pixels that are the farthest right, and farthest left. Then row by row look to see which points are the closest, and calculate the number of pixels between them.

Oh I thought that was pretty clear. So we take out the one image you selected, but then need to put in the header information. In that header information is stuff like how many images are there in the file, and at what file offsets are the images. The first image should always be at offset 22. The second image (if there is one) is after the first image, so its offset is going to vary depending on the size of the first image. In the VB code I linked to earlier this is the variable newCount and newOffset which the comment states is 6 bytes + 16 bytes 6 bytes for the ICONDIR, and 16 bytes for the first image ICONDIRENTRY. I mostly just reproduced the VB code in LabVIEW once I realized what it was doing. I also used Wikipedia. Also I find it kinda funny how I started this thread about 11 years ago and now have an answer that I find satisfying, even though it adds a .Net dependency.

I don't fully know what you are asking. Are you asking how I get the Image Data using the Get Image Data From PictureBox.vi? All that is doing is making a memory stream (a place in memory that has an array of bytes that can be used for various memory stuff). Then save the image into a PNG file, but instead of saving it into a file on disk, it saves it to the memory stream. Now the memory stream contains the same bytes that the file would have, if I saved the image as a PNG file on disk. Then using this array of bytes that is a PNG file, we use a vi.lib function to go from the data to LabVIEW Image Data. This will basically turn any image that the .Net functions can open, into a PNG, then into the LabVIEW Image Data. This is useful, but could be inefficient. Improvements could look at the file type that the incoming image is, and save the stream to the same file type, then open it with the appropriate function. Or possibly turning that directly into the 2D Picture data type. But honestly this is generally used for small to medium sized images and I haven't seen any memory issues.

Well in practice you could have a single Device Class, that all devices inherit from, including your Simulated Hardware Class. But you mentioned you don't want to create a simulate class for each hardware class. I think if you go with this override type of design you will have to. I mean if I have a DMM Class, a Power Supply Class, and a CAN Class, they all are going to have very different needs for what to do for simulation. Which is why you'd probably end up with a DMM Simulation Class, Power Supply Simulation Class, and CAN Simulation Class. This does add a bunch of VIs to your project, and more things to manage for sure. One other cheap and dirty trick that OO purist would probably not like is on your open method of your DMM class pass in a boolean that is "Simulate?" Or have a method to turn on and off simulation. Then you still only have one class for each hardware type, and all that is needed is to have a case structure around your low level communication code. I agree this is less scaleable, and adds more coupling, and less reuse, but it doesn't add tons of overrides, and more VIs in the hierarchy, and for non OO people it is easier to understand. If you can design your classes from the start to be generic enough that a single overriding class can supplement them, then a single simulation class might work. Otherwise it seems like a lot of work.

It seems Keysight VEE is still around, but hasn't seen updates in a few years.

Your supervisor is wrong. Still similar code can be used with regular expression or other string parsing tools to find the first number after an "X" and use that as the X and if it isn't found default to the other value. I'm not good at regular expressions so I'd be using things like the Search Split String to find X and get the values after.

Pretty minor but I found a bug where I wasn't releasing the image before loading the next. The result is memory will always increase, until the VI stops running and the garbage collector runs. Not a big issue for small files but someone loaded a 1GB TIFF file and had issues. Updated version can be found on the dark side.