m3nth

I believe the "E" would be what you were looking for then.... that makes a bit more sense of your previous statements.

So you put "3^2" in a string for example and then what are you trying to do with that string? How are you processing it? Or are you saying you would like the 2 to appear as a superscript? LabVIEW's math functions that handle exponential operations are located in the Numeric Palette. Block Diagram > Functions > Numeric > Logarithmic > Power of X That function "Computes x raised to the y power (x^y)". It uses numerics as arguments, not strings, so if you wanted to use a string that read "3^2" and compute the value, you would need to convert the values to numerics and perform the Power of X function.

I might be able to post an example of this for further understanding, but for now... I have a template with some case structures where I am instantiating a typedef control. When the control gets created it gets placed inside one of the case structures. I actually would like it to be outside of that structure so it can be used as the selection terminal control ("?"). I have found a workaround by just adding a control to the template and then replacing it with the new control (so it's already in the right place and wired properly)... however I was still wondering if there was a known way to solve the above problem.

Big data clusters = Bad news in memory land, but if you're so inclined you can take jpdrolet's suggestion. If you have two For loops... - Outer one goes from 1 to # arrays - Inner one goes from 1 to # array elements for each differently sized array - Index output from inner loop to create a properly sized 1d array - Wire indexed output from the inner loop to cluster Bundle (between inner & outer loop) - Wire output of cluster bundle to outer loop boundary - Index outer loop boundary You now have an array of clusters. Inside each cluster is a properly sized array. Index the array and unbundle to obtain your properly sized array. Usually when I'm doing this kind of thing though it's easiest just to use a 2d array that sized to the max 1d array size, then keep a 1d array of sizes that correspond with each row.

Anyone know how to automatically open the icon editing dialog for a VI?

i2dx, I understand stripping off the executable.llb name once it's compiled but that would just be wired to a DLL argument, which wouldn't break the VI. It might make it not work right at runtime, but it wouldn't keep it from running. What would break the VI is in the properties box of the Call Library Node--if the library listed could not be found or was loaded from a different location (different version).

Hmmm. I use the quotient/remainder function (Block Diagram > Numeric > Quotion & Remainder) to check for even multiples. Is that what you're trying to do?--or something different?

Ah... I just noted that you are using a formula node... somewhat different. Can you exit the formula node and use the regular LabVIEW case structure? It seems like you would be able to re-enter the same node or a slightly different one following execution to pick up where you left off.

Use a case structure with a numeric, enum, or string feeding the question mark terminal. In LabVIEW, each of your "If" and "Else If" conditions will occupy one case of the case structure. You can also use ".." to handle a range of options, such as "0..3", which would work for values 0, 1, 2 or 3. The regular "Else" is equivalent to the case noted as "Default" in the LabVIEW case structures. This can be a case by itself, or it can be assigned to any other case, so you may want the default case to be the case for value 0, so it would look like "0, Default".

I may be missing something here but your application shouldn't compile if you load it in the development environment and the run arrow is broken. Or if you force a recompile (Ctrl+RunArrow) and then it's broken--in neither case should you be able to compile. So if you can load it in the Development Environment and the run arrow doesn't break, and you can compile it, but when you open it up and it's broken, that means it couldn't find something that was supposed to be there. Your DLL's I'm assuming. Or perhaps you have different DLL versions that cause it to break?--One that's being loaded by the development environment and one that's being loaded by the executable? That's what I would check into--where are your DLL's, where are they supposed to be, and are any of them different versions with the same name.

You need to use special calls to set a window always-on-top or not-always-on-top. There's a package with windows manipulation functions already put into LabVIEW wrapper VI's that calls LVWUTIL32.DLL (which you can search for). Here's the link I found even though I'm not sure it's the most recent--maybe someone knows where a more recent link is. http://digital.ni.com/public.nsf/websearch...6256c3f006ee656

My understanding of LabVIEW's automatic multi-threading is that it doesn't actually multi-thread stuff that's on the same block diagram, only when you're making function calls (subVI's) that can be started up in a different thread. For example (in my understanding) if there are two loop structures running in parallel adding up numbers, they're not really executing in parallel--LabVIEW switches back and forth between the two different loop executions to make it seem like it's happening in parallel. But if you took the contents of both of the loops and placed them each in their own respective subVI's, then it would have the capability to multi-thread the calls to the subVI's which would be parallel processed by the OS as compared to LabVIEW. If the part of your code where you're communicating with the dongle is in a subVI, try changing the Preferred Execution System under the Execution settings for the subVI so it is not running in the default thread (same as caller). If the caller is running in the UI thread, then it's going to lock everything up (at least I have had problems somewhat similiar). If that doesn't work or if your code isn't in a subVI already, I'd try taking the whole loop and putting it in it's own subVI and then tweaking the execution settings.

I was wondering if anyone knows of any libraries or optimized functions that perform math on large numbers. I've coded my own but am curious on more optimal ways of implementing some of the functions I have. I haven't been able to find anything online. This post on factorials has been my inspiration to start looking though: The factorial routine that won the NI coding challenge does 3000 factorial in 50ms! That's wayyyyy faster than my math VI's (3.6 million times faster to be exact). http://forums.lavausergroup.org/index.php?showtopic=1543 I was wondering if anyone has seen any pre-existing code floating around somewhere though to perform large number math using arrays.

That's an interesting post you linked to... I ran into the same problem, needing to recursively build a right-click context menu that had sub-menus as well. My solution was almost exactly like Michael's desired solution screenshots.... I basically just enter my menu in a string constant now and the VI's will figure out what level each item is and build the submenus. That saves having to manually code the right-click menus with the different sets of menu-building VI's.

Wow!

This 3000 factorial business sounded interesting so I tried it using array-based math to see how bad of a calculation it would be... it turned out not too bad, only 3 minutes on a 1.6GHz PC and another 45 seconds to convert it into text. The attached FP/BD screenshot shows my results... I used the VI that is blank as a generic base converter for the binary U32 array once the factorial was finished... the number of characters on top determine what base the text is so the binary array can be converted to decimal (as shown) or hex (base16) if the letters A-F were added to the character set. If anyone's interested in doing array-based math let me know--it's very simple and can handle incredibly large numbers.

Those are interesting... be careful with that first one though that locks the mouse cursor!!! With Win2k (probably XP too) you can hit the window key that pulls up the start bar to unlock the mouse. Also with the second ones if you make the mouse invisible it is only invisible over the window that you called the function from. Here is a VI that I use for moving the mouse. I use it in my express dialog boxes to snap to the default button (really convenient for touchpads) and I also use it other places when it's obvious what the user will do next... snap snap snap. Just pass it the control reference and it will figure out the center of the control and snap the mouse there. It can also return the mouse position before the snap was made (which I never use--hence not connected to the connector pane). Download File:post-360-1120072879.vi

On the Block Diagram Select... Functions > Application Control > Property Node Place the property node anywhere that's convenient On the property node > Right Click > Select Class > VI Server > VI From the property node, select Front Panel Window > Origin Right Click > Change All To Write (or Change to Write... there's only one property so it doesn't matter) Right Click > Create > Constant This will recenter the front panel and set the origin to (0,0) every time the program runs. The (0,0) location of the front panel is noted by a diamond when the layout grid is displayed. The attached screenshot shows the VI before it runs... after it runs only the lower right half of the diamond is displayed so it looks like a triangle in the upper left corner of the panel once the program goes back to edit mode and shows the layout grid. Also, there are other (easier) ways to get the front panel property node when there's other code already on your block diagram, but that will get you there from scratch.

Wow... I have never seen that before. Probably because I wasn't looking. :thumbup:

That's not entirely semantics, I just tend to use the cut & paste method since I usually have large apps open and don't want every reference to the opened VI automatically updated to the new file that results from the "Save As"... the one caveat of using that method. Besides that though you're right, it is better than cut and paste if you have nothing else open and want to make a copy. :thumbup:

I have had similiar file error problems with the LabVIEW VI's. I just copy the guts of it to my own wrapper then add or delete what I want in terms of error handling. I like to get rid of the general error handler so I can pass errors in and out of the file routines without getting the pre-canned dialogs. So for you, I would go into the "Write to SGL File.vi" and copy everything into a new VI and save it in your own directory as Write to SGL File 2.vi or something (whatever works). Then either remove the general error handler at the end that will cause a popup, or use another general error handler directly before it with the option set to cancel any error 43 messages that come result from your file operations.

That's an excellent idea Jim--well thought out and something I hadn't considered. I would still like to be able to search by enum instance of course The only concern I might have with making wrappers is trying to remember when exactly LabVIEW makes copies of data. If I had a large amount of data (big array or something) I was passing out of the LV2 global, would there be another copy made because it gets passed out of the wrapper also? Or just one copy made? Either way, having LV2 wrappers for each function sounds like a great idea.

This is exactly the information I was looking for and couldn't find... Bravo! :thumbup: I should be able to implement based on your instructions.

I actually have run into this many times in non-scripting applications where I am performing mods on a control via a set of control refs, hence my suggestion. If it was something just for scripting I don't think it would be worth adding to the wishlist (since scripting isn't really what I use the most in LabVIEW)

Well, here's how it adds up in my book: No interest = No $$$. A faithful following of people who are tantalized with their products will go a long way when they start selling something that they have generated interest in.