dthomson

QUOTE(JohnRH @ Mar 16 2007, 11:21 AM) Arggghhh!!! Glad to see that it wasn't just me. I spent considerable time on this one with NI tech support. Never got anywhere. They wanted me to reinstall LabVIEW and Windows, and I couldn't afford the time. In my case, it locked up LV completely after selecting a custom icon, but not until I closed the build dialog. So I could build the project with the custom icon, but I could never save the project with the custom icon! I never did find the work-around of hitting OK instead of double-clicking the icon in the file dialog. I guess I'm a slave to habit... Dave T.

QUOTE(Ben @ Mar 15 2007, 11:14 AM) A lot of good suggestions from all the above posts. I second the idea that any indication of pain should not be taken lightly, but rather acted on immediately to prevent potentially great discomfort. I ended up with chronic back/neck pain for the last 10 years. 90% sure it's from computer work (e.g. mostly LabVIEW). Tried almost everything but never found a silver bullet. Ergonomics is defnitely a good starting point, though. (Actually, I may be on the road to recovery at the moment. Just found a new PT who really seems to know about neck pain. It seems to be helping...) I got the Kensington trackball mentioned above a couple weeks ago. Not quite an expert with it, but I like it so far. I've used Kensington Orbit trackballs for years. I have no problem getting trackballs to work for LabVIEW programming, but I know a lot of people who sit down at my computers are unable to use them very successfully. In any case, the new Kensington has a lot more functionality than the Orbit - four buttons plus a scroll wheel. (I haven't quite mastered the scroll wheel yet...) But I got tired of the Orbit not having a 3rd button or scroll wheel. The new one cost more, though. I also tried a fancy touch pad, regular mice, and even a foot mouse. Never got them to work well for me. I could do regular computer work, but wiring in LV was difficult. I also connected another Orbit trackball up to my computer (USB) and rewired it internally to switch left and right buttons, so I have another mouse available for switching off hands. I know another fellow who swears by this, but I don't tend to use it much. Cheers, Dave T.

QUOTE(crelf @ Mar 9 2007, 12:24 PM) crelf, I could have sworn that was me on the left, except for the tie... Dave

QUOTE(Mike Ashe @ Mar 9 2007, 07:03 AM) I hadn't heard that coffee was the second largest export after oil. Not too surprising, though, as I had read the related factoid that the coffee industry supports fully 1% of the world's population. I imagine the megabucks of oil are handled by a much smaller workforce. I wonder if there is any other single industry that compares in that regard... For anyone who is interested in the plight of the Ethiopian coffee farmers (and of those in many other coffee-producing regions), you can look for Fair Trade beans that make an attempt to address this situation. Cheers, Dave (coffee-aholic, but managing to keep it to 1 good-size cup a day!)

Lot's of great suggestions in this thread! Thanks! I've used SyncBack, and agree that it seems to do the job. (More recently, I've changed over to using a Mirra server. DEFINITELY not free, but it has some great features...) I don't know if anyone mentioned NoteTab yet. It's a nice replacement for Notepad. My favorite freeware is Firefox and Thunderbird! I find IrfanView useful for simple image manipulation and viewing. I've found TightVNC very useful for remote computer control. UltraVNC looks like a great suggestion, though, since it has a 3rd-party add-on for NAT-to-NAT connections. Has anyone tried that part of it? I've had fun with the free version of Google Sketchup. Pretty quick to learn, and I've even made some useful drawing with it. Skype! They're back to charging for computer-to-phone connections, but computer-to-computer and chat is free. Saves me a bundle calling home when I'm out of the country. I use the free version of Avast antivirus. I've heard that it doesn't catch as much as some (though you can also read reviews that say the opposite), but it also doesn't get in my way like McAfee did. So far nothing has gotten through... Any other experience with Avast?

QUOTE(Dave Graybeal @ Feb 26 2007, 11:20 AM) My understanding is that the three computers can all be at work, as long as you are only using one at a time. The installation at home is separate and existed before the change to the 3-computer installation. Dave T.

Richard, For years, it has been NI's policy that it was acceptable (even "legal", as I understand it), to install LV at home. I believe this is still true after the licensing changes that came out with 8.x. I think the intent was to allow people to learn LV by using it at home, but that it wouldn't be appropriate to use it for monentary gain. I'm not an NI employee, so my comments certainly shouldn't be considered official. In any case, I agree with the previous response that the best thing to do is check with your local rep. Regards, Dave T. QUOTE(BrokenArrow @ Feb 26 2007, 09:11 AM)

QUOTE(Jeff Plotzke @ Feb 18 2007, 04:59 PM) I had a very similar issue, but on a LV 7.1 W2K machine. Daq calls didn't work reliably if the machine started a LV program automatically at bootup. I found a Dos Sleep command, put it in a batch file to sleep 10 seconds on bootup, and then had the batch file launch the LV program in order to get it to work properly. Never tracked it down fully, and I've never seen the same problem on other W2K machines, even running LV 7.1 programs at bootup. The other similarity is that this program did query the MAX database for devices and channel names, from which it set up its daq tasks internally. My guess was that whatever Max processes run in the background at bootup just hadn't finished up yet. Perhaps some of this code is common to RT and Windows systems. (Or at least the symptoms are common!) Regards, Dave T

I have found two versions of this on the NI Forums, one that uses dll calls to the Windows API and one that uses .NET calls. The second can be found at http://digital.ni.com/public.nsf/allkb/935...625711E0055F1FA I prefered the first, since I didn't want to depend on my customers having the proper .NET framework installed. Unfortunately, I can't find a link to it at the moment. I have my own slightly customized version, that I could probably package up for you if you want, though. Regards, Dave T

AQ, Thanks for the example. This just happened to come in useful, as I was working on a custom graph XControl. I simplified your mechanism so that mine is always an Indicator. (This is due to my incredible powers of foresight, allowing me to see all potential use cases and be sure that no one will ever need to use my graph as a control.) (OK, so it's really just due to laziness.) In any case, I thought I'd mention a couple of minor point. I'm just a beginner with XControls, so it may not be surprising that it took me a while to figure out what you had done. One thing that threw me, though, was that you mentioned that your Indicator trick was in the Init.vi. I took this to mean in the XCTL Init VI, e.g. LED-Init.vi. But it was actually in a subvi used in the Direction Change case of the Facade, which runs when the XCTL is initialized (dropped). So perhaps this was all for the best, as it forced me to work for the answer. But you might consider updating the description a bit. The other thing is the observation (perhaps obvious?) that the Direction Change case of the Facade fires when the XCTL is dropped, even if there is no inherent Direction Change. Perhaps this case might better have been named something like "Set Direction". Anyway, thanks for the example. Nicely done! Regards, Dave

I hadn't been using the app builder much lately, so I only recently cam across this same situation. A small app that would only have been 10M or so in LV 7.x gets a 68MB installer in LV 8.2. I back-converted it to 8.0 and got the same result. Also, at least in 8.2, I wasn't able to find any "25MB" small RTE option that Bart mentioned. Any other comments on this? Any way to reduce the installer size? Any explanation why the 8.x installer is so much bigger than 7.x? Regards, Dave

George, As a (hopefully) relevant benchmark, I can tell you about a program I wrote some years ago that uses the approach you suggest at the end of your message. It uses a 4 channel 6110 (which has 4 independent DAC's that share timing/triggering). I run all four channels at 5MS/s and grab 200ms buffers of data. I then scan the first two channels for "events" and whenever either channel finds an event, I save a window of data from all four channels around that event. The program can keep up with this data load, including writing the events to disk, up until you get to about 5000 events/second. At that point the duty cycle drops. The program is architected in such a way as to continue running at reduced duty cycle, and writes the duty cycle to another data file for later analysis. You don't mention your data clock rate, but hopefully that example will give you an idea of what is possible. You could bump it up even more with a faster computer, faster hard disk, and improvements to the memory management scheme. Since you already have DAQ boards, which might mean they are a bit older, and they don't have multiple DAC's, I'm guessing that they are E series, maybe M, but probably limited to 100's of KS/s. If this is the case, it should be possible to write an app that does continuous acquisition on 4 channels and scans the data in memory for triggers. You can get more info from a paper on my website: Go to www.originalcode.com, under Publications, and look for "SP2". Or let me know if I can be of more help. Regards, Dave

I was wondering if anyone had tried using TDM or TDMS files for reading and writing configuration information. My current solution is a variation on the NI Config File VI's. This provides a human-readable (and editable) file that can easily support newly-defined values as a project evolves. It has difficultities with arrays, and structures (clusters) must be parsed out rather tediously. I haven't played with TDMS files much, but it seems like this API would provide an easy way to create flexible files. It would lose the human-readable aspect (which could be an advantage), but would maintain the flexibility of allowing new variables (properties) as the project changes. Arrays would be easier too, since it directly supports them as channels. (Well, at least flat arrays of numbers.) Clusters would still have to be parsed apart. One potential problem is that I don't see a TDMS VI for listing what properties are in a file. I think you can list channels and groups, but I don't see how to get a list of properties programmatically. That probably wouldn't be a huge issue for configuration files, but it would be a nice option. (Maybe it is there but I just haven't found it yet.) I am aware of the OpenG Variant solution, and would be interested in opinions on how it compares as well. Or other solutions you might be using. Regards, Dave T.

I've got a small program running on a cRIO unit. I've just upgraded from 7.1 to 8.20, so I'm not quite clear on how the new project paradigm should be used. The problem is that there is a PC-hosted interface to the FPGA program. If I open the project that was used to build both the FPGA program and the host program, then open and run the host program, everything is fine. If I open the host program by itself, without opening the project, I get errors (something like "FPGA reference opened outside of the project".) This makes sense, since the project is (I believe) where the FPGA hardware description is stored. However, it is less than ideal for the end-user. When a non-LV end-user wants to run the system, it was possible on LV 7.1 for them to just open the host program and run it. Now they need to open the project, navigate to the host program, then open that and run it. Doesn't sound like a big deal, but the extra steps are an annoyance, and the reasons for it aren't obvious to the end-user. The only work-around I've found so far is to build the host program into an .exe. That seems to do the trick. Now they can double-click on the .exe and it runs fine, outside of LV. Then they run another LV program on the PC and things are working. I don't really like this option, though, since at some point I might want the 2nd LV program to communicate with the Host program so as to interact directly with the FPGA program. Having the Host program in an .exe makes this more difficult. Is there any other way to use the Build Specs or some other trick to create a version of the Host program that can be run inside LV without having to open the project first? Thanks, Dave

As long as we're going down that road... How about associative labels for shift registers and sequence locals. (What are sequence locals you ask? You mean you never use those???) Dave

CB, I brought this up with NI during the 8.20 beta. If I recall correctly, this is on their radar for possible improvement in a future version. (Though I love Shared Variables, I think there is ample room for improving them in a number of regards...) Dave

I think all of Mike's ideas are worth pursuing, but actaully, I was thinking of multi-line string indicators. Your questions are good ones, Ton. I guess my initial assumption was along these lines: Find the number of lines in the indicator. (If necessary, find the height and divide by the height of the font.) Find the max number of characters that fit in that many lines, using the rules already defined in the original VI. Let the result wrap however it wants. So, basically, your option 1. Partly because it is simpler. The logic for Option 2 gets messier. But in some sense, your Option 2 is also harder to read. Regards, Dave

Ton, Yeah, I should have tried your XControl first. I did download it now and tried it. Nice job! One other limitation I should note: My VI only works well for single-line string indicators. It shouldn't be too hard to modify it for multi-line indicators. Anyone care to give it a whirl? Regards, Dave

Thanks for the additional ideas. I agree that the error in and out should have been included. As for other data types: My newest example shows how to wire it up for an array of strings (as well as just a string), mostly because that is a particular case that I am planning on using. A listbox would be nice, but I haven't gotten to that. As for a path indicator - my first reaction is that that would be a rather strange use case, since the path being written into the indicator is no longer a valid path. However, as soon as anyone says "no one will ever possibly want to do that", someone will point out a valid use case... But the path indicator combined with the XControl idea brings up an interesting possibility. I'm not too familiar with XControls, so I'm not sure what all is possible. But how about an XControl version that displays the truncated path, but returns the entire original path to the data wire? Or could it even have two outputs (or two types of output that are somehow selectable), the truncated version and the entire original path? Regards, Dave

Thanks! I agree about the "\" before the file name. I added that, but I won't post another version here quite yet so as not to clutter the site with too many revisions. Another note: Although the internal code should all be platform independent, the logic assumes a Windows path syntax... Regards, Dave

Thanks for the example, Mike. I got going on it a bit and ended up writing one that optimizes the string. Rather than counting characters, it takes the string indicator width, font, size, bold, and italics into account and comes up with the best fit. (Or at least it is supposed to.) I'll attach it here, and I'll be putting it on my website before long. I'd be glad to hear of any bugs or issues. I'm sure there are some edge cases that it doesn't handle well. Regards, Dave Download File:post-1255-1159913289.zip

I was wondering if anyone had seen a LabVIEW routine for displaying long paths in a relatively short string. I did a search on the DevZone and found a CVI example, but nothing in LV. What I would like is to restructure a path string so that it fits within a fixed-size string indicator, with the beginning of the path and the end (file name) visible. Due to proportional fonts, it should probably iteratively try truncating the path by different amounts until it fits the available space optimally. Regards, Dave T

Well, an NI employee gave me the recovery procedure on the NI forum: http://forums.ni.com/ni/board/message?boar...mp=true#M207507 At least it is possible to recover, assuming you haven't done anything in 8.20 yet that recompiled any Traditional Daq VIs. But the recovery procedure seems to me to be unnecessarily arcane and perhaps undocumented. I didn't see any warning abou this when I installed. Perhaps I missed it, but this seems like a major concern to me. Regards, Dave

I've searched various forums and haven't been able to find a discussion of this yet. (I did post it on the NI forums yesterday, but I wanted to get the feedback of this group as well.) After installing 8.20, I finally went back to a 7.1 project and tried to open it. It uses Traditional Daq, and the relevant sub-vi pallette has been completely removed! Is this a known limitation? Did I do something wrong? Can it be avoided? Is there a fix? I tried running the Device Drivers CD from both the 8.20 distribution and the 7.1 distribution, but neither was able to replace the 7.1 LV VI's. The 8.20 CD says it has LabVIEW support for Traditional Daq, but it doesn't expand further to mention which versions are covered. Upon further investigation, I realize that the Traditional Daq VIs have also been removed from 8.0! Only 8.20 has Traditional Daq VIs! I consider this unacceptable and inadequate. I keep numerous versions of LabVIEW alive on my development machines. I have to to keep maintaining various projects of various ages. The current situation is going to make this very hard! Regards, Dave T.

Jim, Thanks, I haven't seen that trick before. Question though: What triggers the dialog in this case. My assumption is that you still have to use the Application menu item, not a custom item. If that is true, then the menu item will still be labeled "About LabVIEW...", not "About MyApp...". Dave