hooovahh

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.

Oh well that seems like a poor user interface, that is going to require all kinds of checking. Wouldn't it be a whole lot easier if you asked the user what values they want to input and then default the ones they don't? Attached is what I was thinking. By default you need to provide X, Y and Z, with their default values coming from a constant on the block diagram but could be loaded from a file. Then if you choose to not provide a value it hides that control and will use the default value. Enter XYZ Demo 2013.vi

There's about a dozen ways to store a value and load them later. The easiest in my opinion is to use the OpenG Write Panel to INI and Read Panel From INI, which will save and load control values to a human readable INI file. Other methods involve reading and writing to a binary file with the Read/Write binary where you can bundle all your desired values into a cluster, or turn it into an array. You could also just write it as text. Or write it as TDMS, or a database, or even the Windows registry if your user has permissions.

Hardly a monopoly. NI isn't the only company selling FPGAs. Also NI has 7,000 employees. They are international but I wouldn't call them giants.

Ohhh! This is a different issue all together. You don't have a Waveform Graph, you have XY graph. A Waveform graph has every sample be the same distance apart, where XY it is arbitrary. Attached is an updated version where we write three channels, one for the X one for Array 1 and one for Array 2. Then when we read we read all values from all three channels, then build them back into a bundle of X and Y values. I also built that into an array so one XY Graph can show both plots but you may want that on separate plots. TDMS Waveform Example 2.vi

Using things like the dynamic data type, and express VIs is going to be your down fall. These functions work fine for the majority of the use cases, but having more low level control gives you the features you'll want. In this case I see a couple of issues where you are trying to provide an array of delta times where this should be a scalar value stating the amount of time between samples. This information needs to be recorded in the TDMS file and using the TDMS write primitives do this. That is why the time scale on your graph above is samples since the delta time between samples wasn't recorded, likely because the Write to Measurement File didn't know that meta data was there, since it is write a dynamic data type. Attached is an example of writing and reading a waveform with TDMS. Write Read TDMS Waveform.vi

Both the link in the first post, and the link in your post download it just fine. Are you sure you don't have some firewall, or IT policies preventing the download?

Lets see the code. Also is this for actual hardware or just simulation?

Crosspost sorry I can't help.

Well that's okay I felt like doing some improvements on the image manipulation code. Attached is an improved version that supports ico and tif files and allows to select an image from within the file. For ico files it basically grabs the one image you select (with Image Index) and make an array of bytes that is a ico file with only that image in it, and then displays it in the picture box. For Tif files there is a .Net method for selecting the image which for some reason doesn't work on ico files. Edit: Updated to work with Tifs as well. Image Manipulation With Ico and Tif.zip

You didn't give much to go on, since I'm not familiar with IEC or IEEE Time-Current curves. So attached is some code that allows you to set the current and the Amp Hours are then calculated and if it goes over a limit then a boolean turns on. Overcurrent Test.vi