hooovahh

I'm glad I could hover over that and get the file name, I would not have guessed that was supposed to be a girl.

Yeah I was worried you would make that decision, but I understand. As I'm sure you already know many of us LabVIEW nerds are passionate about LabVIEW and get excited about new features, and ways to make our lives easier. I hope that you understand our curious nature, just as I understand why you won't be posting prototypes in the future.

I of course remembered that VI. I was also informed of the instability of that function and the dangers it has. The point of this post is to warn you to stay away from the Randomize 1D Array function he posted, and to not use any functions you maybe able to pull out of it. As much as I love to dig into NI R&D features, this is one that is truly not ready for prime time. NI wants to have an official feature for native polymorphicism, but the methods shown in that VI are not the way to go. (remember I don't work for NI and I maybe mistaken) Discussion of VI protection is allowed (my understanding at least), but the integrity of Lava could be compromised if users came for the sole reason of cracking a VI. Please be cautious around this topic and consult the Forum Guidelines if you are unsure about a topic, or PM a Admin/Moderator.

Nope no attachment. If you search NI's forum for TDMS and memory issues you'll find alot of posts. I'd suggest going through some of those if you haven't already. Other than that I'd say try to get your issue as reproducible as possible and send it off to NI to see if they can shed any light on the issue.

CAN is a communication protocol. Think of it like a Serial port (RS-232). For it to work you need a device that also speaks the same language (communication protocol). It is different from DAQ which measures (or outputs) a real world signal. A DAQ device can read voltage between two points. A CAN device can read CAN messages. If you don't have a device to talk to that can speak CAN, then the USB 8473 device will be useful to you.

Wow that guys had alot of time and dedication for that. Here's the site which explains a little about what it is. http://www.kshif.com/lv/index.html I expected cool scripting or something to get those attributes but when I dug down saw lots of case statements for each attribute, for each control type.

That's why I said "I don't believe any version of LabVIEW...." I can never be completely certain that a feature isn't in LabVIEW.

I don't believe any version of LabVIEW's development environment has user management or logins. Can you show a screenshot of the dialog you are seeing?

I'm sure you're probably aware of this, but what I've done in the past is use the Mouse Up event on the control, and then check to see if the ROI has changed from what it was previously. Still nothing wrong with catching this event.

One thing I noticed is that when running LabVIEW as the shell, the Aero theme doesn't load (I'm guessing that is a service started by Explorer). So if you develop with Aero turned on, then deploy where it is off, many fonts will be wrong. And it is likely your controls in the windows won't line up right. My fix was to let Explorer start (starting Aero) then kill it with my LabVIEW application. This also will kill any shortcuts like Win + E, Win + D. I never tried but it is likely you could just start the right theme service and have it work properly but I never tried that. EDIT: I also found that command to allow operators in the Users group, access to write files.

If I had to guess I would say this is a behavior of the operating system. I say that because I cannot seem to find a instance, where a single application, that has more than one window, will behave differently than the one we experience with LabVIEW where all other windows are brought up. (I did a quick test with Microsoft Word and IE) Well there are windows DLL calls that allow you to manipulate window Z-order. So one could certainly modify the order of all your applications' windows manually. I don't think I've ever had a case, where my application would have multiple windows, in the same application instance, and want to the operator to see one, without bringing the others in front of all other applications. I guess I just don't know your use situation well enough.

So that means that an operator can simply navigate to the built application and delete the EXE. Now I realize if an operator does this that it would probably be considered malicious behavior. In my opinion giving a user, who likely doesn't fully understand the system, the ability to break a test system so easily is a very big deal. But then again I don't know the type of environment that the system is in, and this may be a fine setup.

This is not the case at all. I can't seem to find the stupid batch file I created, but it would run an installer (with some silent switches) then run the command line program Icacls (built into Windows 7) to allow the INI file that got installed to be written by anyone in the Users local group. This batch file of course would need to be ran by someone with elevated privileges the first time. But then again only someone with those privileges should be installing updates anyway. Then the application (stored in the Program Files) could modify the INI file that was in the same folder as the EXE, even when the logged in user only had limited rights. This also only modifies the security of the INI file, the directory it self still cannot be modified by someone in the Users group.

Just a thought (and probably not a good one) but what if you install to program files like always, and have the ini file in program files along side the EXE, but then during the install run function that will set the privileges of the INI to be written by any level user? The EXE doesn't need to have elevated privlages, the file can just have lower ones. I know there is a Windows command line function to set file permissions but I can't seem to find it at the moment. One downside is the file isn't as hidden as other places, but it also feels like a patch when it sounds like the proper way would be to store the data in ProgramData.

I was curious so I wrote a quick VI to see how fast I could get a loop to run that performs some calculation. Now this is a very simple VI that doesn't call a subVI (so no overhead there). But I wanted to see how fast I could get a loop to run. Please pardon my crude code, but on my machine running 100,000,000 loops, each loop takes about 42 nano seconds to execute. Much faster than I would have expected, but again there isn't really much going on. As soon as you add any communication VIs, loop rate will increase. EDIT: I removed everything in the loop and the loop now runs at less than 2 nano seconds...but again what good is a loop that doesn't do anything? Other than a dwell I guess, which won't be very consistent.

I believe this is an issue with the ActiveX control it self. You have similar issues when you put ActiveX controls like this into tabs. It works just fine, but changing between tabs you'll see a flicker of the ActiveX control on top of the tab, and then moved back into the tab. I don't know of a work around. For the tab it's annoying but doesn't change functionality. For your application it sounds like more of a show stopper.

Or in Windows 7 press [Windows Key] + [P], and choose Extend. This is normally used for projectors to clone or span.

gb119 you have more patience than me. Copied from the LabVIEW help.

Couple things. Your processor maybe running at the GHz but that is if you are only running one instruction. There is tons of overhead when running in windows when compared to a microcontroller. I would say I could do many operations on a 4MHz micro faster than on a 4GHz windows machine, and more reliably. Which is why when I need determinism, and high speed I move to FPGAs or RT environments. Windows is not deterministic, and should not be used for an application that needs to maintain timing less than 1 ms. What if the antivirus application decides to run a scan and slow down the PC? Or if Windows update decides to install a bunch of crap during a very sensitive time? There are many cases where Windows will not be able to maintain timing and will fail. You can run a VI that has a loop rate less than 1ms. But the overhead associated with measuring that applications rate, will effect your timing and then may run slower. Quantum Mechanics is not my thing but measuring something can effect it so that the measurement is not accurate. Also your loop may run faster than 1ms some times, but again with Windows it may take more than 1ms the next time. There was some code posted on NI's forums that I can't seem to find right now that would calculate the number of clock cycles a VI takes to operator, and then using the CPU frequency would calculate the time it took. But keep in mind that doing these operations takes clock cycles and makes your numbers less accurate. Also if you are trying to do something quick try to remove all of the extra steps that maybe in your way, like queues. There have been times where I had a nice wrapper written with queues or user events, but when I needed to do something fast, it was better to just do it in one VI than it was to pass data around to other VIs.

This doesn't look the right kind of error for this, but be sure and disconnect the communication with HyperTerminal before trying to open the port in LabVIEW. If you run both at the same time LabVIEW will not be able to get a lock on the port because another application is using it.

...I think you'll fit in just fine around here.

Your IT guy was wrong. If Windows Device Manager sees a serial port, its because there is a serial port. This may not be a normal serial port that is exposed to the outside world via a DB-9 but an internal one for diagnostic support. I've seen several PCs have internal serial ports that allows for for intimate access to the PC, or it is possibly a serial port that is only accessible through a dock that the laptop is connected to. In any case it is not going to be a serial port that is going to be available for communicating with other hardware and investing in a USB-to-RS-232 is going to be a good idea. I've heard some cheap ones don't work with all hardware, but I haven't found any hardware my no name cheapo couldn't talk to yet.

So alot of people have their opinions (several in this office) but I use UltraMon to manage multiple monitors. It adds a second task bar to the other monitor, and it can be configured to only show windows on the taskbar that are on that monitor. Additionally I use the Hotkey (setup in UltraMon) to allow the CTRL + Space to move the window to the next monitor. Keep in mind this replaces the quick drop feature in LabVIEW which I don't use. If I need to find something I use search. My left hand is almost always on the home keys, and so hitting this set of keys is a quick way to organize Block Diagrams on one window, and Front panels on the other. I can also use this technique to open two projects and have one on each monitor. UltraMon also adds other not as useful features, like multiple desktop images, monitor cloning (built into Windows 7 now), multiple screen saves, and a few other things I don't use. There are other free alternatives that I hear work just as well. EDIT: Sorry I didn't fully read your post. If you want code to span both monitors, UltraMon can add a Maximize to Desktop button. This button appears next to the minimize button of all windows, and when pressed will maximize over all desktops. I don't recommend coding this way. It is useful in Excel, where you open two workbooks and what to view one on each monitor, so you maximize the master window then position the two workbooks independently.

I think if there was an unofficial patch put out, it would need alot of customization, on allowing the user to select things that it modifies. Because some people may want their VI.lib replaced, and some may not even want the Riffle function replaced. EDIT: Nevermind read his post wrong.

I think there was a T-Shirt that said something like This seems relevant.