hooovahh

Isn't that what you were after? If the subVI is running on its own as a "regular" subVI then its front panel would not be open. When in a subpanel the front panel has to be open, so the subVI can check itself based on whether its front panel is open. The property would still be true when the VI is running on its own, but does that matter in this case?

Sorry I didn't give more detail, I didn't want to inundate anyone with too much information, especially if the answer was a simple property node. I'm doing something similar to Ben's Docking code.

http://forums.ni.com...cending#M351512

Here VIs get pulled out (sorta) and become floating windows. In this case the VI always is open, it just may be in its own window, or in the subpanel.

What crelf said.

What about looking at the Front Panel Window's Open property?

This returns true when in a subpanel.

EDIT:

Also I started looking at the properties/methods available to a subpanel and I was surprised at how few there are. I couldn't even find one to tell me what VI was loaded into the subpanel. Is there really no way to know what is in a subpanel.

DOUBLE EDIT:

Apparently it is in 2012 beta. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-subpanel-property-VI-Ref/idi-p/1214481

I think I know the answer to this, but is there a way to know if a VI is loaded into a subpanel from the VI that may or may not be in the subpanel? So say I have 5 VIs running, each of them can be loaded one at a time into a single subpanel in a 6th VI which is running. Is there a way to know from any of the 5 running VIs, if they are currently loaded into the subpanel?

At the moment I am keeping track of which VI is in the subpanel from the 6th VI which the subpanel is in and this works fine, I just didn't know if there was a better solution.

I have also noticed that the property Front Panel >> Title Bar Visible will be false if a VI is in a subpanel, so this could be used as long as the VI has the Window Has Title Bar set to true in the VI properties. This solution won't work for me, because there is the occasion where the VI will have no title bar, but will be outside the subpanel.

Wow this takes me back. So I forgot about some code I did when I was first learning LabVIEW. I had a java program that made an analog clock, so I wanted to recreate it in LabVIEW as a test of my newly found skills. Here is the result. I'm a little ashamed of my code written back then, but it was a learning experience. I'll probably look back on the code I'm producing now in several years and think the same thing.

Edit: Man I need to update my site some time.

Yes, it might be used to multi screen in Labview. Just check with the VI properties.

Might be attached image will help to do multiscreen.

The question was about Multitouch.

For LabVIEW to support multitouch, first windows needs to support it. By default if you installed two mice on your PC, you still would only have one pointer and both mice will control the same pointer. As mentioned by Yair a touch screen is just a mouse so to support multitouch you really need to support multi-mice. A quick search found several 3rd party programs to have multiple mice in Windows, but I've never tried any.

But integrating gzip by using LabPython is really very roundabout. Have you looked at executing the gzip executable through System Exec?

That's what I was going to suggest. At one point I was trying to interface with 7-zip through the command line and I believe it too supports gzip compression.

I have downloaded this VI. But this is devloped in LV 2011.

Saved in 2010

Add Edit Scale 2010.vi

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?