hooovahh

It's text based, but I found it funny. Source

Okay I'll admit it, I didn't realize you could double click the icon to open the icon editor I always right clicked the icon and went to Edit Icon. In either case I have the same behavior with 2009 SP0.

Here's something I whipped up. It uses a VBScript to get the version of a file. I then had LabVIEW call it through a command line and parse the output. It's not the cleanest method by any means, but it was the fastest. I googled getting file version and one of the first things that came up was a VBScript for it. This VI should return the same build version that you have in a Build Specification in the application builder. I didn't do any error checking on if the file doesn't exist, so if you just run it without a path it will not error out, and the version will be blank. The VI is saved in 8.6. GetFileVersion.zip

Thanks Ton another nugget from the VI.lib that could be exposed on the palette.

Attached is a VI that I think does what you want. It opens the file as a text file. Then processes each line one at a time. It will take each line and replace all spaces with tabs. Then it will convert that string to an array using the tab as the delimiter. This will generate several elements that have no value, say if you had a tab followed by another tab. So we then filter the 1D array removing all the empty elements. I didn't know if you had any OpenG stuff installed so I made the OpenG filter 1D an inline VI. BTW saved in 8.6 Open Data File.vi

Also another duplicate post from within Lava under the Site Feedback and Support page? In any case just have your bytes in an array then perform an sum function to get the sum of all the bytes. I added your bytes manually and I didn't get 0xCF I got 0x31 and my program attached also gets 0x31. Next time try to attach some code you've already tried but couldn't get working properly. Checksum.vi

It's nice they put that on the palette but I've been using it for a while, it's one of those nuggests in the Vi.lib that most people don't know about. EDIT: Oh and max undo set to 99, again a feature some people would do them selves. I also saw something about TDMS API improvements but didn't see any examples, can anyone elaborate?

I would recommend the FPGA route. I recently setup an FPGA to have about 10 PWM inputs and outputs on each of the 4 connectors. Each of these 40 PWM signals could be setup for PWM input or PWM output. I then added some debouncing code for each of the 40 PWM inputs. After that I tried adding code to detect 100% or 0% duty cycle on the inputs and that is when I ran out of space on my 4M gate setup (there were a few other things on the card) So I removed some unnecessary code like not all PWM needed to be an input or an output so I removed the unnecessary bits and it fit with plenty of space to spare. Each of the PWMs are being read all at the same time but they can all be in the same time loop (you don't need an individual loop for each PWM signal). Instead of waiting for a high or waiting for a low, you can use feedback nodes. I think NI had an example on this somewhere. There are 2 U32s for each PWM input and 2 U32s for each PWM output on the front panel. I realize this is probably where alot of my gate usage is going, but after investigating memory management in a timed loop I decided to just go with front panel controls because I knew it would work but it might not be the best way. Attached is an example of reading or writing two PWMs with debouneing on a 7813R. I haven't compiled the FPGA, and I haven't test the code but this is the technique I used. PWM FPGA Example.zip

I think the answer you are looking for is CSV or the like. Reading a tab delimited or comma delimited file is a native feature and can be done very quickly. There are some xml parsers that have been written, TDMS of course, and I think think that the file format for .DOC and .XLS are now documented, so theoretically a parser could be written (or may already exist in a DLL) for that. Pretty much the answer is any file type can be read in LabVIEW if you know how to parse it, and what structure it is in.

Cross-Post I am attempting to replace an existing system written in Labtech Notebook. I have the source code but I am having problems viewing it. I went to Omega's site and they have a old version of it available for evaluation but my code is from Windows 95 and the evaluation crashes when I try to open it. I contacted Omega and they said that they don't have anything Does anyone here happen to have a old version of Labtech Notebook (Windows 95 preffered but any would be great) that I can try the evaluation on, so I can just view the source, and then re-write it? Thanks.

You might also want to try turning down your UAC settings as an administrator on that machine.

Wow that sure does work...it actually works a little too good. I wrote a VI that just waits 10 seconds then calls your VI to bring it forward. In the first 10 seconds I took notepad and put it frontmost manually. Then the VI brought it self to the front. Problem is after the VI stopped executing it was still the front, meaning it was Always On Top, of all other windows...I then went to close the VI but nothing happened. I then realized it was because my VI was unsaved and the Save Dialog appeared but because my window was front most I couldn't see it. And because the save dialog was there I couldn't move my VI's window to see the Save Dialog window. I closed it by using the keyboard but how do I make the window not Always On Top after bringing it to the front?

I had some problems with making a LabVIEW window the frontmost of all windows at one point. Using Windows DLLs I could make a LabVIEW window become the topmost of all other LabVIEW windows, but if there was say notepad open I couldn't get it to make the window on top of notepad. So I wrote a quick AutoIt program to do it and it seems to work fine. Source is included. It is a command line program where you can specify the Processor ID, or the Title of the window (not sure why I didn't implement hWnd). If the Processor ID has more than one window it just picks the first one. If you don't know the Processor ID of an application you can open the Task Manager, go to the Processes tab, and then in XP you can add a column called PID using the View >> Select Columns. Not sure how it's done in Windows 7 but I know it is there too. FocusWindow.zip

I've never made anything like this in LabVIEW but there are several commonly used DLLs which give you this function. Searching Hashes.dll in google came up with several places to get a DLL that calculates a whole bunch of hashes. I don't have any VI that uses this DLL but I don't think it should be too hard to get the functionality you want.

I may be wrong but I thought the safely remove was primarily just for storage based devices. And doing so just ensures that you are not writing (or probably reading) to the device when you unplug it. I also heard somewhere that most devices don't need to be safely removed because of some weird buffering that goes on in Windows and removing it while writing won't screw it up just cause the files not to be written (because they didn't finish) So if what I said was all true (and it might not be) then I would say there should be no problem in removing the device without going through the procedure to "safely remove" it. Have you ever tried to safely remove it and it say that it can't because it is being used? Try making a DAQ task that uses it then try to remove it. If it says it is okay to remove then I don't see a need to safely remove it. If it says that it can't be removed, that doesn't mean it will break it, only that it may need more investigating. I'm curious does the manuals say anything about safely removing the device?

Okay I've used the toolkit and I've had limited success but I might be able to help. I've usually seen that modules talk both CAN and CCP on the same CAN bus. So one option is that maybe the device is already broadcasting the Exchange ID over CAN. You could do a CAN read, then close that CAN, then init the CCP engine using the same CAN hardware. Another thing is that this seems odd to me. Inside the A2L file it should specify the CRO Id and the DTO Id, as well as the Baud Rate and Station ID and any SeedKey DLLs. These are all parameters that the module and the A2L agreed on. I always thought that the firmware that was on the module was also the same software as what generated the A2L, and that the parameters in the A2L should never need to be changed. Do you have more than one module? Do they have different IDs?

Yeah the Read and Write DAQmx task can use a string. There is also a VI under DAQ Utility to take an array of string, and convert to a single string, that can be Read and get all of the channels.

That example is crazy. Did you develop this or did you find it? I ask because I noticed some of the front panel controls would be a strange string of characters like "ƒCƒxƒ“ƒg“o˜^Refnum" and even the error clusters have some odd labels. Does this kind of thing happen when developing in a different language? I think I understand how all the pieces work. The only thing is with this design I don't like is you need to have a callback VI for each item in the tray right? What if we needed to populate the list of items to appear when you right click? You could have the same call back VI for several events, but when when an event occurs there is no way to know what the user clicked on if because the only distinguishing part is between items is the VI that is called. I'm also a little confused on what happens if you have more than 5 items when you right click. It seems you are registering all the events at the same time, so you need to know how many events there are, and there is a case structure in the SetMenu.vi that at the moment only goes to 5 items. It would be a pain to have to set that to the maximum number of items you expect to ever have in a tray. I also didn't see a way to add a horizontal bar to separate items. Maybe BarBreak? or Break in the MenuItem property node.

This is not the right way to do this by any means, but here is what I have done in the past. Instead of displaying an array and showing the 6 elements at a time, with a vertical scroll bar to scroll down the array elements, I would create 6 string controls. Then when the operator pressed enter it would toggle a boolean, this event would look at which of the 5 string controls had focus and then bring focus to the next one. If the last string control had focus it would move the vertical scroll bar down. And when the vertical scroll bar changed value it would take the 5 input strings, and put them in an array at the index that the scroll bar was at. This would give an illusion that the operator is seeing an array when really it is just several strings whos keyfocus could be controlled independently. Attached is an example VI of how this all works. Sorry there isn't much comments or documentation but I think it is easy enough to follow most of the time. Just add new questions in the Get Questions case (there are 11 right now) and remember that Enter moves you to the next item. You could probably use Tab if you created an event for the keydown and used that instead of the boolean off screen. There is some issues with giving keyfocus at the beginning so you may have to click in the first element. Also you are required to enter an answer for each of the questions and you may loose keyfocus when the one button dialog box appears telling you to enter data for each element. Once you enter data for each item the output array (to the right) has the answers. Array Focus (8.6).vi I'm hoping there is an easier way of doing this, but I couldn't find a way to get or set the keyfocus of an index in an array.

Never knew that OpenG had that function. I did find what appears to be the same functionality in the vi.lib. <LabVIEW DIR>\vi.lib\Utility\GetType.llb\Get Type of Variant.vi Found that when digging around the TDMS viewer. Using some more code from the viewer you can convert many data types to string.

I realize this is a month old but I wasn't able to check Lava consistently recently. Yeah so my LabVIEW Tray Launcher is different from this application in a couple ways. In my application there is a registry tweak that makes it so that LabVIEW does not get ran when a .VI file is double clicked, but instead my program runs then launches LabVIEW based on what the user selects. This can be a good thing or an unwanted thing based on how you use LabVIEW. Often I will download a VI from the web and I just want to open it quickly. So I'll choose the Open option in my web browser instead of download. It will download it to a temp directory then open it with my launcher then choose the right version of LabVIEW. This is an interesting case because I don't know the exact location of the saved VI (I could find out easily) and I don't know the version of LabVIEW it was written for. In this case the Shell Launcher wouldn't help because the VI would be opened with the default version of LabVIEW since you would need to right click the VI and choose the option to launch it. On the other hand some people probably don't want my program taking over the .VI file extension and may want to right click the VI and choose the right one. My program could be changed to be a right click menu option, and I'm sure that this program could be changed to be ran when double clicking a VI and not just right click. My program does offer a few other features that might be useful but I'll try not to turn this into a post about my program.

I agree, when a set of requirements aren't set in stone, then there isn't a good way to know when to end the project. In that kind of a situation, working by the hour is the only way to go.

"WE'RE GOING STREAKING" (caps is appropriate he was yelling) NSFW?

Hit the clean up button, I dare you.

Is there a reason you haven't tried the tabbed approach? Where tab 1 has just one graph, tab 2 has two graphs, tab 3 has three, up to the number you want. Then color the tab to be transparent (so the user doesn't know it is a tab) and then control which tab the operator sees. That being said I've never had the "Scale FP objects" work properly for very long. Usually I could resize once and it would be okay, then I would scale it back to where it was and every thing would be moved around slightly, and alignments between objects would fail. Maybe grouping them would have helped.