WMassey

It's really easy, isn't it? Just select the text you want in case true/false.

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.

It is sort of: See attached vi for a completly polymorphic version

that can easily be expaned to multi-dimensional arrays.

Uses a reference to the array's element.

But indexing is clumsy, so maybe room for improvment.

Interesting problem. I've never had a use for this operation before.

I can usally make an array with the maximum expected elements first.

-WDC

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've found the source of the problem, but now there's a new question: Is this a LabVIEW bug? It looks like one to me.

It appears that the Waveform Graph control stops responding to the Zoom to Fit tool any time there is a control/indicator overlapping (and in front of) the plot area of the Waveform Graph control. I've tested this in LabVIEW 7.1.1 and 7.1. I'd be interested to hear if it happens in other versions, because I swear I should've run into this before.

A demonstration VI is attached. Anyone care to verify?

I can see the exact behavior you are describing here as well.

It looks like a bug to me.

I'm not sure how to check whether hardware working properly or not. It was mentioned in the manual that interface should connect with DTE(computer) with female, but I end up with both male at the computer. So I used another pin to change it to female at DTE.

Kilaru

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

One way to simplify your code would be to use the reshape array function. See attached image. You still need to check if the index goes beyond the original array size but this method is more efficient.

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

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:

Build the "Run VI.vi" into an EXE file using the NI Application builder and the included .BLD script file.

(you may want to change the "Run VI" icon along the way).

If your project contains just one top-level VI and no dynamically-called VIs then skip the next step.

Create a top-level container VI and put all top-level VIs, external VIs started with the VI server or dynamically-called VIs into this top-level container VI and save it.

Using the top-level container VI (or just the top-level VI if no container is required) select

File --> Save With Options --> Application Distribution and save the entire hierarchy to an LLB file or a folder of VIs. It's up to you whether or not you let the save process strip out the block diagrams.

Place the "Run VI.EXE" and the new LLB (or folder of VIs) into a common "Program" folder. Use the included "Find CallLibrary References.vi" utility with the top-level container VI to get a list of all the DLL files used by the hierarchy. Add copies of all the specialty DLLs (i.e., the ones not normally found included in the LabVIEW runtime or otherwise on the target machine) that are required to a DLL folder in the "Program" folder.

Zip up the "Program" folder and move it to the target machine. Install the appropriate LabVIEW RunTime engine on the target machine. Create a shortcut to the "Run VI.EXE" and give it a name that reflects the function of the project. Move a copy of the shortcut to where ever is appropriate (desktop, Start>Programs, ...).

Execute "Run VI.EXE" - it will expect you to browse to the top-level VI which you want to be executed. It will save that VI's path in a "Run VI.INI" file for subsequent runs and it will then start the VI that was identified for execution.

If everything was done right the project will be up and running.

You may ask, "Why not just build the project using the application builder in the first place?" My reason is that doing it this way I only have to run the app builder once, every time a new version of LabVIEW is released. Complex projects can be difficult to get right using the app builder, often requiring a considerable amount of fussing with its setup to get things working correctly. This has saved me a lot of aggravation when it has come to trying to get the app builder to include the correct dynamic VIs, external VIs and VI front panels (my attitude has been "include them all, disk space is cheap these days.") The "Run VI" app build on the other hand is trivial since it involves only one VI.

Distributing applications this way also allows me to update all the distributed runtime-only projects just by dropping a new LLB (or even individual files) onto the target machines. Besides updates to the VIs themselves, the most I might have to change on the target might be the INI file that identifies the first VI to run. Once you have a working version on a target machine, it is relatively easy to copy it to other targets.

One other note about the "Run VI" VI. I purposely built it without any calls to any external subVIs so that it would both be self-contained (easy App build) and that there would never be any question of a conflict with any VI that might appear within the project it was calling.

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.

transitional states -

this is the FALSE to TRUE (LOW to HIGH in pulse)

or TRUE to FALSE (HIGH to LOW)

change of boolean values..

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

Can you add a link to the document you are referring to?

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

I'll try playing with the ActiveX and GOOP functions. I have never used ActiveX, though, so any tips will be greatly appreciated.

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

I just wanna convert it 2 pixels values, so i don prefer getting NI-VIsion.

It was captured using NI-IMAQ. So i think it had 3 options... TIFF, BMP, and JPEG.

I felt tiff was best for acquisition, so i did.

was i wrong ?

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.

Take a look at this. It is your only hope.

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.

Can i download only the Variant Tools of Goop? My comany's network blocks me and i can not user Commander to do it.

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...

Let's imagine that OpenG has a function called "Trim Whitespace.vi" and NI thinks that it is so great, that they rip-off also create a function called "Trim Whitespace.vi" and ship it as part of LabVIEW, in vi.lib.

: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 want to open this TIFF image and read its pixel values.

its 16 bit grayscale.

Can be opened in ImageJ or Scion Image.

Other softwares dont display it properly!

Can somebody help me.

I dont hav Vision and iam using LabView 6.1

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.

Hi,

i want to develop GUI with multiple dialogs which i want to call from main window like subroutine

with out closing the main window

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.

Thanks for the help. I will try using ActiveX for the first time. In the mean time, our current process requries chyanging the name of the output text file, then running an excel macro to import the data. I know how to run the excel macro via LabView, but is there a function to change a file name? It is a .txt file.

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?

I had the exact same problem. At least I think it was the same problem. I compiled a list of the different things you should check, which it looks like you finally figured out. See my old post here on NI... the list is attached to the post as a document with screenshots of everything you can look into:

http://forums.ni.com/ni/board/message?boar...ssage.id=115500

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)

There are several things that the LV App Builder uses to determine whether or not the FP needs to be preserved. For example, if it has the Open Front Panel When Called attribute set to TRUE, implicit control property or invoke nodes on the BD, or control reference constants on the BD.

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.

Well, not the file format itself, but there ara two VIs from the appbuilder's llb doing the job to read and to write the *.bld files:

C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Load Script.vi

C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Save Script.vi

I did use them once to leave all diagrams within an executable for later debugging.

Thomas

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.

I know that OpenG builder allows you to import an NI build file. This means there is code out there to read this info. Why not download the OpenG builder and poke around?

Of course, the real question is, "why do you need this?" Perhaps if you let us know, we might find another solution to your problem.

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