James N

I was able to run .m scripts in the Matlab enviroment from ActiveX controls in LabVIEW. The one application I worked one with Matlab had me saving some data to a file, then runing an .m script to process the data file. My application was simple since this VI was the only direct interaction between Matlab and LabVIEW. http://forums.lavag.org/index.php?act=attach&type=post&id=6685 -James

Here's the steps I've done to get around this: 1. Right click on the top-level directory of your working copy (directories on your hard drive under source code control) and select TortoiseSNV>Export. This will copy all files (minus the .svn directories) to another location. 2. Run the LV mass compile on this new directory of files. 3. Once the mass compile is complete, copy the top-level directory over top of the working copy directory. This works in Windows since only modified or new files are copied. Any existing files in the directory (in this case the .svn directories) are left unchanged. 4. Commit your working copy to the repository. -James

Search the Help>Find Examples in LabVIEW. Check under "Hardware Input and Output". Look for an example like "Gen Dig Pulse Train-Continuous.vi" There plenty of examples that do almost exactly what you're looking for.. if not exactly! -James FYI: "LAVA > Resources > Bug Lists > LabVIEW 8 Buglist" was probably not the right forum for this question..

I don't know if it will work without the config VI. Good possibility though. I'll give it a shot in the next couple days as I bring up the next tester.. I take that back.. all the new stuff is equiped with USB only. A coworker wrote an VI for networked printers also, btw. -James

QUOTE(crelf @ Apr 5 2007, 10:36 AM) Yeah, This is how I do it too. I use it for postscript files. I include a little more error hanlding but this is basically it. http://forums.lavag.org/index.php?act=attach&type=post&id=5420''>http://forums.lavag.org/index.php?act=attach&type=post&id=5420'>http://forums.lavag.org/index.php?act=attach&type=post&id=5420 I have a DLL that works via USB. -James

I don't think there's any performance pitfalls with using the key down event. Just be sure to handle what you really want to handle inside the event. http://forums.lavag.org/index.php?act=attach&type=post&id=5411 -James

Sounds like you have two DAQ Assistant nodes, each configured to read a different channel. Yeah, you'll have problems. You need to configure both AI channels in one DAQ Assistant, unless you need different configurations (sampling rate, triggering, etc), then you'll need to work with the DAQmx VIs. -James

QUOTE(pockey @ Mar 22 2007, 10:27 PM) I think this relates. Something I overheard one time but didn't get the full details of.. If LabVIEW crashes, it leaves temporary files in your temp directory which are sometimes left if an odd condition. The next time LabVIEW tries to reuse these temp files, errors ensue. So it's a good idea to delete temporary files in this directory.. which files specifically is part of the "details" I missed. I've done about zero research on my own.... but what does anyone know about this? -James

Check out the example of how to use annotations on a graph. C:\Program Files\National Instruments\LabVIEW 8.2\examples\general\graphs\Programmatically Annotate a Graph.vi I thought this was pretty cool when I first learned of it. -James

I try to take care that each working copy of the souce code on different machines have the same directory structure. I've set the SVN repository directory structure up to be similar to the working copy directory. That way when checking out the source code, you can use the SVN directory structure as a guide for your hard drive. I cannot seem to stress this to my users enough, make your VIs READ-ONLY after checking out (or updating) from the repository. Along with this, be sure to set your LabVIEW Options. This way LabVIEW won't ask you to save uncessary changes.. such as some absolute path requirements. If you need to modify a READ-ONLY VI, do the Ctrl-M trick... of course when you save the VI you'll need to uncheck the READ-ONLY property. A little bit of a hassle but helps ensure that you don't make unwanted changes. -James

Tomi, I've always had problems with this as well. Luckily all were in-house created DLLs and I could ask the programmer to not use a structure. So you're saying create a cluster like in the picture and pass this into the Call Library Function? ..with the input type as Adapt to Type. I assume cluster order is important too. -James

I'm in the same boat Chris. My PO was just denied.... heartless penny pinchers. Don't they know how much more productive.. and envied I'd be!?

I've seen the exact same error or very similar just recently. We built some VIs to work with Excel though ActiveX. I think it was Excel 95 when the software was written. Now with Excel 2002, the source code would run fine but it could not compile due to "The VI is not executable" message. What it turned out to be is that Excel 95 uses a function named "Value" where Excel 2002 uses "Value2". The source code runs fine but during the .exe build LabVIEW must go back and throughly double check the ActiveX links and available functions and flagged this one as bad. You can see the VI is executable but the choice "Value" does not exist in the list of available functions. Selecting "Value2" would allow the code to compile. This probably doesn't pertain unless you're using ActiveX. -James

A coworker of mine had a similar problem of not knowing which "ID number" a USB device decided to pick when connected. Since he had only one device in the test system, at launch he would loop through the possible ID numbers and send a specific command to each one. Which ever ID returned a valid response had to be the correct one. Not pretty but got the job done. -James

Have you ever felt little unsure about deploying your latest software build? I found this readme.txt for the newest release of some software I had once thought about using. Here's an excerpt from the readme.txt. I cut out the vendor name to protect the.. innocent? I might start using this... -James ________ DISCLAIMER: This version of the software is very new, has not undergone significant testing, and may in fact contain serious bugs. "We" makes ABSOLUTELY NO CLAIM to the suitability of this software for any use, whatsoever, and in fact, we DO NOT RECOMMEND that anyone install it on any system. We will not accept ANY RESPONSIBILITY for any damages or losses you might encounter as a result of attempting to use this software. WHO SHOULD INSTALL THIS UPGRADE: Practically nobody. If you don't have an existing plug and play issue with the old software, then there is absolutely no reason to risk installing this software. WHO SHOULD NOT INSTALL THIS UPGRADE: If you are not experiencing a critical problem with the old software, we recommend that you do not install this upgrade. ____________

Check your MAX to ensure NI-VISA is installed. It pretty much needs to show up in MAX as a Serial & Parallel device. For a deployed executables, check out: http://digital.ni.com/softlib.nsf/websearc...625709F005BAB77 -James

Search for "annotation" in the LabVIEW Help->Find Examples : Programmatically Annotate a Graph.vi I don't think this feature is available before LV 8.0. -James

I'm using Subversion 1.3.2 on a Windows XP Pro machine. I see the newest release is 1.4.2. The newer version has a few good features, reduced disk space usage for one. It appears you have to "recreate" your repository to get this benifit. I know there's some kind of dump and reload function, but I haven't looked that far yet. There's also notes about the client's computer's working copy be automatically updated. Has anyone gone through the process of upgrading Subversion? Not necessarily to this latest version but in general what should I look out for? Thanks, James

Take a look at the Defer Front Panel Update property. See iif this can help you. You can use this along with Mike Ashe's idea to only update the front panel every Nth iteration.

How about putting a transparent control behind everything which spans the whole Xcontrol facade. That control can then fire a mouse enter event. Is that kind of what you're looking for? -James

alnaimi, You are talking about a Keithley PCI card, right? I've used the KPCI-PIO96 before. You'll need to install the DriverLINX software from Keithley. I believe this should have come with your hardware or a free download. The VIs are very similar to the NI DAQ VIs. Follow these links for some clues.. http://www.keithley.com/products/software/...are/?mn=LABVIEW http://www.keithley.com/products/software/.../?mn=DRIVERLINX http://www.keithley.com/products/dataacqmo...s/?mn=KPCI-3101 -James

Ton, I'm not sure TortioseSVN is recognized by LabVIEW. Under Tools->Source Control->Configure Source Control, I have no choices for Source Control Provider Name. All of the options are disabled. ..and I'm also not too keen on endangering my setup. Sorry, James

Terrible scenario, Ton. You've got to be able to work off-line. I'm using Subversion for SCC, but I DO NOT tie it into the LabVIEW SCC funtion. I do all of the Subversion check-in/check-out outside of LabVIEW with the TortioseSVN API. I'm sure VSS can work the same. -James

I would recommend using the encoder input as your sample clock for the AI. So for each encoder pulse, you get an analog reading. Go to the Help->Find Example and search for "sample" or "sampling". Poke around there for some examples of how to configure the sample clock. -James

Yeah, I agree. Don't try to tie TortoiseSVN or Subversion into the LV Source Control option. Once you get the hang of manipulating files (.vi, .doc, .xls, .whatever), you'll start to consider putting all kinds of stuff under "revision" control. Somewhat unrelated topic, but I'm running Subversion and Apache on a Windows XP machine and am thinking of using the Windows Scheduler app to run a backup (hotcopy) routine each week, then dump that to a network drive which gets maintained by corporate IT. Anyone thought of other good ways to keep your repositories backed up? -James