hooovahh

Just let him have his fun. It lets him feel like a leet haxor. But seriously NI doesn't appear to have any thing to hide in those VIs, as demonstrated by this here.

There's a few things I don't like about the graph controls, and this will just add to my list. I'm going to guess that the reason I have such difficult times with graph controls behaving the way I want, is because they are more advanced controls than a simple string, or numeric, and alot of functionality is actually built into the control, and the behavior I expect may not be the behavior that NI intended when they came out with them. Sure they've added features over the years, with different Property/Invoke nodes, but I still feel like they are complicated and would need NI to invest alot of time to get them to function in a way that is more useful. The functionality in that plot list section of the graph control is very lacking when compared to an array with a vertical scroll bar, and maybe that is the real problem I have with it and exposing more functions for it would probably make me a little happier.

NI

This discussion reminds me of an another Windows API I have yet to use but have wanted to. I saw that there is an API for controlling the progress of an application, through the taskbar (not sure if there is a name for it). http://sine.ni.com/nips/cds/view/p/lang/en/nid/210184 Very neat stuff, but like I said I haven't found a good place to use it yet.

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.