hooovahh

I haven't tested it in anything other than in a development environment, but I believe it will work in RTE as long as the DAQ Assistant VIs are installed. The DAQ Assistant VIs actually call a NI DLL called mxwlvapi.dll, this is what actually does the heavy lifting and I assume this is installed with DAQmx.

So theoretically you could create an installer, which has the added installer of DAQmx and this should still work, that is assuming you get the path to the Assistant VIs correctly. I believe there is a registry read that can be performed to help find this. Possibly something like %National Instruments Folder%\MAX\Assistants\DAQ Assistant\common\supportFiles

As for how I did it...well, the forums have been discussing very grey topics lately, and one of them is block diagram passwords, and how they have been defeated. So out of my curiosity I started looking into all the VIs that were locked in VI.lib to see if I could find anything useful. I couldn't find much, most of VI.lib that has a password is simply a dll call. AQ has mentioned recently that most of the passworded VIs have been unpassworded to help share with the community and that is apparent here. So I searched my whole National Instruments folder and found these llbs named expressVIsXX.llb with different versions for all versions of LabVIEW. By opening up the daqmxNewItem.vit and daqmxEditItem.vit you can see that it has a control that gets casted to a DAQmxName object, and has code for Channels, Tasks, and Scales.

So you can actually use this same code to Create/Edit a Virtual Channel or Task. I'm not sure why this information isn't a knowledge base somewhere other then the fact that NI may choose to change how these VIs work in the future.

AQ has mentioned recently the dangers of using code from a password protected block diagram, but I don't believe this falls into that category, because I didn't use any code from a passworded VI, I'm just calling it, and I needed to know the type of input it wanted for a control. Looking at the BD helped me understand what was needed. In any case NI can still choose to change this functionality in the next version of LabVIEW if they choose.

Looks like you put in a lot of effort into this. One thing I noticed is the list of existing scales show all scales, even ones that are not appropriate for the current tab. So if I have a linear scale, but am on the Map Ranges tab, my linear scale shows up in the list, and trying to edit it doesn't work. Why not only populate the drop down with the scales for that type?

Also is there a reason you are doing this all manually instead of using the DAQ Assistant? Attached is a quick VI I made to edit or create a scale. You may need to update the path constant on the block diagram to point to your DAQ Assistant because the path is set currently to a 64-bit Windows, running LabVIEW 2011.

Add Edit Scale.vi

In some cases we even expose methods on the Application class that can return information about VIs without loading them.

I'm very interested in this. I don't want to cause you any work getting an extensive list, but is there an easy way to know what information can be read without loading the VI and all of its dependencies?

Edit: I may have found my answer is it the "Loads the block diagram into memory" remark or note, on the property/invoke node?

I've yet to use this feature but on my next new project I planned on not including compiled code. I'd like to hear other users sound off on any issues like these, so I know to avoid it for another version or two. I also wouldn't mind hearing people that have used this feature and have had no noticeable issues.

Some times I wish there were a more open file format for LabVIEW. I'm not looking to write my own IDE, but to be able to open the vi and determine what kind of objects are in it, or what labels there are without having to open it in a development environment would be nice.

Lets say I want to do some documentation generation on a folder of VIs. Right now I can read the icon, and VI description without needing to start LabVIEW by analyzing the bytes in a hex editor. But what if I want to get the connector pane information? Like what terminals labels are and their data types?

Or what if I use Requirements Gateway and I want to find all labels on the block diagram that start with "Covers: ". Looking at the VI file structure I have not been able to find free labels or text.

Here are the things I have been able to pull out of the VI file structure by analyzing the hex bytes: Main/Internal VI version, LVSR Main/Internal version, flag bits, if a VI is protected, the Window Title, the Help Path, the Help Tag, the VI Description, a 24-bit image of the icon, and a 1-bit image of the icon. I think I can also determine if a VI is re-entrant, and the Revision History if I spent some time.

I thought about releasing my findings on how to pull out this information from a hex dump of a VI in the hopes someone will be able to get more information, and possibly pull out free label text. If anyone is interested I can try to put some time into cleaning it up a bit and releasing it.

I mostly stopped trying to figure out the VI file structure because most of what I want to do can be done with LabVIEW Scripting. I just think that it could be done faster by reading the VI file.

hooovahh, I had the distinct impression that this was handled correctly in the TDMS viewer you were working. Am I wrong? I feel like we had a discussion about this exact issue and I was totally expecting you to drop in with a couple magical property nodes.

So I did develop a fix of sorts. I basically re-created the functionality of the Plot Legend so that I could do the things I wanted. Like don't allow the value of the vertical scrollbar to be greater than the number of plots, and allowing me to change the value of the scrollbar programatically.

The problem with re-creating the Plot Legend is there is a ton of functionality in it. Changing plot color, plot type, line width, line size, bar plots, filling to other plots, interpolation, point style, scales, exporting data, and a few others. What I did was re-create the functionality I used the most which was a very small subset. In the end I wasn't satisfied with the results and all the extra code involved so I reverted back to the normal Plot Legend just leaving a few known bugs with how the graph functions.

Is it? And what did you learn from this awesome look behind the curtains? Yes there is a function you can use to translate an error code into an error string. But the VI that you looked at does that already for you without the need to bother about correct calling convention, parameter type setup and a few other nasty C details. Not sure I see the awesomeness here, other than the desire to feed your own curiosity and find more ways to shoot in your foot.

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.

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.

You can be sure I won't be repeating the mistake of publicly posting a prototype in the future.

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.

Remember Aristos Queue's "Randomize 1D Array" VI from the NI forums?

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 Devices are DAQ devices or they do something else?

Anybody can help me.

I have seen USB8473 High speed can module. need to know more info about it general CAN devices functionality.

thanks

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.

Maybe you can hack into this bad boy and make it work for your purposes.

http://www.kshif.com/lv/ps150_85.zip

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.

Uncheck: "Tools > Options > Security > Login option > Show the login prompt at LabVIEW Startup time"

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?

http://forums.ni.com...l/idi-p/1999021

Catch ROI change events on image display controls

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.

Just booting into LabVIEW as the shell will usually flummox most operators/users. Disabling CTRL+ALT+DEL means that you can't get to task manager, from which, you can use the run command.

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.

Icacls "<File Path>" /grant Users:(GA)

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.

The benefit of placing it here is that when the normal operator run it and it prompts for a Automatic Software update, the Update Software have permission to overwrite contents in this folder.

The ini files and other local config files, we store in a different folder that we call:

C:\<MyCompany>\<MyAwesomeApplication>_Data

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.

Your solution has one possible drawback. Only changing the rights of the config file alone is likely not enough as the directory needs to have its rights also changed.

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.

You can get VIs to run in well under a millisecond. You probably won't get down to a microsecond though, there is some amount of overhead involved in a VI call (as is the case with function calls in any language). That doesn't mean you can't execute a chunk of code more often than a microsecond, careful placement of loops, use of inline VIs, and subroutines can make for some pretty impressive speeds.

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.