Chris Davis

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)

I'm unsure how to read the value back into the controls - the outputs of the read VIs are variant data. I can read one key at a time, but that would take 50 or 60 key reads!

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)

They plan on deploying their labview application to the client once complete. I assume the user needs to install a client similar to java's virtual machine. So their customer can run the application. Is this correct?

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

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

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

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

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

Or you like to broadcast your office conversation?

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)

Good question. I hadn't thought about that. People is free to use the code, modify it as they please and redistribute it, provided they respect original authorship and their versions retain the same conditions. Is there any of the usually acepted licenses that accomplishes that?

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

Or someone knows how and if it's possible to know the path from which I'm installing and the one in which I'm putting the files?

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

Is there a question here? I wish you all the best with this project, but I don't see a question...

QUOTE(Aristos Queue @ Feb 15 2007, 01:18 AM)

One customer in the crowd had mentioned his complete test harness for his hardware was in a single VI which took up nine screens (arranged 3x3, not nine in a line scrolling left to right) and he argued that this was better because he had everything right there in front of him with no jumping around to different files every time he needed to look at a different part of the structure. It was during this exchange that he casually mentioned having 90+ controls on the front panel that displayed the status of his test harness as it ran.

To a mechanical engineer this might be akin to machining a bridge out of a single piece of metal. Sure, it could be done, but what if one of the bridge supports breaks, you'd have to start all over.

This could be an interesting discussion... I am a computer scientist by degree, not who you usually find using labview in the field. I also work for an engineering firm, that has me doing, computer software for engineers / scientists to use. I've worked with engineer groups who do nothing but code, and I work with several CS majors who do mostly DAQ coding. In general the engineering groups who program think of thier code as a means to an end, and they get caught up in feature creep issues, and lack the knowledge and desire to impliment ideas that are typically taught as part of a CS curriculum. I must admit that I don't impliment all the CS ideas they taught me in college, but over the last 7 years I have at least learned why they taught them.

Another suggestion might be to use the caption property of your control as a method to display where the call was made from. Not easy either, but it might be the quick fix you are looking for.