Jim Kring

QUOTE(Gary Rubin @ May 2 2007, 05:45 PM) Probably want to avoid the heartache that will occur when they turn out to look nothing like thier avatar

I did a bit of work on a design pattern, a while back, called "Asynchronous Call By Reference". This allows you to have a handle to your asynchronously running VI, query status, get return data, and even abort it.

QUOTE(tcplomp @ May 1 2007, 09:54 PM) What I think Ton means is that, if you cross post, please state that you have cross-posted your question and put a link to the other (cross) post so that people here will know if your question has been sufficiently answered in another forum. Thanks, -Jim

QUOTE(Michael_Aivaliotis @ May 1 2007, 07:28 PM) How about this? When a homework hustler posts a message that does not conform to the forum rules and expectations, a moderator will do the following: move it into a special "Homework Hustler" forum (maybe, not syndicated via LAVA's RSS feed) reply to the topic with a standard, canned response (which includes a "Homework Hustler" emoticon, of course) explaining why the posting was rejected and how to "try again" lock the topic so that neither the homework hustler or the homework hustler hecklers have a chance to butt heads. Moving the posting into a special "homework hustler" forum will create a nice archive that will amuse the homework hustler hecklers and create good examples of how not to post questions to LAVA.

QUOTE(crelf @ May 1 2007, 02:21 PM) Isn't addiction a form of mental illness? Are you addicted to LAVA? (I know I am.)

QUOTE(Aristos Queue @ Apr 29 2007, 06:03 PM) I got about 75% of the way through the paper, last night. Yes, it is a very enjoyable read. I never took Greek philosophy (although I regularly have philisophical discussions with a real live Greek person), so this was all pretty new information. It's interesting to see concepts that we're all so comfortable with (like categorization and reason) dissected into first principles. It's also interesting to learn more about the origin of words (and thier original meanings) to understand better how they are used (and abused) today.

QUOTE(NadavC @ May 1 2007, 08:37 AM) Nadav: If you can't trap the error programmatically and it Aborts execution of your VI, then you cannot exit LabVIEW programatically.

QUOTE(Aristos Queue @ Apr 30 2007, 03:12 PM) A quick googling of the article title produced a link to this page, which in turn produced a link to a downloadable copy of the article (PDF file).

QUOTE(Michael_Aivaliotis @ Apr 30 2007, 11:51 AM) It does seem to be jumping up and down and enjoying itself QUOTE(Michael_Aivaliotis @ Apr 29 2007, 11:40 PM) Hey, I put a warning up... and I put it in the LAVA Lounge. Besides, I'm just trying to raise awareness. Tryin' to help the ladies out there... I'm not saying that you crossed the line. You're just dancing on it... like a jack rabbit.

Your tireless work, this weekend, on the LAVA Forum Guidelines followed by this posting is incredibly ironic.

QUOTE(chrisdavis @ Apr 29 2007, 07:43 PM) Hi Chris (and others), I was thinking of borrowing some design inspiration from OpenG Builder and how it handles Support Files (see screenshot, below). It uses a very flexible scheme that allows wildcards, recursion, and exclusions (enabling the recursive exclusion of .svn and CVS folders, for example). http://forums.lavag.org/index.php?act=attach&type=post&id=5670''>http://forums.lavag.org/index.php?act=attach&type=post&id=5670'>http://forums.lavag.org/index.php?act=attach&type=post&id=5670 -Jim

I think that this thread should be titled "The proper treatment of abusive members". Let's focus on what's appropriate behavior on both sides of this and move on.

QUOTE(chrisdavis @ Apr 28 2007, 07:01 PM) In my response to Tomi, I posted a work-around that will allow recursively adding directories. I would like to add native support for this -- I need it, too

I think that there is some missunderstanding. lvlib (and lvclass, xnode, xcontrol, etc.) support are being added to OpenG Builder, not OpenG Package Builder. Much of what Ton is describing relates to OpenG Builder.

Hey, Chris, I should have mentioned this, but I did some work on this design pattern a while back and posted an example to the OpenG forums. I call it the Asynchronous Call By Reference. Cheers,

QUOTE(AndersBjork @ Apr 25 2007, 02:43 PM) Contact NI, directly, and let them know how you feel.

QUOTE(ForgivablE @ Apr 26 2007, 01:43 AM) Yes, there are a lot of examples in the "examples" folder beneath LabVIEW's installation location. You can also use the NI Example Finder, from the LabVIEW Help menu.

QUOTE(Tomi Maila @ Apr 26 2007, 02:28 AM) </example> This would allow much better integration with present source code control tools. Even XML merge would in principle work for the source files, although I'm not sure how usable it would really be. We might take a clue from http://www.python.org' target="_blank">Python. Source files are generally named with a *.py extension. When python executes a *.py file, it compiles it into bytecode that is stored in a *.pyc located in the *same* directory as the *.py file. It is a simple matter to tell ones source code control system to ignore *.pyc files.

QUOTE(ForgivablE @ Apr 25 2007, 07:52 PM) I suggest a battery or power supply for the voltage (don't forget that you'll need some current, too, if you want any power). Connect the fan to the DAQ card with wires, and put a relay/switch in to turn it on and off. Note: the thermocouple will create voltage and current, but not enough to drive your fan.

QUOTE(ragglefrock @ Apr 25 2007, 09:34 PM) Thanks for mentioning the Wait Until Done flag. I just (incorrectly) assumed that it was obvious that I meant to set this flag to FALSE (that's how the called VI gets into a "running top-level" state). Regardless, you can still detect whether the called VI is running and read return data, even if you set Wait Until Done to FALSE -- simply monitor the VI's execution state and when it becomes idle read the indicator values on the front panel.

Aborting Dynamically_Called_SubVI.vi would abort the entire call, and therefore TopLevel_RunMe.vi. If you want to abort this called VI, then you need to do it, one of two ways... 1) Use a shared messaging mechanism to ask the subVI to stop doing whatever it's doing. This can be a User Event, Queue message, Notifier, etc. 2) Use the VI Run method to invoke the subVI -- this will allow you to use the VI Abort method, since the "subVI" will be running top-level.

Hi Tomi, > [GENERAL] > I decided to go with the combination of OpenG Package Builder and VI Package Manager as dependency control is a must have when there are multiple related libraries with inter-library dependencies. LabVIEW application builder don't allow me to specify package dependencies which will eventually lead to problems to library users and that would mean support requests to me that is not an option. That's great to hear. We (JKI) are going to work hard to make this a powerful solution for you, as a tool developer. > The issue that is open to me now is that if this is really wise way of doing the build process? The downside of this process is that if I want to modify something in all of the classes A, B, and C, then I cannot do that in a single project but I need to first modify A, then install modified A, then modify B, then install modified B and so on. This may be complicated when the project contains multiple dependent classes. Any recommendations and experience on this issue? This is a tough question to answer. There are costs and benefits on both sides. It really depends on how much value you will get by decoupling the development+release cycles of the classes, and there are two main factors to consider: what the dependency tree/matrix looks like how often you will be releasing each component Personally, I prefer to develop each component seperately and rely on the dependency management capabilities of VIPM. > [BUILDING PACKAGES WITH OPENG PACKAGE BUILDER] > In General tab there is a version and a release number. Is version number and the release number combined to a form major.minor.release or are version and release number complitely independent of one another. Release number applies to the package, independent of what is being packaged. For example, if we change the LabVIEW version compatibility declared by the package without actually changing (rebuilding) the library (that is being packaged/installed), we will increment the release number. The version and release number are used in the package name, as follows: name-version-release.ogp For example, let's look at the following package: In this case: name = oglib_array version = 1.0 release = 2 > In the Package Files tab, if I create a new file group and use file mask *.* for source files, are folders in the source directory included recursively into the build or do I need to manually select each sub folder in the source hierarchy Subfolders are not added recursively. This is an annoying limitation, and one which I would love to remedy, ASAP. As a work-around, here is a VI that I use to create a File Group list of files from a directory, recursively: http://forums.lavag.org/index.php?act=attach&type=post&id=5638 Note: This VI ignores CVS and .svn folders and also ignores files that begin with a period (".") > In the Package Files tab, if I chage Group Source Directory a message pops up "Abosulte value of dependent paths may be either kept as is or revised according to new base directory". What does this actually mean? There are many paths that can be specified relative to other paths. The paths of files in a File Group are specified relative to the File Group's Source directory. If you change the Source directory, you have two options: Abosulte value of dependent paths may be either kept as is - do not change the absolute path of the files and recalculate the relative path to the new Source directory (Abosulte value) revised according to new base directory - change the absolute path of the files, leaving the relative path to the Source directory unchanged > In the Package Files tab, there are a few replace modes. If I select "Is Newer" what actually is meant by newer in this context? "Is Newer" means "Replace the file if the one in the package is newer (by timestamp) than the one on disk". >In the Platform tab, I'd need to require LV 8.20 or newer but this option is not yet supported. Perhaps somebody can make the modification... Thanks for reporting this -- I'll make the change. Actually you can just type in "8.2" -- this text input is a string control with a menu ring, for convenience. >In the Platform tab, What are allowerd values for the OS string? This is tested against the LabVIEW Application property "Operating System: Name". Valid values are: Windows 95 Windows NT Mac OS Linux >What is meant with "OS is greater than <some string>"? Operating systems have a version. This tested against the LabVIEW Application property "Operating System:Version Number" Note that Windows NT = 5.1 ==> "Windows XP" Windows NT = 5.0 ==> "Windows 2000" I'm not sure, off hand, what Windows Vista will be, in terms of "Operating System: Name" and "Operating System: Version Number". >I tried to add dependencies but I couldn't get them to work. VIPM didn't complain of dependecies even though I added them here. Should or can the Revision number be included in the version number in dependency management? Yes, revision numbers can be used in dependency declarations. >In the Script VIs tab, What is the interface for the VIs that can be used here? There is no defined interface. The VIs are invoked with the VI "Run" method and are not passed any data. If the VI has an "error out" indicator, it will be read by VIPM after the VI completes execution. > [INSTALLING PACKAGES WITH VIPM] > VI Package Manager is currently at version 1.0 and is pretty polished and very easy to use. I have some VIPM related issues I'd like to ask here: Thanks. That's good to hear > I can add add local Packages to the list of packages from the Package menu. Can I remove packages from the list somehow? There is no simple way to do this, right now. It is on our radar. For now, simply go into the "cache" folder and delete your_package.ogp, your_package.bmp, and your_package.spec -- this will cause the package to disappear, the next time you check the network for packages or restart VIPM. > Can I add Packages by remote URL, not just files? No, VIPM does not have such a feature. I've made a note of it and we will consider it, for future development. > I didn't get the dependency management to work but I guess this is an issue of package builder. It should be working. Ping me, off-line, and I'll be happy to work out any details with you. Thanks for your interest. Keep the questions coming and I'll do my best to address them Lastly, there is a very old document, here, that documents the spec file format. This is not 100% accurate/current, but may have some answers to questions. Thanks, -Jim

QUOTE(Tomi Maila @ Apr 24 2007, 07:18 AM) Hi Tomi, I'm sorry to hear about your predicament and happy to hear that you've worked through it. The VIPM package "repair" feature is on our roadmap. Thanks for the feedback. -Jim

QUOTE(craftmail @ Apr 24 2007, 02:05 AM) Good luck and, please, let us know your results and how your project goes

QUOTE(craftmail @ Apr 23 2007, 02:11 PM) From the info on thier website, Weeder is a small company founded by a fellow, Terry Weeder, who has a passion for hobby electronics and a lot of industry experience. They have been around for quite some time ('89). I googled them and found links to college courses that used their parts in assigmenents/projects. Try emailing or calling thier sales department and see how thier customer service is -- that will provide some useful information. My guess is that you'll get what you pay for, and maybe even more.