WMassey

Make sure that PC-related stuff isn't messing you up.

Make sure the system isn't going into standby or some BIOS-driven power saving mode.

Also make sure the DMM isn't going to do the same thing.

Is there a way to put the decorations "under" the controls?

User the "Reorder" button on the toolbar.

I was taking screen shots of a running LabVIEW program and dumping them into a MS Word document today and at some point, in switching back to the LabVIEW from the MS Word, I realized that the open subVI window which I was looking for didn't show up in the WinXP taskbar list of open VI windows.

After some investigation I figured out that the subVI in question is setup to programmatically disallow the "minimize window" option and that was what was keeping the window name off the taskbar list.

I wouldn't exactly call this a bug because it sort of makes sense that a taskbar item wouldn't be needed to restore a window if the window couldn't be minimized. But the taskbar items can also be used to bring a window to the front and this ability is effectively denied to us in this situation given the way this was implemented.

Call me greedy but I wish the choice had been left to me about whether or not hide the taskbar window name.

Ahh.. this is just what I needed. I did need to revise your top-level VI just a bit to get it to stop err'ing out on the vi's without block diagrams or those from vi.lib that were password protected but otherwise it worked like a champ! Thanks!

FWIW, I've attached my modified version of your tool.

Download File:post-2800-1137433536.zip

yes, that was the way i tried, but i think some poll mechanism will be better~.

i don't find the SCPI command for this yet. Could you have some advice?

Well if you don't want to wait and do want to poll try using the "VISA Bytes at Serial Port" function to see when there are enough bytes waiting to be input to attempt a read.

You could also setup another asynchronous process (or loop or state) whose job it would be to hang on the read until a complete response were available and then make that response (possibly with a timestamp) available (queue, global, LV2 global, ...) to the rest of your code before going back to wait again.

I agree that Khalid's answer may be what you really need to make your application work, but to answer the question as you posed it, to get your simple VI to output a 3-byte ASCII string then you need to use a %03d format string.

FWIW, you used the the "Format Value" function found on the String -> String/Number Conversion palette.

That (and most all of the other conversions on that palette) are somewhat outdated and have been replaced by the more universal "Format into String" function (and its complementary "Scan from String" function) found on the top-level String palette. One of the advantages of the "Format into String" function is that you can right-click on it and select the "Edit format string" option which will bring up a window which will lead you through the various options required to produce the type of output string you desire. For example, the foregoing %03d format string is built using:

Format Decimal Integer + Right Justify + Pad with zeros + minimum width=3

Download File:post-2800-1136554812.vi

Download File:post-2800-1136555775.zip

If you actually want to control it while the VI is running then you will need to use a VI Toolbar Visibility property node. More info can be found here.

That's odd. I've mixed and matched fonts in labels of controls without any problems. Dumb question, but did you make sure to make the current value the default before saving it? Have you tried it with other things - like maybe a label?

George

It works with labels. It works with text strings that just sit on the front panel.

It just does not seem to work with Boolean Text.

"Making value default" does not affect it.

Christmas eve was warm, not a cloud in the sky and the temperature was warm: 20 celsius. It's really not Christmas unless you have snow on the ground...

Sounds like someone needs a quick trip up to the Sierras.

Just wait 'til summer gets here Michael...

As Mark Twain said "The coldest winter I ever spent was one summer in San Francisco."

Of course with the changing weather patterns around the globe who knows what the future will bring.

Happy Holidays & pass the sun block!

2 options -

The first is to place the typedef on the front panel and hide it. This way you will have a control terminal on your diagram which is very small.

The second is to place the typedef as an output for a subVI and use that subVI to get the control. This is my prefered method.

This second method is a favorite of mine as well. I use the TypDef'd control to establish the structure I want and then use the subVI to provide the access to the constant and also to establish the default value for the constant. I've attached a small example of this taken from some work I have done. Very few changes to the example are required to allow for multiple enumerated constants, if that is desirable.

Download File:post-2800-1135686401.vi

Hi Wmassey,

first i would like to thank you for the example file. Very useful. I still have a problem: When the user clicks on the abort-button (or types Ctrl-[dot]), there is no question of wether he wants "really" to exit.. Doesn't that fire an event?

I think i understood the strategy of deleting the queue and thereby declaring that the vi has to be closed. Nice.

thnx. merlin.

No, the abort button/function does not have an event associated with it.

FWIW this same topic was discussed over here.

I think that the best you are going to be able to do is to hide the abort button if you don't want the user using it. You can do that either through the VI setup properties or a VI property node.

Keep in mind that, before you hide the function, your VI needs to be bulletproof in the way it operates because you won't have a good way of stopping it (other than the three-finger salute [Ctrl/Alt/Del]) if it misbehaves.

Hi all LabVIEW developers,

As I am working on it I found that this approach has a big problem: the size of those "instrument contol" VIs (in a llb file) could one day have grown very large. Now in the llb file I have getter/setter pair of 7 parameters (14 VIs in total) and the file size of the llb file is closed to 400kB. And I think I will add more and more complicated features so I am afraid that it would grow very large.

If you are indeed worrying about the file size getting too big, I'm not sure the worry is justified in this era of huge disk drives and disappearing interest in floppy disks.

It is possible to save the VIs in a more compact form (eg. just the code, not the graphical stuff).

Yes, using the file zip tools of the OpenG package, you could decompress zipped VIs before they were called and delete the expanded file afterwards.

If you have the application builder as part of your LabVIEW development system you could use it to strip the front panels from the VIs that didn't require them before they are saved to the LLB file.

You can also minimize the amount of memory used by the front panels that are required by minimizing the number and complexity of the controls & indicators you use on the front panels.

According to Wendy from NI, this would seem to be a "feature" of LabVIEW.

I'll need to try one or more of the workarounds offered here.

What part of the color ramp do you want to scale?

The Gradient bar or the actua display of the current value?

I want to scale the gradient bar and the scale associated with it..

Ok. So this is only for scrolling. Could you tell me how to make the cursor to write one line under another?

I've attached vi in which I tried to do this

You need to realize that each time your VI loops it replaces the text in the "Value" of the "source" so that at any time there is only the one number (using at most 2 ASCII characters) present. With only that one small bit of text in the text indicator, the text string is not long enough to wrap around enough to force the text box scrolling on and certainly not enough to cause there to be 29 or 30 lines of wrapped text as your example would seem to want

• As you probably suspect now, scroll position is not the same as cursor position.
  
• There is no cursor position control available to do what you want.
  
• The scroll control will only work if there are enough lines in the display to enable scrolling and even then you can only scroll down as far as there are lines available. Depending on word wrap to get you the number of lines that you want is a bad idea - where and when the wraps occur depend on the text indicator size and the font size - a real house of cards. :thumbdown:
  
• There are other characters you can insert into text strings that do break them into multiple lines such as your carriage return or line feed (a.k.a. new line) or the generic end-of-line character. Use one of them at the end of each line of text and build up an ever-increasing length of text and you'll end up with multiple lines and eventually the ability to set the scroll position
  

Note however that if your text indicator is tall enough to hold, for example say 3 lines of text without scrolling, that you will not get a scroll bar and be able to set a scroll position until you get four lines of text. And, in this case, when you do get 4 lines of text you will only be able to select either scroll position #1 or position #0. When you add a 5th line of text then you'll then get the additional option of scroll position #2, a 6th line of text will give an additional scroll position #3 and so forth. If someone comes along and resizes your text box vertically so that it'll hold more or fewer lines of text then all these numbers will change. (It's beginning to look like that "house of cards" again if a change to the size of a front-panel object causes a change in the way that the code behaves.)

If your only intent is to always have the last line of text showing then this won't matter; just wire a number equal to or greater than the number of lines in the display to the scroll position and the last line will always be displayed.

See example.

Download File:post-2800-1135094308.vi

It's the 2D array that I need to split. I need a 1D array of "column 0" and another 1D array of "column 1". It looks like the decimate function is only to split a 1D array into smaller subarrays. Am I missing the point?

Thanks!

Oops! My Bad!

You simply need the index array function, assuming the data has some reasonable distribution within the 2D array. See the attached VI.

Download File:post-2800-1135039549.vi

Hello. I'd like to use error (source,code,boolean) control as a GUI. I mean to use 'source' window to write test results to it. What I want to do is to create such VI that can write results line by line, and when the window is full to autoscroll the bar. I've tried to use property node for 'source' and text.scrollpos element, but it doesn;t work.

It works for me.

Download File:post-2800-1135038586.vi

I've been struggling with what should be very easy. I have a comma seperated value file from another instrument. I need to plot this data for analysis and prefer to use LabView over excel, sigmaplot, etc...

When I open the file with the read from spreadsheet file function I get a 2x10000 dimensional array. In order to use the graph XY function I need to separate the array to two different 1x10000 arrays and then bundle them together and send the bundle to the XY graphing funtion.

Can anyone help me either spit my 2D array into two 1D arrays or give me a different way to go about the problem?

Thanks

On the Array Palette look for (or search for) the Decimate 1-D Array function. It does what you need by "dealing out" the elements of your big array into two or more smaller arrays.

I'm having problems with LV losing track of the locations of DLL files when I move code back & forth between the development machine and the target machine. The DLL files are located in (what I think to be) the same location on both machines yet whenever I move the code from one machine to the other (direction does not matter) I have to tell LV where to find the DLL files and that always triggers a warning like this:

Virtual Instrument

- The external library expected to be at

"Program Files:\SI Image SGL C\tiff2vi.dll" was loaded from

"C:\Program Files\SI Image SGL C\tiff2vi.dll".

- The external library expected to be at

"Program Files:\SI Image SGL C\SpecInst.dll" was loaded from

"C:\Program Files\SI Image SGL C\SpecInst.dll".

:

Any idea what might be causing this and what I might do to prevent it or fix it?

In LV7.1.1 is there any way to get the color ramp to scale with changes in the VI panel size?

I've tried telling it to scale the intensity graph indicator with the panel and that didn't work nor did telling it to scale all front-panel objects with the panel. The ramp always retains its original size.

What is up with this rash of newspeak of late? "Creative Action Request". Just call a bug a bug.

It's all part of NI's new Creative Request for Action Policy. :laugh:

WMassey,

Can you do that in LV8? Feed it 2 arrays?

All the XY graphs I have used require arrayed[clustered( ordered pairs)]

Mike

When I said "feed the graph" I didn't mean to be taken quite so literally.

I would assume** that the clustering of the arrays, like this:

is needed for LV8 just like it has always been. Sorry for any confusion.

** I say assume because I have not been masochistic brave foolish enough found any pressing need to install any one of the three copies of LV8 I have sitting on the floor of my office.

Assuming you feed the graph an X array and a Y array that define the points and if the ordering of the points within the X array is increasing then you should get a graph. You may need to adjust the line type property of the graph to "connect the dots" if all you are getting are the data points.