Chris Davis

If all you are trying to do is print a text file out, you could use notepad. Just call notepad with a /p option at the command line. notepad.exe /p "c:\logfile.txt"

What you are seeing is the fact that your plugin VI's can't find the vi.lib files it needs to execute. You'll have to package your plugin's as LLB files using either the OpenG Builder (what I reccommend, particularly since you will probably need "name mangeling") or the NI application builder. Basically an EXE doesn't have access to vi.lib, and the application builder only includes the vi.lib files your exe needs to run. BTW, when you build your plugins, either in the OpenG builder, or with the NI Application Builder, you will have uncheck the option to exclude vi.lib files, user.lib files, and (possibly) instr.lib files. There has been discussion on this topic elsewhere on LAVA before, but I can't find it right now.

QUOTE(Thang Nguyen @ Mar 20 2007, 09:20 AM) Sorry I can't help you much more, we've stepped outside my area of expertise. You should be able to ask an electrical engineer, who would be able to help you out with the circuit design and connections needed to turn current into voltage. As for DC to DC converters, look at http://www.digikey.com' target="_blank">DigiKey, they have a ton of them, and can help you pick one out to fit your exact needs. Sorry I can't be of more help. Chris

QUOTE(AnalogKid2DigitalMan @ Mar 21 2007, 08:51 AM) Some of Max's test panels were written in LV 7.1, thus the need for the 7.1 RTE. I suspect that something else in Max may have been written in 8.0, thus the need for that RTE.

The AI-110 is a good module for high resolution, slow speed (1 per second at best) analog input measurements. Its manual has instructions on how to set it up to read typical industrial contol currents. I don't think that is what you want here though. If you want to measure high currents, which my be present in your battery system, you'll have to convert your current to voltage using a known value of resistor (I think). I can't tell you what resistor, it will depend on the maximum amount of current you expect to measure...

QUOTE(BrokenArrow @ Mar 19 2007, 10:15 AM) Use the primitive "Variant to Data" and wire your cluster into the type input. You'll get your cluster out with values filled in from your INI file on the output side.

I can't give you much info on SignalExpress, I have never used it, I've just heard of it, and seen demos. As far as hardware, NI makes a broad range of analog input / digital io hardware ranging from $160 to $3600. The cable/terminal block link you have in your post only provides you with a nice way to connect your signals to your NI board, if it is a PCI/PCIe board. You have to buy a board to connect those terminal blocks too. It sounds like you are trying to feel out what LabView can do for you, and so your best bet may be to try it out... Contact a local sales representative to discuss hardware to your hearts content. BTW, you may want to look at purchasing a student copy of LabView before you graduate, there are great discounts for students, in fact you can get a usb daq board with LabView Student Edition included.

I read this post and your other one, and I thought I would try to answer some of your questions... QUOTE(leblanc @ Mar 14 2007, 03:27 PM) Your question seems to be, "Does LabView require a run-time install?". The answer is yes. No different from any of the other higher level computer languages out there. QUOTE So does this mean the customer needs to buy the same daq equipment used by the development team? won't that be expensive, because only high end boards seem to be the only ones advertised with SignalExpress and Measurement Studio for Visual Studio .NET, or is it possible to buy a cheap terminal block and still use vs.net? If this "team" is developing a piece of labview code that will interface to some hardware, then yes, any deployment, large or small scale will need to have that hardware as well. As for SignalExpress and / or Measurement Studio for VS.NET, they are two different products, designed for different users. Measurement Studio is designed to provide the VS.NET programmer an easier way to interface with the wide range of National Instruments hardware. SignalExpress is designed to help non-programmers interface to data acquisition devices and perform tasks. QUOTE I always pictured labview as a test/development platform and never a production line item. The only place I can see this beneficial is in a large control system where it will greatly reduce the # of custom controls that need to be created in c# or qt. But most control systems i've seen are developed inhouse and not sold to a mass market. So is their solution viable for mass production? Its hard to determine what you are really asking here, since the sentences don't make much sense to me. I use LabView for just about everything I do, from automating my source code control's (subversion) backups, to high level image processing, to taking 10 megasample / second data displaying it to the user and allowing him to analysize it anyway he can think of. Controls that represent real-world type items, such as knobs, dials, tanks, and switches are just one of LabView's features. Is this "team's" solution viable for the mass market, I would say that it depends the market, and what it is willing to bear. I've seen presentations featuring Labview's ability to run a DARPA unmanned vehicle race, provide feedback from oil well's in remote locations, and power a LEGO robot to react like a scorpion. QUOTE From my experience I've used serial or com port to interface hardware with a pc. My senior project interfaces hardware with usb using a usb to uart bridge and c#. (my project is a transmission controller designed for gear heads that want to fully control shiftpoint of an automatic transmission. They use my gui to load/save user preferences and flash them to the controller.) In my application controls don't even exist for what i need. Example i created a graph where the user can drag the lines on the y axis to modify default operation. I'm guessing this is where Measurement Studio for Visual Studio .NET seems to fit in. I can create my custom controls and use labview's dll for data aquisitions - that would normally be received through serial/com/usb . Your project sounds interesting, if you are asking could it have been accomplished with LabView, the answer is probably yes. Your USB to UART / serial port bridge could be accessed using an API known as VISA. The GUI and all the code needed to successfully convey your information to the user could have been developed in LabView, and you could have recorded voltages and or current readings using a National Instruments daq device. QUOTE Anyone with any thoughts? List of successful projects that integrated labview in the real world. There are a lot of successful projects that have been done with LabView that integrate into the real world, NI has a http://www.ni.com/news/webreply3.htm' target="_blank">good instrumentation newsletter that has new ones each issue. Check them out, one from this month had to do with an underground "excevator" that was powered with a compactRIO that communicated with a computer via fiberoptics.

Read this tutorial on LabView graphs, go to this exercise in that tutorial to learn the ins and outs of zooming in graphs. If needed, read the whole tutorial, it is a good place to start to learn LabView.

I've read this post, and the others that you have posted about this problem and I'm still not seeing it. Could you post a screenshot of what you would like to be able to do?

Your question is to vauge, search the examples that ship with LabView, there are plenty of examples on how to use the event structure. If you've got a specific problem with the event structure, upload some code to show us what you've tried, and we can help you solve a specific problem.

QUOTE I think they broadcast for the benefit of the community. If they hadn't broadcast this question, they wouldn't have come up with this answer. Either way, thanks for this thread and its information. I'll be using this method in the near future with an 8.2 project. Guess I'll have to turn on the SuperPrivateSecret(Captain)Stuff to see this event.

Security is another benefit of inlining. Jim gives a good explanation here.

you can also check out this online basics 1 class.

For these kinds of errors, the first thing I reccomend is start looking for references that you aren't closing. If you have multiple writes to your database in your code, you could add them in one at a time to see which one causes the memory leak, that would help you figure out where to debug. Start probing references and make sure the reference number isn't changing each time the code is called, that indicates a new reference being made each time the code is called.

Back2Zip is one that I use. It has saved me on numerous occasions. If you don't like anything that people suggest, you could write your own in LabView!

could it have something to do with this post?

You won't be able to do this by writing to the origin. You'll have to write to the FP.WinBounds property. Check out my example.

QUOTE(Aitor Solar @ Feb 26 2007, 09:23 AM) I think that would be http://www.opensource.org/licenses/bsd-license.php' target="_blank">BSD liscensing. But take a look and decide for yourself.

Chris, I had heard of the VISTA documentation tools before now, and but I hadn't seen them in action. Thanks for posting an example. I'll have to explore this option to see if it provides me what I'm looking for. Jim, Thanks for sharing what JKI uses to document VIPM, I have to admit I was suprised that you use Doc-To-Help. My last experience with the product wasn't good, and I haven't gone back. But because I left them off the list, I didn't know that they would read things besides word documents as source material. I'll also have to take a closer look at it as an option to replace robodoc. Ars_Stowers Thanks for your option as well. I'm not against paying for something, especially if it does a good job! I'll have to explore HelpMaker as well, although I do need to be cross platform in some cases, and this product only appears to output windows compiled help files.

QUOTE Try looking in the file io pallette for a Current VI's path primitive. This will give you an absolute path to the VI that is running, which will hold the drive letter from which you are installing. As for which path you are installing to, you could pass that as a command line argument to your labview program from your installer program. P.S. Don't double post, its bad form.

I wanted to pose a question to the community, to get options for developing help files and users manuals for code that you distribute. I'd like to know, for example, how the VIPM team develops and maintains thier help manual that is delivered with VIPM. Its always been a problem for my group, and I want to know what others are doing. Software engineering documents/books and experience tells me that the help manual has to be developed and kept in close sync with the code itself. For text based languages there are many tools to accomplish this, doxygen, robodoc, and many others. These tools let you embed the developer documentation inside you code and flag the comments you want pulled out with a special comment marker. You can then automate the creation of the most current help files from the command line in a batch process, allowing you to deliver those manuals with your code. For LabView, the closest thing that exists is the printing functionality that NI provides. This works fine for smaller VI's and small projects, but I'm afraid I've had little success with this form of documentation as my project expands. To be clear, I'm asking two different questions here. How do members of the LAVA community develop users manuals for thier projects? and How do members of the LAVA community develop documentation for thier code so that other developers can understand that code and add to it? To be fair, I'll include what I'm doing now to create a users manual for one of our (beta) projects. It is in its infancy, but the pay off is already clear. I use robodoc to convert simple text files into HTML files that are delivered and accessed with my program. The advantages that we are experiencing right now are: 1. Members of the team don't have to know HTML to write documentation for thier code. They can learn a small subset (3 - 4 tags) and create good looking help files, as long as our text files follow the set of robodoc rules, that I've written. 2. Since we are writing simple text files, subversion has an easy time keeping track of any and all changes (subversion diff'ing is great here) 3. We automate the creation of the latest help files in our OpenG Builder prebuild VI. This ensures that we have the most current ** help files avaliable at the time of the build. 4. We also automate the creation of a NSIS build at the end of our OpenG Builder run, ensuring that the "setup.exe" file that is generated also has the most current documentation avaliable to the installer. **If someone knows how to do a subversion update from the command line on a know directory I would be appricative. I haven't had the time to look it up yet. I'm really interested in how groups handle developer documentation with LabView. But I would also love to hear from groups who are creating users manuals too.

I've been using the package creator for a while and haven't had any problems with it. Granted what I'm trying to do is not rocket science. In fact the package format, and the package creation utility and is open as well, if you have the time you can explore and / or expand the functionality. I believe Jim and crew are using it now to unit test all the VI's that go into the OpenG packages, amoung other things. Creating your own packages make the installation and configuration manageable through VIPM. Take another look if you get the time.

I can think of a couple of options... 1. Create what you want in the picture control... It would be labor intensive for anything but the simplest outputs, but you might end up with something that you could use in other places. 2. Think about setting up predefined templates and printing them as a temporary PDF file that you can display to the user. The downside is your template might get out of control, or your users will want the capability to add thier own templates which could get cumbersome. 3. The DIAdem toolkit mentioned above. If you stop and think about the manhours that could be involved in creating, debugging and adding features to the two options I've mentioned above, DIAdem's price starts to look small.

You might also want to check how much current your SSR's need to function, the counters the DIO ports don't provide much (~180 mA).