Jeffrey Habets

Develop a LabVIEW or Visual Basic application that show's all the web browser windows within one application, and pick and choose which window i want to see at a certain time

You could use Mozilla Firefox for this. With tabbed browsing, you can open a complete folder of links in different tabs at once.

Thanks a lot for the input guys. Both the listbox and the array will come in handy. One thing I like about the listbox is that it has a vertical scrollbar. Is there any way of inputting a scrollbar on an array?

It can be done, but you'll need to program it. You can use the IndexVals property of the array in combination with a numeric slider to set the visible part of the array.

As of october 3rd it will very probably be built into LabVIEW. :thumbup:

I would probably display the arrayvalues in a listbox. The listbox click events can easily be captured. Then, use the listbox value to index the array.

Hi jeffreyhabets!

I think the property you mentioned is called Run-Time Menu Path. I think it doesn't help me in this.

Thank for interest.

Best regards, Badwolf

:beer:

I think you got me wrong. The 'property' I mentioned doesn't exist (yet). What I ment to say was that it should exist. Indeed the Run-Time Menu Path is not of use for what you want.

Hmmm, nice one..

Although I haven't had the need for it yet, I'd say for sake of completeness there should be a VI property Runtime-Menu reference.

Edit: I entered a product suggestion for this on NI's website.

Hi everybody, as we all know, Labview is a data-flow programming language,everything must "flow in" from left and "flow out" to the right. I can't convert this programming style from general language. Here is an example that add 1 to itself.

in C. the code is :number += 1;

in lv,it looks like the following picture.

I feel it's so bad, but I have no other way.

Somebody can bring me a new idea?? Thanks.

The C notation number += 1; basically is short notation for number = number + 1; So the LV diagram is not that different from C here.

The diagram you posted can be simpler. Loose the sequence, it's not necessary (dataflow). Also, you can get rid of one local in this particular example.

Whether or not you need the second local havily depends on the context in which you would be doing this operation. Most of the time you will be operating on data in shift registers or results from sub-vi's and displaying those in an indicator. No locals needed there.

Learning moment: stop thinking in variables, the 'variable' is the wire!!

but I have yet to see a way to set which case is the one that is currently displayed.

Has anyone else noticed a way to do this?

You need the VisFrame property. Wire the index of the frame you want to see.

Yes, there are many important files that are accessible via FTP. MAX should be able to restore these files if they ever get damaged.

Yes, I understand.. What I (or my customer actually) was interested in, was wether or not it would be possible to recover without MAX (e.g. via ftp). My thought was that this could be possible as long as no crucial OS or FTP-service files would be deleted.

Yes you should lock (password protect) access to FTP, if you cannot secure access to the network containing the RT system.

So, from your answer I asume that the lock in MAX also pw-protects ftp-access?

Do you or someone else know if there's a possibility to pw-protect only certain directories as I would be able to do on *nix systems? (The users needs ftp-access to a certain directory but I would like to prevent them from reaching the rest of the system directories, like chroot-ing.)

Hmmm, something inside me tells me this probably isn't possible and should go on the wishlist.

Hi,

One of our customers asked me if important system files on the filesystem on his cRIO controller could be deleted through ftp. Since I don't have a RT system at hand to test this and don't want to encourage him to just try it I was hoping one of you guys might shed some light on this.

Does the locking feature (in MAX) of an RT-target also prevent deletion of crucial system files?

Thanks!

I think in general it is bad to have nested user interfaces (except for dialogs/modal windows), specifically because of the problems you described.

Loose coupling of UI and application functionality is the answer. If you need to spawn a subprocess which needs to be monitored and/or controlled by the user, make the subprocess message based, but without a UI and let the owning VI be the UI and control the sub-VI through messages.

Although still not the best way to do it, but in your case a nice solution without redesigning your application: instead of using the tab to display a message that the VI can't be operated you could use the tab do display the UI components of the sub-VI that is performing operations at that moment. Subpanels is one option here, the other is passing reference of the controls/indicators you want to be able to use and see.

This is ofcourse a very short version of the answer and nothing really implementation specific is mentioned here. I could go further into implementation details, but lets first see how the discussion takes of further.

When I run the program from the labView programming enviroment it creates the files and folders perfectly.

I compiled the program with the Application Builder and i ran it again. Then it says that it cant find the specified file and/or folder. It does that because it cant create it, but i dont know why.

You are probably using the Current VI's Path constant to build a path to the file or folder you want to create. This constant's value is actually not so constant in that it is different in a build executable.

Say your VI is normally located in c:\app\main.vi and you build an exe in c:\app\build\main.exe.

In the first case, the constant's value will be c:\app\main.vi in the second case it will be c:\app\build\main.exe\main.vi

So in the case of an executable you'll need to strip of one more path element to find the application directory.

If you have the OpenG libs installed, you can use the Current VI's Parent Directory VI instead of the Current VI's Path constant. It will figure out if it's running from an exe or dev.environment automatically for you.

Or you can do it yourself by looking at the Application.Kind property.

Ok, I thought I knew all the tricks to make LV frontpanels behave nicely in all screen resolutions and DPI-settings but here's one thing I can't solve and I'm not sure this is a LabVIEW (runtime) bug or something Windows/ActiveX-isch thing.

I have a LV app running on a cRIO target. The UI is exposed to the user using a webpage with an embedded panel. This runs perfectly on every resolution with the standard dpi-setting of 96dpi. Problems begin to occur when the user has selected 120dpi which is ofcourse the case with our customer. Actually I see this happen often with the crappy non-standard resolutions nowadays.

Actually LabVIEW does pretty well with the 120dpi setting when you do not use the application font, but rather something like Arial. If you want to use application font you need to prepare your entire UI for the larger DPI setting unless you think overlapping buttons and such are nice.

With the remotepanels something odd seems to happen. See the pics below.

The left pic shows the webpage (which is designed of a minimum vertical resolution of 1024 pixels) on my desktop PC with a resolution of 1280x1024@96dpi, it's how it should be. On this same system @120dpi, it also displays as you'd expect and the picture is the same.

The right pic shows the webpage on a widescreen laptop with screen resolution of 1680x1050@120dpi. Here it seems the FP itselfs 'shrunk' (since I'd expect it to be about the height of the screenres) and at the same time the embedded LabVIEWControl object grew, since it now expands beyond the vertical screen size (the actual object height=888 pixels).

Also if I switch resolution on the laptop to 1280x1024@120dpi, the webpage displays the same as at 1680x1050@120 whereas it displays correct in this very same resolution on my desktop system.

So my very fuzzy conclusion would be that on some systems with an unusual native screenresolution at a 120dpi setting some unexpected behaviour occurs when using remotepanels in a webpage. The question remains wether this is a LV runtime problem or Windows/ActiveX related.

Has anyone encountered something similar?

Or better yet, tell me it's not a bug/problem and the solution is actually very simple.

I know there are quite some folks who disable the autowiring feature because they want to stay in control of the wires (of course).

But did you know you can very easily toggle the autowiring on and off with the 'a' key? This in combination with the space-bar for changing the wires' direction (which y'all probably knew already) makes a quite powerfull combo and certainly saves me some mouseclicks now and then.

What you need is the so called Merge VI.

First, make a VI that contains the diagram as you want it to have it when you drop it on an other BD. You need to make this VI available on your palette (e.g. place it in user.lib).

Under Tools->Advanced->Edit Palette Views you can edit the palettes. Here you can right click on VI's in the palette and select Merge VI to drop the VI's diagram instead of a subVI on your VI's diagram. So what you need to do is find your VI in the palette and enable the Merge VI option.

Are you saying that after you do a write to flash, you will lose that data if you do any file IO before the write timer expires? This is odd.

If you keep that up during the lifetime of the program, yes.

I first ran into this because I was constantly (I think it was at a 500 ms rate or so) was reading volume info to provide realtime insight into available diskspace on the flashdevice. After I added the code to do that, all data I thought was written to flash mysteriously disappeared when the device was rebooted. My first thought was something was wrong with the hardware (defective flash e.g.). It took me over a day to figure out what actually was going on.

Found this on a cRIO system and NI reproduced it also on a cFP controller, so this problem probably exists on all ETS RT targets.

The filesystem cache seems to get committed to flash every second or so. With each files access you do, the timer used for this is reset. So, if you (like me) for example call the volume info primitive in your idle case and your loop rate is < 1s, this timer is constantly reset and thus all data your write to the flash (either from your app or through ftp) is lost on system reset or reboot unless you gracefully end your application using a stop button and ending your loops (which is mostly not the case on an embedded system).

Call the flush primitive you might say.. Well, this doesn't seem to work on the target.

So basically I see at least two bugs here:

1. The flush should simply work

2. The calling the volume info primitive should not reset the cache timer

Have a look at CdRecord, popular commandline burning program on unix platforms but also available as windows binaries and a huge number of other platforms.

CdRecord home: http://cdrecord.berlios.de/

Win binaries: http://www.sbox.tugraz.at/home/t/tplank/

You should be able to call these tools with the system exec.