Jim Kring
-
Posts
3,905 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jim Kring
-
-
Wow! I'd call that a shopperstopped
I have edited my post, in order to accurately qualify my statement:
"the development environment crashes on me periodically when editing VIs."
I haven't had any problems with crashes, when simply running code -- only when editing code.
-
Personally, I am being very selective of which projects use LabVIEW 8.0. I have been using it regularly, and the development environment crashes on me periodically when editing VIs. And I have discovered quite a few bugs -- the one that I dislike the most is that Drag and Drop doesn't work in built EXE's. If you decided to convert a project to, or start a new project in, LabVIEW 8.0, make sure that you have tested to make sure that the critical functionality is present. FPGA, RT, PDA, and other LabVIEW modules got a big boost from the LabVIEW 8.0 project, and other, features -- I have tested PDA, and it is *much* better in 8.0.
Regarding the license, it is my opinion that the LabVIEW 8.0 license is much better than the LabVIEW 6.1 or 7.x licenses.
-
Another fairly common term that I've come across is "VI Global" or "VIG"
Chris, it might be a little late, but I have added VI Global to the poll.
-
Yeah, I know that it is bad to use globals. But let's say you had too. What would you use as the file extension. LabVIEW will use the .vi extension, by default from the Save dialog. And, LabVIEW does not recognize the .glb extension. However, I have seen people use .gbl as a file extension for global variables. What naming convention do you use?
-
I was just informed by someone at NI (thanks again, Darren!), that the LabVIEW documentation calls them Functional Globals.
You can find this in the help, here:
Fundaments >> Multitasking, Multithreading, and Multiprocessing >> Concepts >> Suggestions for Using Execution Systems and Priorities
Synchronizing Access to Global and Local Variables and External Resources >> Functional Global Variables
You can also find a few references to them in the help if you search for "Functional Global" (include the quotes when you do your search).
-
Because the Austin Convention Center is (probably) cheeper in August. The weather is very hot -- it can get up to 110 degF! And, it is easier for people to take a week off of work during the summer.
-
I recently installed the LabVIEW Version 7.1.1 for Windows 2000/NT/XP -- Patch and have been experimenting with dotNET 2.0.
I first installed the 7.1.1 update, mass-compiled, then installed the 'f2' patch. These installs replaced the original files in my 7.1 installation directory. Everything works fine.
Now....
I'm about to start work on a project with others using LV 7.1 from the original CDs installed.
Does the 7.1.1 version change the VI versions? Would my VIs created in 7.1.1 be compatible with 7.1, or will I need to revert. It's not a problem to revert, I'd just like to save myself the trouble....
7.1 and 7.1.1 are compatible. However, they will be re-compiled when moved between these two versions.
-
I have created a poll. Let's find out what the consensus is.
-
Hi, Jim. I'm pretty certain there isn't a property to do this, as there is no VI Server class that coincides with the plot groupings. The only thing I can think of is to see if you can get a reference to a plot area, and if so there might be a property under there somewhere (sorry, I don't have 8.0 installed on my machine to look to verify).
I haven't seen many comments regarding the MSG, and haven't seen the bug reports since I'm working on the MINDSTORMS project right now (I did about 80% of the work on the MSG - long enough to write a bunch of buggy code, but not long enough to stick around and fix the bugs
. Are you finding it useful?J
Hey Jason. I don't see anything related to the Plot Area that shows any hope of changing the plot group title. I haven't had an opportunity to use the mixed signal graph, but I'm looking forward to it -- it's a pretty powerful UI component. The multi-plot cursor feature is very cool, too.
Cheers,
-
The account is closed.
If you like to leave something after you, write a book. This information on SERVERS will be lost in time.
Wrong. http://web.archive.org/web/*/http://lavausergroup.org
-
Jim,
This is off-topic, but something that got me curious. Can you share with us how you get your BD annotations? I can't find any built-in LV decorations that can be modified to reproduce the thick-lined ovals and rounded boxes, arrows, etc that I see. Some of your stuff looks enough like the Pro differencing toolkit that I'm wondering if you've got some tricks up your sleeve. Or maybe you're just retouching your screenshots with MS-Paint...
Left wondering,
Dave
David, I use SnagIt.
-
Can you not use the Variant to Flattened String? This should give the current LV8 type descriptor data?
Look deeper.
-
Hmmm... they are only functional or intelligent if you put some functionality inside of the case structure -- for example, by having operations besides Read Data and Write Data, such as Initialize, Do Task A, Do Task B, etc.. If there is no intelligent functionality in them, does that make them dysfunctional globals or unintelligent globals? I am, of course, being a little silly -- discussing LabVIEW should always be fun
I think that I am leaning towards functional globals. This term just implies that they have some functionality -- I wouldn't want to put too much pressure on beginners by making them think they have to write code that is intelligent
Thank you both, Philippe and Franz, for the ideas. I owe you each a frosty one :beer:
-
LabVIEW 2 Globals is a term used to describe the usage of uninitialized shift registers to store data in an application. This name comes from the fact that LabVIEW 2 did not have global variables and clever developers figured out that they could use uninitialized shift registers to store data, and make it globally accessible throughout the application.
If you had to introduce this concent to a new developer, what would you call LV2G's? Obviously there is some historical significance to the name, but it doesn't do much to describe the concept. How about "Uninitialized Shift-Register Globals" or "Uninitialized Shift-Register Data Store"? Any thoughts?
Cheers,
-
Thanks, Oskar.
When I go to that OpenG link, it seems I should download something(openg_commander-2.0-alpha3.zip).
What is in that zip file and how to use it?
Maybe this is a stupid question. I am a newbie and have never heard of OpenG before.
Kang
That's OpenG Commander. Read the Quick Start Guide for instructions on how to install and get the OpenG goodies into your system.
-
I've been reading about OpenG this and OpenG that but I don't know where to start. There is very limited documentation explaining why anybody would want whatever it is OpenG offers . Maybe I suck at researching but I'm pretty sure I'm not.
Breifly, what is the advantage of OpenG other than it being "free"? Do I need to install Commander before I can use/install the OpenG Toolkit/Builder? Is there a chance that installing this software will break my current LabView program causing a reinstall? Will I need to package new run-time lib for sending out to beta testers that have only installed the main run-time? Currently I enjoy sending out updates of just a compiled exe to replace the old... I'm sorry for all of the questions but the OpenG websites I've visited haven't given me my answers. Would be nice to see some screenshots
. Last question, if you don't mind; Is the OpenG builder a replacement for the LabView application builder or is it just a builder for wrapping vi's to send as toolkits? 
The more I know, the more help I can be in the future. I plan to stick with LabView for life... eventually helping out with this OpenG stuff
To start, visit the OpenG Commander page and see the usefull links to get to the Download, Quick Start Guide and Manual.
OpenG Builder is also pretty well documented. It is a replacement for the LabVIEW Application Builder, but it does a whole lot more. You should note that you still need the LabVIEW Application Builder if you wish to build EXE's (OpenG Builder uses the LabVIEW Application Builder for this feature).
OpenG tools are very well written, and can be trusted about as much (hopefully more) than stuff coming out of NI -- we even have packages that patch bugs in vi.lib (VIs developed by NI that ship with LabVIEW). And, if you have any problems we are more than happy to help get you rolling -- we have a support forum here.
-
"that's almost as good as two 1600x1200's side-by side" - are you saying that from personl experience
G'day, Chris! Actually, my set up is a 1600x1200 and a 1900x1200 -- only 60 pixels (wide) shy of 2560
-
Now, that's big! Dell's new 30" Widescreen does 2560x1600 -- that's almost as good as two 1600x1200's side-by side.
-
You should check out the Variant Configuration File I/O VIs from OpenG. These can read and write anything to an INI file (clusters, arrays, etc.). Download OpenG Commander and make sure that the variantconfig package is installed.
-
LabVIEW does not support this directly. You will probably need to call external code to achieve this.
-
It looks like it might be a bug in the Read LabVIEW Measurement File Express VI. Can you attach and example of the file, and the VI that you use to read it?
-
There is a trick. In the menu activation event frame, you can obtain the tag of the item that the user right-clicked on. Use the Tree's Point To Row Column menthod:
Converts a pixel coordinate to a tag-column pair in the coordinates of the control. This method also returns whether the point is inside the bounds of the content rectangle and whether the point is within the custom symbol of the cell.
When integrated into your code, it looks like this:
Here is your example, with my edits:
-
Here is a quick update: there is a good discussion going on the cross posting I made to the NI forums. I got some very useful information from Jeff and Darren, two NI developers, including some information on some vi.lib/tree/ VIs in 7.x that provide very useful functionality, including that provided by the "Point to Row Column" tree method of 8.x.
-
I got a response from the developer at NI, who worked on the new drag and drop feature. This addresses all of my questions. Also, it was great to learn of the new Point to Row Column method of the Tree Control -- this is also present in Listboxes and Multi-column Listboxes, too! That's a feature that's been needed for quite some time.
First of all, as the developer of drag and drop in LabVIEW 8.0, thank you for using my feature. Implementing this was a big challenge, especially since drag and drop was so limited in 7.1. Using drag and drop events is harder than it used to be. I apolgize for that. However, I think that you will see that the change was justified, and that we have ways to do virtually everything you could do in 7.1.First, let me explain why we changed the drag and drop events.
In 7.1, drag and drop was very limited, and we only had events for drag and drop in a tree control. This meant that we could expose more information in the event structure. For example, 'source tag' and 'destination tag' both make sense if your drag source and target are both tree controls (or, technically, the same tree control).
In 8.0, drag and drop is much more general: you can drag from one tree to another; you can drag from any control to any other control; you can drag from one VI to another; a drag target can accept or decline all kinds of data; and you can register for events for all of these behaviors.
This reduced what we could expose in the event structure. Suddenly in 8.0, 'source tag' and 'destination tag' *don't* make sense, because your drag source and drag target could be *anything*.
I understand that this makes your use case harder -- but it makes many, many more uses possible.
Now, let's talk about your use case: filtering tree drag and drop like you did in 7.1.
In the tree's popup menu, there's an option called "Allow Drag/Drop Outside Control". Turn this off, and the tree won't be able to drag tree items to other controls, or accept drags from other controls (in other words, it'll behave like it did in 7.1).
To get the destination tag, use the "Point to Row Column" method on the tree control. Just pass it the point that you get from the drag/drop event. [1]
To get the source tag, use the LV_TREE_TAG data from the "Get Drag Drop Data" primitive. This is the source tag. (Alternately, you could cache the source tag in the "Drag Starting" event.)
Finally let's address your last comment:
Another issue is that the source item disappears from the tree control after the drop event is processed. This is not the end of the world (I can recreate the deleted node and child nodes), but it is still a bit of a pain and I believe that this is a bug.
I uploaded a test VI with a tree and a couple of the new drag/drop events: << link >>
If you run it and drop item 'c' on item 'a', item 'c' does indeed go bye-bye.
Why?
First, let's examine the built-in LV behavior for tree drag.
When you drop 'c' onto 'a' at edit time, LV does its normal built-in behavior for the tree's drag and drop.
That built-in behavior actually involves two steps:
Step 1: We update the drag source by deleting 'c'.
Step 2: We update the drag target by adding 'c' under 'a'.
And yes, 'source' and 'target' are the same thing: the tree control.
Certain drag/drop user events override built-in LabVIEW drag/drop behaviors.
More specifically:
* If you register for "Drag Source Update" on a drag source, LV will no longer do its built-in behavior for updating the drag source. Instead, LV leaves that entirely up to you.
* If you register for "Drop" on a drag target, LV will no longer do its built-in behavior for updating the target. Instead, LV leaves that entirely up to you.
This sample VI has registered for "Drop", and so at run time step 2 doesn't happen. If you register for the "Drop" event, you have to implement that Drop behavior yourself, in G.
I hope this clarifies things a little bit, and I hope that you will continue working with drag and drop. I know that it's not the easiest feature in the world to use, so any suggestions are appreciated.
[1] A quick note about what you said:
I have found a work-around by writing a routine that calculates which element the mouse is hovering over, but this is very non-direct and a bit of a kludge.
I don't think this is a kludge at all. In fact this is exactly what LabVIEW was doing internally before to determine if you were in droppable spot.
The book
in LAVA Lounge
Posted
By posting the phone number of the employer on a LabVIEW developer's forum, your odd's of getting the job might have just devolved.