Leaderboard

The IDE doesn't provide a UI for disabling this, but there is an INI key which works. Add the following line to the LabVIEW.ini file and restart LV: showTipStringsOnDiagram=False

LabVIEW RT does support event structures, at least in the newer versions of LabVIEW. (We use event structures in RT ourselves!) Generally one doesn't have front panels with a deployed RT application. (We don't handle front panel events directly. The way we handle this is to run the View as a separate application on a desktop machine. The View handles front panel user events and then sends messages to the RT application. Each time the RT application receives a message it generates a user event that a controller loop, properly speaking, handles.)

We went through pretty much the same process of discovery. Short answer: Yes, we put classes that work together to perform some specific tasks (e.g., configuration) in a library (.lvlib). We also put classes (or other files) in a library when a group of these form part of a template but in each instance we need a unique namespace. (The library provides a namespace and we don't have to rename all the individual contents. We can also copy the entire library on disk at once.) Finally, sometimes we have a group of child classes that obviously go together (for examples, we have Commands.lvlib and States.lvlib that contain children of CommandThisComponent.lvclass and State.lvclass, respectively.) In all cases we need all elements of the library in the project anyway, and it is actually quite handy to have everything grouped under a library in the project. (I think this is an especially important practice, by the way.) When these situations do not apply (i.e., we have a class that we may call all on its own) we usually do not put classes in libraries since we do not see an obvious benefit. (Putting disparate classes in a library adds unneeded items to the dependencies, as you say. We could make a library for an individual class, but especially since a class is already a library there doesn't seem to be anything to gain by doing that.) The other thing to keep in mind is that if you open a nested library it will open the parent library and any other libraries in the nest. Paul

many thanks Yair!! i put the line right below showTipStringsOnTerms=False and voila, no more popups! And yes, jcarmody, it certainly is a lot of local variables, you should see the rest of my vi! I've never had any formal LV training and am more of a design engineer than a programmer. I find that locals are the easiest way for me to get stuff done. yes, my code may not look pretty but it typically works (after a couple debug sessions ;-P )

Is the error related to "lack of information"?

What protocol are you using to transfer files? I would also be interested in this but more to see how much data is being transferred back and forth to view a remote panel. That's not something you can easily access AFAIK.

Here are the VIs we use for Windows authentication and domain groups. Validate Username and Password.vi takes the username and password and returns a TRUE if it validates against the domain controller. User in Group.vi takes a username (or current user if left blank) and a Domain Group name and returns TRUE if the user is a member. User Groups.vi takes a username (or current user if left blank) and returns an array of Domain Groups to which the user belongs. We only use these on our internal network, so I can't guarantee they work in every situation. Still, they may give you a starting point if you need something similar. Pat P.S. LabVIEW 2010sp1 User Groups.vi User in Group.vi Validate Username and Password.vi

Data transfer would be bytes per second. Bytes would be number of U8s or length of string. Seconds would be the dt between reads. It's pretty trivial from there.

Much better than serial (8 bit bi-directional, i.e digital inputs OR outputs ). My favourite low cost digital IO. Fantastic for foot-switches and system monitoring and essentially free. Unfortunately, not many PCs come with them nowadays. http://digital.ni.com/public.nsf/allkb/B937AC4D8664E37886257206000551CB There are also a couple of examples in the "Example" finder. You have to check whether your motherboard already has pull-up resistors (most do, some don't). Then you can connect 5V LEDs directly or just short them to ground (if using as digital in). Note that logic is reversed since you sink to ground THROUGH the IO line to light an LED. I always stick a transistor in there too to be on the safe-side, since if you get it wrong...you blow the port. It also inverts the logic so I don't get confused (happens regularly). http://www.beyondlogic.org/spp/parallel.htm