Neville D

Dear Ayumi, I don't know what platform you are using, but if its PC running Windows, then forget about deterministic nanosecond timing response. If you use LabVIEW-RT on a PC or PXI target you should be able to get loop rates of the order of the high kHz or even a MHz. The fastest and most reliable platform would be the compact-RIO running LV-RT on a FPGA. Note that writing to file, or displaying data in plots would affect loop speed as well. Best way to do timing tests is to repeat the test about 10,000 times or something like that and then calculate and display (or save to file) the average speed. See the NI site for some rough timing comparisons. Neville.

Hi Srik, No offense, but why don't you implement a pure LabVIEW solution? That should take care of all the headaches . LabVIEW has a rich set of array functions, if that is what you need.. Neville.

Hi Michael, There is a tool on the OpenG website that renames a bunch of VI's. Here is a version written by David Moore. Do the following: 1 Place the rename.llb in your LabVIEW/Projects folder. This way the "rename" function will appear in your Tools menubar. You might have to restart LabVIEW to make it appear.. 2 Open the top-level VI (this is very important!) 2 Start the "Rename Main" from the Tools menu, and give it the suffix or prefix you want to rename the project with, and let it rip. Be sure to try it out on a small dummy project first! Backup a copy of the project before you try it as well, just in case the renaming screws up all the links. Another approach is to open the top-level VI and Save with Options>Development Distribution This will save all the VI's used in a separate location, and then you can build your plug-in from there.. (I am not exactly sure I understood what you are trying to do). Enjoy! Neville. Download File:post-2680-1124988945.llb

There are a number of ways: 1 Set up a Q, and write data in one VI and read a Q element from the other VI. 2 Use a Notifier. When you have data, notify it to the other VI. With notifiers there is no caching of data (like a Q) so if you don't listen when its sent, it will be missed. 3 Use a Global between the two VI's. Neville.

Here is a link to Scott's site: Check out the Serial Terminal VI's. He does not have a Q architecture in them, but there are a lot of examples in LV that you can take a look at. http://hannahsmac.magnet.fsu.edu/labview/vi_library.html Neville.

You could continuously read the input and discard data that doesn't fall within your criteria (200mV or whatever). Neville.

I don't think you can program serial communication that way yet.. but look at Scott Hannah's Serial Server which is freeware. It will give you an idea of how to configure serial comm. Basically, trigger off of "Bytes at Serial Port" being non-zero. If it is, then read serial, else loop back. Put serial reads/writes in their own parallel fast loops (10ms or less loop time), and the UI (display, parsing etc). in a slower parallel loop. Pass data between the two with Q's. When data is read by the serial loop, throw it on a Q, and then the UI slow loop reads Q elems, and parses them, at leisure. Neville.

Ayumi, the 6220 is an M-series device.. one of the newer ones released at the time DAQmx was introduced. It will not work with LV 6.1. Neville

Hi Ayumi, DAQmx was released starting with LV 7.0. Older hardware will work with the old-style DAQ as well as DAQmx. Newer hardware will ONLY work with DAQmx. You should check your hardware, and if it is newer, then it may not work with LV 6.1 Newer versions of LV will continue to support the older style DAQ as well, so as not to break your old projects. A good way to know if your particular device is supported in LV 6.1 (old style DAQ) is to: open NI-MAX>Devices & Interfaces>DAQ & see if your card shows up there. Do a "refresh" (F5) just to make sure. If you don't see it there, then it is a newer device supported only by DAQmx. Neville.

Hi everyone, anybody know when LV 8 is coming out? I would have thought it would be released at NIweek? Neville.

I am not sure why you want to open a word file to display in LabVIEW. What is easier is to save the information as a text file (with extension *.txt) and then just read in the text with the read file VI's. No need for complicated ActiveX calls. Display it as you wish after that. Neville.

Yes, look up dynamic event handling in the user manuals. You can put all event handling into a subVI. Neville.

No problem. Somewhere in the LV documentation there is a page showing all the operators allowed for the formula node & expression node. N.

Use the DAQ assistant in the DAQmx pallete, answer all the questions in the pop up menus. Then right click on the generated express VI, open it up (convert to VI) and look at how the VIs are set up inside.. use that as an example to write your own code. It is difficult to find one-to-one correspondence for all the various combinations of DAQ processes, AI, AO, DIO, Counters/Timers, Triggering etc etc. without knowing any specifics about your application. It will take a while to convert to DAQmx, but it is worth it. Neville.

Try x**y (where y is the exponent). Neville.

Two tips: 1 To make more space on the block diagram press Ctrl and drag. 2 For icon editing, you can drag a picture file or another VI's icon over (with the arrow tool) and automatically update the icon picture. Enjoy! Neville.

I am not sure, but you may not be able to call a VI from an executable. Just build your plugin VIs into an exe as well, and then try it. It should be an easy test. Neville.

Say your plugins are in plugin.exe, and the vi is First.vi. Specify absolute path as C:\plugins.exe\First.vi. Don't forget that the path is now *.exe not *.llb as before. Hope this helps. Neville.

Maybe you don't have the required Hardware installed in your PC? DAQmx can be very sticky about configuring channels that don't physically exist. You might play around with listing virtual chans (by simulating the hardware in NI-MAX). Neville.

I am not sure why you have separate AO VI's. Why don't you combine all the AO's on Device1 and all the AO's of Device2 on a single AO output Multiptle Chans Single Sample? As far as I remember, writing vals to the AO uses the onboard FIFO of the DAQ card. Using the 2 DAQ chans, but still having only one physical FIFO means some magic has to be performed at the driver level. You might want to clean up the locals in your while loop as well. They seem unnecessary & might cause race conditions (they also make extra copies of the data). Wire the controls and indicators directly. Neville.

FYI, if you go to the Installer settings Tab of the App builder, it allows you to add components of the LV Runtime Engine to your installer. Then once the whole installer has been built (with your selected components of the LV RTE), you install your app on a new machine. This installs the RTE, puts your executable in the folder you specify in the build etc etc. Very professional! I don't see the confusion.. Obviously LV needs the RTE to display the buttons etc (at the most basic level), and these are all added to your target machine at install time. Easy as Pie! Neville.

You don't need to create a dll. What I meant was you can make an executable out of your file read code which could then be installed on any other machine. (You don't need the whole LV install to run it). It is fairly straightforward, and can be achieved in a few mouse clicks. I don't know what LV package you have but you would need the Application Builder (to be able to build an executable). This is not part of the LV Base or Full Development System, but could be purchased separately. It is part of the Professional Development System As to the datalog file format, that will never be documented, because then it becomes difficult for NI to make changes. Again, the idea is ease of use. It would be like documenting the C code behind LabVIEW. We don't need to know, and we don't really care either. All we users care about is that the datalog files be readable between LV versions, and if not, then document the workaround to make that happen. Hope this helps. Neville.

Search the examples under graph. They used to have a similar example for the older versions that didn't use the event structure. Neville.

You could probably hack through the formatting and figure it out, and then spend a few hours writing the C code. But WHY would you bother?? Just write an LV program, build an exe and hand it to your C-user. It will make everyone's life a lot easier. The idea behind the datalog files is to make them easy to read and write to using LabVIEW. If you need to interface with other code, you are better off defining a reasonable format and then writing the files as tab-delimited ASCII text (as a first start) or binary (if you have storage space constraints). Yes, you hit the nail on the head. The file format can (and most probably will) change between different versions of labview. Newer versions will be able to read files created with older versions, and if there is a change, there will be NI documentation to support it. Hope this helps Neville.

I think binary files would be a better way to go. The files are anyway NOT human readable (if you can't open them up!!). This will make your files much smaller and your database easier to handle. If there is any specific info that you absolutely must be able to have human-readable, just throw that in the file name. For example: Coil_01_2004_08_03_1_30_pm_First_Run.bin It will be a bit of work to write the acquisition and file-read VI's, but once debugged, you don't have to mess with them again. Look at the binary data acquisition VI's as well for ideas. You could break up the number of records in a single file, have individual databases by month or year to limit the size of your database. Alternately, you could have a summary of the data go to a database, i.e., max/min/median thickness for the day or something like that. Face it, 99.99% of the time, nobody is going to look at the reams of raw data. I used to work in the Fuel-Cell industry where they had a mania for maintaining raw data (2Gigs per day). I found in a year's time, NOBODY bothered with looking at it! They were only interested in anomalies (deviations from the norm). That might help you to think about what is important to look for and only store that bit of the information, rather than reams of raw data. Cheers, Neville.