dthomson

Chris, Thanks for the ideas. Sounds like you've got an interesting system working. From what I gather, you zip the distribution to save space, then unzip it dynamically to use it? Even zipped, the Report Generation Toolkit seems bigger than I would like to distribute. Maybe someone has a third party LV tool for making PDFs? DaveT

I was wondering if anyone had come across any alternatives for creating html reports that don't use the NI Report Generation Toolkit. We're starting to play with the Report toolkit, but my previous experience is that when you create a distribution, it bundles in a huge amount of LVOOP libraries, directories, etc. We're making a built executable with plug-in modules. The report will be generated by a plug-in, and so we need to deploy all the necessary sub-vis as a source distribution. I'm reluctant to have it blow up into 10s or 100s of MB's just for a fairly simple piece of functionality. I wouldn't be surprised if people had made their own html report generation code, but so far I haven't been able to find any. Thanks, DaveT

QUOTE (crelf @ Apr 11 2008, 08:06 AM) I second that. (Or third, or whatever.) I've noticed this issue, and although I don't need it often enough to have as strong of a desire to have it automated, I would certainly appreciate having a feature built-in to the Project Manager that would allow these versions to be synchronized. DaveT

At the risk of continuing the highjacking of the thread (though in truth, the thread was already pretty far from LabVIEW and actually on a fairly related subject...) I think perhaps you overestimate both my class and my aresenal, Ben! Though perhaps not my interest or conviction. In truth, I'm not much of a debater. But I do think the issue is important, and if you were to choose to discuss it (publicly here, or in a less public format), I would hope that we might both end up learning something. As for your last point, I couldn't agree more. I have a personal opinion on the issue and a professional opinion, and I'm glad to share either one with anyone who is interested, under appropriate circumstances. Our recently-retired lab directory had a very strong philosophy in this regard and it rubbed off on a lot of us: professionally, our job is to acquire data and distill the best possible scientific understanding from it, then present that to the policy makers and the public in the most accurate and understandable way possible. I'm in the process now of transitioning to the private sector, but I'm proud of having spent almost two decades working for a government lab that is guided by that principle. Cheers, DaveT QUOTE (neB @ Apr 10 2008, 07:18 AM)

QUOTE (crelf @ Mar 31 2008, 07:51 AM) I'd be curious, Ben, to know what phenomenon you believe doesn't exist - changing climate, the anthropogenic origin of changing climate, or something else? DaveT

QUOTE (tcplomp @ Apr 1 2008, 01:18 AM) Ton, Thanks for pointing that out. You are quite right - 8.5 handles the issue directly whereas 8.2 does not. I'll work on getting the customer to upgrade. Dave

I'm trying to make some new applications Vista compatible. I'm no expert on Vista, but one thing I'm doing is putting configuration and data files in different places than I used to. Apparently you can't write to files in C:\Program Files\My App, so I'm using C:\Documents and Settings\All Users\Application Data\My App\Program (or its Vista equivalent) for config files and C:\Documents and Settings\All Users\Application Data\My App\Data for data files. So for one program, I want to have an additional config-type file in the new config folder, but with the Installation script (LV 8.2.1), I can't find a way to do that. When you build an executable, you have a lot of flexibility for determining the destination for each item, but with the Installer, you can only add destination folders that are sub-folders of the paths that are already known to the installer script. At least from what I can tell. Does anyone know of a work-around so that I could include additional support files in the installer and have them go to a particular location? The best I can think of is to have the program copy the files to the desired location the first time it is run, probably from its own installation location, which the installer can access. Thanks for any ideas, DaveT

QUOTE(crelf @ Feb 24 2008, 04:57 PM) Thanks for the update. I appreciate the info! DaveT

QUOTE(Jim Kring @ Jan 27 2007, 02:11 PM) CRelf, I am considering implementing something along these lines, and was about to post a question when I came across your thread from a year ago. Very informative discussion. Thanks to all the LAVA readers who posted. I was wondering, though, if you could update us on any progress or experience you've had since this thread was started. Thanks, Dave

QUOTE(guruthilak@yahoo.com @ Feb 18 2008, 11:54 PM) Guru, Interesting idea. However, I assumed that was what LabVIEW was doing for me. I've built whole systems on the basis of this (for sub-vi's, not for dynamicly-called VI). I use a single VI to access a resource/driver/object, and can call that VI from multiple top-level LV VI's confident that LabVIEW's scheduler will prevent simultaneous calls to the non-reentrant VI. So I guess the question is, is there any reason (other than the error I've seen) to believe that dynamically called VIs should be any different?Yen, Thanks for the idea. I wrote some test code to demonstrate this. One vi that spins its wheels with arithmetic for n seconds, with an optional second loop that reads a really big file. Two callers that each call that VI dynamically. Regardless of whether the file reading option is on, both callers operate as expected, with one minor exception: Without file reading, the second VI obviously waits for the first to finish before it starts. E.g. if they are both set to 3 seconds and both started at almost the same time, the 1st finishes in 3 seconds and the 2nd in 6 seconds. However, with file reading on, both VI's run without error and read the correct data, but their run arrows both turn blank at the same time! They don't "appear" to be sequential. So although I'm not getting the same error, maybe it is doing the same thing at some level...DaveTQUOTE(Aristos Queue @ Feb 19 2008, 12:13 PM) The whole point of a functional global is you don't need a semaphore. Only one VI can call any given subVI at a time -- if you want more than one to be able to call simultaneously, make the VI reentrant, which is, in effect, creating separate VIs for every caller. But for a non-reentrant subVI, only one caller can call at a time, so you don't need semaphores.To dthomson: Sorry, I don't have anything to say to help with your issue. I've never seen a problem with this and I'd have to see some code to make any guesses about what is wrong. Aristos, Didn't see your post until just after I replied. Given my observations with the test program, do you think that is enough to submit to NI for further investigation? Actually, I just ran it again a few times. There are subtle hints that they are running sequentially, and that it is only a front-panel update issue that turns the run arrows off at the same time. The window titles get updated about half-way through, suggesting that they run sequentially, but the windows don't get fully graphically updated until both are done since the cpu is maxed out. So I'm beginning to conclude that my demo is a bust. It should have the same basic features as the full program, but I haven't been able to duplicate the problem yet...Dave

I've got a system in which there are numerous top-level VI's running in parallel. One of them will obtain a reference to a functional global and then share that reference with other top-level VIs. Each of these VI's can then call the functional global and have it execute various commands on its data. Most of these calls are brief, but one (load a file) can take several seconds, depending on the file size. Normally, everything works fine, but if the functional global is reading a long file and another VI tries to access it, the 2nd call gets an error 1026, reference not valid. A Call by Reference is similar to a sub-vi call. I would expect that the LV scheduling system would queue up requests to the functional global like it would for any other sub-vi call. I think this works in general, when calls are of short duration. I've never noticed other 1026 errors, whereas there should have been some coincidental calls by now in al the times that the program has been running. But, if I ask the functional global to read a really large file, which takes seconds, then a simultaneous call from another VI gives 1026. I've verified this by adding a simple delay of several seconds, letting the file read finish before making the same call from the 2nd VI. That works fine, so it really seems that 1026 is returned when the VI is busy, but only when it is busy for a longgg time. I haven't been able to find documentation on this feature. It makes a certain amount of sense, but surprises me since it apparently isn't documented. Does anyone else know about this "feature"? Thanks, DaveT

QUOTE(Gabi1 @ Dec 11 2007, 04:33 PM) I think I've pointed it out before, but just for reference (in case someone decides to try it), there was something like this at least once before. See www.vibots.com It had limited success, but the fellow behind it did a pretty good job setting it up. One downside was that the competitions weren't "live". You submitted your bot program, then he ran them all and posted the results. He also posted playback files, so you could view how the match went. But it would be cool to have a web interface where you could post a bot VI and have it fight other bots that had already been posted to the site. Dave

QUOTE(Jeffrey Habets @ Nov 8 2007, 04:55 AM) I think it's a great idea. I used to put it in the suggestion box about every version, but lately it slipped off my radar. I would also suggest built-in lables for Sequence-Locals. (Not that I would ever use a Sequence Local!) It seems obvious to me. NI pushes for programming standards, including good documentation, but this obvious feature remains missing. Cheers, Dave T.

There have been a few threads about using VMWare to test LV programs on different OS's and to keep different versions of LV separated. I used it briefly to try and test LV 8.5 beta. It worked, more or less, but the performance was less than ideal and I eventually gave up on it. I was wondering if anyone had tried usingn MS Virtual PC 2007? From what I've read, Virtual PC 2004 was slower than VMWare, since it didn't have some of the tools VMWare did for optimizing graphics and hardware access. Hopefully it has caught up by now. Any opinions/experience with this? Thanks, Dave T.

Thanks for all the suggestions. I also found a website that gave a really easy explanation: http://www.maths.surrey.ac.uk/explore/emma...es/Vector7.html Based on that, I created a VI to do this. It is posted on my website if anyone else should need it: www.originalcode.com, under Programs, then Scientific Programs. Cheers, Dave