WMassey

Heck, that's the hard way! Try this instead... and if you REALLY want simple it doesn't get any simpler than this (though it isn't so useful for archival of information) In fact, when faced with a problem like this it is always a good idea to at least try the "Format Into String" node in this manner to see if it can cope with the data type conversion. It really is rather good at it for many data types.

Wow, interesting approach, though somewhat out of left field. I'm now sure how efficient it would be or is there is a way to make it work without the upper-level VI having a control/indicator for it to operate on but I'll give you points for creativity. I find I use this operation most often when dealing with instrument/system configuration data that a user is saving to a file devoted to storage of similar data. I have no idea at the outset how many various setups a user might eventually use or want to keep so I have to allow it to dynamically grow. In some cases there is even an advantage to letting the user pick the index which the setting is saved under. I just learned early on that the "insert into array" primitive didn't behave like I thought it should if it was given an index a bit beyond the bounds of the incoming array. Heck, it didn't even return an error. Thanks for the reply. It was interesting.

I can see the exact behavior you are describing here as well. It looks like a bug to me.

A long time ago (at least in computer hardware terms) the folks who came up with the RS-232 communications specification decided that there would be two broad classes of equipment. DTE (Data Terminal Equipment) and DCE (Data Communication Equipment). An RS-232 communication link was expected to have a piece of DTE at each end with DCE in the middle. As you might guess, teletypes, terminals and computers are considered to be DTE and things like modems are considered to be DCE. The specification actually went on to say all DTE connectors would have male pins and be wired in a certain fashion and all DCE connectors would have female sockets and also be wired in a certain fashion. In the case of DB25 connector, for DTE, pin #2 was for transmission of data out from the DTE and pin #3 was for receipt of data coming into the DTE. On the other hand, for the mating DCE connector, socket #2 receives data into the DCE and socket #3 transmits data out of the DCE. This makes sense so far - pin#2 transmits & mating socket #2 receives - and - pin #3 receives while its mating socket #3 transmits - you can practically see the data flow. But if you go on to imagine what's going on in the DCE you will soon realize it has a female connector on each side of it and, on both those connectors, sockets #2 receive data into the DCE and both sockets #3 transmit data out of the DCE. Obviously the only way that this will actually work is if the transmit and receive lines (and all the other handshaking lines as well) get swapped within the DCE. That is exactly what happens. The bottom line here is that between any two properly-wired pieces of DTE, you need a piece of DCE to cross the signals over between the transmit and the receive pins. Assuming you don't need a real modem to cover an extended distance, you will at least need a "NULL MODEM" to swap the signals as they pass through. Null modems usually fit in the palm of your hand and have a female DCE connector on each side and look a lot like a gender changer. You can also get null-modem cables that just plug into the DTE on each end. For that matter, there are also non-standard null modems that are male on each side, or male on one side and female on the other. They are usually labeled "null modem" but you can always get out a continuity tester or ohm meter and see if the pins run straight through or else get swapped. Many manufacturers of DTE don't follow the RS-232 spec and you can get DTE with female connectors or DTE whose connectors are wired like DCE with the transmit & received signals swapped. All you, as a use can do, is to read the documentation and keep a supply of cables, null modems and various gender changers around and keep reading or trying various combinations until you find the right one that works. It usually doesn't take too long. Attached is a file from NI that provides some useful info on serial communications. Download File:post-2800-1131137043.pdf

Hey, that is better! :thumbup: Thanks! P.S. I've attached a polymorphic (for the common data types) version of this VI. It still won't do arbitrary cluster data, but it is easy enough to paste TypDef'd controls into its front panel to generate new VI's to handle those data types. I'm just really surprised that this isn't built in by NI somewhere. Download File:post-2800-1131058454.zip

Yes, I even considered that once as well. But that, like everything else I have thought of so far, is not a one-box-contains-everything solution. You still need at least one additional external step (in this case, pulling out the array reference) before calling the subVI. If I'm willing to allow one additional external step then I can easily do it very simply with variants. I just thought that, since this seemed like such an obvious thing to routinely do, there should be some universally-polymorphic LabVIEW primative to do it. Followup: OK, I'm going to have to retract those last two sentences. It's not so easy with variants. I tried it here: and anytime the initial array size value isn't large enough to include the "Index" value I get an "Error 91 occurred at Variant To Data - The data type of the variant is not compatible with the data type wired to the type input."

I was a half-hour into a detailed reply to you when my browser crashed (due to something else going on on the machine). I figured that it would be simpler and almost as quick if I just showed you some sample code. Since you didn't answer all the questions I asked in my 1st reply I had to make some assumptions. If they are wrong, you can adjust accordingly. This attached VI does depend on there being an equal number of similarly-names X/Y files and an equal number of lines in each file. I didn't have any of your data files to try it against so you are on your own for testing & debugging it. I can see that you are relatively new to this LabVIEW stuff but you really do need to learn to use state machines. They are one of the BIGGEST hammers in the LabVIEW toolbox! Download File:post-2800-1131035494.zip

Are there always as many X files as there are Y files? Are there always the same number of lines in any given pair of XY files? In the VI you posted I don't see any concatenation going on. If your intent is to just have this as a subVI that returns one X/Y pair (concatenated or not) each time it is called why not do just that and leave the timer stuff, if it is needed, to the calling VI. If I have guessed the intent correctly, you could do it in a simple state machine. A first call to the machine would initialize it and subsequent calls would return an X/Y pair. If the files are not expected to be changing over the course of a run then the initialization state could read in all the file data and have it ready to spit out as pairs on subsequent calls.

OK, I'm fixing to show my ignorance here

Thanks to some of the information found in this thread I have found an easier way (for me at least) to use the application builder in my distribution of LabVIEW applications. I don't think that sharing this method and the VI's I have used to implement it runs afoul of of NI's App Builder but i wanted to get others opinions about this before posting the VIs. You still need the App Builder to turn the important VI into an executable file, and I am not posting that file as an executable. That VI, when combined with an INI file telling it what VI to in turn run and an LLB (or folder) of all necessary VI's that make up a project, will run the project's VIs on any system that has the appropriate LabVIEW RunTime engine installed. Rather than repeating a bunch of stuff I have already written, here is a README file that I have included with the VIs: This is what I am proposing that I submit (as a zip file): Should I go ahead and add the zip file? Any interest? Is it legal enough?

The attached VI shows one method of finding the containing folder regardless of where the VI is stored. It may be in a folder, LLB or EXE and if it is either of the latter two, then the folder containing the LLB or EXE is returned. Download File:post-2800-1130792964.zip

And if NI cannot manage to do it for a group of objects, how about at least giving us a way to select a next object and then repeat the last action, assuming it is an appropriate action for the newly selected object. Just look at any of the Microsoft Office products and their Ctrl-Y function (Edit -> Repeat) to see how well this can work. But regardless how NI manages to implement it, I agree that they need to do something in this area. The last time I missed functionality this much in LabVIEW was back before it had an "UNDO" function.

:question: Has anyone ever found a use for the Boolean transitional state colors? Are they ever actually visible?

Start -> Programs -> National Instruments -> LabVIEW 7.1 -> LabVIEW -> Help -> VI, Function & How to Help ... -> Index -> (Type in the keyword to find) -> Generate Occurrence -> click "Generate Occurance" -> look in the right lower pane -> read

You don't really need too much, if any, ActiveX experience to use the Excel Toolkit that I referred to earlier. That's been done for you. I've attached an example that uses a VI I pulled out of a working system. I've added a dummy front end to generate some fake data for it to operate on. You can see some of the stuff you can do with the toolkit in regards to generating Excel spreadsheets. This example is in LV 7.1.1 and I believe it includes copies of all the VIs needed to run it. Download File:post-2800-1130413684.zip

Well given that LabVIEW without IMAQ only supports BMP, JPEG and PNG, someone got it wrong. It may have been you or it may have been the folks who put together the IMAQ image-save options or else the folks who decided what image file formats were going to be supported by the standard LabVIEW package. I'd say you have the right to feel irritated by all this, not that it'll do you any good however. If you have the option of re-acquiring the data then BMP would be the best choice considering all this. If you need to process images you have already acquired you could convert the image file data from TIFF to BMP using any one of many image processing programs. ImageJ is well though of at my place of business and it is free.

Well actually there is the "FIND VI PASSWORD" routine on this page as well, but each use the "Set Lock State" method to test the trial passwords and that has been "fixed" to twart brute-force search routines. I strongly suspect NI has hidden a time delay in the code that does the unlock because the one time I tried to use it, it would only test about 10 words a second (if I'm remembering the number correctly). It would be a reasonable way to frustrate brute-force routines. If you don't already have a good idea of the word used, you might as well not even try.

That's a very good question. I'd like to update the OpenG libraries on a machine that is no longer connected to an open network. I wonder what folder of files I need to copy from an up-to-date machine to effectively update a machine where Commander won't work...

:laugh: :laugh: :laugh: I wondered how this came to be! That's a great piece of trivia. They say imitation is the sincerest form of flattery. I guess that means NI likes the OpenG work. Next thing we know NI will be trying to acquire it and sell it (all of OpenG) as their own.

I don't believe the basic LabVIEW development system provides an easy way of reading or writing TIFF images without the IMAQ Vision add-on. I guess it is possible, with an understanding of the TIFF image file format, to build your own TIFF file reader using the basic file I/O functions but that would require a bit of work. I've always been lucky enough to be able to use IMAQ Vision for my stuff. I do remember, for at least some of the TIFF image stuff I've done, having to convert from Big to Little Endian & vice-versa to get the image to display properly, but come to think about it, that may have been more to do with the way the image was acquired then the file format.

You might want to consider "subpanels" within the main VI. (Help --> Find Examples --> Search --> subpanels) Another way is to make use of the "tab control" to produce a paged front panel on your main VI.

Here's a fast way to start using the ActiveX method: Excel Toolkit (GOOP) It works really slick! Also... LAVA Forums > LabVIEW > The LabVIEW FAQ > Miscellaneous > How do I rename a file?

Thanks! :thumbup: This will be a handy thing to keep around. I agree with Jim that it should go into the FAQ. Perhaps a section of the FAQ could be devoted to application building? Both with the NI & OpenG tools? And speaking of App-Builder things that should go into the FAQ, here is another NI thread that was useful for me: Why are the fonts on my VI different from the fonts on the EXE after App Builder? (I will note that the INI file you save with the executable does not have to be the full LabVIEW.INI file; just the lines with the font information will be enough)

I took a close look at the VIs that had their front panels retained and I could find obvious reasons for all but one. A bit of digging and testing on that one turned up a couple of places where the caption text of a front panel indicator was being changed (left over when the VI had a starring role). Once I removed those property nodes, the requirement to have the front panel loaded went away.

Thanks. Yes I found these yesterday after I had already asked the question the day before. I ended up using the Load Script VI to accomplish that task I had in mind. Thanks as well. I have the OpenG builder but I have not taken the time to figure out how to use it yet. I certainly didn't know that it could import a BLD file. That will be a good starting point for me in the learning process because it'll allow me to take what I alreay know about the NI builder and see how the OpenG builder gets setup to accomplish a similar task. As to why I need this, forgive me for not saying in the original question but it was starting to get late at work on a Friday afternoon... Anyway here it is now: The NI app builder is pretty good at determining which VIs should retain their front panels and which ones should lose them when building an application, but sometimes it gets it wrong, especially when many of the VIs have their front panels opened programmatically. I had just tried my first build of a project and when it was run discovered that the app builder did indeed remove some front panels that were needed. It's easy enough for me to tell which VIs in the project need to keep their front panel (they all share a couple of common subVIs used to control the appearance of the front panel). But it wasn't so easy for me to check my list against the app-builder's list of VIs that got to keep their front panels (there are 450+ VIs in the project). I just wanted a way to mash the two lists together and have a result spit out telling me which VIs need their app-builder settings changed. This is what I came up with: The real trick (for me anyway) was figuring out how the 3-state current/build "rm panel" values actually determined what was going to happen. The v7.1.1 VI is attached but you will need to have the NI app-builder packaged installed to use it because it needs the Load Script vi out of that package. In fact, it would be best if the app builder were idling in the background before attempting to open the attached VI just so it'll automagically find the VIs that are part of that package without you having to tell it where to look. :question: This has all led me to another question. The app builder has some subVIs in the project flagged as needing their front panels yet they are ones that never are called upon to show their panels. Any ideas why this might be? Thanks again! Download File:post-2800-1130089051.zip