m3nth

I agree... it would help to have a ruler and/or coordinates added. Another area that I find myself wishing for this is when controls are created on the front panel way far away from all the other controls. This is usually during cut and paste operations. So double clicking on the block diagram terminal switches to the front panel and I want to grab the control and move it to be in close proximity of the other controls, only don't know where that happens to be. The navigation window has helped some with this but if you're like me and don't keep it on then you have to turn it on, move the object, then turn it off.

I'm not sure how many times I've used the group and alignment icons, but I'm sure not as many times as I've changed back and forth between the front panel and the block diagram. I think many of us have become comfortable with using Ctrl+E to switch without thinking but there are still those times when I'm using the mouse only for navigation on machines where it's just more convenient. This was also one of my largest frustrations when I was a LabVIEW beginner--trying to figure out how to switch windows and wondering why in the world there wasn't an easy to see icon that would do it instead of having to find the menu command. I think an icon to switch back and forth would be really nice and super convenient. Or better yet, if the toolbars were customizable like Microsoft apps, where you can add commands from the menu that either have their own icon or add in as text 'icons' that are really just buttons.

Thanks for the info... got it added in successfully. Still would be nice if it just came on the normal palette though... I guess in due time.

Actually, clusters automatically have items added to the end numerically--you have to reorder the control to be an earlier index (which is what I did since I wanted the items grouped together). Second... I have been reading info on LV2 globals and do not understand how there are less copies of memory made for an LV2 global in comparison to using a global or a global reference that is used to pull the value out through a property node. When an LV2 global (subVI) is called... isn't a copy of the global created at the output terminal of the subVI? Is this any different than a copy being created when you read a global variable, or a global-variable-referenced property node to some other control? Obviously there are other benefits, such as avoiding race conditions, but I'm still trying to figure out what the big advantage is from a memory management perspective. If I had a large array on the main.vi and accessed the Value property through a global reference, it would create a copy of that array, correct? And if I simply had the array itself as a global and I read the value directly, LabVIEW would make a copy of it right? And if I had the array stored in an unitialized shift register that gets passed to the output array terminal of a subVI, there is then a copy that is generated for that too right? So is there any difference besides the overhead of loading a global in comparison to loading a subVI? Finally, a note about my use of globals is that their use is typically limited by the execution flow control of my program. Since program execution is linear, there cannot be a problem with race conditions.

Well... after implementing the strict-type constant approach I've found (unfortunately) the major downfall: Unbundle by name functions do not retain the same name if the strict typedef control is updated. They are based instead on an index that remains constant. Ie, after inserting an element into the front of the cluster, the advantage is no broken wires on storing the reference, but all of the numerous unbundle by name calls in various VI's are now accessing the wrong data! doh! If the names of the items they were unbundling linked back to items #2, #3 and #4 in the cluster, they will now be unbundling items #2, #3 and #4 with the new item inserted, which means they're all off by one. Old Cluster Boolean String String Unbundle by Name: Boolean String New Cluster Double Boolean String String Unbundle by Name now is automatically updated and errantly says: Double Boolean

Well I've heard rumors of such things before... My request then would be to add support for this feature so we can have it on the palette and don't have to cut/paste it from some other VI. Obviously without message boards I would never be able to use this feature in my native LabVIEW environment. How come I find myself cut/pasting the features I want in LabVIEW instead of NI just giving them to us... rrrrr.....

I have the same problem. Good idea. :thumbup:

I would like a way to comment stuff out of my code so that it is not visible to the compiler. Just like you would normally be able to do in a text-based language. I've wanted this since just about day one of using LabVIEW and have had a hard time wondering how hard in the world it could really be to implement. A "comment" structure would allow for uncompilable code, broken wires... whatever you wanted. It would be a true comment, not a comment that must be compileable, as is the case for a case structure wired false, in which: The LabVIEW compiler still 'sees' the code The LabVIEW compiler will try and compile the code Your program can't run if your 'commented out' code is not compileable Any VI's that you 'comment out' and want to simply have available for reference, are loaded into memory (and compiled). In C++ the compiler doesn't even know commented code exists--LabVIEW has no equivalent.

Alright... you're right on... I got your example to work after some fiddling. I had no idea that a constant created from a strict-typed control would update with that control--that's the missing link I was looking for. Which is what you were saying previously, just that it looked like the "strict-type" constant in your example was just strictly-typing the variant--I didn't realize that it itself was strictly typed (linked) to the control it was created from. Very helpful. My previous understanding of the behavior of that constant would be if you were to create a constant from the control without the control being a strict typedef... hence my errant conclusion that it would just be a constant then, not linked to anything, and require re-creating a new constant every time the control is updated. Thanks for the explanation... :thumbup:

In regards to globals... consider why they are "a no no". It is because they are horribly innefficient correct? But this is an innefficiency from the computer's point of view. From the programmer's point of view (mine anyway), they are not horribly innefficient at all. Horrible innefficiency from a programming perspective is wiring the same thing through ten different VI's, having a mess of wires, not being able to understand the code, not being able to code new things easily, not being able to change old things easily, etc etc. Globals can serve a very good purpose in this regard--sure it's nice to know good programming practices and to follow them (which I do), but I am also of the "don't care" philosophy when it comes to balancing the efficiencies listed above. So it costs me an extra ten megs of memory... or maybe fifty... or maybe a certain routine even goes a little slow. New computers aren't getting slower though, or coming with less memory, so really I don't mind making my coding several of orders magnitude more efficient at the expense of a little bloat here and there, just so long as it's limited to areas where there are large efficiency benefits. Also if I am not mistaken, there are 'efficient' ways to use globals too, by using a 32-bit reference for example, instead of an array of several hundred cluster elements with who-knows-how-much stored in them. About the example you posted--that will work, but essentially what you have to wind up changing then is the strict-type constant for every instance where you access the data of the cluster--this would be worse than what I have now since you would basically be re-coding everything any time there is a change, much as you would have to recode a non-strict typedef control if you were passing through several VI's by value. When passing by value, strict typedef controls let you not recode everything on the receiving end by opening the master typedef control and changing it once. There is apparently no way to link those changes to a reference control though that is strictly typed to the strict-typedef control.

I use strict typedef referencing to manage large data clusters. To make this data available globally I create a global reference which is initialized on startup with the reference of the FP cluster control (where the data is stored). My current problem is that when I change the specific typedef (what's in the cluster--say I add a new item or something), all of the SubVI's that use that specific typed input will update automatically (as they should). The reference to the typedef control containing the data however is now typed differently than the strict type of the old definition used for the global variable, which is used to access the data by reference anywhere in the program. That means of course, all kinds of wires break until I fix the global. Here's a summary of what happens: I add an item to the specific typedef All subVI's update with the new typedef The reference -> Global Variable wire breaks Lots of other wires break wherever data is accessed by reference using the global. To fix this currently I must: Click the reference Create a control so I now have a specific typed reference control Rename it to be the same as that of my current global variable containing the old specific typed reference control Double click to open it on the front panel Ctrl+X to cut it Back to the diagram... click the global to open the global definition Ctrl+V to paste new typedef reference This is, at a minimum, annoying--especially when I'm making numerous changes to the control :headbang: Does anyone know of a way to create a global variable that is linked or automatically updated as specific typedefs are? I have tried to create a reference control that is typed to the cluster control, but I can't make it linked to that cluster control--so that the reference type automatically updates when the cluster type is updated.

How were you able to extract the "Control.Terminal" property from the VI you listed?

What a great idea! Modal dialogs also made my life completely miserable when I first started using LabVIEW. My solution to this problem now is to use the "Compiled?" flag I usually carry globally to set the modal properties for each dialog box I create. The first time the dialog is called it will check the flag to see if the VI is compiled (running in an executable) and set the window property to Modal/Dialog if so, Floating if not. This works great for developing when you're going to compile the final product, but your little app lets you develop exactly as the app will be run, especially if you're not compiling. For users curious to peek at the source code but can't figure out how to open it, here's one way:

I'll second that.

That link didn't work for me but this one did :arrow: FTP Link

In order of execution, the "Card" input is fed to the top two VI's which output "Status", "ID" and "Handle". Handle is then used for all remaining calls to retrieve hardware information. If by error checking you want to know that the hardware is valid and connected, what you would usually do is check for an invalid Handle (Handle = 0?). Without a valid Handle, none of the secondary calls using Handle as an input will execute correctly. A second way would be to determine that one of the output values such as Wrap Around Angle always needs to be zero or non-zero, or some other criteria, then check for that, although checking for it to always be zero (as your post stated) doesn't seem to make intuitive sense (but who knows). One thing that you can try to do is to induce errors into the system and see what number values they produce in the VI. In other words, try running this VI with probes on the different outputs and without the hardware connected. Does Handle always equal some random number when the hardware is connected? Does it always equals zero when it is disconnected? Does status always equal a fixed number when the hardware is disconnected? By seeing what conditions are present with and without the hardware you might hopefully be able to see what to test for.

I am not familiar with your exact issue/setup but hyperthreading does cause problems with certain hardware. You can try disabling hyperthreading, which is what we did with our particular (unrelated) hardware problem we were having--that let us isolate it to a hyperthreading issue and then contact the hardware vendor.

Background information for this post: I wanted to learn how to make an Express VI and was able to do so thanks to PJM labview ( :arrow: Creating Express VI's) and Jim Kring ( :arrow: Recursive LabVIEW Calls, Using scripting/OpenG/VIServer to create recursion). Many thanks to them for their information and source code which I have compiled and used here. :thumbup: In order to help me understand how Express VI's work I made a Word document that essentially turned into a tutorial on the way NI has set up Express VI's, to the best of my understanding. Not only are they fairly simple once you take the time to try and understand them, but you can make your own with a little bit of effort and a starting set of template files. Attached is the Word document Download File:post-360-1095356483.doc, the set of template files Download File:post-360-1095354541.zip, and my own Msg+ Express VI Download File:post-360-1095354635.zip which I was in dire need of as it greatly expands upon the flexibility of the Display Message to User dialog box that is included with LabVIEW. In order to be able to use the Express VI that I've included however you will need to run the Tagger.vi to link it correctly since it is linked using an absolute path (which I haven't found a workaround for). It works fine on my system but won't be able to find "Msg+ Express Config.vi" until it is tagged with the absolute path on the machine you're using. My understanding of the Express VI's is probably limited so I'd be interested in anyone else filling in any other information I may have missed, or any other comments/questions on getting the code to work. Everything works right for me so post problems if you have any.

I have a very specific need for an Express VI, basically to use my own dialog message box code instead of NI's so I can move the mouse onto the buttons, set the title, change the appearance, etc. I can currently use my own code but that doesn't allow me to move the constants off the block diagram that are required to set the title, message and button captions (which I find very very helpful when coding to reduce clutter). At times I resort to using the Build Text Express VI but that has obvious disadvantages (mainly making the VI hierarchy window unreadable) NI charges $500 for their Express VI toolkit which there is no way I'll be able to get. Does anyone out there have it that might be willing to work with me to create one? Or is there anyone with a service for this, ie a flat fee to work with end customer (me) to give me something useful in relatively little time, for relatively little $$$ compared to the whole blooming toolkit? I'm guessing not but can't hurt to ask... Thanks...