Yair

OK, here's another version. It becomes opaque when you enter the window (I had to replace the checkbox for that) and uses a string instead of the array, which looks better.

Implementing the resizing will be more complicated, because it involves making sure that the window does not become too small and will probably require turning the VI into a state machine.

Download File:post-1431-1126426494.llb

I would program it myself but I think the Mouse Enter event is only available in 7.1.

6080[/snapback]

Actually, I think it even existed in 6.1. This VI already uses the mouse leave event. You can copy the transparent VI with the input into the mouse leave event and then duplicate the case for the mouse enter event and feed 255 into the VI. The problem is that the white backgrounds remain transparent when you do this and only return to white when you stop the VI.

This VI would actually be portable into 6.1, but that didn't include the mouse input VIs used to move the window around. Those could probably be worked around using mouse events (move, up, down, leave), but I don't feel like it.

Like I said, this program was written rather quickly, so the result isn't perfect, and there are some problems porting. One example is that I now opened it on another computer and the minimize and close buttons have different sizes (They could be replaced with buttons with images). Some other improvements could be making it resizable, getting rid of the taskbar button, maybe adding a taskbar icon and using a string instead of the array for display (again, quickly written).

You might wish to search for Greg's presentation from one of the NIweeks (I think it was 2000) called "The good, the bad and the Ugly", where he shows a nice example of how to analyze the problems with a UI and correct them.

The things I write are usually not for scientists and engineers, but for simpler people, and can involve running complex systems, sometime with touch screens, which are harder to design for (you need larger buttons, can't really use menus). A favorite technique is taking a relevant picture and using that as part of the interface. If the picture is too colorful, reducing the amount of color helps to make the indicators stand out (the same thing that happens when winXP's shutdown dialog pops up, and I swear I thought about it before them, or at least before they published XP). That makes it much clearer to the operator, better than any text label can.

I agree that using gray as the background is usually good, because it helps make your stuff stand out, and that using too many colors is usually bad, because then nothing stands out. A good UI should be clear to the operator.

Nice desktop clock. :thumbup:  Were can I get one?

6058[/snapback]

Since this is a LabVIEW board, here is a quickly written clock similar to that one, windows only.

It includes transparency, a round window, the ability to be always on top, and the ability to be moved by clicking anywhere inside the VI.

I used code from LTR, LVWutil32 and LAVA to do the window shape, always on topping and transparency, but since they all call user32.dll (as far as I could tell), I think it should work as is. I don't use it myself (I believe in a clean computer. If I want the time, I have it in the corner of the screen), but if anyone thinks this is nice and would like to improve it, I wouldn't mind seeing the results.

Download File:post-1431-1126381117.llb

There is a way to insert a control wired to the "end loop" terminal?

6019[/snapback]

If you have the reference to the loop, wire it into a property node and get the Loop End Ref>Reference property. Wire it into an invoke node with a Create Control method.

Scripting features that actually modify VIs cannot be used on a running VI nor one reserved to run.

6021[/snapback]

That's not entirely accurate. You can use the VI class method Fake Exec State to trick LV into thinking that the VI is idle (state 2), but you should be aware that many features will either stop your VI, cause it to crash or cause LV itself to crash, because modifying LV code while the VI is running is almost a sure way to do that.

For those interested, this presentation can be found here.

It's ok that I can build the vi again in Linux, but I just want to make sure that the functions which are available in Windows LabVIEW are also available in Linux LabVIEW.

I may be wrong, but my understanding is that you can only run a LabVIEW EXE on the platform for which it was built on.

5960[/snapback]

Yes, you can only run an EXE on the platform it was built in, and I remember seeing a fairly detailed explanation from Rolf somewhere on exactly why this is so.

An OS emulator (like wine) would probably work if you don't use hardware, but I don't know how fast or reliable it would be.

Thank you for your reply! 

I would also like to know whether the funtions available in LabVIEW for Windows will also be available in that for Linux. (Since I have finished writing some vi with LabVIEW in Windows, I understand that the vi written in Windows cannot be used in Linux, but at least I hope that I can use those vi written in Windows as the blueprint and modify not too much if I want to have the same function in Linux)

Thank you for your attention~

Ayumi

5947[/snapback]

You can use the VIs you wrote in windows, but if they call windows specific code (DLLs, registry VIs, ActiveX), that code won't work. All the code that is pure G should work.

Build a three-frames sequence structure. In the first and third frames place the tick count VI and in the second frame place your code. Subtract the value of the counter in the first frame from the value of the counter in the third frame and you have your time (in ms).

Note that updating front panel controls can create some serious jitter, so unless this is part of your test, you should not update any control inside the second frame.

Thanks for your answer, this will work i am sure.

My concern is if the data block is large (10 Mbyte onwards), that the overhead will be time consuming ?

It's difficult to imagine what the data conversion is adding (my previous saving in Ascii format cost a lot time converting from double -> Ascii and from Ascii -> double in Matlab and i lost resolution)....?

5873[/snapback]

There should be some overhead when converting to variants. As a neater solution, if you have the professional version of LV, you can create a polymorphic VI, which is basically a collection of VIs with similar connector panes, but where some of the input data types are different. Once you wire in an input which exists only in one of the subVIs, that subVI is selected, similar to what happens when you wire an array of a certain type or size into an array function.

To create a polymorphic VI go to File>New and select Polymorphic VI. Now you can have one VI which will save a DBL, another which will save booleans and so on. Don't forget to include a variant one. You can save all of the VIs in a single LLB and have the polymorphic one as the top-level VI. You can also look at some of the VIs from OpenG for examples (like the Data Changed? VI).

This should at least remove the overhead involved in the conversion.

For example, having the ability to set the execution highlighting to run only in certain parts of the VI, or only when certain conditions happen (like using a BP\Conditional BP, but having LV turn HE on and off automatically).

Or, like having a slide speed control which will allow us to play with the speed of the flow, so we can tell it to move fast when we see it gets to a boring loop, or tell it to go slower or fully stop when there's data we want to examine more closely.

Which VI gave you this error?

Are you trying to explicitly include it in the application?

You should have no problem building executables that use the picture functions, and you shouldn't have to explicitly include them. They should be installed with the run-time engine if you create an installer for your application.

If you call them dynamically and want to make sure the application knows about them, place them in a VI and include that VI in the build.

Your question is very general, but I would say use a for loop with some waiting and place the indicator in the loop. Here are 2 examples, one using shift registers and one using calculation.

The easiest way is to use a global.

Drop a global from the structures palette on the diagram and double click it to open a Globals VI. All controls in these VIs can be accessed through the globals. Create the control you need, wire the data into it in one loop and copy the global to the other VI and read it there. You should note that using globals can be dangerous if not used properly, because you can easily get race conditions.

Another global option you can look for is LV2 style globals, which are somewhat safer in the race conditions department.

You should look up some LV tutorials which explain these things.

Hi Everybody...

I use LabView for many applications.  And whatever our clients need.  I may attempt writing a video game for fun... 

JLV

5835[/snapback]

Hi Joel, welcome to the LAVA forums.

I think you will find out if you put some time into the LAVA forums as well you will find it even harder to reach 1000 replies. Plus there are no s here.

I use LV for various control applications, also in agricultural and semi-industrial applications (like growing fish or sorting corn), while providing advanced communication (wi-fi, ethernet) and various interfaces (PDAs, cell phones)...

Ditto for the games comments.

I thought to myself, God almighty! Is it really possible that there are such bad LV programmers out there?

5811[/snapback]

Yes, for the exact reason I mentioned before. People think it's "programming for non-programmers" so they just go ahead and do it. I know what you mean about bad diagrams (and FPs).

Picture this... Suppose someone asked you to write LV program, and the only way you could pass data around was via the "value" property and using ctrl references. Now you get the picture.

I never could figure out how so many new users manage to find the Value property before they find local variables. I see that very often users use it extensively (usually without refs, because they don't know what they are), and have the terminal put somewhere on the side. I have no idea how people can read such code, with wires going to the left, overlapping objects and so on. Then again, I never could figure out why certain members of my family have a tendency to leave a mess whereever they are when tidying up the room takes about 30 secs.

So when you say you can easily figure out LV code quicker than C code, think again. You'd be surprised.

I'm sorry, you're right. I should have said "a properly written diagram is much easier to grasp in a single look..." and I still consider this to be true, as I'm sure you do. The color coding and the fact that you can clearly see structures really help when you look at large piece of code (more than 6 or so nodes).

This doesn't negate my previous claims about documentation. I still think that it's preferable to read a comment that tells you what the code does than to start figuring out by reading the code. This also helps when debugging, reviewing or modifying the system later, because you know what the programmer intended for the code to do.

you can't do easy compares on the code since it's graphical, and other issues like that (such as the fact that files are tens to hundreds of k's, instead of small text files, and that no two compiles of identical code turn out identical executables).

5761[/snapback]

Just some minor nitpicking, not disagreements - I don't know about SCC, but LV has a built in comparison option, at least on a single VI level. The files are tens of Ks, because unlike the small text files, they also include the front panel and the compiled code, which allows each VI to be fully executable by itself. As far as I know, the building into an executable produces different code because the builder adds some information to the file (date\time and such). I don't think it affects the building of the executable code.

The problem is that people usually do that with not enough time and not enough experience and their coding style and archictecture is horrible.

The simplest way is to use the built in remote front panels feature. All versions other than the base version have it and you should get 1 or 5 licenses with LV. You will need to activate the license using the license manager (Start>Programs>NI). This will allow anyone to view the VI. If you want someone to control it, they will need to install the LV run-time engine, which should be a free download from NI's site. You should also consider the fact that only one person can control the VI at any given time. Read the LV help for more details on this feature.

Another option, which does use JAVA and is free, is LabVNC (search google for it). It basically translates your FP into a JAVA applet, so you don't need to install the RTE on remote machines. The main down side to it is that it wasn't a commercial project and that its development was stopped several years ago, so it may not be fully finished and it may have bugs.

Sorry I couldnt ZIP it, my work firewall filters uploaded zipz

5733[/snapback]

Does your firewall filter ZIPs which have been renamed to have a different extension?

It should be easier for people to download one file and rename it.

Also, an important tool is the LLB, which allows you to save many VIs to a single file (although you need to be careful in how you use it). You can save as an LLB by going to File>Save with Options>Development Distribution.

Just a tip for next time. :arrow:

I had no problems hearing it with windows media player 10 under XP.

I also tried the mplayer2.exe (that's version 6.4) and it worked fine.

The podcast (about 30 minutes, 18 MB) has been posted to NIs FTP server here. The file is called LabVIEW Architecture Podcast Project.zip

I suggest you try posting to NI's forums. At least 2 regular users there (Unclebump and Donald) have some experience with these things and can probably help you.

I believe that you can use Datasocket to connect to OPC data, but as far as I know, this is highly unrecommended for anything more than a fairly small number of tags. You can search NI's site for quite a few posts about OPC.

Another option I saw recommended there was to use the OPC server from Kepware.