hooovahh

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

Does C++ have any overcurrent protection? C++ just like LabVIEW is software and overcurrent conditions is a physical issue. What do you really mean?

Uggh, this does not look easy. Here is some VB code that looks to attempt to pull individual icons out of an icon file, and then load them into a picture box. https://www.codeproject.com/articles/6171/access-multiple-icons-in-a-single-icon-file Sorry I don't have any good suggestions.

Just lots of trial and error. Even hidden windows have a title, and have a handle (HWND) that can be found. Some times this can be done by first finding a process ID that is linked to a file on disk. Then you can get all windows associated with an application, and manipulate that, without needing a window title. Sorry I don't have any examples of this, it's been years since I had to do something like that. As for reaching search fields maybe pressing tab a set number of times will get you there, or using simulated mouse clicks.

Just tested my stand by method of using .Net and it seems to open and work just fine. Here is the code I posted over on the NI forums a while ago. It opens an image using .Net and then scales it to fit to the pane without any extra work. It supports all the different image file types, alpha layers, and can be exported back into LabVIEW Image Data.

Yes Channel Wires existed in a semi-beta state in 2015 but are official in 2016. Go to Help >> Find Examples and you'll find lots of examples showing the different types of Channel Wires and explaining how they can be used for communication between loops.

It does really depend on your software needs, but generally any new industrial rack mounted PC is going to be an I3 or better. I'd pretty much avoid Atoms at this point unless you really know your needs are small and dedicated. I've been using the atom based RT controllers running Linux and this seems fine most of the time but I wouldn't mind more performance. The cost difference between a dual core atom, and a quad core I5 or so isn't that great. We generally spend $1500 to $2000 US on a rack mount industrial PC and it has more than enough horse power for what we need. As for OS we still stick with 7. I think 10 is fine, and we'll probably start moving to it for new projects. We just couldn't see using 8, especially before the 8.1 update.

Without the source your only hope is to use the mechanisms left by the developer. If there is no ActiveX and the only interaction is with a mouse and keyboard, then you'll have to simulate a mouse and keyboard. There are several examples of using AutoIt or LabVIEW to look for windows to be active (based on their titles) then simulate pressing keys to navigate where you want and type in information. This is quite error prone and user interaction may mess with stuff.

Need to see the code, but I suspect a few local variables, or some communication scheme between loops would work. Have you looked into Channel Wires? This could also be used to facilitate communication between loops.

Either method would work. I was suggesting it leverage the select class so that you don't have more code to manage, but making a Select - String class as a apposed to a Select - Numeric class would be a fine solution too.