Jump to content

James N

Members
  • Posts

    59
  • Joined

  • Last visited

Posts posted by James N

  1. I've lost access to a couple functions in the Configuration File VIs between LV8.6 and LV2009...

    In 8.6 we use "Config Data Get File Path.vi" to return the configuration file path from the config file refnum. This VI no longer exists and the equivalent VI in LV2009 is "private" in an lvlib, so I can't use it.

    Same goes for "Config Data Write To File.vi", which we use to write data to the file on the disk without closing the config file refnum.

    It can be worked around but it's not elegant... grumble grumble..

    -James

  2. QUOTE (Ton @ Sep 16 2008, 11:37 PM)

    You can set SVN to name the folders _svn which are ignored by LabVIEW.

    Is this true with any underscore directory name? We've started using the directory name "_Core" for some common files. Would this directory be ignored with a mass compile? And I suppose it would not automatically show up in the palettes either, right?

    Are there any other LabVIEW idiosyncrasies with "_" directories?

    -James

  3. QUOTE (JFM @ Aug 28 2008, 01:30 AM)

    I second that. The main reason for this is that I like to manage error dialogs my self.

    /J

    I will third that.

    For example, we have a standard VI that creates a directory. The auto error handler will post an error if the directory already exists... well... OK. That's what I wanted.. a directory there. If it's already there, then good!

    As I type this I realize that if I know an error routinely happens, I should avoid it. I should probably check if the directory exists first. So maybe the auto error will point out places that I should correct.. like jdunham does.

    Thanks a lot.. now I feel compeled to turn on the automatic error handling...

    -James

    [edit]

    I just check the VI that initializes paths. I do check if the directory already exists. Sometimes I'm good and don't even know it. :)

  4. QUOTE (crelf @ Aug 14 2008, 03:56 PM)

    Not that I'm sure that this is what you're insinuating, but for the record: neither I nor my employer is in cahoots with JKI. We certainly do have an interest that VIPM is top-notch, but that's because we depend on it to help us achieve LabVIEW development environment configuration management.

    I was just ribbing you. I'm would never mean to suggest any unethical business practices are occuring. Please don't take it that way.

    I agree, if someone produces a great product or does a great job, by all means, praise that effort publicly.

    I was just looking for ideas from those who haven't mastered the chainsaw, but are still plugging away with axes.

    -James

  5. QUOTE (crelf @ Aug 14 2008, 11:28 AM)

    Thanks for the plug on this, crelf!

    No thanks needed - it's a great product and I wouldn't plug it if I didn't beleive that.

    I guess these's something to this thing call VIPM... hmmm. I suppose we'll have to break down and take a look at it sometime. :shifty:

    Yeah, I kinda figured VIPM would be one of the responses to my question. As it should be.

    Anybody else not in cahoots with JKI?

    -James

  6. Our department uses Subversion and TortoiseSVN with about 10 developers. Love it! I would use it if I were alone on a deserted island (aside from the inherent technical challenges on a deserted island).

    Another Side Topic (if I may):

    How do people handle LabVIEW versions in their SCC? I don't think this has been discussed here.. I didn't read every post completely.

    I'm primarily talking about the migrating a Reuse Library to newer versions of LabVIEW while minimizing the affect to older LabVIEW code which must be maintained and/or is still being developed.

    I don't really think I want multiple directories in my repository, such as "LabVIEW8.2", "LabVIEW8.5", etc., branching the library with each new LabVIEW version. I know there's no reason to mass compile a library just for the sake of mass compiling it, but as new VIs are added or older VIs are modified and saved in newer versions of LabVIEW.. this will affect down-level users.

    Thoughts..

    -James

  7. With the Vision Acquisition Software installed, you should just be able to plug in the camera (and power of course) and the system should recognize the camera. It may take a few seconds. You should then be able to launch Measurement & Automation Explorer and see the camera under Devices and Interfaces.

    Here's a great resource for GigE http://zone.ni.com/devzone/cda/tut/p/id/5651

    Also, never over look the examples.

    Launch LabVIEW and click Help>Find Examples. Browse "Hardware Input and Output>IMAQdx"

    There may also be some issue with your network card.

    The camera documentation should detail any special needs for setting up the network card.

    -James

  8. You can right click on the graph and select Data Operations > Make Current Value Default. Then save the VI.

    This will also save any data stored in the graph. So you may want to select Data Operations > Clear Graph first.

    -James

  9. We had a similar problem working with braches early on.

    Our repo is structured like so:

    ../svn/scc/ProjectFiles/Project_xyz/Trunk/

    ../svn/scc/ProjectFiles/Project_xyz/Branches/

    The working copy on our hard drives looks like

    ..\ProjectFiles\Project_xyz - Pointing to code from the /trunk or /brach directory on the repo.

    Do not include \trunk or \branch in this path! This got us the first few times too. LabVIEW VIs know the absolute path to subVIs. If you change the absolute path to any subVIs, things can't be found. As you know.

    It's also important that any one else co-developing software keep the exact same directory structure on their hard drive.

    We do not have the \trunk revision and the \branch revision checked out on the same computer. You work with one -or- the other at any given time.

    -James

  10. Thanks for the advice guys.

    I just need to download a couple applications and test them out.

    Probably between Norton Ghost, Acronis True Image and SelfImage

    I think I've convinced everyone in my department that disk imagining software is a good investment on any new system. Just snap an image before we send the tester out the door.

    -James

  11. I'm looking for a good disk imaging software that I can use to back up several (about 10) test stations.

    Some of these station are 6 yrs old running LV6 code, old hardware drivers, etc. It would near impossible.. scratch that, impossible to rebuild the system if the hard drive crashed. Of course, sometimes I pray for catastrophic failures that would force us to revamp the system but I don't want to be the guy doing it.

    There's $ tools like Norton's Ghost, Acronis True Image, Active@ Disk Image.

    Freeware like SelfImage, DriveImage XML.. .and dozens more no doubt.

    I couldn't quickly figure out if all the $ tools require a license for each computer or if the tools allows backing up many computers for the one purchase price.

    We probably need to start creating disk images of brand new systems too. This would be easier to absorb into the cost of the new tester.. but getting approval to spend $10k on old lab equipment is tougher so I want to make a good choice.

    It would be MUCH easier to justify the $10k after just 1 computer crashed...

    Thanks for any advice,

    James

  12. QUOTE (Tim_S @ May 21 2008, 04:04 PM)

    Our local NI field support has copies of everything NI has put out since... well, I think they showed me a copy of LabVIEW 2. The Field Engineers are pretty good about handing out older versions of licenses of software you've purchased.

    That's always been my take... if you have a license for a certain version of LabVIEW, you can legally install any lower version(s). How many people with the Service Agreement would be dead if they couldn't run LV7.1?

    -James

  13. QUOTE (Michael_Aivaliotis @ May 13 2008, 01:36 PM)

    People, a hand full of turd balls does not translate to a full blown user interface with real time graphing, reporting and data analysis application. Unless of course you're a mystical fairy who shoots pixie dust out of your a** when you fly.

    That quote's going up on my door right now! Perfect.

    -James

  14. Hello Louis,

    We've used a couple dozen Symbol LS9100. They've held up pretty well in a clean-room manufacturing enviroment. I don't know who actually spec'd that paticular one or why.

    I would fully recommend a "keyboard wedge" type. It behaves as if you typed in the barcode from the keyboard.

    http://www.taltech.com/products/interface.htm

    Part of this article states:

    Also, if you need to modify the data in any way before it goes into the application program running in the PC, you cannot do this.

    Which is completely false if your the one writing the application program.

    I'm sure all models let you configure various aspects, such as appending a carriage return after the scan. Which is handy to automatically start a test.

    -James

  15. I have no advice, only consolation.

    I had two PCI-1409 boards in a computer with 8 cameras. All 8 are wired into one custom power supply box that should supply enough current for all 8.

    At some point I started getting similar problems. "Unrecognizable video source" or some such message from my software and MAX. After a few days of testing station "warm-up" time, I figured out that I needed to turn on the power supply at least 15 minutes before trying to acquire an image.

    ... about midway though the life of this equipment, I did upgrade the IMAQ software.. I don't think that had anything to do with it though..

    I had no problem with a 30 minute warm-up period, so a label on the power supply stated this requirement.

    Like I said.. no advice.. only consolation.

    Good luck,

    James

×
×
  • Create New...

Important Information

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