Jump to content

dthomson

Members
  • Posts

    52
  • Joined

  • Last visited

Posts posted by dthomson

  1. QUOTE(JohnRH @ Mar 16 2007, 11:21 AM)

    This is it! If I select the icon file then click OK rather than double clicking the icon file, it works without locking.

    Thanks!

    John

    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.

  2. QUOTE(Ben @ Mar 15 2007, 11:14 AM)

    First

    I urge you to concider seeing a doctor. CT can disable you. I was waking up at night with shooting pains in my forearms.

    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.

  3. QUOTE(Mike Ashe @ Mar 9 2007, 07:03 AM)

    http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=5we&q=%22history+of+coffee%22&btnG=Search' target="_blank">Coffee, the Elixir of Life. Googling on "history of coffee" (in quotes) brings up over 115,000 entries, which is appropriate since we have coffee to thank for the prominence of the most prestigious modern insurance and banking companies and is the second largest international export after oil.

    ...

    P.S. In an expression of social responsibility, uncharacteristic for an otherwise conservative capitalist such as myself, I'd like to make a shameless plug for an upcoming documentary on the plight of Ethiopian coffee farmers contrasted with the bega-bucks* of Starbucks and others.

    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!)

  4. 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?

  5. QUOTE(Dave Graybeal @ Feb 26 2007, 11:20 AM)

    From what I remember, I believe that legally you can install a single labview liscense on up to 3 machines. I believe these 3 machines are intended to be development machine, laptop and a computer at home. I also believe that the intended function of them is that they are used exclusively of each other. Now that being said, I doubt any sales rep is going to mind anything relatively close as long as its not being used to allow other developers in your business to develop from a single liscense.

    Just my 2 cents, but if it's going to be installed on a home pc to increase your labview coding skills then I don't think anyone's gonna be filing a lawsuit against ya :shifty:

    Dave

    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.

  6. 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)

    I have a "friend" who uses LV 8.2 at work. He wants to take it home and install it there as well, perhaps on two computers because this bloke never knows which one will be available to him (he has a kid).

    He has premission from his boss to take home the CD's. The NI liscense says his copy is good for three different computer installs. This number has been reached at work. Will it install at my, I mean his home? This new internet mandated install stuff with 8.2 has him worried. ;)

    Thanks,

    Richard

    p.s. liscense is very hard to spell

  7. QUOTE(Jeff Plotzke @ Feb 18 2007, 04:59 PM)

    Here's a discovery I made today:

    If you're using DAQmx Property Nodes in an RT application, they may not work correctly until about 5 seconds after the RT system has been running. In my case, I'm using a PXI RT controller and my application calls the "DevNames" DAQmx System property to return all the devices on the system when it begins. However, after a long search, I've discovered that this node gave back only 1 of my 7 cards on the system when it executed in a deployed startup application. If I put a 5 second wait before this property node, it works fine, returning all the cards.

    I don't know if this is a "bug" or just that LVRT needs to discover all the cards first, but I wanted to post this in case anyone experiences this problem.

    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

  8. Is there a slick way to display the application's revision number?

    I have yet to find one. You can access the main vi's revision number in the development environment and display it, but this number reverts to 0 once the vi becomes part of an application. There's an auto-(or manually)-incremented revision number as part of the application builder, but I can't see a way to grab it for display once the EXE is running.

    Right now I'm displaying the month-day-year (i.e. Rev. 11-08-06) at the end of title bar by reading the EXE's modified date, but I'd like to use a real revision number. I could read one from my .ini file, but that's a pain to make sure it's always correct.

    I've searched the ni forums on this with no luck.

    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

  9. Here's the link to an XControl I wrote that defaults to indicator, among other interesting properties.

    http://community.ni.com/examples/scrolling-led-xcontrol

    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

  10. 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

  11. I have 4 channels of data that I want to sample for 15 msecs. When I start sampling each of the channels depends on a corresponding independant trigger that the code will initiate. For instance, trigger 1 happens so sample channel 1 for 15 msecs. Trigger 2 happens so sample channel 1 for 15 msecs. The triggers can happen any time in relation to one another so for instance trigger 2 could happen during the sampling of channel 1. Part of the problem might be that I have existing DAQ boards I need to use that don't have parallel DAQ inputs.

    I was thinking that I have to do a continuous acquisition of all channels and then somehow pick out the data of interest based on a timestamp of when the trigger happened. Does that seem reasonable or is there a better approach?

    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

  12. 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.

  13. 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

  14. 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

    Hi folks,

    I encountered the following unexpected behaviour, when using Shared Variables with LV 8.20:

    I created a new Shared Variable (Single Process Type) with a custom control, which is typedef'ed. I thought, that, if I change the typedef, the type of the Shared Variable would change automatically, too. Instead, it sticks to the old type, which results in many broken wires.

    Is this a bug? Am I making a mistake? What's wrong?

    I'd like to file a product suggestion at ni.com, with the request, that Shared Variables, which are created with a typedef'ed custom type, auto-update from that typedef. But before I bother them, I'd like to be sure, that there's a "bug" ...

  15. I think by "multi line" we would mean listboxes or tree controls fed by an array of paths, not a multi line string control. The tree control is an especially difficult problem since you might have to retruncate for different branches which might have more or less room.

    List Boxes or Multi-Column Listboxes are next. Given an array of paths and a reference to the control, and a column number (if MCLB) read the available column width, then convert and truncate the strings and populate the rows of the control. For a real bonus you could detect a mouse up event on the listbox, then check if the user resized a column and if so, rerun the truncation VI.

    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

  16. Guess you didn't open the XControl?

    Don't worry I almost finished the item, only I think in placing it in the Code Repository

    Ton

    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

  17. 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

  18. Very nice!

    Personally I would prefer if the filename was prepended with a backshlash so it's clear to the user that he is seeing the complete filename.

    e.g. C:\Program Files\Natio...\labview.exe

    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

  19. 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

  20. 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

  21. 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

  22. 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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.